CCminer(SP-MOD) Modded GPU kernels.

[sp_]

speeds build 51 (factory standard clocks)
quark:
gtx 970(gigabyte oc): 16.200 MHASH (up from 15.700 in build 50)
gtx 750ti(gigabyte windforce): 5,7 MHASH

Do you have power consumption metrics for these? Specifically the 970. I'm trying to decide if they are worth it or if I should stick to 750 Tis...

The 750ti use around 40 watt. the 970 around 140 watt.. But..
You need to add the idle watt, and messure with a gold rated PSU or bether. With a cheap PSU the wattage is increased.

[1714918535]

1714918535

[1714918535]

1714918535

[1714918535]

1714918535

[5w00p]

I know I can google it and find links, but what procedure do you guys recommend for flashing a higher TDP BIOS?

My card is a Zotac GTX 970 ZT-90101-10P

I am about to put a waterblock on it and then I want to flash a different BIOS, raising the max power limit.

Thanks in advance, and a BIG thank you to sp_. A donation in appreciation from me is forthcoming.

[djm34]

I know I can google it and find links, but what procedure do you guys recommend for flashing a higher TDP BIOS?

My card is a Zotac GTX 970 ZT-90101-10P

I am about to put a waterblock on it and then I want to flash a different BIOS, raising the max power limit.

Thanks in advance, and a BIG thank you to sp_. A donation in appreciation from me is forthcoming.

http://www.overclock.net/t/1514085/official-nvidia-gtx-970-owners-club/10#post_22876454

[Grout]

The 750ti use around 40 watt. the 970 around 140 watt.. But..
You need to add the idle watt, and messure with a gold rated PSU or bether. With a cheap PSU the wattage is increased.

Thank you. I found a tomshardware page that mesured the idle power usage at 20W (and the "torture" at 243W), so 160W total on quark. Nice!
I think it is the first time 970 beats 750 on a H/€ AND H/W comparison.

BTW, I removed one 750Ti (windforce OC) from my rig and the power consumption difference is exactly 60W from the wall, on a 80plus gold PSU.

edit: just did the math and 970 are still worth with insane 1200+ platinum PSUs...

[ManiacMiner]

How to mine scrypt-jane with this miner? For example nfactor=15. Old cudaminer work fine with my 750Ti rig, but with this miner i have errors. Need other parameters?

[Nubminer]

release 50
gtx 980 -  lyra2 -i 21 @nicehash 1325  
              quark -i 24 @nicehash  19500

release 51
gtx 980 - lyra2 -i 21 @nicehash 1325
              qiark -i 24 @nicehash 19200


temp of card.. it seems to me the mfg wanted this card to run hot... I will crank up the fan speed a bit and try and get in the 75ºc gpu1 and gpu2 will probably drop to 72ºC but any more and my wife will complain

[chrysophylax]

hi all ...

has anyone any issues with compiling since sp introduced compute_52 into the makefile? ...

sp - the compile crashes with - nvcc fatal   : Unsupported gpu architecture 'compute_52' - since you introduced the compute_52 arch into git ...

even if you comment out the option in the makefile - the compilation bombs out with - config.status: error: cannot find input file: `Makefile.in' ...

could you 'fix' this please? ...

#crysx

[sp_]

Just use the old makefile. Or remove the +

[bensam1231]

Curiously are you guys overvolting too? Overvolting usually results in worse efficiency.

The 290/x series were designed to operate at up to 95c at which point the fan ramps up to whatever your maximum threshold is and once it reaches whatever you set the maximum to it starts downclocking to stay under 95c. AMD said they were perfectly alright operating at those temperatures. That was what they were engineered to do. That doesn't apply to 280/x series though. The conception that it's 'too hot' is based on what people know about other GPUs besides those.

For gaming but not for 24/7 heavy use.

That is incorrect. It includes render farms, which can be just as strenuous as mining. 'Gaming' is a very loose term as well, some games push cards harder then others. They wouldn't make such a statement based off using the card for 1-2 hours at those temps. They were designed to run at that temperature. It's not magic, you can engineer something to run at whatever you want, you just have to use components that work at higher temperatures.

[5w00p]

Beer donation sent

https://blockchain.info/tx/646094cd6ce1a8e0e01c63c1881f7d04dbac1904291e86fbf59fc25e9f5bd504

[myagui]

@bensam1231

I have the 980's undervolted, which has so far proven to provide about the same stability ceiling, while driving less power and heat (so yeah, I'd expect that overvolting would tend to lower the efficiency). Standard voltage at top clock bin is 1.125v IIRC, while mine are running at 1.112v.
I don't have any 750's anymore, but I do recall those behaving very differently. The ones I had before, would allow quite a bit more overclocking if also running overvolted - but on those - I was not bound by thermal or TDP limitations (which I am on the 980s). 

The issue with running the cards very hot (near the specification limits) is not one of killing the cards in an instant. They are certainly designed to manage the temperatures for long periods of time (hence the thermal throttling). The issue is that, cards that always run hot, will tend to have a shorter lifetime than those than always run cool.
Manufacturers are also not stupid. They will be happy to have a good number of cards failing after some 4 or 5 years of abuse, so they can sell some new ones 

@SP_
980 @ 1370, 3505 - quark
   release 44 - 19.2MH/s
   release 51 - 19.5MH/s

[joblo]

hi all ...

has anyone any issues with compiling since sp introduced compute_52 into the makefile? ...

sp - the compile crashes with - nvcc fatal   : Unsupported gpu architecture 'compute_52' - since you introduced the compute_52 arch into git ...

even if you comment out the option in the makefile - the compilation bombs out with - config.status: error: cannot find input file: `Makefile.in' ...

could you 'fix' this please? ...

#crysx

Guess you missed this post....

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

If you only have 750s you don't need compute_52. As SP pointed out compute_52 will give
better performance on 9xx cards.

[sp_]

Beer donation sent
https://blockchain.info/tx/646094cd6ce1a8e0e01c63c1881f7d04dbac1904291e86fbf59fc25e9f5bd504

Thanks:) I think I should spend some more time on quark.. to low tdp on the highend cards

[chrysophylax]

hi all ...

has anyone any issues with compiling since sp introduced compute_52 into the makefile? ...

sp - the compile crashes with - nvcc fatal   : Unsupported gpu architecture 'compute_52' - since you introduced the compute_52 arch into git ...

even if you comment out the option in the makefile - the compilation bombs out with - config.status: error: cannot find input file: `Makefile.in' ...

could you 'fix' this please? ...

#crysx

Guess you missed this post....

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

If you only have 750s you don't need compute_52. As SP pointed out compute_52 will give
better performance on 9xx cards.

tanx jo ... i understand ...

BUT - when the latest git clone was made and a compile got underway - the compile bombed out ...

editing the Makefile.am and removing that part for compute_52 did nothing more than create more errors concerning a missing Makefile.in ...

i have written a very simple script for the compilation of ccminer-spmod for our systems ...

simple but effective - in that it automates the entire process from cloning to compilation to installation and rebooting of the system to mine with the new miner without manual intervention for each of the machines in the farm ...

unfortunately - when there is an issue with the compilation ( as this has currently ) the process is broken ... which means manual intervention - and i REALLY dont like manual intervention ...

as per sp's advice - the compilation finishes successfully when the 'older' Makefile.am replaces the new one ( that is still currently in git ) and the latest ccminer gets compiled ...

but that takes intervention on my part for EVERY miner in the farm - and that is a major pain ...

so whether we need compute_52 or not - it exists currently in the Makefile.am when you clone and thus compilation crashes ... this was not an issue prior to the latest change - which made everything run automatically ...

and im a lazy guy - that likes automation ...

#crysx

[Slava_K]

Just now setting larger memspeed - on quark hashing going up...

[joblo]

hi all ...

has anyone any issues with compiling since sp introduced compute_52 into the makefile? ...

sp - the compile crashes with - nvcc fatal   : Unsupported gpu architecture 'compute_52' - since you introduced the compute_52 arch into git ...

even if you comment out the option in the makefile - the compilation bombs out with - config.status: error: cannot find input file: `Makefile.in' ...

could you 'fix' this please? ...

#crysx

Guess you missed this post....

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

If you only have 750s you don't need compute_52. As SP pointed out compute_52 will give
better performance on 9xx cards.

tanx jo ... i understand ...

BUT - when the latest git clone was made and a compile got underway - the compile bombed out ...

editing the Makefile.am and removing that part for compute_52 did nothing more than create more errors concerning a missing Makefile.in ...

i have written a very simple script for the compilation of ccminer-spmod for our systems ...

simple but effective - in that it automates the entire process from cloning to compilation to installation and rebooting of the system to mine with the new miner without manual intervention for each of the machines in the farm ...

unfortunately - when there is an issue with the compilation ( as this has currently ) the process is broken ... which means manual intervention - and i REALLY dont like manual intervention ...

as per sp's advice - the compilation finishes successfully when the 'older' Makefile.am replaces the new one ( that is still currently in git ) and the latest ccminer gets compiled ...

but that takes intervention on my part for EVERY miner in the farm - and that is a major pain ...

so whether we need compute_52 or not - it exists currently in the Makefile.am when you clone and thus compilation crashes ... this was not an issue prior to the latest change - which made everything run automatically ...

and im a lazy guy - that likes automation ...

#crysx

I see. You want the default makefile to work for your process. So compute_50 should be the default with others
being optional requiring manual intervention. Ex:

Code:

nvcc_ARCH = -gencode=arch=compute_50,code=\"sm_50,compute_50\"
#nvcc_ARCH += -gencode=arch=compute_52,code=\"sm_52,compute_52\"
#nvcc_ARCH += -gencode=arch=compute_35,code=\"sm_35,compute_35\"
#nvcc_ARCH += -gencode=arch=compute_30,code=\"sm_30,compute_30\"

Or you could just install the supported cuda version and your process should work
with the existing default makefile.

I'm curious whether you do seperate compiles for each system or just one central
compile. If your environment is homogeneous you could compile once and distruibute
the executable to all rigs. This would simplify your process in the event manual intervention
(ie editting makefile) is needed. With a central compile there is less incentive to optimize
for only the arch you need, Ie less need to modify the makefile.

It wasn't my intent to mess up your process with my query. I was just wondering if there
was a technical reason for not including the compute_52 option, even in commented form.

Since compute_52 support doesn't exist in the default cuda version it makes sense not to enable
it by default in the makefile.

[chrysophylax]

hi all ...

has anyone any issues with compiling since sp introduced compute_52 into the makefile? ...

sp - the compile crashes with - nvcc fatal   : Unsupported gpu architecture 'compute_52' - since you introduced the compute_52 arch into git ...

