Stale Shares from High-Latency Pool Connection

Confirm the stale rate is real. Pull the stale-shares counter from your pool's worker dashboard over a 4-24 hour window. Compute stale percentage as stale / (accepted + rejected + stale) * 100. If under 0.5%, you don't have a problem worth solving — invest your time elsewhere. If above 1.5% sustained, you have a real issue. Screenshot the baseline so you can prove the fix worked later.

Switch your pool URL to the closest regional endpoint. Most major pools publish region-specific endpoints (US-East, US-West, EU, Asia). The generic anycast URL routes you to whatever server the pool's geo-DNS chooses, which is often suboptimal. Look up your pool's docs, change pool slot 0 to the closest geo-endpoint, save, reboot. Watch stale rate over the next hour. This single change resolves a majority of stale-share complaints from home miners.

Move the miner to wired Ethernet. WiFi adds 20-80 ms of jitter and packet loss whenever 2.4 GHz competition appears. Run a Cat5e cable. If a cable is impossible, switch to a 5 GHz network on a clean channel using a WiFi analyzer to pick one. Ethernet is non-negotiable for serious mining; WiFi is a hobbyist compromise that costs measurable revenue at scale.

Restart your home router and modem. ISP routers degrade over weeks of uptime — buffer bloat, DNS cache rot, NAT table saturation. Power-cycle the modem and router (full 60-second power-off, not a soft reboot) and re-test stale rate over the next 4 hours. Lowest-effort fix; works more often than it should.

Disable any VPN or proxy on the miner's network path. VPNs add 30-150 ms of RTT, fragment your MTU, and route through whatever exit point the provider chose. Unless you have a specific privacy reason, mining traffic should go direct. If you must use a VPN, pick an exit node geographically close to your pool — don't tunnel from Montreal through Switzerland to reach a New York pool.

Run a `ping` test to the pool from your miner's network. From a laptop on the same LAN: `ping -c 100 <pool-host>` (Linux/macOS) or `ping -n 100 <pool-host>` (Windows). Note the average RTT and any packet loss. Above 150 ms average or > 1% loss is your stale-share source. Compare against the closest regional endpoint of the same pool — if the regional one is materially lower, you've found the fix.

Run a `traceroute` and look for the tromboned path. `traceroute -n <pool-host>` (Linux/macOS) or `tracert <pool-host>` (Windows). Look for unexpected geography (Canadian traffic going through London to reach a Frankfurt pool, for example), single hops adding > 80 ms, or hop counts > 15. This tells you whether latency is from raw distance or from your ISP's poor BGP choices. Distance you fix with a closer endpoint or proxy; bad routing you fix with a different ISP, a stratum proxy in the pool's region, or pool migration.

Test for path MTU blackhole. `ping -M do -s 1472 <pool-host>` (Linux) or `ping -f -l 1472 <pool-host>` (Windows). If this fails or returns `Packet needs to be fragmented but DF set`, your path MTU is below 1500 and TCP is paying a retransmission tax on every stratum message. Fix at the router by clamping MSS: `iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu`. Or remove whatever VPN/tunnel is adding header overhead.

Check your ISP's evening congestion pattern. Stale rate that spikes 6-10 PM local time is residential ISP congestion — your neighbours streaming Netflix push your connection's effective bandwidth and latency through the floor. Run `mtr -rwc 100 <pool-host>` at 3 AM and 9 PM. If 9 PM RTT is materially worse than 3 AM, your ISP is the bottleneck. Solutions: business-class ISP, fixed-wireless backup link, or a stratum proxy on a VPS that bypasses the residential BGP path.

Switch DNS to a low-latency resolver. Some ISPs run slow or geographically distant DNS resolvers. Configure your router to use Cloudflare (`1.1.1.1`) or Quad9 (`9.9.9.9`) — DNS lookups for the pool host happen on every reconnection, and slow DNS adds startup latency. Re-test after switching.

Deploy a stratum proxy on a VPS in the pool's region. Spin up the smallest available VPS at DigitalOcean, Hetzner, Vultr, or OVH in the city or region closest to the pool. Install the SRI `translation-proxy` (github.com/stratum-mining/stratum) — speaks SV1 to your fleet and SV1 or SV2 upstream. Point home miners at `vps-ip:3333`. The proxy-to-pool leg runs at IXP latencies; your home leg becomes a TCP keep-alive that tolerates higher RTT without producing stale shares.

Enable Stratum V2 if your firmware and pool support it. On Antminer, flash DCENT_OS — D-Central's open-source firmware — or Braiins OS+, LuxOS, Vnish. Toggle SV2 in pool config. Point at Braiins Pool's SV2 endpoint (`stratum.braiins.com:3333` with SV2 enabled). SV2's binary protocol with header-only update frames produces measurably fewer stale shares at the same RTT. Stock Antminer / Whatsminer / Avalon / ESP-Miner / NerdMiner are SV1-locked.

Run an SRI Job Negotiator + local `bitcoind`. Maximum-sovereignty configuration. Local `bitcoind` builds block templates from your own mempool. Local Job Negotiator (part of SRI) negotiates the template with the pool. Beyond decentralization, local template generation eliminates the `clean_jobs: true` stale-share spike — when a real block is found upstream, your miner switches templates faster than it could waiting for a remote `mining.notify`. Budget a weekend for first deployment.

Wire Prometheus + Grafana to your stratum-layer telemetry. DCENT_OS and Braiins OS+ both export per-share metrics: accepted, rejected, stale, submission latency. A 30-minute Grafana dashboard catches stale-rate regressions the moment they happen — instead of finding out a week later. Alert thresholds: stale > 1% over 1 hour = warning; stale > 3% over 1 hour = page someone. Catches ISP path changes, pool endpoint moves, firmware regressions.

Tune your firmware's submission timing. DCENT_OS, Braiins OS+, LuxOS, and Vnish expose stratum-layer tuning (submission threshold, work-queue depth, asicboost mode). Defaults are conservative for compatibility. On a low-latency, well-peered network you can shave milliseconds off submission delay; on a high-latency network you may want to deepen the work queue so the miner has more local templates to work on between `mining.notify` arrivals. Read your firmware's docs; benchmark before-and-after.

Stop DIY and escalate. Network is optimized (low RTT, no MTU issues, optimal routing, regional endpoint, Ethernet, stratum proxy if needed), firmware is current with SV2 enabled where possible, and stale rate is still > 1% sustained. You're now looking at a pool-side issue, an ISP-level peering pathology, or a hardware bug producing slow submission. Open a D-Central support ticket at `https://d-central.tech/contact/` with: 4-hour stale rate breakdown, `ping`/`traceroute` to the pool, firmware version, pool endpoint, and any Prometheus stale-rate graph you have.

Fleet-scale stratum infrastructure. For operators with > 10 miners, D-Central's bench can architect a sovereign stratum stack: VPS-hosted SRI proxy in the pool's region, local Job Negotiator + `bitcoind`, Prometheus/Grafana telemetry, failover to a backup pool. End state: stale rate < 0.3%, encrypted transport, your own block templates, alerting that catches problems in minutes. Get in touch via the D-Central contact form.

Hardware suspicion last. Rare, but a control board with a failing Ethernet PHY or an aging USB-Ethernet adapter on a Bitaxe / NerdMiner can produce intermittent packet loss that masquerades as latency. If you've ruled out network and pool, and switching the miner to a different physical Ethernet port / cable / adapter changes the behavior, you have a hardware lead. Ship to the D-Central repair bench at `https://d-central.tech/services/asic-repair/`.