Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 962. (Read 2347664 times)
If you share your code I can take a look
Nah, 6.5 on both boxes. Slightly older 6.5.12 on Linux and 6.5.19 (the latest 6.5 + compute 5.2 support I think) on Windows. Tried x64 builds too, doesn't seem to make much of a difference either way. Weird shit. I did manage to make the win build a little better by manually unrolling stuff, just looks like the win version of nvcc isn't really trying to figure stuff out itself. Which brings me back to weird shit.
If you use cuda 7.5 you should build in 64 bit mode. The x86 compiler is broken.
Trying to make a Windows build for the modified lyra is leaving me with a seriously 
face. Same exact code and nvcc generates something completely different that actually runs slower than the original, be it on a 970 or another 750 Ti. That in addition to VS insisting on rebuilding EVERYTHING after changing something for a single source file in the project file, gotta love it.
face. Same exact code and nvcc generates something completely different that actually runs slower than the original, be it on a 970 or another 750 Ti. That in addition to VS insisting on rebuilding EVERYTHING after changing something for a single source file in the project file, gotta love it. 
@sp - is there any future upgrade to the Spreadcoin miner in the near future?
@joblo, glad you got linux OC working. which release are you running?
it takes a little digging with google and man pages, and it's definitely not user friendly (i.e. work locally first to setup up initial OC of multiple cards, then deploy as headless SSH), but does work.
it takes a little digging with google and man pages, and it's definitely not user friendly (i.e. work locally first to setup up initial OC of multiple cards, then deploy as headless SSH), but does work.
Currently using Fedora 20. Although it's EOL it's the last Fedora release supported by cuda 6.5.
I'm crossing my fingers that cuda 7.5 gets optimized soon so I can upgrade to Fedora 22 or Centos 7.
@joblo, glad you got linux OC working. which release are you running?
it takes a little digging with google and man pages, and it's definitely not user friendly (i.e. work locally first to setup up initial OC of multiple cards, then deploy as headless SSH), but does work.
it takes a little digging with google and man pages, and it's definitely not user friendly (i.e. work locally first to setup up initial OC of multiple cards, then deploy as headless SSH), but does work.
Pool is looking good here now too. Good job.
Now we just have to be careful polishing the porcelain.
Now we just have to be careful polishing the porcelain.
More stable and higher hashrates. Enjoy.
Happy mining!
Lyra2REv2 on SM52 is 5% lower - but pool side is GOOD!Happy mining!
On SM50 2-3% higher.
More stable and higher hashrates. Enjoy.
Happy mining!
Happy mining!
So stable... Thank YOU!
since release 64 was bugged I buildt release 65
-More bug fixes.
-Fixed the hashrate on the pools (lyra,x11 etc)
-Merged changes from pallas and T Nelson
1.5.65(sp-MOD) is available here: (03-09-2015)
https://github.com/sp-hash/ccminer/releases/
The sourcecode is available here:
https://github.com/sp-hash/ccminer
-More bug fixes.
-Fixed the hashrate on the pools (lyra,x11 etc)
-Merged changes from pallas and T Nelson
1.5.65(sp-MOD) is available here: (03-09-2015)
https://github.com/sp-hash/ccminer/releases/
The sourcecode is available here:
https://github.com/sp-hash/ccminer
I hope you know that by stratum specifications, when miner receives new diff, that diff shall be used for every next job. And NOT current jobs as so many miners (even official cgminer) and many pools work wrong way.
When coding a miner, it is simply best to have another variable in job/work structure called diff. Compare each share to this diff.
When pool provides new diff, you just save this diff and apply it to every next job that arrives.
If you make it like this (by official stratum specifications), you will also reach maximum efficiency on NiceHash.
If you use old/wrong principle where new diff is immediately applied, your miners will be loosing few percent of hashrate on NiceHash and causing slight rejects with share above target.
When coding a miner, it is simply best to have another variable in job/work structure called diff. Compare each share to this diff.
When pool provides new diff, you just save this diff and apply it to every next job that arrives.
If you make it like this (by official stratum specifications), you will also reach maximum efficiency on NiceHash.
If you use old/wrong principle where new diff is immediately applied, your miners will be loosing few percent of hashrate on NiceHash and causing slight rejects with share above target.
Thanks for clarifying. I have been wondering exactly this for the past couple of days. But apparently not enough to get around to looking up the spec.
I will definitely look into redoing stratum to the spec. What's there now looks like it only works by chance.
I point my rig to nicehash I have 26,5Mhash for the rig verified on the pool with no rejects..
p2pool takes some time to get stable. (when de difficulty reaches a good value)
p2pool takes some time to get stable. (when de difficulty reaches a good value)
I improved it abit with the last commit. The fix is a stupid fix. Inserted alot of tests.. Must be a bether way to do this.
Kill the thread? I will build another release, since 64 had bugs.
Kill the thread? I will build another release, since 64 had bugs.
This more looks like a stale share, since shares were sent after pool informed you about the new block.
Yes it is.
I am working on code that will exit the miner threads faster after a new block/diff change.
Ccminer with -i 19 will mine 2048 hashes every round. In the current version it has to wait untill all the 2048 hashes are done, and there are no test to exit before the cpu-test.
Found the bug I think. I put the reset flag in the change difficulty method in utils.cpp. Again testing something and it got commited. There is a problem when the pool is changeing the difficulty rapidly. ccminer will submit shares with the old difficulty, and you get reject rates.. Try lyra2v2 on p2pool.pl 5% reject rate.
I hope you know that by stratum specifications, when miner receives new diff, that diff shall be used for every next job. And NOT current jobs as so many miners (even official cgminer) and many pools work wrong way.
When coding a miner, it is simply best to have another variable in job/work structure called diff. Compare each share to this diff.
When pool provides new diff, you just save this diff and apply it to every next job that arrives.
If you make it like this (by official stratum specifications), you will also reach maximum efficiency on NiceHash.
If you use old/wrong principle where new diff is immediately applied, your miners will be loosing few percent of hashrate on NiceHash and causing slight rejects with share above target.
I'm quite familiar with them, and I'm also rather sure this is incorrect. You do NOT apply it to every next job that arrives, it only takes effect after a new job with cleanjobs = true has arrived.
Cleanjobs flag set to true only signals miners to drop all current work and start this new job. It doesn't have anything to do with diff. I don't exactly understand what you are trying to say here with "NOT apply" ?
I do not think you understood me what I wrote, please read again.
Here is more about this: https://bitcointalksearch.org/topic/m.12165885 (with example what is wrong)
We submitted this even to official cgminer, at first, they included the patch, but later revoked as there are many pools that don't work correctly, even ckpool. And since creators of ckpool = creators of cgminer, patch will probably never be in cgminer.
But hopefully, you will not make the same mistake.
Here is more about this: https://bitcointalksearch.org/topic/m.12165885 (with example what is wrong)
We submitted this even to official cgminer, at first, they included the patch, but later revoked as there are many pools that don't work correctly, even ckpool. And since creators of ckpool = creators of cgminer, patch will probably never be in cgminer.
But hopefully, you will not make the same mistake.
A you can see in the picture above. CCminer has a problem when the pool changes the difficulty, but on Nicehash we get few rejects since the default difficulty is much higher than in the p2pool.pl example.
This more looks like a stale share, since shares were sent after pool informed you about the new block.
Found the bug I think. I put the reset flag in the change difficulty method in utils.cpp. Again testing something and it got commited.
That pretty much fixed the low hashrate on pool AND hashrate flooding! :-)
You can revert the "prevent hashrate flooding" fix, now it's kinda reporting dry
I do not think you understood me what I wrote, please read again.
Here is more about this: https://bitcointalksearch.org/topic/m.12165885 (with example what is wrong)
We submitted this even to official cgminer, at first, they included the patch, but later revoked as there are many pools that don't work correctly, even ckpool. And since creators of ckpool = creators of cgminer, patch will probably never be in cgminer.
But hopefully, you will not make the same mistake.
Here is more about this: https://bitcointalksearch.org/topic/m.12165885 (with example what is wrong)
We submitted this even to official cgminer, at first, they included the patch, but later revoked as there are many pools that don't work correctly, even ckpool. And since creators of ckpool = creators of cgminer, patch will probably never be in cgminer.
But hopefully, you will not make the same mistake.
A you can see in the picture above. CCminer has a problem when the pool changes the difficulty, but on Nicehash we get few rejects since the default difficulty is much higher than in the p2pool.pl example.
On p2pool.pl I get this when a block is changed and the diff is low. As you can see ccminer uses 0.8 second to shut down the threads, and by that time it has found alot of solutions.. The hashrate is also lower when the default diff is as low as this..
you can reproduce with this bat:
ccminer.exe -a lyra2v2 -u Vpir9UQWjDmajnC81eNS6nXVH2qAGos6Ma -p d=x -o http://eu.p2pool.pl:9171
I will try to solve it.
you can reproduce with this bat:
ccminer.exe -a lyra2v2 -u Vpir9UQWjDmajnC81eNS6nXVH2qAGos6Ma -p d=x -o http://eu.p2pool.pl:9171
I will try to solve it.
Jump to: