Got many REJECTED when not overriding worker details
p4u opened this issue · 11 comments
When trying to use the proxy WITHOUT -cu, -cp and -cs options (so miners send directly their packets with the original worker information), I get many REJECTS (not all of them but more than 80%). It seems to me that the minig-proxy does not handle properly the job_id or so.
2014-01-30 22:23:54,607 INFO proxy stratum_listener.submit # [23ms] Share from 'worker.sm3' REJECTE:D (-2, u"Job 'bf7f' not found", u"Traceback: <class 'lib.exceptions.SubmitException'>: Job 'bf7f' not found\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/protocol.py:185:dataReceived\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/protocol.py:230:lineReceived\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/services.py:13:_handle_event\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/services.py:81:call\n--- ---\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:134:maybeDeferred\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/services.py:78:_run\n/root/stratum-pools/auto-pool/mining/service.py:168:submit\n/root/stratum-pools/auto-pool/lib/template_registry.py:198:submit_share\n")
2014-01-30 22:23:55,321 INFO proxy stratum_listener.submit # [21ms] Share from 'worker.sm1' REJECTED: (-2, u"Job 'bf7f' not found", u"Traceback: <class 'lib.exceptions.SubmitException'>: Job 'bf7f' not found\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/protocol.py:185:dataReceived\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/protocol.py:230:lineReceived\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/services.py:13:_handle_event\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/services.py:81:call\n--- ---\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:134:maybeDeferred\n/usr/local/lib/python2.7/dist-packages/stratum-0.2.12-py2.7.egg/stratum/services.py:78:_run\n/root/stratum-pools/auto-pool/mining/service.py:168:submit\n/root/stratum-pools/auto-pool/lib/template_registry.py:198:submit_share\n")
I think this is the problem we mentioned in issue #35 ,if use different username for different rigs, we go rejects. I find the first rigs or one of them works fine, the others just got rejects.
This seems to be a pool-related bug. Firstly, proxy doesn't care about usernames, it just resend the string to the pool. Secondly, it works for me:
2014-02-01 16:09:00,511 INFO proxy stratum_listener.submit # [132ms] Share from 'slush.miner1' accepted, diff 1
2014-02-01 16:09:02,458 INFO proxy stratum_listener.submit # [135ms] Share from 'slush.miner2' accepted, diff 1
2014-02-01 16:09:05,797 INFO proxy stratum_listener.submit # [133ms] Share from 'slush.miner1' accepted, diff 1
2014-02-01 16:09:07,744 INFO proxy stratum_listener.submit # [134ms] Share from 'slush.miner2' accepted, diff 1
Proxy also doesn't touch job_id, so your traceback indicates that pool doesn't accept such combination of username/job id for some reason. I bet they don't allow multiple user authorization on single stratum connection...
But, if I use getwork instead of stratum it works fine (nodes get accepted all time). However the "log.warning()" calls in the getwork_listener.py seems not to print the information about the accepted/rejected jobs. Any idea about why?
I'll try to debug this problem a little more and test some other pools.
I've been debuging this problem a little more but I'm not able to find why is it happening.
First of all, I've tested the latest mining-proxy software with several pools (the most known).
Second, I'm using scrypt
I've captured the packets going and coming from the pool with WireShark. You can find the pcap file here: http://dabax.net/files/stratum80.pcapng
Just use "wireshark stratum80.pcapng"
The only captured data is the communication between the stratum-pool and the stratum-proxy. So if is easy to understand.
As said, with one single worker it works fine. With more than one, pool starts to submit "REJECTED". If using getwork, it also works fine even with many workers.
Am I the only one experiencing such issue?
I think I have this issue too.
This morning it works fine for me! But there is something different from the pool: it always send the same difficulty for all miners behind the proxy (32). Yesterday, it was sending different difficulties for the workers. So, could it be the "seed" of the problem?
p4u: In packet No.280 server sends to client new job with ID 1b16.
In packet No 281 client (proxy) sends solved share for job 1b16.
In packet 282 server respond with "Job 1b16 not found"
-> I don't see any way how this can be a bug of proxy. I bet the stratum pool doesn't follow the stratum specification and it handles mutiple authorization in some weird way. It would be nice to report this issue to pool owners, maybe they'll explain why they are rejecting such submits.
Dont forget that normal miners (cgminer, bfgminer) dont implement multiple authorizations per stratum connection so its completely possible that pool operators didn't test this feature of stratum properly.
it always send the same difficulty for all miners behind the proxy (32)
It's not bug, its a feature. All miners on single stratum connection uses the same difficulty, because they "act" as single miner.
I'm not saying it is a bug. But it is not always a "good thing". For mining BitCoins where the block time is around 10 minutes, it makes sense. But for other crypto-currencies where the block time is between 30 or 60 seconds (such as dogecoin) it can be a big problem. If the total hashrate of the ring behind the proxy is 10GH/s the difficulty in most of the pools will be set to a high value such as 1024. A single miner of 300/400 KH/s cannot solve this difficulty in less than 30 seconds so it is not able to send any ACCEPTED share.
About my issue, I still don't understand why today works when yesterday the same pool I'm using now was rejecting at least 50% of the shares. As said, the only different thing I can see is that now the difficulty is static (32). Yesterday it was changing all the time.
So, it makes me thing that the problem was because of a bad implementation of the stratum server (why? if the only public existing code is the one you implemented?). As long as I was using a single stratum connection with multiple workers, the stratum server tried to configure different difficulties for each one. So once the difficulty is changed the shares obtained with the old difficulty were discarted (JOB NOT FOUND).
What I don't understand is why it worked if using getwork instead of stratum as proxy server.
Does it makes sense for you?
But it is not always a "good thing".
No, it is always a good thing. Please learn more about how shares, vardiff and submit rate works; this has been discussed zillion-times already.
the stratum server tried to configure different difficulties for each one
This only confirms that its a problem of pool software, because it has problems in dealing of multiple workers on single connection. Please report this issue to affected pools and use single credentials in meantime.