CCminer(SP-MOD) Modded GPU kernels.

[lawrencelyl]

sp_, beers for you:  f2ef0399741b3e1a01358bd126b5869492cd1985ecc65c5d13ef23fbc81e5888

[chrysophylax]

Here is from the DJM-34 code: default lyra2v2 intensites.

        unsigned int intensity = 256*256*8;
   intensity = (device_sm[device_map[thr_id]] == 500) ? 256 * 256 * 4 : intensity;


-X 8 on gtx ,950,960,970, 980,980ti
-X 4 on gtx 750,750ti

While in my modded lyra2v2 I use

-X 18 on 970,980,980ti
-X 16 on 750ti
-X 5 on 750
-x 16 on 960

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.

(My version is around 10% faster on the 750ti)

sp - would it be too difficult to setup a table of the default intensities for the various algorithms used by his fork? ...

that would help greatly with a LOT of the issues that are present ...

i can even set one up - but i would need to be updated regularly and consistently for any changes that will occur between updates ...

btw - donation links are ready - and will be published in the next couple of days ( when i get back to the office ) ... they test well with thefarm - but would like to test them with community support with mining - for donations ( if of course you want to donate that way ) ...

#crysx

[pallas]

Here is from the DJM-34 code: default lyra2v2 intensites.

        unsigned int intensity = 256*256*8;
   intensity = (device_sm[device_map[thr_id]] == 500) ? 256 * 256 * 4 : intensity;


-X 8 on gtx ,950,960,970, 980,980ti
-X 4 on gtx 750,750ti

While in my modded lyra2v2 I use

-X 18 on 970,980,980ti
-X 16 on 750ti
-X 5 on 750
-x 16 on 960

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.

(My version is around 10% faster on the 750ti)

sp - would it be too difficult to setup a table of the default intensities for the various algorithms used by his fork? ...

that would help greatly with a LOT of the issues that are present ...

i can even set one up - but i would need to be updated regularly and consistently for any changes that will occur between updates ...

btw - donation links are ready - and will be published in the next couple of days ( when i get back to the office ) ... they test well with thefarm - but would like to test them with community support with mining - for donations ( if of course you want to donate that way ) ...

#crysx

what about making a header file with a data structure containing all the default intensities?
and maybe other miner settings...

[theotherme]

Here is from the DJM-34 code: default lyra2v2 intensites.

        unsigned int intensity = 256*256*8;
   intensity = (device_sm[device_map[thr_id]] == 500) ? 256 * 256 * 4 : intensity;


-X 8 on gtx ,950,960,970, 980,980ti
-X 4 on gtx 750,750ti

While in my modded lyra2v2 I use

-X 18 on 970,980,980ti
-X 16 on 750ti
-X 5 on 750
-x 16 on 960

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.

(My version is around 10% faster on the 750ti)

is it something which is reproducible ?

[sp_]

sp_, beers for you:  f2ef0399741b3e1a01358bd126b5869492cd1985ecc65c5d13ef23fbc81e5888

Thanks for the support.

[sp_]

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.
(My version is around 10% faster on the 750ti)

is it something which is reproducible ?

try it:

ccminer -a lyra2v2 -u 1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd -o stratum+tcp://lyra2rev2.eu.nicehash.com:3347 -p x

overclock. Can you reach 5MHASH on the 750ti?

[sambiohazard]

Here is from the DJM-34 code: default lyra2v2 intensites.

        unsigned int intensity = 256*256*8;
   intensity = (device_sm[device_map[thr_id]] == 500) ? 256 * 256 * 4 : intensity;


-X 8 on gtx ,950,960,970, 980,980ti
-X 4 on gtx 750,750ti

While in my modded lyra2v2 I use

-X 18 on 970,980,980ti
-X 16 on 750ti
-X 5 on 750
-x 16 on 960

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.

(My version is around 10% faster on the 750ti)

Ok i will try that with your release. Thanks for your time & replies

[joblo]

I managed to reproduce the performance state bug and that's how I did it.
Since it only happened recently, I thought of what changes I did to the system.
The only one was: creating a xorg.conf for all the cards in order to be able to change the fan speeds using the cool_cpu2.sh script.
That means it starts an X server at boot, while it didn't before.
If you leave the X server running, no problems.
If you stop it by running "sudo service lightdm stop", the hashrate bug starts to happen after the following ccminer ctrl-c.
If you start lightdm again, THE ISSUES IS GONE, without the need to reboot :-)

Very interesting. If you didn't start an X server at boot I presume you were in run level 3 and possibly headless.
Your result suggests the presence of the X server has some effect on the problem. It doesn't explain all the
failure modes (ie it also happens on Windows and has happened to me with an X server running) but the
ability to reproduce it is a big step.

All of my Linux systems use run level 5 and therefore start X at boot. My experience with the degradation started
before I fudged xorg.cong to get coolbits on my second card, and it occurred on my primary card, ie the one with
the X server running. I don't recal if the problem predates me adding coolbits to my primary card. All this to say
that the degradation can also occur with an X server running.

I don't know how Nvidia manages card performance levels, whether the card's FW is responsible fo reacting
to load or whether the driver is supposed to tell it to change levels. Either way it's not happening in some
cases.

While in the degraded state my display still works normally and the card can still hash so I assume the card is
still sane and would probably hash at full speed if it switched to the higher performance level.

So the question is how are performance levels managed and why is the process failing.  I'm going to take a guess
that performance levels are based on non-cuda related card functions and that cuda applications can't or don't
affect performance levels directly. In the absence of another trigger to raise the performance level the cuda app
is left to run on a degraded gpu. Starting an X server may be such a trigger.

Is there a way that ccminer could set the pstate of the GPUs at launch? This would confirm whether the GPU is
responsive to pstate changes, and if successful is a good workaround for the problem. And it should work on
Windows and Linux.

It's lots of speculation about an architecture I know little about but maybe there is something usefuil here.

[sambiohazard]

Here is from the DJM-34 code: default lyra2v2 intensites.

        unsigned int intensity = 256*256*8;
   intensity = (device_sm[device_map[thr_id]] == 500) ? 256 * 256 * 4 : intensity;


-X 8 on gtx ,950,960,970, 980,980ti
-X 4 on gtx 750,750ti

While in my modded lyra2v2 I use

-X 18 on 970,980,980ti
-X 16 on 750ti
-X 5 on 750
-x 16 on 960

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.

(My version is around 10% faster on the 750ti)

sp - would it be too difficult to setup a table of the default intensities for the various algorithms used by his fork? ...

that would help greatly with a LOT of the issues that are present ...

i can even set one up - but i would need to be updated regularly and consistently for any changes that will occur between updates ...

btw - donation links are ready - and will be published in the next couple of days ( when i get back to the office ) ... they test well with thefarm - but would like to test them with community support with mining - for donations ( if of course you want to donate that way ) ...

#crysx

what about making a header file with a data structure containing all the default intensities?
and maybe other miner settings...

or miner can print what intensity its using when we start it so that for any given version it can be seen like

1 miner thread started with default intensity -i/X ??

@sp I tried djm intensities with your miner but can't reproduce the stability & hashrate. i guess its like launch config with cudaminer, you have to hit the sweet spot to get right result. I am too lazy to try lots of intensities so i will just use djm miner till its profitable.

[flipclip]

I managed to reproduce the performance state bug and that's how I did it.
Since it only happened recently, I thought of what changes I did to the system.
The only one was: creating a xorg.conf for all the cards in order to be able to change the fan speeds using the cool_cpu2.sh script.
That means it starts an X server at boot, while it didn't before.
If you leave the X server running, no problems.
If you stop it by running "sudo service lightdm stop", the hashrate bug starts to happen after the following ccminer ctrl-c.
If you start lightdm again, THE ISSUES IS GONE, without the need to reboot :-)

Is there a way that ccminer could set the pstate of the GPUs at launch?

Tpruvot's fork has pstate setting.  Only for drivers 352.21+, and Linux, Win64 though.

[djm34]

Here is from the DJM-34 code: default lyra2v2 intensites.

        unsigned int intensity = 256*256*8;
   intensity = (device_sm[device_map[thr_id]] == 500) ? 256 * 256 * 4 : intensity;


-X 8 on gtx ,950,960,970, 980,980ti
-X 4 on gtx 750,750ti

While in my modded lyra2v2 I use

-X 18 on 970,980,980ti
-X 16 on 750ti
-X 5 on 750
-x 16 on 960

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.

(My version is around 10% faster on the 750ti)

hmmm, my public version does 4.7MH/s overclocked at +150/+150 on my stock gainward, so I guess most of the other 750ti can get it to that level, without any effort (also the intensity can be adjusted...)
Slightly more can be obtained by increasing the throughput by a factor 2 (or the intensity by 1), using higher values isn't really usefull except for consuming more power for no real gain. (this a semi hard-mem algo and it is better to not get too high frame buffer rate (and that's what does a too high intensity... I mean it is like a bucket with the (small) hole at the bottom, there is no point in increasing water debit if the bucket is already  almost full with a smaller debit...  ).

[scryptr]

All systems have fresh Win 8.1 installations.
I am running the 355.60 Driver on all rigs and i am using the 61 build due to best performance for me with that one.

Can you try build 67 please.

Do you have a cudart32_65.dll in the ccminer folder?

Downgrading the driver could increase by 200-300KHASH per 750ti. (Hot tip )

Don't forget to donate guys.

TWO NICKLES...

I flipped both you and t-nelson a nickle.  The work fixing the "ctrl-c" exit, and the "cpu-mining" switch were both significant contributions.  The hash rate really went up on my 970s with the "cpu-mining" switch, frm 14.5Mh/s to 16.5 -17Mh/s.  My 750ti cards also do better.

Thank you!       --scryptr

[sp_]

Thanks

I removed some more instructions @github. (blake,bmw,lyra2,lyra2v2) Doesn't seem to have alot of effect. perhaps 5KHASH on the 750ti. (quark & lyra2)

[Strannik-74]

del =)

[chrysophylax]

Here is from the DJM-34 code: default lyra2v2 intensites.

        unsigned int intensity = 256*256*8;
   intensity = (device_sm[device_map[thr_id]] == 500) ? 256 * 256 * 4 : intensity;


-X 8 on gtx ,950,960,970, 980,980ti
-X 4 on gtx 750,750ti

While in my modded lyra2v2 I use

-X 18 on 970,980,980ti
-X 16 on 750ti
-X 5 on 750
-x 16 on 960

With my mod (sp-mod 67) lyra2v2 is doing 5 MHASH with overclocking. DJM34's is doing 4,5 with overclocking.

(My version is around 10% faster on the 750ti)

sp - would it be too difficult to setup a table of the default intensities for the various algorithms used by his fork? ...

that would help greatly with a LOT of the issues that are present ...

i can even set one up - but i would need to be updated regularly and consistently for any changes that will occur between updates ...

btw - donation links are ready - and will be published in the next couple of days ( when i get back to the office ) ... they test well with thefarm - but would like to test them with community support with mining - for donations ( if of course you want to donate that way ) ...

#crysx

what about making a header file with a data structure containing all the default intensities?
and maybe other miner settings...

that would be good - though i believe placing all the default intensities and settings would be more beneficial on the op - unless they change way too often ...

i just think that there is no where near enough information to users ( veteran and new miners alike ) to get the most out of the mining experience ... and the best hashrate ...

too high intensity - too low - just right - extra parameters on some algos ( like 'throughput' ) - common settings - etc ...

none of this exists ...

even as a veteran miner - i STILL dont understand 'throughput' or '0xblah' parameters in certain algos ... there is no documentation or direction ... we all just have to wing it - and hope for the best - AND ask questions here that would not have to be asked ( cluttering the input to the page - and announcements ( yes - im VERY guilty of that ) ) had there been the relevant info in the first place ...

i would be more than happy to compile such a list - and keep it updated - as long as i have ALL the relevant info at my beckon call ...

ONE resource - ONE place - ONE list ... copied all over the place - that EVERYONE can use to reference ...

ill even start a new thread for it today if that sounds like a good idea to everyone ...

btw pallas - will be responding to the pm today ... ive just been inundated unfortunately - and wont have much 'free' time ( pfft - as if ) till next week ... i really appreciate your ideas and input ...

#crysx

[t-nelson]

All systems have fresh Win 8.1 installations.
I am running the 355.60 Driver on all rigs and i am using the 61 build due to best performance for me with that one.

Can you try build 67 please.

Do you have a cudart32_65.dll in the ccminer folder?

Downgrading the driver could increase by 200-300KHASH per 750ti. (Hot tip )

Don't forget to donate guys.

TWO NICKLES...

I flipped both you and t-nelson a nickle.  The work fixing the "ctrl-c" exit, and the "cpu-mining" switch were both significant contributions.  The hash rate really went up on my 970s with the "cpu-mining" switch, frm 14.5Mh/s to 16.5 -17Mh/s.  My 750ti cards also do better.

Thank you!       --scryptr

Danke!

[qqqq]

When issue with solo mining will be fixed ? I mean crashing miner when block is found. http://cryptomining-blog.com/5730-updated-windows-binary-of-the-ccminer-1-5-67-git-fork-by-sp-for-maxwell/

66 release has the same problem also.

[serg_25]

Hi miners.
Can you please advice, for 750Ti card what is the best Nvidia driver version for linux x64?
in Ubuntu official repo stable is this one -  NVIDIA binary driver - version 340.76


P.S. as i understand from this thread, CUDA must be 6.5.

[theotherme]

Hi miners.
Can you please advice, for 750Ti card what is the best Nvidia driver version for linux x64?
in Ubuntu official repo stable is this one -  NVIDIA binary driver - version 340.76


P.S. as i understand from this thread, CUDA must be 6.5.

The easiest, is probably to keep the drivers which get installed when CUDA 6.5 gets installed.

[scryptr]

When issue with solo mining will be fixed ? I mean crashing miner when block is found. http://cryptomining-blog.com/5730-updated-windows-binary-of-the-ccminer-1-5-67-git-fork-by-sp-for-maxwell/

66 release has the same problem also.

IT DOES CRASH--

I suspected as much when I set it up to mine VTC solo.  The miner crashed 3-4 times, about the same frequency at which I should be finding blocks.  Each different rig crashed at least once.  The blocks never made their way to my wallet; I gave up in frustration.  It looked to be working properly.  I was using release dot 66.

--scryptr