Current known system issues

[gpopprohashing]

Hi guys! Finally Live Worker Status got populated again and error reads: "This miner attempted to authenticate with a duplicate worker name, so its n= password argument is being ignored" Can this cause any hashing issues? Any info would be greatly appreciated since I'm not familiar with PH...

[AppleMiner]

No its normal, if you restart the miner when it reconnects the next time it should have its original name back.
When the miner connects in and the old worker name in use hasnt been disconnected from the server yet it gets a randomized ID number assigned just so it can be tracked.

Ideally you want to give each miner its own unique n=workername so you can monitor each miner separately. But if you used all the same or miners reconnect and show strange ID names, they are still producing hashing and shares and you are still earning coins.

[gpopprohashing]

OK, i just did that a few minutes ago and indeed the name came back. Hope it will stick this time since I restarted it before. As long as I'm not losing shares, I'm happy! Thank you AppleMiner!

[spauk]

You say that it will find a share eventually even on 65536 difficulty, how long should we wait to see a share (i realize it also depends on hashrate, so for example 2x 28mh/s miners)? The dynamic difficulty never seems to go lower even after several hours of hashing without submitting any shares. Shouldn't dynamic difficulty adjust lower after a few minutes if no shares submitted? I guess this isn't a bug with the mining server so much it is with the miners, but dynamic difficulty could work better. And it totally does affect profit if no shares are being submitted at all.

[AppleMiner]

Is there a minimum hashrate under which you might not appear to generate enough shares to be recognized at the default initial difficulty setting of the pool?

Steve Chris?
with the increase in difficulty has that now imposed a 'base' level that workers connecting in have to be on or above in order to mine and get shares now?

[spauk]

i wouldn't be surprised if anything less than 100 mh/s won't work here anymore until they change the difficulty options. but it probably depends on the miner. i haven't figured out why my zeus miners (thunder x3 first gen) won't submit any shares at 65536 or higher, even on other pools it doesn't seem to work. but i could get shares at 32768 within about 2 or 3 minutes and submitted difficulty is often at least 65536. i just tried another pool (granatgas) where i can set the static difficulty in increments of 2 instead of powers of 2, i tried to set it a bit lower than 65536 and it will start submitting shares at 65534.

[kwibis]

Been reading here and it seems I am still experiencing some connectivity issues. I am mining with 2 D3's here and the miners are switching to my next pool every now and then as they do not receive work from this pool. I have not set a static diff. Anything I am missing? Or is there a server issue still?

[Steve Sokolowski]

Been reading here and it seems I am still experiencing some connectivity issues. I am mining with 2 D3's here and the miners are switching to my next pool every now and then as they do not receive work from this pool. I have not set a static diff. Anything I am missing? Or is there a server issue still?

What connectivity issues are you experiencing? Could you provide more details about the issue?

[kwibis]

Sorry, yes. The miner switches to the 2nd pool configured even though prohashing is still online. The LStime in the antminer status shows then e.g. 2 minutes, while upon refresh it should just be zero.

[OrcephRye]

Hello,

I redirected one of my miners over to this site to see if it is worth the switch 11 hours ago.

So far the only major issue is the "Live worker status" section under the Earnings tab doesn't always show my miner. It appears that it disconnects for a while then comes back.

The issue sounds similar to:

Some users are reporting that miners are not displaying in the "live coin status" portion of the "earnings" page. We have not been able to reproduce this issue, but we were able to confirm that no money is being lost because of it. As soon as we can figure out a reproducible test case, we'll look into it.