Repeating high-effort dry spells on Nano after ~2 months of use #180
Replies: 3 comments
|
300-400% is entirely within reason to see somewhat commonly in statistical variance. That is on the scale of a bit 5%-2% chance to have received zero shares. You may perhaps notice it more often on Nano because, of course, you're seeing more shares, so there's statistically more opportunities. The highest I have personally canonically confirmed was on the scale of ~1000% (which was incidentally on P2Pool main, because I watch the XvB raffle), which is on the scale of 0.005% chance to have not yet found a share (so, entirely statistically plausible to see rarely over a long period of time). The nice thing about not panic resetting is you'll get to see your true average, which should be relatively close to 100%. At the time of writing this, where I haven't personally reset for ~22 days, I've incidentally gotten relatively lucky and have an average of 92%. This includes multiple occasional high effort shares on the scale of 400%+, but also some moments where luck gets absolutely absurd and I see less the 1% effort. |
|
Thanks for the detailed reply — I appreciate you taking the time. I understand that what I’m seeing is largely statistical variance on Nano, especially since I’m generating more shares, which naturally leads to more noticeable dry spells. That makes sense. However, I’ve noticed a very repeatable pattern: after a restart of P2Pool (or the whole app), I typically get 2–3 Current Shares within 1–3 days. Then effort climbs high (often 300%+) and I sit at 0 Current Shares for many days. Restarting again usually restarts the cycle with new shares appearing relatively quickly. I realize restarting doesn’t actually change the underlying probability, but it does appear to clear the internal session state and the ZMQ/RPC connection between XMRig and P2Pool. This often results in shares registering more effectively in the PPLNS window again. Is it possible that something on the back end (ZMQ timing, session state, or connection health) is getting slightly “stuck” after several days, even though everything shows green and the logs look normal? Or is this purely normal variance and I should just let it run through 500–1000% effort periods without restarting? I’m trying to find the right balance between accepting statistical reality and not wasting excessive CPU/electricity on very high-effort stretches with zero Current Shares. Any insight you have would be really helpful. Thanks again, |
This repeatable pattern is statistically expected. It's a very simple truth that a higher effort share, you are more likely to notice the existence of, because it of course lasts longer (especially if your hashrate is otherwise relatively low, which, since you mention sometimes you have 0 shares, I imagine your hashrate is quite low) Now, of course, restarting does not lose you a significant amount of time, so if it makes you feel better, you're not losing that much by doing so, but no, it doesn't actually help you. As long as you are seeing the effort number go up, you are in fact "progressing". This is a true number, not a calculated time estimate |
Uh oh!
There was an error while loading. Please reload this page.
I’ve been running Gupax for almost 2 months now on the Nano sidechain (~1.1 kH/s) and I’ve noticed a consistent pattern:
After restarting P2Pool (or the whole app), I typically get 2–3 Current Shares within 1–3 days, often with effort below 100%. This usually results in 1–2 payouts.
Then I enter a long dry period — sometimes 5+ days with effort climbing above 300% (I’ve seen spikes over 700%) and zero Current Shares.
I usually restart at that point, and the cycle repeats (new shares appear within 1–3 days).
Is this simply normal statistical variance / bad luck on Nano (correlation, not causation)? Or could something in the session state, ZMQ connection, or P2Pool behavior be contributing to these prolonged high-effort periods with no Current Shares?
I’ve avoided letting effort go beyond ~300–400% because it feels like wasted resources, but I’m happy to let it run longer if that’s the expected behavior.
Thanks in advance for any insight.
All reactions