-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sanity check: one rig times out on all pools but dwarfpool #19
Comments
This is not normal behaviour in my opinion.
By the way v0.2.3b has built in injector you may give it a try. |
LOL copy and paste from the issue under mine. Sorry about duplicating that. I wasn’t sure if the same applied for me, his error messages were way different than mine. I was just wondering if during this time of it waiting and searching for a pool to successfully connect to (seems only dwarfpool), is it really doing any harm or hindering anything? Thanks again. |
Need full log running for at least few hours (both claymore log and nodevfeeLog.txt) to try understand what is going on. There are different errors - (Authorization error / Socket was closed by pool) but seems like same problem pool does not like authorization packets. I think this may be harm, cause all this time it tries to recconect to devfee pool is wasted not on mining. Update: Similar problems occurred here - #4 #5 #17 If nothing helps only solution is to rebuild whole devfee packet structure and change it from |
Thanks a lot for your willingness to help. I wouldn't have the slightest idea how to rebuild anything :\ I took the easy way out for now and remoted in to specify - esm 0 (as it looks like that’s what nanopool uses) and I created the nodevfeelog and will let it run a few hours. I killed the process so I couldn’t see if it was ok after eth_submitLogin ->. I’ll have more in a few hours. Thanks! |
Here’s about 5 hours worth of both nodevfee and the miner log. I also took a screenshot of it trying to reconnect then finally successfully to the only dev pool that works, dwarfpool. I see in between this it still caught a share so that makes me feel like its not sitting there wasting time at least. I swear I don’t see this on my 8 GPU rig and its running the same of everything to my knowledge. I've touched nothing in a few months. Its so weird. Thanks again for your time. |
According to log it is exactly what I was saying, similar behaviour as all previous occasions. In your case-
If setting Overall it requires rebuild of whole devfee packet structure and change it from |
Thanks a lot for the time and explanation. I just wanted to confirm with you that my 8 GPU rig is indeed doing the same lame thing. The few times I was looking it just happened to pick dwarfpool first. I see the same try/time out till finding dwarfpool routine now. I just want to say say that something absolutely changed then, likely on the pool(s) side. I am certain that it didn’t used to do this till just recently. Also you said Ethermine supports both ESM 0/1, I am sure that the devfee never successfully connects to Ethermine (only dwarfpool). Adding ESM 0 to the bat file made no difference. I don’t know if you meant I had the ability to rebuild something (I don’t know the first thing about coding) but it seems to not be making any serious problems. On my 8 GPU rig (which gets shares faster) I see it catching shares the whole time while its connecting/disconnecting dev pools hunting for dwarfpool. Again in the end something somewhere has changed likely on the pool side. I’ve made 0 changes in months. I’m sticking with nanopool though, I’ve tried all the big players and I have the best results there. Thanks again for your work and time here. |
I think Claymore choose devfee pool randomly (or by some specific algorythm - by order or by ping). Fixing it requires update in nodevfee code, no simple solution. I dont know exact implementation of devfee, but I think main mining is slowed down while devfee is mining and devfee takes 2% of mining time, so it might waste more time on finidng right server and might decrease your mining efficiency, but I cant tell for sure. By the way do you use Update: seems to work fine on nanopool without
|
No I don't use the -allpools command. I just logged in to double check. To your comment before I've kept all versions of claymore. Both rigs have been on v10.0 for months per your request back when you first made this utility. I haven't tried 9.7 though and I think I saw you mention that as well. |
you might wanna try this one: Edit: stop spamming links! |
Hi Demion,
I’ve been using your solution since you first created the github page on it but I’m noticing something odd that only shows up on my 4 GPU rig (oddly not on my 8 GPU rig). I’m just checking to see if you’ve seen this or if you think its impacting my shares. It seems like it will try a few pools and from the logs it only (thinks) it connects successfully to dwarfpool. Any other pool it seems to time out. I’m also not using your huge pool listing rather one I made months ago of pools I saw.
This is on nanopool using your 0.2.2b, Claymore v10.0 and external DLL injector via ExtremeInjectorv3 (been solid for months).
Thanks for your work.
The text was updated successfully, but these errors were encountered: