Pool Difficulty Variance — Share Rejection Spike Explained

Read the pool's vardiff documentation. Foundry, F2Pool, AntPool, OCEAN, Braiins Pool, solo.ckpool.org, public-pool.io all publish their vardiff target (e.g. 'one share every 15 seconds') in operator docs. Knowing the target tells you exactly what `share-diff` to expect for your hashrate. If your observed `share-diff` matches the formula `share_diff = hashrate_H_per_s × target_interval / 4.295e9`, vardiff is working perfectly and there is nothing to fix.

Switch to a different stratum endpoint if your current port is mismatched to your hashrate. Many pools offer multiple ports tuned for different miner sizes — low-diff endpoints for sub-1 TH/s hobby miners, high-diff endpoints for >500 TH/s farms. Picking the right port reduces vardiff retune frequency at session start. Consult the pool's endpoint table and update the Stratum URL in your miner's pool settings.

Set realistic dashboard expectations. Stop tracking shares-per-minute as a primary KPI. Track `reported 5m hashrate` and `paid hashrate` from the pool's worker dashboard — these are the two numbers that actually correlate with revenue. Shares-per-minute is a derived metric that scales inversely with `share-diff`, and it WILL move whenever the pool retunes vardiff.

Do NOT reboot the miner. A reboot resets the vardiff calibration window — the pool will start you at its default `share-diff` (often 8192 or 65536) and ramp back up over the next 5-15 minutes. If vardiff variance feels alarming, rebooting makes it worse by recreating the calibration noise. Walk away from the dashboard for 15 minutes instead.

Wait at least 15 minutes after any pool change. First connection sends a default `share-diff`. Vardiff takes 5-15 minutes to settle on the right value for your hashrate. Reading the share rate during the calibration window is reading noise — it is not a useful diagnostic signal.

Capture a baseline log. From your miner's log endpoint (cgminer.log on Antminer, BTMiner log on Whatsminer, AvalonOS log on Avalon, AxeOS Logs tab on Bitaxe), capture 30 minutes of stratum traffic during normal operation. Save as `baseline.txt`. Next time vardiff retunes and you suspect a fault, capture another 30 minutes and diff against baseline. Real faults add new error strings; vardiff variance shows the same `mining.notify` cadence with different numbers in `mining.set_difficulty`.

Validate the formula on every miner you operate. Build a spreadsheet: `model | hashrate | pool | share_diff | expected_interval | expected_shares_per_min | observed_shares_per_min`. Fill it in for each miner in your fleet. Any miner whose observed rate is within ±50% of expected is healthy. Any miner outside that band needs investigation. This single spreadsheet catches roughly 95% of false-positive vardiff alerts.

Switch pools as a sanity test. Point the same miner at two different pools sequentially over a few days and compare share rates. If both fall within ~1.5x of the formula at the pool's reported `share-diff`, hardware is fine. If one pool consistently produces share rates outside the expected band, that pool's vardiff is misbehaving for your hashrate band — escalate to the pool operator or stay on the better pool.

Enable a third-party firmware on Antminer for per-chip visibility. Stock Bitmain firmware shows aggregate `HW%` and aggregate share rate; it does NOT show per-chip submission contribution. Flash DCENT_OS — D-Central's open-source Antminer firmware (recommended) — or Braiins OS+, LuxOS, or Vnish as alternatives. All four expose per-chip share submissions. If submission rate dropped because one chip stopped contributing, the per-chip view will show it within seconds — and that is a real fault, not vardiff. DCENT_OS is Antminer-only; for Whatsminer use BTMiner; for Avalon use AvalonOS; for Bitaxe / Nerd use the device's native firmware.

Run a control miner. Operate a second miner on the same pool with the same address. Both should show similar `share-diff` from vardiff (since vardiff calibrates per worker; same hashrate band → same diff band). If one shows wildly different diff than the other despite matching hashrates, one of the two has a stratum bug or firmware regression. Swap firmware versions and re-test.

Run `tcpdump` against the stratum connection for 24 hours: `tcpdump -i any -A -s 0 'host <pool_ip> and port <pool_port>' -w stratum-24h.pcap`. Open in Wireshark; use the Stratum protocol dissector or follow the TCP stream to extract every `mining.set_difficulty`, `mining.notify`, and `mining.submit` line. Plot share submissions per minute over 24 hours; overlay `share_difficulty` on the same time axis. The two curves should be visibly inverse — when diff goes up, submissions per minute go down. Reported hashrate over the same period should be flat.

Build a per-worker variance dashboard. Aggregate stratum logs from your fleet via Telegraf / Prometheus / a small Python script. Expose: `worker_id`, `current_share_diff`, `observed_shares_per_min`, `expected_shares_per_min`, `delta_pct`. Alert when `delta_pct > 50%` for more than 10 minutes — that is your real-fault trigger. Anything inside that band is vardiff variance and should not page anyone.

Correlate vardiff retunes with pool-side block events. Some pools accelerate vardiff retunes immediately after they find a block, when stratum work changes en masse. If your vardiff retune cadence speeds up in the minutes after the network finds a block, that is pool-side behaviour, not your miner. Cross-reference your retune timestamps against `mempool.space/blocks` for the same period.

Build a Monte Carlo simulator for your config. In Python: `numpy.random.exponential(scale=expected_interval_s, size=86400)` simulates a day of expected share waits. Compare your real distribution to the simulated one. If your real distribution falls inside the simulated 95% confidence interval, you have textbook Poisson variance under vardiff. If it is outside, escalate to the real-fault path.

For Whatsminer fleets, use the BTMiner API to log `mining.set_difficulty` history. BTMiner exposes a status endpoint that reports current diff, recent diff changes, and submission rate in structured form — easier to parse than raw stratum logs. Pull it every 30 seconds and stash a CSV. Same approach works for Antminer with cgminer-api or DCENT_OS / Braiins OS+ / LuxOS API endpoints; for Avalon use the MM (Mining Module) log strings via AvalonOS.

Real-fault triggers — escalate when ANY of these is true: (a) reported hashrate dropped materially alongside the share-rate change, (b) `HW%` climbed alongside the share-rate change, (c) reject rate climbed alongside the share-rate change, (d) submission rate is >4x outside the formula's expected band for over an hour AND the pool dashboard confirms the same anomaly. Variance is no longer the answer — proceed to the appropriate per-model troubleshooting page.

Antminer real-fault path: reflash with DCENT_OS — D-Central's open-source Antminer firmware — for per-chip submission visibility. Identify which chips stopped submitting. From there, follow `Antminer S19 — High Hardware Error Rate` (or model-equivalent) for chip-level isolation. Alternatives: Braiins OS+, LuxOS, Vnish — each exposes per-chip diagnostics in their dashboards.

Whatsminer real-fault path: pull BTMiner status via the API, identify the failing slot or chip, and follow the appropriate per-error page from D-Central's Whatsminer troubleshooting library at d-central.tech/asic-troubleshooting/. Common cousin errors at this point: hashboard temp-sensor failure, hashboard not detected, chip-id read failure, and error codes 300/301/302 or 530/540/550 — each has its own dedicated page.

Avalon / Innosilicon / Bitaxe / Nerd real-fault path: use the appropriate per-model troubleshooting page from D-Central's ASIC Troubleshooting library at d-central.tech/asic-troubleshooting/. Most 'vardiff masquerading as fault' turns out to be a standard low-hashrate, chip-init, or share-rejection issue already documented for that hardware.

Open a D-Central support ticket only after the math is verified. If the formula confirms a real divergence, capture: 24-hour stratum log, miner-side logs, pool-side worker history screenshot, and a one-line summary of `expected_shares_per_min` vs `observed_shares_per_min`. Open a ticket at https://d-central.tech/contact/. Variance alone is not a ticket — vardiff variance is normal pool behaviour and not a hardware concern.