CCminer(SP-MOD) Modded GPU kernels.

[pallas]

In the continuing story of cuda 6.5 vs cuda 7  I tried using the Fedora 20 version of cuda 6.5
on Fedora 22 but it didn't work. The problem is with the gnu compiler on f22. The cuda library
headers fail to compile producing lots of syntax errors. I gave up.

It looks like the best option for Linux users is to use an LTS release like Centos 6 to have a supported
OS that also supports cuda 6.5.

on ubuntu you can have more than one gcc version installed, I'm sure you can do the same on fedora.
that's what I do to compile with cuda 6.5 which requires gcc 4.7, while the system's default is 4.9

[joblo]

In the continuing story of cuda 6.5 vs cuda 7  I tried using the Fedora 20 version of cuda 6.5
on Fedora 22 but it didn't work. The problem is with the gnu compiler on f22. The cuda library
headers fail to compile producing lots of syntax errors. I gave up.

It looks like the best option for Linux users is to use an LTS release like Centos 6 to have a supported
OS that also supports cuda 6.5.

on ubuntu you can have more than one gcc version installed, I'm sure you can do the same on fedora.
that's what I do to compile with cuda 6.5 which requires gcc 4.7, while the system's default is 4.9

My only choices in the fedora repo are 4.9 and 5.1. I'ts not urgent for me as i can live with a stale
Fedora 20 for a while. Hopefully by then the cuda 7, 7.5 issues will be solved.

[joblo]

Just to be clear i wasn't expecting ccminer to do it, just lamenting the poor handling of the fault by nvidia.

That's not poorly handling a fault - now AMD... they know how to poorly handle a fault. Not only do cards have degraded hash after a driver crash, quite often I have seen the entire OpenCL portion of shit in the driver just refuse to service calls. I mean, SGMiner won't work, CodeXL can't compile OpenCL for analysis... the calls just hang. They will do this until reboot - the instance of SGMiner responsible for the driver crash simply hangs as well. And I mean HANGS - kill -9 does fuck all for it.

LOL. I guess I'm just used to more sophistiated fault handling that includes fault detection, identification,
isolation, mitigation, recovery, post-analysis and reporting. But then again I'm not talking about consumer
grade systems but a fully redundant mission critical (non military) control system. I need to reset my expectations.

[scryptr]

Yesterday I submitted a tiny speedup in x11. 2-5 KHASH on the 750ti. (simd) I think there are some more easy pickings here. might try to find them this weekend.

Don't take this the wrong way, sp_, as I think you do really good work - but you might want to establish a margin of error. I wouldn't be surprised if you reverted it later with a commit message saying it seems to have no effect - but it sure looked like it at 3AM after having been coding for 12h or so.

I've totally done that - and assuming that the max difference caused was 5Kh/s, and the usual 750Ti speed on X11 is 3Mh/s with your mods (do correct me if I'm mistaken; while I pay attention to the developments, the exact numbers I no longer watch as closely since I stopped working with CUDA myself), the percentage difference on that would be 0.000166%. My personal opinion on a VERY lax margin of error would probably be at least around 0.05% - 0.10%.

EVERY LITTLE BIT COUNTS--

The sum of many small changes will creep over the statistical barrier.       --scryptr

[djm34]

In the continuing story of cuda 6.5 vs cuda 7  I tried using the Fedora 20 version of cuda 6.5
on Fedora 22 but it didn't work. The problem is with the gnu compiler on f22. The cuda library
headers fail to compile producing lots of syntax errors. I gave up.

It looks like the best option for Linux users is to use an LTS release like Centos 6 to have a supported
OS that also supports cuda 6.5.

on ubuntu you can have more than one gcc version installed, I'm sure you can do the same on fedora.
that's what I do to compile with cuda 6.5 which requires gcc 4.7, while the system's default is 4.9

actually it is also possible to compile cuda with "--override" to use whatever gcc version there is on the system
(always had bad experience when trying to install different version of gcc)

[djm34]

Yesterday I submitted a tiny speedup in x11. 2-5 KHASH on the 750ti. (simd) I think there are some more easy pickings here. might try to find them this weekend.

Don't take this the wrong way, sp_, as I think you do really good work - but you might want to establish a margin of error. I wouldn't be surprised if you reverted it later with a commit message saying it seems to have no effect - but it sure looked like it at 3AM after having been coding for 12h or so.

I've totally done that - and assuming that the max difference caused was 5Kh/s, and the usual 750Ti speed on X11 is 3Mh/s with your mods (do correct me if I'm mistaken; while I pay attention to the developments, the exact numbers I no longer watch as closely since I stopped working with CUDA myself), the percentage difference on that would be 0.000166%. My personal opinion on a VERY lax margin of error would probably be at least around 0.05% - 0.10%.

+100%

[joblo]

RESTORING DRIVER--

I use PrecisionX 16 to restore the driver without rebooting the system.  These are my steps for a card on Windows that has low hash (crashed driver):

     1) Start or re-open PrecisionX 16.
     2) Turn off K-Boost with the toggle switch (upper right-and corner).
     3) Turn on K-Boost with the same toggle switch.
     4) Re-select the boost profile that you prefer (important!).
     5) Verify that the fan profile and boost settings are again in place, and that temperature is appropriate.
     6) Close or minimize PrecisionX 16.
     7) Restart miner, it should again have appropriate hash readings for boost/overclock settings.

You may also have to open nVidia control panel and reset the display resolution if your graphics now "look odd".  It isn't every time, but frequently I have to reset display resolution for normal graphics.   This is for my work computer, Win 7 X64, with a GTX 960 that I mine with when not playing games.  The GTX 960 will get 10.6Mh/s on Quark, but if it crashes with a segmentation fault, it will only get 3Mh/s on miner restart.  I then perform the steps above and restart the miner.

There is a memory leak somewhere, but I was suspecting poorly programmed flash-media websites, like my local news site.  I need to reboot about once a day because of increasing memory bloat.       --scryptr

I'm using an ancient ccminer so I'm not sure about the issue but it does sound like a simple soft crash to me when the card reverts back to lower P state with 405 Mhz. That is how my cards crash if I have too high OC on them or set too high intensity or accidentaly mine on the same card with 2 instances. Memory leak would imply a leak of some sort causing excess memory usage and/or slow performance degradation over time.

I hadn't checked the p state when my card degrades but I think you're right about that. I don't know anything about
a "soft crash". When I set too high intensity ccminer errors out with an out of memory error. When I start two instances
on the same card they each hash at lower rates but the card doesn't crash and never gets stuck in a degraded state. I have also seen
driver crashes due to too high OC where I lose the display for a few seconds. If the degradation is the result of some sort of soft crash
or exception why leave the gpu degraded? Why not reset automatically like it does for a hard crash? (rhetorical questions,
I don't expect an answer)

and how do you do that exactly ?

I have a different solution if the driver crashes and sets the gpu to some lower state. I just go into the device manager and disable the problematic gpu and re-enable it.
It restores the default gpu state. Then You just have to click the profile in the MSI afterburner and You have it back.

I had another degradation on my Fedora20/GTX970 mining neoscrypt and took some notes.

- The performance level was still at 2 and the GPU clock was still around 1500 (+120 OC)
- gpu utilization was 100%
- mem utilization 69%, normally 41% (of 4 GB)
- hash rate was 61K, normally 540K

This eliminates a memory leak, at least to the point of mem exhaustion.
The GPU was pegged but only hashing at 1/9 normal, interesting that it is
almost an exact multiple.

Was it only using 1/9 of the cuda cores? If so what were the other cores doing?
Maybe a runaway process, a crash seems unlikely.

Could there be a problem with the way cuda processes are killed when the host process
dies leaving an orphan still running?

nvidia-smi has a reset command and a process monitoring command but I'm not sure
if they work on lowly geforce cards. I'll try that next time.

[scryptr]

Yesterday I submitted a tiny speedup in x11. 2-5 KHASH on the 750ti. (simd) I think there are some more easy pickings here. might try to find them this weekend.

Don't take this the wrong way, sp_, as I think you do really good work - but you might want to establish a margin of error. I wouldn't be surprised if you reverted it later with a commit message saying it seems to have no effect - but it sure looked like it at 3AM after having been coding for 12h or so.

I've totally done that - and assuming that the max difference caused was 5Kh/s, and the usual 750Ti speed on X11 is 3Mh/s with your mods (do correct me if I'm mistaken; while I pay attention to the developments, the exact numbers I no longer watch as closely since I stopped working with CUDA myself), the percentage difference on that would be 0.000166%. My personal opinion on a VERY lax margin of error would probably be at least around 0.05% - 0.10%.

EVERY LITTLE BIT COUNTS--

The sum of many small changes will creep over the statistical barrier.       --scryptr

Correct - assuming it's not something you've hallucinated, or the result of a single clock tick propagating across a certain circuit in the GPU somewhat faster right when you check hash, or some other freak accident...

CODE REVISION--

Thanks for the nod.  If code is reduced to fewer instructions and loops, with precalculations and assembly code in place of bulkier, higher level code, it will run faster.  A shorter path to the same end.

Lately, I don't compile every increment submitted, but have seen progress mining Quark on my cards over the last 2 months.  It trends...         --scryptr

[lawrencelyl]

Once a while I will get the following error message after running ccminer for a while:
Cuda error in func 'cuda_check_cpu_setTarget' at line 28 : the launch timed out and was terminated.

Anyone have any idea what might be the issue?  Thank you.

[sp_]

Yesterday I submitted a tiny speedup in x11. 2-5 KHASH on the 750ti. (simd) I think there are some more easy pickings here. might try to find them this weekend.

Don't take this the wrong way, sp_, as I think you do really good work - but you might want to establish a margin of error. I wouldn't be surprised if you reverted it later with a commit message saying it seems to have no effect - but it sure looked like it at 3AM after having been coding for 12h or so.

I've totally done that - and assuming that the max difference caused was 5Kh/s, and the usual 750Ti speed on X11 is 3Mh/s with your mods (do correct me if I'm mistaken; while I pay attention to the developments, the exact numbers I no longer watch as closely since I stopped working with CUDA myself), the percentage difference on that would be 0.000166%. My personal opinion on a VERY lax margin of error would probably be at least around 0.05% - 0.10%.

EVERY LITTLE BIT COUNTS--

The sum of many small changes will creep over the statistical barrier.       --scryptr

Correct - assuming it's not something you've hallucinated, or the result of a single clock tick propagating across a certain circuit in the GPU somewhat faster right when you check hash, or some other freak accident...

CODE REVISION--
Thanks for the nod.  If code is reduced to fewer instructions and loops, with precalculations and assembly code in place of bulkier, higher level code, it will run faster.  A shorter path to the same end.
Lately, I don't compile every increment submitted, but have seen progress mining Quark on my cards over the last 2 months.  It trends...         --scryptr

Excactly. By removing a few assembly instructions, the speed increase might be too small to measure. but if you do it 200 times, the speed increase will be visible..

The last simd improvements should be fixed by the compiler but it wasn't

You have a buffer that is set to zero:

Code:

Somebuffer[x] = 0;

Further down you have a loop that use this buffer to multiply and does some other stuff.

Somebuffer[x] = Somebuffer[x] * constmemory ^ blablabla

In my changeset I just removed some of the instructions that worked on zero values, and the gain was around 40 assembly instructions..

[Slava_K]

to restart fault videocards just download and use "nvidiaInspector.exe -restartDisplayDriver"

[hashbrown9000]

@joblo, can you share your script for shutting down ccminer?

I don't use ^C to kiil ccminer, I have a script that does a taskkill or pkill depending on the OS

I'm running linux so I can't do any of the Windoze solutions.

[joblo]

@joblo, can you share your script for shutting down ccminer?

I don't use ^C to kiil ccminer, I have a script that does a taskkill or pkill depending on the OS

I'm running linux so I can't do any of the Windoze solutions.

I simply do a pkill ccminer from a shell script. In Windows bat it's taskkill /f /im ccminer.exe.

Your question got me thinking about the difference between ^C (SIGINT) and pkill (SIGTERM). I may change
it to pkill -SIGINT ccminer to see if that makes for a cleaner exit.

Does anyone who has the degradation problem on use ^C instead of pkill/taskkill?

[hammer24p]

can't get the new vert miner to on 750 need help bat,yes got the new miner ,test port

[scryptr]

@joblo, can you share your script for shutting down ccminer?

I don't use ^C to kiil ccminer, I have a script that does a taskkill or pkill depending on the OS

I'm running linux so I can't do any of the Windoze solutions.

I simply do a pkill ccminer from a shell script. In Windows bat it's taskkill /f /im ccminer.exe.

Your question got me thinking about the difference between ^C (SIGINT) and pkill (SIGTERM). I may change
it to pkill -SIGINT ccminer to see if that makes for a cleaner exit.

Does anyone who has the degradation problem on use ^C instead of pkill/taskkill?

WINDOWS KILL--

The problem I had when I was attempting to use the YAAMP protocol for auto switching was that an error message from Windows would pop up and interrupt the batch file.  Although I disabled Error Reporting, Windows would still send the alert and interrupt the batch file.  Manual interaction was required, mining stopped.

Currently, I do everything manually.  I left-click the red X at the top right of the window, and close ccminer.  If I use ctrl-c, there is a chance of the degradation problem.         --scryptr

[joblo]

@joblo, can you share your script for shutting down ccminer?

I don't use ^C to kiil ccminer, I have a script that does a taskkill or pkill depending on the OS

I'm running linux so I can't do any of the Windoze solutions.

I simply do a pkill ccminer from a shell script. In Windows bat it's taskkill /f /im ccminer.exe.

Your question got me thinking about the difference between ^C (SIGINT) and pkill (SIGTERM). I may change
it to pkill -SIGINT ccminer to see if that makes for a cleaner exit.

Does anyone who has the degradation problem on use ^C instead of pkill/taskkill?

WINDOWS KILL--

The problem I had when I was attempting to use the YAAMP protocol for auto switching was that an error message from Windows would pop up and interrupt the batch file.  Although I disabled Error Reporting, Windows would still send the alert and interrupt the batch file.  Manual interaction was required, mining stopped.

Currently, I do everything manually.  I left-click the red X at the top right of the window, and close ccminer.  If I use ctrl-c, there is a chance of the degradation problem.         --scryptr

If I ctrl-C the mining window on Windows I get the error popup. But my bat file uses the start command to open a seperate window
for the miner. The bat file keeps running and when it decides to switch pools it issues a taskkill which closes the existing miner
window and a new one is opened. There are no popups but I have no idea if there are any ugly messages that appear in the
window as it vanishes.

If your GPU sometimes goes into a degraded state following a ctrl-C  (assuming signals on Windows is as on Linux)
there seems to be no difference between SIGINT and SIGTERM.

nvidia-smi -r --id=0 doesn't work on the primary gpu so I still have to reboot.

[sp_]

I submitted another speedup in quark and x11. Looks like most gain on compute 5.2 cards

Note that I removed a big memory buffer in the x11 hash(simd) intensity can now be set to 28 or more. (but default on the 750ti is only 5)

[sp_]

- neoscrypt +10khash on the 970 (1.8%)
- qubit +50khash (compute 5.2)
- faster x11, quark (compute 5.2) (quark +300khash on the gtx 980) (1.7 %)
- yesscrypt has been removed.(faster to mine with cpu)


1.5.58(sp-MOD) is available here: (09-08-2015)

https://github.com/sp-hash/ccminer/releases/

The sourcecode is available here:

https://github.com/sp-hash/ccminer

[pallas]

- neoscrypt +10khash on the 750ti (6%)
- qubit +50khash (compute 5.2)
- faster x11, quark (compute 5.2) (quark +300khash on the gtx 980) (1.7 %)
- yesscrypt has been removed.(faster to mine with cpu)


1.5.58(sp-MOD) is available here: (09-08-2015)

https://github.com/sp-hash/ccminer/releases/

The sourcecode is available here:

https://github.com/sp-hash/ccminer

Thanks SP_!
Last commit on neoscrypt is from 15 days ago (just before the previous release), are you sure you committed it all?

[sp_]

- neoscrypt +10khash on the 750ti (6%)
- qubit +50khash (compute 5.2)
- faster x11, quark (compute 5.2) (quark +300khash on the gtx 980) (1.7 %)
- yesscrypt has been removed.(faster to mine with cpu)
1.5.58(sp-MOD) is available here: (09-08-2015)
https://github.com/sp-hash/ccminer/releases/
The sourcecode is available here:
https://github.com/sp-hash/ccminer

Thanks SP_!
Last commit on neoscrypt is from 15 days ago (just before the previous release), are you sure you committed it all?

I had one commit rigth after the release 57 (10khash on the 750ti) as well.
(10khash on the gtx 970)

https://github.com/sp-hash/ccminer/network

https://github.com/sp-hash/ccminer/commits/windows