lolMiner-releases
lolMiner-releases copied to clipboard
Lolliedieb
ZIL too many rejected shares with 1.68...1.72
Hi I'm using lolminer-1.68.SwitchHiveOS.tar.gz and I have 20-30% of invalid shares mining ZIL with a well probed low OC profile. I don't have this problem with 1.67 so I think maybe there is a bug in 1.68 I used this parameters with 6 nvidia 3090: NEXA,pool.woolypooly.com:3124,WALLET.%WORKER_NAME%,{--coff 255,210,210,210,210,210 --cclk 1560,1740,1740,1740,1740,1740 --mclk 5001 --pl 350,350,350,350,350,350} ZIL,ssl://etchash.auto.nicehash.com:443,WALLET,{--cclk 1100 --moff 1800 --coff 0 --pl 350 --ethstratum ETHV1}
I fully confirm., I also have a lot of red zil shares in hivos and in windows.
I also noticed a very large number of connections on port 5000. Apparently this is for switching to zil. I closed port 5000, but it broke the switch to zil. I would like the miner not to create 10 thousand states.
Yes the 5000 is to check the windows hehe... if you closed no Windows ZIL to check :-) it is connecting to a ZIL Node
Is it possible to reduce the number of states? other miners (I will not name them here) do not create such a huge network flow, although they also switch to zil in time. I'm not very good at this, but this seems wrong to me
VPN tcp 192.168.15.7:25707 (192.168.1.5:49292) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49294 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:44417 (192.168.1.5:49294) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49298 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:34363 (192.168.1.5:49298) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49300 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:9335 (192.168.1.5:49300) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49302 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:59866 (192.168.1.5:49302) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49306 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:17622 (192.168.1.5:49306) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49308 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:7108 (192.168.1.5:49308) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49310 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:13574 (192.168.1.5:49310) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49316 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:59343 (192.168.1.5:49316) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49320 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:27167 (192.168.1.5:49320) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4
And there are thousands of such connections. And all my other devices add up to 200-300.
Is it possible to reduce the number of states? other miners (I will not name them here) do not create such a huge network flow, although they also switch to zil in time. I'm not very good at this, but this seems wrong to me
VPN tcp 192.168.15.7:25707 (192.168.1.5:49292) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49294 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:44417 (192.168.1.5:49294) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49298 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:34363 (192.168.1.5:49298) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49300 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:9335 (192.168.1.5:49300) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49302 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:59866 (192.168.1.5:49302) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49306 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:17622 (192.168.1.5:49306) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49308 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:7108 (192.168.1.5:49308) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49310 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:13574 (192.168.1.5:49310) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49316 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:59343 (192.168.1.5:49316) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4 / 3 396 B / 164 B MINING tcp 192.168.1.5:49320 -> 99.83.212.14:5000 ESTABLISHED:FIN_WAIT_2 4 / 3 396 B / 164 B VPN tcp 192.168.15.7:27167 (192.168.1.5:49320) -> 99.83.212.14:5000 FIN_WAIT_2:ESTABLISHED 4
And there are thousands of such connections. And all my other devices add up to 200-300.
Sure that will be solve with the release in lolMiner... you are right is a small ping to check if ZIL start... Not the best way, it was a fast way until it is properly coded in the miner. I'm sure we will see it quite soon working as you desire
I still have many rejected shares under 1.70 to nicehash I can see the message "Share is stale (78ms)" under HiveOS but under Nicehash was rejected
You cannot connect without the ETHV1 to nicehash, he use nicehash proto
As you can see in my first post, I already use the --ethstratum ETHV1 parameter.