Stale shares and latency: why ping barely matters

Your miner works on a job — a specific block template. The moment anything changes (someone, anywhere, finds a block; the pool refreshes transactions), that job is obsolete. Any share you submit for it afterwards is stale: rejected as too late, worth nothing. Stales (plus outright invalids) are the friction of mining, measured as a percentage of hashrate thrown away.

Causes, in rough order: job-switch lag (your miner is still finishing the old template when the new job arrives), network jitter (shares in flight during a switch), and rarely, misconfiguration (wrong algorithm, too-high intensity producing bad hashes).

Only three operations are latency-sensitive: receiving new jobs, submitting shares, and the pool's daemon connection. The hashing itself — everything that costs electricity — happens on your hardware, untimed. So the difference between a 20 ms and a 200 ms pool is a fraction of a percent of stale shares; the difference between a 1% and a 2% fee is a full percent of income. Ping is the smallest number on the page.

• Wired connection — Wi-Fi jitter dominates stale rate long before geographic distance does.
• Let vardiff pick share difficulty — oversized shares amplify every switch event.
• One region away is plenty — same continent beats same city; cross-continent only matters for professional latency play.
• Watch the rejected-reasons panel — stale vs invalid vs duplicate tells you which fix applies; a rising *invalid* rate is a config problem, not a network one.

Pool cards list each pool's stratum endpoints across regions — pick the nearest healthy one and move on; the stats that deserve your attention (fees, scheme, payouts) sit beside them.