testing your 17 release
6x 750ti overclocked
minercontrol on YAAMP on x13
after trying with the intensity 20.5 After hashing for about 5 min I had a ccminer stopped working crash and had to restart.
upon restart the miner would not hash and got the error with the same ccminer stopped working.
changed intensity to 20.3 and started to hash again for about 5-10 min then i get this error
[2014-12-08 01:13:50] GPU #5: result for 0014cc00 is not in range: a8cf372c > 1f
Cuda error in func 'quark_blake512_cpu_setBlock_80' at line 309 : unspecified launch failure.
restart pc
happened a few more times on about 3 different cards out of the 6, all cards are overclocked so I adjusted the mem clocks down 50mhz and the core on the cards that seem to fail down 10mhz on the core.
after about 10 min hashing had a card fail with the error above.
was hashing with your beta 13 release with no issue although the speed is slightly less at 14,445
compared to your 17 release which seems to settle around 14,686
will test some more tomorrow, could be my intensity setting contributing to the instability, what intensity to you set your 750 ti's to when your testing your kernels Sp?
Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1212. (Read 2347597 times)
Might not be fixed yet...
I will branch 1.5.1 and merge my kernals now.
I will branch 1.5.1 and merge my kernals now.
Thanks Sp !
downloading now
downloading now
Restored performance on 970/980 cards. (+200-300 KHASH from release 16)
Now the miner is keeping the smallest nounce and not the first it can find. Should speedup on pools with low diff.
With extreme overclock I managed 3.2 MHASH on the 750ti and 9,9MHASH on the 980.
New binary from git:
http://www.filedropper.com/release17
The sourcecode is available here:
https://github.com/sp-hash/ccminer
Now the miner is keeping the smallest nounce and not the first it can find. Should speedup on pools with low diff.
With extreme overclock I managed 3.2 MHASH on the 750ti and 9,9MHASH on the 980.
New binary from git:
http://www.filedropper.com/release17
The sourcecode is available here:
https://github.com/sp-hash/ccminer
I have found an issue in build 16. If the miner mines on a low diff with high intensity and find one solution, it will pick the first solution it finds, and not the best solution. This could cause the missing hash in the pool.
I need to keep the solution that gives the best hash. Should run at the same speed with the new fix.
Why don't you keep both? I need to keep the solution that gives the best hash. Should run at the same speed with the new fix.
https://github.com/tpruvot/ccminer/commit/c3bdb623e82ed4bc6906ff06d616a2b13494b424Also, any news about the API?
I need to refork soon. Alot of good work has been done on the other branch.
Does anyone have power usage stats for a 970 for x11/x13/x15?
I have found an issue in build 16. If the miner mines on a low diff with high intensity and find one solution, it will pick the first solution it finds, and not the best solution. This could cause the missing hash in the pool.
I need to keep the solution that gives the best hash. Should run at the same speed with the new fix.
I need to keep the solution that gives the best hash. Should run at the same speed with the new fix.
Why don't you keep both?
https://github.com/tpruvot/ccminer/commit/c3bdb623e82ed4bc6906ff06d616a2b13494b424Also, any news about the API?
just tested build 16 on a 980 and its slower than release 13... on the 750ti it's faster.
I have found an issue in build 16. If the miner mines on a low diff with high intensity and find one solution, it will pick the first solution it finds, and not the best solution. This could cause the missing hash in the pool.
I need to keep the solution that gives the best hash. Should run at the same speed with the new fix.
I need to keep the solution that gives the best hash. Should run at the same speed with the new fix.
I have thested both the 1.5.0 and my modded version and they seem to report the correct hash on other pools like wafflepool, yaamp, and nicehash, so this seems to be a pool issue, but it might be a bug in ccminer as well.
I second that - all multicoin/profit switching pools I've tried work fine, but most the single coin ones report much lower hash speed than what's reported by ccminer. At least that's the pattern I've noticed. version8 is the last one that works fine I think... All the newer report higher hashrates but pools don't "like" them.Version 15 is no different for me - try it yourself at pool.profitcoin.org
I might have a look at this problem in the weekend.
What difficulty are you mining on in these pools?
I've been using default settings - just algo, and pool credentials. No intensity setting.
I'll also do some more testing when my rig is available (not rented).
I have thested both the 1.5.0 and my modded version and they seem to report the correct hash on other pools like wafflepool, yaamp, and nicehash, so this seems to be a pool issue, but it might be a bug in ccminer as well.
I second that - all multicoin/profit switching pools I've tried work fine, but most the single coin ones report much lower hash speed than what's reported by ccminer. At least that's the pattern I've noticed. version8 is the last one that works fine I think... All the newer report higher hashrates but pools don't "like" them.Version 15 is no different for me - try it yourself at pool.profitcoin.org
I might have a look at this problem in the weekend.
What difficulty are you mining on in these pools?
Fixed solomining/echo, and improved fugue (x13). Now building release 15.
what was the problem with echo ? the last changes (in aes.cu) reduced x11 perfs to less than 2900And yes i have 2 Gigabyte Black Edition, and also a normal Gigabyte with black edition bios (only stable on linux)
yes, the AES change is only faster if there is more registers so I reverted it. The current echo_final is running with 64 register.
The problem with the first checkin was that if the hash was on target the program didn't find it. Also if the diff was very low. diff in hash[6]..hash[0] the program didn't find it.
new version without cpu errors.
I also reverted the AES change and merged klaus'es echo compiler optimalizations.
http://www.filedropper.com/release16
The sourcecode is available here:
https://github.com/sp-hash/ccminer
I also reverted the AES change and merged klaus'es echo compiler optimalizations.
http://www.filedropper.com/release16
The sourcecode is available here:
https://github.com/sp-hash/ccminer
Fixed solomining/echo, and improved fugue (x13). Now building release 15.
what was the problem with echo ? the last changes (in aes.cu) reduced x11 perfs to less than 2900
And yes i have 2 Gigabyte Black Edition, and also a normal Gigabyte with black edition bios (only stable on linux)
Release 15 here. Now also support for compute 3.0 devices.
http://www.filedropper.com/release15
source
https://github.com/sp-hash/ccminer/
http://www.filedropper.com/release15
source
https://github.com/sp-hash/ccminer/
yep, im not so confident about one pool graph... But i need to compare also...
But its not related to the extranonce feature... which is not even used by most pools its only one request on start in this case.
But its not related to the extranonce feature... which is not even used by most pools
its only one request on start in this case.I have thested both the 1.5.0 and my modded version and they seem to report the correct hash on other pools like wafflepool, yaamp, and nicehash, so this seems to be a pool issue, but it might be a bug in ccminer as well.
I second that - all multicoin/profit switching pools I've tried work fine, but most the single coin ones report much lower hash speed than what's reported by ccminer. At least that's the pattern I've noticed. version8 is the last one that works fine I think... All the newer report higher hashrates but pools don't "like" them.
Version 15 is no different for me - try it yourself at pool.profitcoin.org
Release 15 here. Now also support for compute 3.0 devices.
http://www.filedropper.com/release15
source
https://github.com/sp-hash/ccminer/
http://www.filedropper.com/release15
source
https://github.com/sp-hash/ccminer/
definitely faster on x11 but seeing a lot of result does not validate on CPU messages.
Release 15 here. Now also support for compute 3.0 devices.
http://www.filedropper.com/release15
source
https://github.com/sp-hash/ccminer/
http://www.filedropper.com/release15
source
https://github.com/sp-hash/ccminer/
Fixed solomining/echo, and improved fugue (x13). Now building release 15.
Your makefile use 128 registers and mine has 80 registers as default, and this will cause big differences.
actually, this should be removed from any makefile or setup (even though I didn't do it myself...), this method of allocating register is deprecated and should be replaced by __launch_bounds__ (I am paraphrasing cuda doc...) That is right to support all past and possible/future cards.. not for the 90% of users with 750Ti or 970/980
The problem is that when you change the number of registers in one kernal, all the other kernals needs to be recompiled, and sometimes the performance in the other kernals get worse. Use launchbounds. It's faster and bether.
also for past gen card, you can just duplicate the kernel with different launch_bound parameters then call using minor/major to make sure the correct kernel is used at launch time based on the card compute version
else your echo improvement works on linux too... 2870 yesterday 2920 now we are close to the 3MH on the 750Ti ^^ I need to inspect the changes
you have also remains of a missing simd free with current commit (does not build)
you have also remains of a missing simd free with current commit (does not build)
The new Echo is doing 8.xx rounds of echo instead of 10 rounds. The previous version did 9.25 rounds. And the original version does 10rounds.
On the 980 we will probobly get 300KHASH more.
Less work, less power more hash.
great work sp ! looking forward to testing your next release
keep up the good work bro Jump to: