CCminer(SP-MOD) Modded GPU kernels.

[ryen123]

CPU usage is up significantly when using multiple threads, How much load on the i7?

CPU usage somewhere between 7 to 13% (VARDIFF)
Edit: With d=0.05, constant cpu usage around 13%.

Interesting, Is the load spread across the cpu's? or do you have one cpu that takes most of the load?

It looks to me like most of the load is across 3 threads.

[rednoW]

I think the problem is that you are using the 750 (512 shaders, 1gb memory) card. The card is out of resources, and is unable to increase the speed with more threads.

So why miner stats show high hashrate? You should fix it I think. If you will fix the stats you will see real situation with performance.

[sp_]

I think the problem is that you are using the 750 (512 shaders, 1gb memory) card. The card is out of resources, and is unable to increase the speed with more threads.

So why miner stats show high hashrate? You should fix it I think. If you will fix the stats you will see real situation with performance.

The stats needs to be fixed, and the cpu validation errors needs to be gone. Working on it..

[sp_]

CPU usage is up significantly when using multiple threads, How much load on the i7?

CPU usage somewhere between 7 to 13% (VARDIFF)
Edit: With d=0.05, constant cpu usage around 13%.

Interesting, Is the load spread across the cpu's? or do you have one cpu that takes most of the load?

It looks to me like most of the load is across 3 threads.

This is as expected. Each gpu thread is assigned a cpu if available.

[sp_]

I think the problem is that you are using the 750 (512 shaders, 1gb memory) card. The card is out of resources, and is unable to increase the speed with more threads.

So why miner stats show high hashrate?

try with -d 0,0 . is the total hashrate correct?

[fenomenhaa]

Redownload latest built rom Git, with g 2 or 3 parameter miner crashes within a minute.win 8.1 5x750 Ti .

[sp_]

you need to revert the latest checkin

[ryen123]

@Sp_

Something interesting. Same config -g 3 -i 22 but with cpu-priority to High(4) instead of Realtime(5), no crazy displayed hashrates in the miner window.

[fenomenhaa]

you need to revert the latest checkin

@Sp Didn't understand clearly, Donation on the way ))) not to much but it's better then nothing )))
Dark  intstanX :  480f058051f5f89797738585f63c0d491149c27f3f2aeacbd42f5f48223a828b-000

[sp_]

Thanks for your support

You need to remove the changes in the last submit to github:

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

Then it should be stable.

It ran for 6 hours on my testrig without any issues with -g 3 -i 22

[arpika]

Some longer interval tests...

My 970/750ti test rig (linux, quark algo, 0.1 diff) reports ~27M with -g 3 setting now. It was 19M without -g parameter. But yaamp reports lower hashrate! It is about the half of the hasrate reported by ccminer. (13M vs 27M)
So the accepted hasrate decreased by 30% It is a 3 hours average.
The situation is almost the same with -g 2 setting.
But as I recognized acceptance rate is 100%!

[sp_]

@Sp_
Something interesting. Same config -g 3 -i 22 but with cpu-priority to High(4) instead of Realtime(5), no crazy displayed hashrates in the miner window.

This is interesting. My fork uses realtime as default.

I want to test to revert to the original ccminer.cpp stats and threading code (djm34 fork), to see if I can locate invalid hash with multiple thread bug.

[sp_]

Some longer interval tests...
My 970/750ti test rig (linux, quark algo, 0.1 diff) reports ~27M with -g 3 setting now. It was 19M without -g parameter. But yaamp reports lower hashrate! It is about the half of the hasrate reported by ccminer. (13M vs 27M)
So the accepted hasrate decreased by 30% It is a 3 hours average.
The situation is almost the same with -g 2 setting.
But as I recognized acceptance rate is 100%!

If you run quark at nicehash, you will get the average speed of the last 24 hours and also a detailed graph of the performance over time.
Do you get many "does not validate on the cpu" errors?

Try to reduce the cpu-priority

[fenomenhaa]

Thanks for your support

You need to remove the changes in the last submit to github:

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

Then it should be stable.

It ran for 6 hours on my testrig without any issues with -g 3 -i 22

Thanks' for your Work!

Ahh i don't know, how to do this ))) .I'm very bad about software, It seems i need cuda kit,ohh it's more then 900mb )).Maybe it's better to wait your release ))) .If i find time,i'll check )))

[ryen123]

Sent you 0.015 BTC. It's not a lot but a thanks for your work.

https://blockchain.info/tx/da1253e35c58439938496088483aec4838a8aec7ecb2abaa1181555ddca46dfd

[sp_]

Some longer interval tests...
My 970/750ti test rig (linux, quark algo, 0.1 diff) reports ~27M with -g 3 setting now. It was 19M without -g parameter. But yaamp reports lower hashrate! It is about the half of the hasrate reported by ccminer. (13M vs 27M)

when you build yourself you need to make sure that you have compute5_2  in the makefile. Compute 5.0 will cause invalid hash on compute 5.2 cards for some reason.

nvcc_ARCH  = -gencode=arch=compute_50,code=\"sm_50,compute_50\"
nvcc_ARCH += -gencode=arch=compute_52,code=\"sm_52,compute_52\"

[sp_]

Sent you 0.015 BTC. It's not a lot but a thanks for your work.
https://blockchain.info/tx/da1253e35c58439938496088483aec4838a8aec7ecb2abaa1181555ddca46dfd

Thanks.

[rednoW]

try with -d 0,0 . is the total hashrate correct?

Nope, it shows higher hashrate then my favorite Release43 but it doesn't confirm by the pool.

[arpika]

Some longer interval tests...
My 970/750ti test rig (linux, quark algo, 0.1 diff) reports ~27M with -g 3 setting now. It was 19M without -g parameter. But yaamp reports lower hashrate! It is about the half of the hasrate reported by ccminer. (13M vs 27M)

when you build yourself you need to make sure that you have compute5_2  in the makefile. Compute 5.0 will cause invalid hash on compute 5.2 cards for some reason.

nvcc_ARCH  = -gencode=arch=compute_50,code=\"sm_50,compute_50\"
nvcc_ARCH += -gencode=arch=compute_52,code=\"sm_52,compute_52\"

I compiled that way
You also suggested to lower the priority. I reduced the nice level by 5 (from 0 to +5) but same performance.

[tbearhere]

-i 10 -g 4 seems to work with the latest on git.

x11 is 25% faster on my 3 card testrig. gtx970,960,750ti

Do we really need to use these? I just over clock. Or would I get a higher hashrate if I used these and over clocked?  thx