CCminer(SP-MOD) Modded GPU kernels.

[djm34]

I wanted to try cuda 7.5 and here's my experience with it and neoscrypt mining.

On cuda 6.5 I'm working on an optimized version which does about 560 Mh/s on 970.
Simply switching to cuda 7.5 brought it down to 420.
So I wanted to try to reach at least the same hashrate as before, but I failed: after tuning it for the new cuda version for half a day, I was only able to bring it up to about 460.

Any suggestion on how to do better than that? Or should I just leave 7.5 alone? :-)

same here... (with an additional crash on the 780ti)
you can try to add that to the compilation option: -Xptxas --def-load-cache=cs -Xptxas --def-store-cache=cs, haven't really try on neo, the problem it is 1hour to recompile each time... might help (however it is rather for the 780ti...)

[1714693262]

1714693262

[1714693262]

1714693262

[sp_]

I wanted to try cuda 7.5 and here's my experience with it and neoscrypt mining.

Cuda 7.5 is broken. Try to compile shavite.
With 6.5 the kernal compiles with 64 registers 0 spill stores 0 stack.
In cuda 7.5 the stack and memory usage explodes. The x11  performance is down 30%. I have tried to tweak it with register count and launchbounds, but just small gains.

[zTheWolfz]

Had expect more out of 32 cores, but core speed is 1Ghz below my Intel rigs. Still not to bad I guess.  

[djm34]

your intel rig is using an amd processor... on an amd board
(but yeah, nobody can stop you from putting an intel sticker on it  )

[lawrencelyl]

Had expect more out of 32 cores, but core speed is 1Ghz below my Intel rigs. Still not to bad I guess.  

As a comparison, my i7-4790K is achieving close to 228H/s on 8 threads at 4GHz (Turbo disabled).  However, I still think it doesn't justify for the amount of power my CPU consumed.
https://bitcointalk.org/index.php?topic=826901.msg12060791#msg12060791

[bensam1231]

I gotta say, I'm not a believer in that ASIC thing, that just seems to be a bunch of horse.

I've had lower and higher ASIC cards, both OC quite well, and also the higher hasn't always been the best. Basically, most of these cards OC till a certain limit, regardless of how well they're made.

From what I've seen, extremely bad cards can't even hold their factory boost clock, but then again, it's got nothing to do with ASIC.

Yeah, from I've seen ASIC doesn't mean a whole lot. Sometimes you like to give things meaning that seem like they should. I've had good and bad OCers with high and low ASIC values.

[hashbrown9000]

has anyone figured out a solution to the memory leak on the newer builds?  it seems to happen for most of the popular algos.  

here's what happens:  reboot, start a fresh mining session. Stop the miner using CTRL+C, get a seg fault message almost all the time, restart the miner, and almost instantly, one GPU crashes (hash shows about 1/3 normal speed), exact same speed everytime the hashes pop up.

rebooting will always fix the issue.

[Nubminer]

has anyone figured out a solution to the memory leak on the newer builds?  it seems to happen for most of the popular algos.  

here's what happens:  reboot, start a fresh mining session. Stop the miner using CTRL+C, get a seg fault message almost all the time, restart the miner, and almost instantly, one GPU crashes (hash shows about 1/3 normal speed), exact same speed everytime the hashes pop up.

rebooting will always fix the issue.

I monitor the cards with Precision X and just wait till they drop below 400 before I begin a new session.  it never crashes for me if I wait till they drop down to below 400

Also you can just disable your video card in Control Panel > Hardware & Sound > Device Manager

then Re-Enable it after a couple of seconds and you wont have to reboot.




(I dont have my monitor connected to my Mining GPU's either so disabling the card does not prevent me from seeing what I am doing. I am not sure what will happen if you disable the card you are using with your Monitor )

[lawrencelyl]

has anyone figured out a solution to the memory leak on the newer builds?  it seems to happen for most of the popular algos.  

here's what happens:  reboot, start a fresh mining session. Stop the miner using CTRL+C, get a seg fault message almost all the time, restart the miner, and almost instantly, one GPU crashes (hash shows about 1/3 normal speed), exact same speed everytime the hashes pop up.

rebooting will always fix the issue.

I monitor the cards with Precision X and just wait till they drop below 400 before I begin a new session.  it never crashes for me if I wait till they drop down to below 400

Also you can just disable your video card in Control Panel > Hardware & Sound > Device Manager

then Re-Enable it after a couple of seconds and you wont have to reboot.




(I dont have my monitor connected to my Mining GPU's either so disabling the card does not prevent me from seeing what I am doing. I am not sure what will happen if you disable the card you are using with your Monitor )

You still can disable the card that attached to a monitor.  The screen will go blank for a couple of seconds but will be back again.  After that you can re-enable the card back. I have done it a number of times on my system when something goes wrong and my card stuck at low clock speed.  Didn't want to reboot so I guess the best method just disable and re-enable the card to recover.

[djm34]

has anyone figured out a solution to the memory leak on the newer builds?  it seems to happen for most of the popular algos. 

here's what happens:  reboot, start a fresh mining session. Stop the miner using CTRL+C, get a seg fault message almost all the time, restart the miner, and almost instantly, one GPU crashes (hash shows about 1/3 normal speed), exact same speed everytime the hashes pop up.

rebooting will always fix the issue.

don't think it is related the control-c problem is a known issue in sp release (there is a fix in tpruvot)

[joblo]

has anyone figured out a solution to the memory leak on the newer builds?  it seems to happen for most of the popular algos.  

here's what happens:  reboot, start a fresh mining session. Stop the miner using CTRL+C, get a seg fault message almost all the time, restart the miner, and almost instantly, one GPU crashes (hash shows about 1/3 normal speed), exact same speed everytime the hashes pop up.

rebooting will always fix the issue.

I see this problem almost daily but only on two specific cards. One of my 750ti's on a Windows machine is affected
but the other on a different Windows is not affected. My 970 on a Linux box is also affected. Both affected machines
have two cards but only one card is affected and always the same card.

I've only seen it on a couple of algos but they are the ones that I mine the most. It may have occurred on algos that
run less frequently and for shorter intervals without me noticing.

Given only some cards seem to have the problem if the devs don't have one it will be almost imposible to crack.
I would be willing to help troubleshoot on my systems if I'm provided instructions on data to collect. An instrumented
version of ccminer could be used to look for specific things like an unexepectedly low hash rate for the card type to
trigger specific data collection when the problem is detected. There could also be useful info gathered with tools
such as nvidia-smi, gpuz etc.

[scryptr]

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

[bathrobehero]

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.

[zTheWolfz]

Had expect more out of 32 cores, but core speed is 1Ghz below my Intel rigs. Still not to bad I guess.  

https://bitcointalk.org/index.php?topic=826901.msg12070096#msg12070096

your intel rig is using an amd processor... on an amd board
(but yeah, nobody can stop you from putting an intel sticker on it  )

http://forums.evga.com/FindPost/1924932
Yes the one a page back is AMD, I was referring to the 3 EVGA SR2 http://www.evga.com/articles/00537/ boards I also have
that have X5xxx or E5xxx CPU chips OCed to 3.3, 3.6 & 4.0Ghz.
My Intel rigs gives those same speeds or better on only 16 to 20 cores, but are 1Ghz or more faster per core
was my intent.
http://forums.evga.com/SR2-E5645-and-E5620-works-m1504334.aspx  

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

OCing or not doesn't have an effect on the frequency of degradations.

I don't use ^C to kiil ccminer, I have a script that does a taskkill or pkill depending on the OS. I do a few dozen kills
per day depending on profit volatility and I get about 1 degradation per day. The degradations always seem to occur after
mining for severeal hours. The intervals vary less than finding blocks mining.

I now have a few things I can try next time.

[djm34]

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 ?

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

[dominuspro]

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.

[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 ?

Exactly, I don't know. But I would assume the same way the card recovers automatically from a hard crash.
Whatever triggers the card to go into a lower performance state when under heavy load could also trigger the
reset. Just to be clear i wasn't expecting ccminer to do it, just lamenting the poor handling of the fault by nvidia.

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