Author

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

hero member
Activity: 677
Merit: 500
Asus Strix 980GTX 20.8 Mh Quark 1380 MHz.
legendary
Activity: 2716
Merit: 1094
Black Belt Developer
Yeah the one plus side to the Gigabyte cards is they never seem to throttle and clock the highest. Of course they use like 10-15% more power then all the other cards, so...

As I said, my Zotac card start to mine quark at 15.5 mhash, and then it trottles and fall down to 13.5-14. My gigabyte is stable at 17MHASH. 3,5 MHASH bether.

http://www.zotac.com/products/graphics-cards/geforce-900-series/product/geforce-900-series/detail/geforce-gtx-970.html

The zotac card is much smaller and heats up faster.

I have an msi 970 that is more stable than the others, but still it starts at 16.5 and goes down to 16 after a while.
Well, I may get a gigabyte or just wait for the winter ;-)
sp_
legendary
Activity: 2954
Merit: 1087
Team Black developer
Yeah the one plus side to the Gigabyte cards is they never seem to throttle and clock the highest. Of course they use like 10-15% more power then all the other cards, so...

As I said, my Zotac card start to mine quark at 15.5 mhash, and then it trottles and fall down to 13.5-14. My gigabyte is stable at 17MHASH. 3,5 MHASH bether.

http://www.zotac.com/products/graphics-cards/geforce-900-series/product/geforce-900-series/detail/geforce-gtx-970.html

The zotac card is much smaller and heats up faster.
legendary
Activity: 1764
Merit: 1024
I must say that I didn't have any problem benchmarking amd cards: if the room was hot, I'd put the fans at high speed, run the miner and wait a couple minute to stabilize, and that's it. I could make 100 changes to a kernel in a day and check them all, accurately.

On nvidia I have throttling problems I can't easily fix (the cards reduce clock speed in a number of situations I just can't predict), overclocking/downclocking is more difficult as the cards tend to change clocks by themselves, and the hashrates fluctuates wildly, and even changes between ccminer runs.
The rig is headless so I only have nvidia-smi to work with, and it can't set the fan speed.
So when I make a little kernel speedup, I spend more time benchmarking it (to be sure it's indeed an improvement), than making the improvement itself :-/
Maybe there are some nvidia-smi settings to make it more stable?
Or maybe on windows it's different...
Finally I may need a workstation with a nvidia as main card, and work on it.

Buy another 970 card. The gigabyte windforce oc never trottle and mines on a stable clockrate. easy to verify speedups. For very small changes, taka a look at the generated PTX assembly code, less code lines is bether but not always..
You can also test your chances on a big rig with many cards, If you have many cards small speedups of 0-1 KHASH per card can be visible.

To finance the cards, you can hope that you will ROI the cards in 1 year by increasing the speed of the kernals Smiley

Yeah the one plus side to the Gigabyte cards is they never seem to throttle and clock the highest. Of course they use like 10-15% more power then all the other cards, so...
hero member
Activity: 677
Merit: 500
Ok! Thanks.
sp_
legendary
Activity: 2954
Merit: 1087
Team Black developer
These settinge should be taken out of the hardcoded kernal and be adjustable in the commandline. Like in scrypt.   -l 7x19 (7threads per block with -X intensity 19).
Because on the 970 9 seems to be bether.
hero member
Activity: 677
Merit: 500
TPB52 7 is best for mining. My gtx 980 make 11.2-11.6 Mh. 960 gtx make 6 Mh. Super!
For rig (2x980+1x960) hash is 28500!
PS. It is LYRA2v2! +100 git 1052 works!
sp_
legendary
Activity: 2954
Merit: 1087
Team Black developer
I must say that I didn't have any problem benchmarking amd cards: if the room was hot, I'd put the fans at high speed, run the miner and wait a couple minute to stabilize, and that's it. I could make 100 changes to a kernel in a day and check them all, accurately.

On nvidia I have throttling problems I can't easily fix (the cards reduce clock speed in a number of situations I just can't predict), overclocking/downclocking is more difficult as the cards tend to change clocks by themselves, and the hashrates fluctuates wildly, and even changes between ccminer runs.
The rig is headless so I only have nvidia-smi to work with, and it can't set the fan speed.
So when I make a little kernel speedup, I spend more time benchmarking it (to be sure it's indeed an improvement), than making the improvement itself :-/
Maybe there are some nvidia-smi settings to make it more stable?
Or maybe on windows it's different...
Finally I may need a workstation with a nvidia as main card, and work on it.

Buy another 970 card. The gigabyte windforce oc never trottle and mines on a stable clockrate. easy to verify speedups. For very small changes, taka a look at the generated PTX assembly code, less code lines is bether but not always..
You can also test your chances on a big rig with many cards, If you have many cards small speedups of 0-1 KHASH per card can be visible.

To finance the cards, you can hope that you will ROI the cards in 1 year by increasing the speed of the kernals Smiley
legendary
Activity: 1154
Merit: 1001
Or maybe on windows it's different...

Yeps. On Windows it is extremely simple to set fixed clocks, fans, overclocking, so you can easily have a "benchmark platform".

With a headless Linux system I don't think there's any solution for fixed fans yet, others might know differently. I previously had fixed fans and clocks on Linux, but I perfectly recall that I specifically had to configure/attach a monitor in order to get that working at the time.
legendary
Activity: 2716
Merit: 1094
Black Belt Developer
I must say that I didn't have any problem benchmarking amd cards: if the room was hot, I'd put the fans at high speed, run the miner and wait a couple minute to stabilize, and that's it. I could make 100 changes to a kernel in a day and check them all, accurately.

On nvidia I have throttling problems I can't easily fix (the cards reduce clock speed in a number of situations I just can't predict), overclocking/downclocking is more difficult as the cards tend to change clocks by themselves, and the hashrates fluctuates wildly, and even changes between ccminer runs.
The rig is headless so I only have nvidia-smi to work with, and it can't set the fan speed.
So when I make a little kernel speedup, I spend more time benchmarking it (to be sure it's indeed an improvement), than making the improvement itself :-/
Maybe there are some nvidia-smi settings to make it more stable?
Or maybe on windows it's different...
Finally I may need a workstation with a nvidia as main card, and work on it.
legendary
Activity: 2940
Merit: 1091
--- ChainWorks Industries ---
What's the most accurate way to benchmark kernel modifications?
Using --benchmark or connecting to a pool? What time interval? Any other reccomendation?

Poolmining is never completely reliable, especially if there's vardiff which will always fluctuate. But even with fixed diff you'll have to run it for a long time to be sure.
--benchmark had plenty of issues in the past so I've stopped using it so I'm not sure how it is recently.

For checking speed only, I personally like to just solomine to any local wallet, doesn't even matter if the algo is different and just check the reported hashrate.
Stable clocks and fix fanspeed recommended.

Regarding aluminum cases, I'm also curious how much people who own them paid for them.

frames? ... i build them custom ...

the frame ( 1.5mm square aluminium tubing ) - edge connectors - screws and lugs - angle iron ( 90 degree edging ) ... all this comes to approx $70.00aud ...

but initially i had to buy the cutting and measuring equipment as well as the files and mallets ( yes plastic head mallets - not hammers ) ...

parts alone - not counting labour - if you are looking at adding teh countless hours to design the thing in the first place ...

prototype 1 - prototype 2 and now prototype 3 is probably the design we are going with ...

hope that helps bathrobehero ...

#crysx
legendary
Activity: 2002
Merit: 1051
ICO? Not even once.
What's the most accurate way to benchmark kernel modifications?
Using --benchmark or connecting to a pool? What time interval? Any other reccomendation?

Poolmining is never completely reliable, especially if there's vardiff which will always fluctuate. But even with fixed diff you'll have to run it for a long time to be sure.
--benchmark had plenty of issues in the past so I've stopped using it so I'm not sure how it is recently.

For checking speed only, I personally like to just solomine to any local wallet, doesn't even matter if the algo is different and just check the reported hashrate.
Stable clocks and fix fanspeed recommended.

Regarding aluminum cases, I'm also curious how much people who own them paid for them.
legendary
Activity: 1154
Merit: 1001
Most important recommendation I have, is to benchmark at a low'ish & fixed GPU clock setting (stuck in performance mode), along with a high'ish & fixed fan speed. This should eliminate most/all thermal & clock stability variations.

For significant code changes, and particularly when the changes are not strictly related to the hashing algorithm in particular - so more about backend/generally efficiency - definitely need to test with a pool, Nicehash is usually great at that, with a minimum interval of 4 hours, but ideally, a full 24 hour cycle.

For specific kernel changes, benchmark should be best (and also the practical approach). I tend to benchmark for whatever duration is necessary until I see that I get about 5 minutes of stable output speed & stable temperature reading. Some algorithms take a while ramping up, others not so much, some algorithms start faster, but slow down once temperatures get high enough.
legendary
Activity: 2716
Merit: 1094
Black Belt Developer
What's the most accurate way to benchmark kernel modifications?
Using --benchmark or connecting to a pool? What time interval? Any other reccomendation?
legendary
Activity: 2716
Merit: 1116

I am running all my stuff in alu frames. These +five more where stacked with 5 x 280x cards until two years ago when i stopped mining. I have a total of ten frames but i think i will stop when these are filled up because i promised myself to not go full retard again Cheesy

In total there will be 20 x 750Ti and 5 x 280x cards.

hahah full retard mode was funny
Nice stands, very clean setups.

Cheers
legendary
Activity: 3164
Merit: 1003

I am running all my stuff in alu frames. These +five more where stacked with 5 x 280x cards until two years ago when i stopped mining. I have a total of ten frames but i think i will stop when these are filled up because i promised myself to not go full retard again Cheesy

In total there will be 20 x 750Ti and 5 x 280x cards.
I went with metal frame this time instead of wood. Building from scratch.  Tongue What are the cost of those frames plz. thz
Sorry sp for messing your thread up.
sp_
legendary
Activity: 2954
Merit: 1087
Team Black developer
thanks.
member
Activity: 70
Merit: 10
T Nelson are you there?

Seems to be an error in the latest builds, the miner won't exit without pressing ctrl+c

This was working fine in release 52

-- SNIP --

And here it hangs and then the user have to click ctrl c to exit

[2015-09-07 22:58:16] CTRL_C_EVENT received, exiting once miner jobs complete.  Ctrl+C again to abort miner jobs

Must be Windows only.  Linux seems fine.  Can you grab me a stack trace with it hung?  I won't be able to check Windows for several hours.

Scratch that.  I botched the rebase to HEAD.  Gimme a few to rerecompile.

https://github.com/sp-hash/ccminer/pull/44
member
Activity: 70
Merit: 10
T Nelson are you there?

Seems to be an error in the latest builds, the miner won't exit without pressing ctrl+c

This was working fine in release 52

-- SNIP --

And here it hangs and then the user have to click ctrl c to exit

[2015-09-07 22:58:16] CTRL_C_EVENT received, exiting once miner jobs complete.  Ctrl+C again to abort miner jobs



Must be Windows only.  Linux seems fine.  Can you grab me a stack trace with it hung?  I won't be able to check Windows for several hours.

Scratch that.  I botched the rebase to HEAD.  Gimme a few to rerecompile.
member
Activity: 70
Merit: 10
T Nelson are you there?

Seems to be an error in the latest builds, the miner won't exit without pressing ctrl+c

This was working fine in release 52

-- SNIP --

And here it hangs and then the user have to click ctrl c to exit

[2015-09-07 22:58:16] CTRL_C_EVENT received, exiting once miner jobs complete.  Ctrl+C again to abort miner jobs



Must be Windows only.  Linux seems fine.  Can you grab me a stack trace with it hung?  I won't be able to check Windows for several hours.
Jump to: