@deepceleron
That is completely baffling to me... I use the EXACT same code to determine which hashes to send as diapolo (from the poclbm kernel).
How are you getting the hash results?
If they are from the server, then i'm pretty sure they never will be 00000.... because the rejection comes because of a mismatch in state data, so the hash comes out different on the server than on your client, right?
If they are from the Client, are you running a modified version of phoenix? I don't think the stock phoenix logs that information. If you are, could you post details, so I can look into the bug.
Two miner instances per GPU.
Why are you running 2 instances per GPU? That seems like it would just increase overhead and double the amount of stales. Try only running 1 instance per GPU and perhaps decreasing the AGGRESSION from 13 to 12. If that doesn't fix it, I'm not sure what else I can do without further information.
Anyone else getting this bug?
The output that I pastebinned is the standard console output of phoenix in -v verbose mode, I just highlighted the screen output on my console (with a 3000 line buffer) and copy-pasted it. It includes the first eight bytes of the hash in the results as you can see.
Actually when I said that it was unmodified phoenix that I was running, I lied, by forgetting I had done this modification at line 236 in KernelInterface.py (because of a difficulty bug in a namecoin pool I was previously using):
Original:
if self.checkTarget(hash, nr.unit.target):
formattedResult = pack('<76sI', nr.unit.data[:76], nonce)
d = self.miner.connection.sendResult(formattedResult)
def callback(accepted):
self.miner.logger.reportFound(hash, accepted)
d.addCallback(callback)
return True
else:
self.miner.logger.reportDebug("Result didn't meet full "
"difficulty, not sending")
return False
Mine:
formattedResult = pack('<76sI', nr.unit.data[:76], nonce)
d = self.miner.connection.sendResult(formattedResult)
def callback(accepted):
self.miner.logger.reportFound(hash, accepted)
d.addCallback(callback)
return True
All I've done is remove the second difficulty check in phoenix, and trust that the kernel is returning only valid difficulty 1 shares. Now, instead of spitting out an error "Result didn't meet full difficulty, not sending", phoenix sends on all results returned by the kernel to the pool. Without this mod, logs of your kernel would just show a "didn't meet full difficulty" error message instead of rejects from the pool, which would still be a problem (but the helpful hash value wouldn't be printed for debugging). We can see from the hash value that the bad results are nowhere near a valid share.
This code mod only exposes a problem in the kernel optimization code, that sometimes wild hashes are being returned by the kernel from some bad math (or by the kernel code being vulnerable to some overclocking glitch that no other kernel activates.) Are these just "extra" hashes that are leaking though, or is the number of valid shares being returned by the kernel lower too - hard to tell without a
very long statistics run.
I am running two miners per GPU not for some random reason, but because it works. With the right card/overclock/OS/etc, I seem to get a measurable improvement in total hashrate vs one miner (documented by using the phoenix -a average flag with a very long time period and letting the miners run days). The only way my results could not be true would be if the time-slicing between two miners messes up the hashrate calculation displayed, but if this was true, such a bug would present with multiple-gpu systems running one phoenix per gpu too.
With only a 1% improvement from a kernel that works for me, reducing the aggression or running one miner would put the phatk 2.1 performance below what I already had. Putting back the diapolo kernel, I'm back to below 2500/100 on my miners.
My python lib versions are documented
here.
Joulesbeef:
I don't like the word 'stales' for rejected shares unless it specifically refer to shares rejected at a block change because they were obsolete when submitted to a pool, as logged by pushpool. The results I have above are not stale work, they are invalid hashes.
!