Pool Latency Optimization for Solo Mining: Reduce Stales and Rejects

The 2 a.m. Stale Share Spike

It's a rack check at 2 a.m., and the stale share rate on one rig has climbed from under 1% to almost 5% overnight. Nothing physically changed — no reflash, no new firmware, no cable swapped. That's usually the tell that it's a latency problem, not a hardware one.

Stale shares happen when a worker submits a solution for a block template the pool has already moved past. Reject shares happen when the share itself doesn't clear validation — wrong difficulty, bad nonce range, whatever the reason. Both eat into your effective hashrate even though the miner's hashboards are working exactly as advertised. A rig showing 110 TH/s on its own display can easily be paying out closer to 105 TH/s once stales and rejects are subtracted, and most of that gap traces back to the network path between the miner and the pool.

What's Actually Driving the Numbers

Ping time isn't the whole story, but it's the fastest thing to check. Going from 40ms to 180ms round-trip to a pool endpoint doesn't just feel slower — it changes how much stale risk you're carrying on every share, because the miner is working against a job that's already a few hundred milliseconds old by the time the solution lands back at the pool.

VarDiff makes this worse if it's tuned for a stable connection and your path isn't stable. On a jittery link, VarDiff keeps resizing difficulty trying to hit a target share rate, and every resize is a small window where shares can get rejected. Fixed difficulty avoids that churn, but only works if you've picked a value that actually matches your hashrate — too low and you flood the pool with shares, too high and your share rate gets choppy and hard to read.

How We Actually Run the Fix

We don't guess at this. The workflow we use when a rig's stale rate creeps up:

• Ping and traceroute both the primary and backup pool endpoints, and note the round-trip time and hop count for each.
• Decide VarDiff vs. fixed difficulty based on how stable that specific link has been over the past week, not just today.
• Let the change run for at least 24 hours before calling it a win — one clean hour can just be a lucky window.
• Keep a tested failover profile saved and ready, so if the primary endpoint gets flaky again we can repoint in under a minute instead of troubleshooting live.

One thing we've learned the hard way: change one variable at a time. Swap the endpoint and retune VarDiff in the same session and you'll have no idea which change actually helped — or which one is quietly making things worse.

Where This Goes Wrong

Here's the honest caveat: latency tuning without a baseline is close to useless. If you don't know what your normal stale rate looks like on a good night, you can't tell whether a change helped or you just got lucky with lighter pool load. We keep a rolling log of stale/reject percentage per rig per day specifically so a "fix" doesn't get credited to a config change when it was really just quieter network traffic that night.

We've also chased latency ghosts that turned out to be a flaky switch port, not the pool at all — worth ruling out your own local network before you start repointing endpoints.

Tune one thing, watch it for a full day, write down what you saw. Skip the baseline and you're just rearranging deck chairs.

Related Reading

If you're setting up failover from scratch, the Solo Mining Playbooks on MySoloPool walk through endpoint setup and failover in more depth.