Re: [ATTN: POOL OPERATORS] PoolServerJ - scalable java mining pool backend
That's great! And thanks, Luke.
Edit to prevent double post:
There seems to be a (or even two more) different bug(s) related to counting invalid shares as valids. This time, I changed Phoenix to submit every share 10 times with a delay of 1 sec between sends (I'm not sure if the delay works, it might send them instantly..). The first share was counted as "valid" two times, and "invalid" two times as well, so a total of 4 shares were recognized. I'm not sure if phoenix stopped sending the share after the 4th time, or otherwise 6 shares were sent but not registered as valid/invalid.
I assume phoenix then found a second nonce in the same getwork, this time producing 10 valid shares. That bug is probably in WorkProxy.java, line ~186.
Moving "entry.solutions.add(data);" below that if/else if should fix this. There's still the problem with the first nonce in a getwork accepted multiple times, but not infinitely often.
Update:
python does not respect my time.sleep(1), so all the nonces are sent without delay. The problem with identical shares being accepted multiple times could be a race condition. This is from the phoenix log:
Yet another update:
My suggestion to move "entry.solutions.add(data);" below the if/else if is wrong, it should probably go pretty far down the validation method, maybe after checking the hash. That should fix the double-accepts.
Are "duplicate" rejects not getting logged on purpose?
(Omg, I'm spamming this thread, sorry!)
Edit to prevent double post:
There seems to be a (or even two more) different bug(s) related to counting invalid shares as valids. This time, I changed Phoenix to submit every share 10 times with a delay of 1 sec between sends (I'm not sure if the delay works, it might send them instantly..). The first share was counted as "valid" two times, and "invalid" two times as well, so a total of 4 shares were recognized. I'm not sure if phoenix stopped sending the share after the 4th time, or otherwise 6 shares were sent but not registered as valid/invalid.
I assume phoenix then found a second nonce in the same getwork, this time producing 10 valid shares. That bug is probably in WorkProxy.java, line ~186.
Code:
if (entry.solutions == null) {
entry.solutions = new ArrayList(10);
entry.solutions.add(data);
} else if (entry.solutions.contains(data)) {
return buildGetWorkSubmitResponse((Integer) request.getId(), false, "duplicate");
}
When the second share of the same getwork is received, "entry.solutions != null" and "entry.solutions.contains(data) == false", so the second share is accepted (this is correct behaviour). However, unless this happens elsewhere in the code, the second nonce is *not* added to entry.solutions, so it can be sent infinitely often and will award a valid share every time.entry.solutions = new ArrayList(10);
entry.solutions.add(data);
} else if (entry.solutions.contains(data)) {
return buildGetWorkSubmitResponse((Integer) request.getId(), false, "duplicate");
}
Moving "entry.solutions.add(data);" below that if/else if should fix this. There's still the problem with the first nonce in a getwork accepted multiple times, but not infinitely often.
Update:
python does not respect my time.sleep(1), so all the nonces are sent without delay. The problem with identical shares being accepted multiple times could be a race condition. This is from the phoenix log:
Quote
[19/08/2011 18:19:31] Result: e36b1881 accepted
[19/08/2011 18:19:31] Result: e36b1881 accepted // and indeed, this share was logged twice by PoolServerJ as "valid"
[19/08/2011 18:19:31] Result: e36b1881 rejected
[19/08/2011 18:19:31] Result: e36b1881 rejected
[19/08/2011 18:19:31] Result: e36b1881 rejected
[.. 5 more rejects]
The rejects are not logged in PoolServerJ, so I guess they fail because of connection issues (sending 10 shares at the same moment might cause problems in phoenix).[19/08/2011 18:19:31] Result: e36b1881 accepted // and indeed, this share was logged twice by PoolServerJ as "valid"
[19/08/2011 18:19:31] Result: e36b1881 rejected
[19/08/2011 18:19:31] Result: e36b1881 rejected
[19/08/2011 18:19:31] Result: e36b1881 rejected
[.. 5 more rejects]
Yet another update:
My suggestion to move "entry.solutions.add(data);" below the if/else if is wrong, it should probably go pretty far down the validation method, maybe after checking the hash. That should fix the double-accepts.
Are "duplicate" rejects not getting logged on purpose?
(Omg, I'm spamming this thread, sorry!)