Quote from: bakermining76 on June 19, 2019, 06:32:13 AM

Quote from: efudd on May 13, 2019, 03:34:29 AM

Since the dev pool stay in place even when not being used, if the primary pools are not reachable or otherwise have some connectivity issue, cgminer will automatically fail over to another pool. There is a chance in that scenario that it could make it to the dev pool.

However, when the primary pool recovers, cgminer should automatically switch back within 5 minutes of identifying the pool as responsive again (it has a 5 minute holdback timer to make sure things stabilize).

This scenario could be what you have seen. There should be clear indication in the logs if this were the case.

Regardless, please do let me know if you isolate things any more. I am definitely interested in ensuring everything acts as expected.

Thank you,

Jason

I've run into this issue again, where my Z9 Mini is disconnecting from the pool (presumably to dev fee mine), then won't connect again for several hours or until I restart it. I thought it was just an issue with Prohashing's pool since I wasn't entirely sure I'd seen it at other pools. But recently when I've mined on Slushpool, I'm getting the same issue. Again, I have two Z9 Minis - one works fine at 750Mhz without your firmware, so I only use your firmware on the other, which has to run one hashboard at lower clocks. I switched both over to Slushpool at the same time and the one without your firmware has been connected the whole time, while the one running your firmware has disconnected and submitted no shares to my pool for 2+ hours at least 3 times in the last week - in fact, one of the times was over 6 hours before I realized.

Screenshot of my miner status page showing an example of the latest issue:
https://imgur.com/a/rOXBkde

And my support id:
fe3db4--SNIP--21ea4d

Can you look into this?

Yeah, that is weird. By chance do you have the logfile from this same time? Specifically the lines that say "Switching pool"?

The logs on these rotate quickly... what I'm gonna do for now is flag your system as no-dev-fee though because the last thing I want is for you to be having issues with something you need to run (board that must be run lower clock).

That is active as of 6/19/2019 @ 06:49:27 UTC.

This is not the first time I've seen what you are describing and I have not been able to come up with a reproducible test case. I believe there is a "race condition" (timing issues) that is causing this, but I would have to see a log of the "Switching pool" lines to confirm.

Alternatively, some pool issues can cause it, but I've discounted those since you have a 2nd machine running as an effective control here.

I am sincerely sorry for the challenges you've run into; it is not the experience I want for any user.

(I now have your support ID saved, you can edit it out of your original post now if you'd like -- it is unique to your machine).

Thank you,

Jason