Naming argument errors

[MinerBert]

I experienced the name display problem discussed in this topic on Antminer T9, S9 and L3+ miners. I believe I now know what was causing it for me. Each miner has 3 pools configured. On the miners experiencing the problem, the P0 pool was Prohashing, the P1 pool was a different pool, and the P2 pool was Prohashing. The password n=name argument was the same for the P0 and the P2 configurations for a given miner. I noticed that even when the miners are running well, I occasionally see GetWork operations on the P2 pool configuration--which Prohashing software appears to interpret as a second miner with the same name parameter, causing the problem.

I added an "a" to the end of name parameter for each P2 configuration, and that appears to have fixed (or at least worked around) the problem. I still sometimes see the long numeric name display after network problems have occurred, but it now clears after a few minutes (rather than staying that way for as long as I cared to wait.) I know that name changes cause problems for the miner history information, but I don't use that--I am more concerned with what my miners are doing right now, and knowing which one(s) I need to handle when things go wrong.

[Steve Sokolowski]

I experienced the name display problem discussed in this topic on Antminer T9, S9 and L3+ miners. I believe I now know what was causing it for me. Each miner has 3 pools configured. On the miners experiencing the problem, the P0 pool was Prohashing, the P1 pool was a different pool, and the P2 pool was Prohashing. The password n=name argument was the same for the P0 and the P2 configurations for a given miner. I noticed that even when the miners are running well, I occasionally see GetWork operations on the P2 pool configuration--which Prohashing software appears to interpret as a second miner with the same name parameter, causing the problem.

I added an "a" to the end of name parameter for each P2 configuration, and that appears to have fixed (or at least worked around) the problem. I still sometimes see the long numeric name display after network problems have occurred, but it now clears after a few minutes (rather than staying that way for as long as I cared to wait.) I know that name changes cause problems for the miner history information, but I don't use that--I am more concerned with what my miners are doing right now, and knowing which one(s) I need to handle when things go wrong.

Thanks for figuring this out! This is a huge find. There have been many people who have complained about things like "ghost miners," but we had never been able to determine where they came from.

This issue likely stems from how some mining rigs will connect to all the pools in the list simultaneously, and only submit shares to the first one. These wasted connections will cause a duplicate name error because there will be two connections here with the same name. The only solution to this issue is to update the documentation about it, and I'll do that next week.

It's thanks to customers like you that we are able to resolve hard to find bugs, and I thank you for your service!