Underscores/worker names reports

[Steve Sokolowski]

There are some users who are reporting issues with mining when they use underscores in the "n=" worker name password argument. However, I just spent 30 minutes testing this issue and was not able to reproduce the problem.

Is anyone here affected by this problem? What specific worker names are you using?

[youdontknowmu]

Hi there,

I'm using underscores and don't encounter issues.

[Bertilax]

All my miners use underscores - never had problems and no problems now either.

[AppleMiner]

We had some users who were seeing prohashing site as DEAD for going on 20+ mins, Rebooted, still saw it DEAD for another 10+ mins.
Removed the _ from their workernames and saw it as ALIVE shortly after applying changes. It could have been just any change would have allowed it to see it as ALIVE and connect in. Or it could have been dumb luck and slots for workers just opened up. But 2 people had the change work for them, and then 2 people posted screenshots of worker names with underscores working fine, so not sure.

I have also had the issue in the past where my miners would half see the site as ALIVE and half DEAD, and restarting the machines and switches and routers would have no effect on the miners that still showed DEAD, but then changing the account names to mine on a test account and hitting apply and 2 mins later they would see PH as ALIVE and connect in.

My issues with the account names was way back in september after the first move and i think after the first round of ddos attacks and floods and the counters to those attacks, way before the nov. upgrades. It seemed like some miners were in some cache either on my end trying to connect, or the pool saw it as a dead process and wouldnt allow it to connect back in. Changing the account name or in this case the worker name may have forced a fresh connection that wasnt cached somehow and allowed the connection to be re-evaluated? And then allowed the connection to be made?

As a test, I guess if people are going long times seeing the pool as DEAD, try altering the worker name a bit and applying the changes and see if it picks up the pool as ALIVE for them?

[ZiGen]

There are some users who are reporting issues with mining when they use underscores in the "n=" worker name password argument. However, I just spent 30 minutes testing this issue and was not able to reproduce the problem.

Is anyone here affected by this problem? What specific worker names are you using?

I am using underscore in my miners' names since the beginning of using Prohashing - mid September 2017. They are "n=al3_1", al3_2, etc., and never had to change them. No problems on my side at all.

[Aura89]

We had some users who were seeing prohashing site as DEAD for going on 20+ mins, Rebooted, still saw it DEAD for another 10+ mins.
Removed the _ from their workernames and saw it as ALIVE shortly after applying changes. It could have been just any change would have allowed it to see it as ALIVE and connect in. Or it could have been dumb luck and slots for workers just opened up. But 2 people had the change work for them, and then 2 people posted screenshots of worker names with underscores working fine, so not sure.

I have also had the issue in the past where my miners would half see the site as ALIVE and half DEAD, and restarting the machines and switches and routers would have no effect on the miners that still showed DEAD, but then changing the account names to mine on a test account and hitting apply and 2 mins later they would see PH as ALIVE and connect in.

My issues with the account names was way back in september after the first move and i think after the first round of ddos attacks and floods and the counters to those attacks, way before the nov. upgrades. It seemed like some miners were in some cache either on my end trying to connect, or the pool saw it as a dead process and wouldnt allow it to connect back in. Changing the account name or in this case the worker name may have forced a fresh connection that wasnt cached somehow and allowed the connection to be re-evaluated? And then allowed the connection to be made?

As a test, I guess if people are going long times seeing the pool as DEAD, try altering the worker name a bit and applying the changes and see if it picks up the pool as ALIVE for them?

What happens if you set two miners with the same name?

If one of them ends up showing the pool as dead, then i wonder if the pool periodically thinks a miner is connected when its not based on its name?

But if they can both connect still, then i don't think the cache issue would be relevant?

[AppleMiner]

They later put in place if 2 miners connect in with the same worker name one was assigned that id 123-2321312-354212334-2121
so you could still track it, but it was just random string of numbers, but that was once it actually would connect in if it had 2 workers with the same names, this was the pool itself showed DEAD, but after changing a setting, in this case the worker name, and restarting it then saw it ALIVE and was able to connect.

Back in early September, I had 12+ going pre-worker limits and some would see pool as alive, some would see it as DEAD it was confusing, restarting and repowering everything wouldnt change it, then swapping what account username the DEAD ones were told to connect to, 90 sec reboot later and poof they saw the pool as ALIVE and would mine. Sometimes swapping the usernames back hours later would keep it ALIVE and sometimes DEAD. Made me wonder if there wasnt an issue with multiple miners on the same account. I once tested all the miners on separate accounts to check and wasnt any different.