Sanity check: one rig times out on all pools but dwarfpool

[TPSreports]

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.

[Demion]

This is not normal behaviour in my opinion.

As far as I understand, devfee use different pools and different protocols (-esm 0 / -esm 1) according to each pool. Only thing you can do is use pool which accept both protocols (like ethermine for instance) or you can try forcefuly set -esm 0 / -esm 1 in your bat file, but that might not help, no other solution so far.

By the way v0.2.3b has built in injector you may give it a try.

[TPSreports]

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.

[Demion]

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: You can check if it only fails after eth_login -> and is ok after eth_submitLogin ->. If that is the case you can try specify -esm 0 in bat file (may not help) or change pool which supports both protocols.

Similar problems occurred here - https://github.com/Demion/nodevfee/issues/4 https://github.com/Demion/nodevfee/issues/5 https://github.com/Demion/nodevfee/issues/17

If nothing helps only solution is to rebuild whole devfee packet structure and change it from -esm 1 to -esm 0 or vice versa.

[TPSreports]

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!

[TPSreports]

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.

1517854844_log.txt

nodevfeeLog.txt

[Demion]

According to log it is exactly what I was saying, similar behaviour as all previous occasions. In your case-

1. nanopool only supports -esm 0 (eth_submitLogin).
   2. devfee first tries to connect to devfee pools which use -esm 1 (eth_Login) - ethpool, ethermine (although ethermine supports both protocols).
   3. devfee pool is redirected to nanopool but it fails to authorize cause nanopool only supports -esm 0 (eth_submitLogin).
   4. finally devfee tries to connect to dwarfpool which uses -esm 0 (eth_submitLogin) which is supported by nanopool so redirection and authorization succeeds.

If setting -esm 0 in bat does not help, then only solution is switch to pool that supports both protocols (like ethermine for instance) or bear with it (I dont like it cause it may waste your mining time, you need to check it for yourself).

Overall it requires rebuild of whole devfee packet structure and change it from -esm 1 to -esm 0 or vice versa.

[TPSreports]

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.

[Demion]

I think Claymore choose devfee pool randomly (or by some specific algorythm - by order or by ping). I have no idea why it is changed, unless you updated Claymore version. Ethermine supports both protocols, but is only useful if it is your main pool (and devfee redirected pool).

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 -allpools option? If devfee can mine to nanopool without -allpools then maybe better solution is not use it.

Update: seems to work fine on nanopool without -allpools mining directly to nanopool

DevFee: ETH: Stratum - connecting to 'eth-eu2.nanopool.org' <92.222.10.59> port
9999
NoDevFee: eth_submitLogin -> 0xcb4effdeb46479caa0fef5f5e3569e4852f753a2
DevFee: ETH: Stratum - Connected (eth-eu2.nanopool.org:9999)
ETH: Authorized
DevFee: start mining
DevFee: ETH: 02/06/18-21:08:32 - New job from eth-eu2.nanopool.org:9999
ETH: 02/06/18-21:08:32 - New job from eth-eu2.nanopool.org:9999
ETH - Total Speed: 28.539 Mh/s, Total Shares: 1, Rejected: 0, Time: 00:19
ETH: GPU0 13.391 Mh/s, GPU1 15.147 Mh/s
GPU0 t=39C fan=40%, GPU1 t=46C fan=40%
DevFee: ETH: 02/06/18-21:09:00 - New job from eth-eu2.nanopool.org:9999
ETH: 02/06/18-21:09:00 - New job from eth-eu2.nanopool.org:9999
ETH - Total Speed: 29.257 Mh/s, Total Shares: 1, Rejected: 0, Time: 00:20
ETH: GPU0 14.035 Mh/s, GPU1 15.222 Mh/s
GPU0 t=39C fan=40%, GPU1 t=46C fan=40%
DevFee: stop mining and disconnect

[TPSreports]

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.

[Demion]

You can try -retrydelay 1 for faster switch to needed pool (dwarpool in your case). Thanks for idea to rvsh2 at https://github.com/Demion/nodevfee/issues/25

[grml123]

you might wanna try this one: seems to work for me, I test ran two rigs for 12h and compared. ups my hashrate reported on nanopool bis 2-3%

Edit: stop spamming links!