IceRiver Web Hashrate vs Pool Hashrate Large Gap Explained

Set expectation: compare 24-hour averages on both sides, never live or 5-minute numbers. Live web UI bounces ±10% on every share submission; live pool dashboard lags 15-30 minutes after any reconnect. Live-vs-live comparison is mathematical noise — only 24-hour averages are fair. This single principle resolves about 30% of hashrate-gap support tickets the D-Central bench fields.

Wait at least 30 minutes after any restart, pool change, firmware update, or network blip before re-checking the gap. The pool's averaging window must rebuild from incoming shares — for the first 15-30 minutes it always reads low even though the miner is hashing at full nameplate. This is mathematics, not malfunction.

Read the pool's accepted, rejected, and stale share counters from the worker detail page. Compute reject_pct = (rejected + stale) / (accepted + rejected + stale) × 100. Under 2% is healthy on Kaspa. 2-5% is acceptable. Above 5% means real fault — proceed to Tier 2/3. Under 2% means your gap is averaging-window math and there is nothing to fix.

Switch to your pool's closest regional stratum endpoint. WoolyPooly, F2Pool, HeroMiners, KaspaPool, and Acc-Pool all offer NA / EU / Asia endpoints. North American miner on a European Kaspa pool silently bleeds 2-4% to stales because of trans-Atlantic round-trip latency. Pick the endpoint closest to you, reboot, wait 24 hours, re-measure.

Upgrade IceRiver firmware to the latest release for your exact KS model from iceriver.io/firmware/. Pre-2024-Q4 builds on KS5L/KS5M shipped with a slow stratum implementation that elevated stale rate. Always download for your exact model — KS0 firmware does not work on KS3 and vice versa, and the wrong firmware will brick the controller board.

Run a 60-second ping to your pool's stratum hostname from a device on the same LAN as the miner. Record average RTT and jitter. RTT under 50 ms with jitter under 10 ms = excellent. RTT over 100 ms or jitter over 25 ms = significant Kaspa stale loss is mathematically expected — switch to a closer regional endpoint.

Replace any WiFi-Ethernet bridge with a direct hardwired Cat5e or better Ethernet cable. IceRiver KS miners are wired-only by design; if you've added a WiFi bridge, that bridge is silently injecting 1-5% packet loss which translates directly to stale shares on Kaspa.

Audit your home router for buffer bloat. A consumer router under heavy household traffic adds 30-200 ms of outbound latency at peak hours, producing evening-hour reject% spikes. Enable Smart Queue Management (SQM/CAKE/fq_codel) on the router, or place the miner upstream of household traffic on a dedicated network segment.

Run a side-by-side pool comparison: Pool A for 24 hours, Pool B for 24 hours, same miner, same network. If one pool consistently reports 1-2% higher effective hashrate, that pool's accounting methodology favors you marginally. If they're within 1%, the math is honest on both sides and the gap you see is real measurement-window structure.

Drop from Turbo mode to Normal mode if your firmware exposes the option. Turbo runs the chip closer to its silicon-lottery limit, elevating reject% by 0.5-2 percentage points. The math: 5% lower nameplate × 4% lower reject% ≈ comparable payout, with materially less thermal stress, longer hashboard life, lower fan noise, lower power bill.

Pull system log from the IceRiver web UI (Settings → Log Export). Search for `stratum`, `share rejected`, `submit timeout`, `disconnect`. Repeated stratum disconnects every few minutes mean the pool is closing your TCP connection — usually a stale keepalive issue. Try the alternate stratum port your pool offers (most pools have separate low-difficulty and high-difficulty ports).

Verify the worker name format matches the pool's required schema. Standard is `kaspa_address.workername`. Some miners get configured with `address` only or with a slash separator that the pool then assigns to a default difficulty bucket too high for your hashrate, elevating stale rate. Re-set carefully and reboot.

Verify time-sync is correct. Web UI → Settings → Network → confirm NTP server reachable and current time is within 1 second of real time. Some pools reject shares whose timestamp is more than 60 seconds off. A firewall blocking NTP on UDP 123 leaves the miner running on a wildly wrong clock. Set NTP to time.cloudflare.com or pool.ntp.org if the default fails.

Confirm stratum protocol and port match the pool's specification. Different Kaspa pools use different ports — 5555, 7777, 8888 are common — and stratum+tcp:// vs stratum+ssl:// (encrypted) differ. A protocol mismatch can produce silent share rejects rather than clean connection failures. The pool's 'how to connect' page is the source of truth.

Per-board parity audit: web UI → status → per-board hashrate. On a KS3 (3 boards) or KS5L/KS5M (6 boards), every board should hash within ~3% of the others. If one board is 5-15% below the others, the gap you thought was network is a partially-failing chip on that board. Move to Tier 4 — this is hardware.

Stop DIY: reject% sustained above 5% for 48+ hours, on the closest pool endpoint, on the latest firmware, in Normal mode, with hardwired Ethernet, AND per-board parity shows a board 5%+ below peers. At this point the loss is hardware-side. Book a D-Central ASIC Repair slot — confirm KS-series capacity at booking, since D-Central stocks KS3/KS5 spares but not all KS variants deeply.

D-Central bench process for KS-series: power-on diagnostic on a load tester, full-load thermal profile, per-board chip-count verification using IceRiver's diagnostic mode, paste/pad refresh on hashboards over 18 months old, PSU swap-test with known-good IceRiver supply. Note: deep chip-level repair on kHeavyHash silicon is not realistic — chips are not aftermarket-available, so severe damage means hashboard replacement, not chip-level reflow. Pack hashboards in anti-static bags, double-box with ≥5 cm foam, include a note with symptoms, firmware version, and your contact.