even if you comment out the option in the makefile - the compilation bombs out with - config.status: error: cannot find input file: `Makefile.in' ...

could you 'fix' this please? ...

#crysx

Guess you missed this post....

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

If you only have 750s you don't need compute_52. As SP pointed out compute_52 will give
better performance on 9xx cards.

tanx jo ... i understand ...

BUT - when the latest git clone was made and a compile got underway - the compile bombed out ...

editing the Makefile.am and removing that part for compute_52 did nothing more than create more errors concerning a missing Makefile.in ...

i have written a very simple script for the compilation of ccminer-spmod for our systems ...

simple but effective - in that it automates the entire process from cloning to compilation to installation and rebooting of the system to mine with the new miner without manual intervention for each of the machines in the farm ...

unfortunately - when there is an issue with the compilation ( as this has currently ) the process is broken ... which means manual intervention - and i REALLY dont like manual intervention ...

as per sp's advice - the compilation finishes successfully when the 'older' Makefile.am replaces the new one ( that is still currently in git ) and the latest ccminer gets compiled ...

but that takes intervention on my part for EVERY miner in the farm - and that is a major pain ...

so whether we need compute_52 or not - it exists currently in the Makefile.am when you clone and thus compilation crashes ... this was not an issue prior to the latest change - which made everything run automatically ...

and im a lazy guy - that likes automation ...

#crysx

I see. You want the default makefile to work for your process. So compute_50 should be the default with others
being optional requiring manual intervention. Ex:

Code:

nvcc_ARCH = -gencode=arch=compute_50,code=\"sm_50,compute_50\"
#nvcc_ARCH += -gencode=arch=compute_52,code=\"sm_52,compute_52\"
#nvcc_ARCH += -gencode=arch=compute_35,code=\"sm_35,compute_35\"
#nvcc_ARCH += -gencode=arch=compute_30,code=\"sm_30,compute_30\"

Or you could just install the supported cuda version and your process should work
with the existing default makefile.

I'm curious whether you do seperate compiles for each system or just one central
compile. If your environment is homogeneous you could compile once and distruibute
the executable to all rigs. This would simplify your process in the event manual intervention
(ie editting makefile) is needed. With a central compile there is less incentive to optimize
for only the arch you need, Ie less need to modify the makefile.

It wasn't my intent to mess up your process with my query. I was just wondering if there
was a technical reason for not including the compute_52 option, even in commented form.

Since compute_52 support doesn't exist in the default cuda version it makes sense not to enable
it by default in the makefile.

tanx for the example code .. i havent tried it with that makefile - im not a developer and only know so much - enough that would get me into a lot of trouble ... hence where we are now ...

what we have here is 'becoming' a homogeneuos environment ... this is the intent and the reason why the farm is going through a huge transition from the 'bitsa' system in its current form - to the cloned system homogeneous farm that it will become in the coming months ...

you are completely on par with what the goal is - having a singular carbon copy of EACH machine throughout the farm ...

it is a major pain in the rear in its current incarnation ... different cpu's with different motherboards with different psu's and a mix of usb risers and cabled risers ... mostly with the same video card ...

that is all changing ... which will ( as you mentioned ) make it a far simpler process with only ONE compile and ONE roll out with ONE script across the entirety of the farm in its present state - making it an easier way to expand the farm in the future ... we have just taken delivery of another 40 x identical motherboards which are ready to be built ( including rebuilding the current workers ) into clone workers for the farm ...

the only technical reasoning behind the omission of compute_52 is that it 'broke' the compile ... thats all ... but tomorrow ( as its late here now ) i will make the changes to the makefile and see if it compiles 'normally' without breaking ...

there is a need to get a higher level card ( or three ) to test for testing purposes - as the entire farm ( apart from the amd 280x cards ) is comprised of the gigabyte 750ti oc lp cards ( including the standard oc powered ones - but they will be sold off soon ) ... so the makefile in that format would make a lot of sense ...

the process we have here is a process put together by me for the 'production' environment and not for the 'development' environment ( which currently is a single machine with 2 x gigabyte 750ti oc cards ) - which makes for a double handling of manual intervention if the compiles break all the time ... corporate SOE has rubbed off a little here ...

so its a major learning process for me - and with all the help that you and the forum has given - is fast becoming a standardized way of compiling and rolling out - albeit not as streamlined as i would personally like it ... yet ... im still working on that ...

ultimately its about building - compiling - rolling out - streamlining ... all clones of one worker ... all with linux - all with exact same hardware - all with ccminer-spmod ( and sgminer at the moment for the current amd cards ) ...

i guess we will need to wait and see if any of these plans come to light ... im on this full time and daily now - so time is not an issue any more ...

edit - the compile still bombs ... but i am tired and need sleep - so maybe im doing something wrong ... tomorrow will work on it further ...

#crysx

[bensam1231]

Anyone using some 960s? What are you getting for Quark/X11/Neo?

I assume ccminer doesn't scale and needs to be tailored to each cards gen.

[joblo]

Anyone using some 960s? What are you getting for Quark/X11/Neo?

I assume ccminer doesn't scale and needs to be tailored to each cards gen.

I'm not sure what you mean by ccminer scaling and I have no data for the 960 but
I did observe fairly linear hash rate vs cuda count scaling among the 750ti, 970 & 980
in quark & X11. Don't know about neo and I do know that lyra2 doesn't scale linearly
(as was graciously pointed out to me).

I'm satisfied with using the default ccminer parms. It works on all my cards, including
compute 3.5,  and produces hash rates comparable to test results posted by others.

[joblo]

ultimately its about building - compiling - rolling out - streamlining ... all clones of one worker ... all with linux - all with exact same hardware - all with ccminer-spmod ( and sgminer at the moment for the current amd cards ) ...

i guess we will need to wait and see if any of these plans come to light ... im on this full time and daily now - so time is not an issue any more ...

edit - the compile still bombs ... but i am tired and need sleep - so maybe im doing something wrong ... tomorrow will work on it further ...

#crysx

Hardware shouldn't be an issue except for the CPU and GPU. There is no technical need, though you may have other reasons,
to have all the HW identical. Even the CPU and GPU differences can be ovecome in many cases. Different GPU generations
can be supported with a single compile as discussed in the part that I snipped. And differences in CPU extensions can be worked
around by specifying the arcitecture that works on the least capable CPU. Not really a good idea for CPU critical progs.

Software, of course, has to be the same.

I don't know if there is any benefit to having matching GPUs in the same rig. I tend to mix bigger and smaller cards as it's
easier on power supplies (I'm less likely to need a new bigger one) and heat dissipation especially on Linux where fan control
is usually limited to only one card.

Regarding your compile problems, and assuming they are related to the compute version setting in the makefile, the syntax
is pretty straightforward if you understand the difference between = and +=. Any C programmer would not have to think twice
but you've said many times you are not a coder so I'll offer the following.

= is a direct variable assignment. There must be exactly one of these for the compute version.
+= will add to the existing variable. There may be any number of these or none and they must be
after the direct assignment.
# is a comment. Those lines are not read by the compiler.

If you are compiling for only one compute version you only need the direct assignment of that version.
If you are compiling for multiple compute versions you need one direct assignment followed by as many
add assignments as needed to specify all the desired compute versions.

I took a close look at the code I posted and it should have worked for you as is. I also took another look
at your problem description, the part about Makefile.in. AFAIK that file is not part of the clone but created
by the compile process (either autogen or configure, not sure which). The point is did you do a make distclean
before attempting the second compile with the modified Makefile.am? I sometimes delete the tree and re-expand
the tarball if I'm having a bad compile day. You may want to reclone and edit (or replace) Makefile.am before doing
anything else.