icemining reward latency
Why 50ms vs 150ms ping barely moves rewards here.
icemining's internal job and share path is designed to be extremely low latency. That means miner ping mostly shows up as a narrow job-change edge, not as a broad reward penalty. If we credit that recent edge with a smooth decay, 50ms versus 150ms ping becomes a small rewards effect.
The short version: on a fast 5s chain, 150ms ping is about 0.79% uncredited tail after decay. On a normal 60s chain, it is about 0.066%. Slower chains make the difference smaller again.
Fast chain · 5s blocks
Even the fast-chain case is mostly an edge-tail problem.
Normal chain · 60s blocks
At normal block times, ping barely moves expected rewards.
For slower-than-one-minute block times, the ping effect gets smaller again because the same milliseconds are divided by a longer block interval.
Share quality
What Good, Recovered, Late, and Rejected mean.
Good — shares that arrived on the current job and counted in full. On a healthy worker this is almost all of them.
Recovered — shares that landed just after their job retired, but recently enough to earn smooth decayed credit toward your next payout window. A stricter pool would throw these away; icemining's low internal latency keeps that tail tiny and pays most of it back, so a small Recovered count is normal and is real work you still get paid for. The decay rule is in the math below.
Late — shares that arrived past the decay window, so they carry little or no weight. A climbing Late count usually points to ping or job-delivery delay rather than a broken rig.
Rejected — shares the pool could not accept at all (too stale to use, duplicate, or invalid). These never pay, and a rising Rejected count is worth investigating.
The icemining rule
Our low internal latency lets us credit the edge.
The part icemining controls is the pool-side path: job fanout, share receive, validation, and accounting handoff. That path is built to stay lean, so we do not need a large late-share window to compensate for our own infrastructure.
What remains is the miner-side edge around a job change. A share can arrive just after the old job is retired even though it still represents real work sent during the transition. Counting that share for the just-found block would be wrong, but denying all credit is also too harsh.
The policy should be: no old-block claim, no miner-reported timestamps, and no hard cliffs. Measure lateness by pool receive time versus the pool's own job-retired timestamp, then give very recent ordinary shares decayed forward accounting credit.
This is why the page models both cases. First it shows the pessimistic "deny the whole ping tail" math. Then it shows the actual icemining direction: because our internal latency is already tiny, a small decayed grace tail is enough to make ping differences mostly irrelevant for rewards.
Block time matters too. The same 150ms reported ping is a much smaller reward issue on a one minute block-time chain than on a five second block-time chain, because the job-change edge is spread across a longer expected block interval.
Python model plot
The pessimistic case: denying the whole ping tail.
Python model plot
What outright denial would mean on expected monthly earnings.
Python model plot
Where hidden latency starts to matter more than ping.
Python model plot
How a decayed late-share grace tail would treat 50, 100, and 150ms ping.
Hidden latency
Node.js stratum delay can dominate the number miners see.
A pool built on a Node.js stratum can have higher internal tail latency than its public ping suggests. JSON parsing, event-loop backlog, single process fanout, and garbage collection do not show up in a simple ICMP or TCP ping, but they can delay job broadcast and share handling.
Blockchain jobs also have inherent upstream delay. A pool cannot publish the correct next job before its daemon sees the new tip, validates it, chooses the next template, and hands that candidate to stratum. On fast chains, that upstream job-source delay can be bigger than the miner's ping difference.
Expandable math
The earnings impact model, step by step.
1. Convert ping into stale hash time
Miner ping is normally round-trip time. Job freshness is closer to one-way arrival time, so the ping-only stale window is:
With 100ms reported ping, the raw one-way edge is roughly 50ms regardless of block time.
2. Convert stale hash time into expected earnings impact
If slightly late shares receive no credit, block arrivals are modeled as a Poisson process. The raw exposure is the probability that a new block appeared inside the stale window:
On five second blocks and 100ms reported ping:
On a one minute block-time chain, the same 100ms ping is:
3. Add internal pool and daemon latency
The miner-visible ping term is only one component. The stale window that affects expected earnings is closer to:
This is why a pool with a lower ping can still produce worse expected earnings if it has worse tail latency in the stratum server, template source, or job fanout path.
4. Translate the fraction into percent and dollars
For an expected monthly earning amount E, the no-grace dollar exposure is:
With E = $1,000, RTT = 100ms, and B = 5s, the no-grace model says about 0.995%, or $9.95/month. The difference between 50ms and 150ms ping is about 50ms one-way, which is roughly 0.99%, or about $9.90/month on the same $1,000 model before late-share credit.
With B = 60s, the same 100ms ping is only about 0.083%, or $0.83/month on a $1,000 model before late-share credit. At that block cadence, miner ping differences become even less meaningful for rewards.
5. If crediting late shares, use decay instead of cliffs
For shares from the immediately retired job, a smooth credit curve avoids payout jumps around arbitrary thresholds:
That gives about 78% credit at 25ms late, 61% at 50ms, and 47% at 75ms, then the pool can hard-reject beyond a small cap such as 250-300ms on a five second chain. This credit should feed future share accounting only, not the just-found block.
The key is that icemining's internal latency budget is already tiny. With a lean stratum path, the late-share tail is mostly the miner and network sitting on the edge of a job change, so a narrow decayed grace window is fairer than denying every slightly late share outright.
With this example curve, average 50ms, 100ms, and 150ms ping imply roughly 25ms, 50ms, and 75ms one-way lateness at the job edge. The corresponding forward credit weights are about 78%, 61%, and 47% for those very recent late shares. On five second blocks, the uncredited tail after decay is about 0.11%, 0.39%, and 0.79%. On one minute blocks, it falls to about 0.009%, 0.033%, and 0.066%.
Conclusion
On icemining, internal latency is the real story.
If slightly late shares are denied outright, 50ms, 100ms, and 150ms ping create about 0.50%, 1.0%, and 1.49% raw stale exposure on five second blocks, and only about 0.042%, 0.083%, and 0.125% on one minute blocks. That is the pessimistic baseline, not the intended icemining policy. With a very low-latency pool path and decayed forward credit, the same edge is mostly compensated: 50ms is small, 100ms is still modest, and even 150ms is not a reason to expect materially different rewards by itself.