Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 947. (Read 2347664 times)

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)

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

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...  ).

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

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.

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.

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

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?

Thanks for the support.

is it something which is reproducible ?

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

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

sp_, beers for you:  f2ef0399741b3e1a01358bd126b5869492cd1985ecc65c5d13ef23fbc81e5888

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)

I told you. I use high default intensities. (the amount of work passed from gpumem to the gpu-core)

My builds use more memory and power.. you can easily avoid this by reducing the intensity levels yourself.

With the -i switch or the -X switch.

more performance = (in most cases) more power usage = more throttling

I am aware that my card is throttling as i mention i have a temp limit of 77C. My question is  why it throttles so much more on your build as compared to djm34's build? Its the amount of throttling & its frequency on your build that worries me. I sure want to get higher performance but stability as well.

My perfcap reason is mostly thermal limit that i have chosen & power. But i guess even if i allow power upto 110% it will throttle due to temp limit.

I guess i will stick with djm 0.4 until he releases next version.

@djm34 can you release a new version with latest optimizations?

Your card is trottle'ing. You can try to reduce the intensity. F.ex -X 16 My default intensities are high.

Start gpuz and check why your card is trottle'ing. there is a graph that explains it for you. The graph have different colors for different symptoms POW, or TMP etc. If you get Vop like I did here in this picture, you need to overclock the card.

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 :-)

970,980 user should use this build. I checked in a hashrate fix after build 67 was published

http://cryptomining-blog.com/5730-updated-windows-binary-of-the-ccminer-1-5-67-git-fork-by-sp-for-maxwell/