Pool hashrate lower than rig hashrate: where the percent goes
The miner shows 600, the pool draws 570, and the payout feels like 550. A classic scene — and a classic reason to blame the pool. Sometimes deservedly. But more often the numbers "disagree" because they are three different numbers measured three different ways. Here is where the percent really goes, which gaps are normal, and which are a red flag.
The short version (for the no-time-to-read)
- Rig hashrate and pool hashrate are different measurements. The rig measures how much it computes; the pool — how many shares arrived. A speedometer and an odometer: both about speed, not the same thing.
- Compare daily averages, not the current figure. The pool's hourly charts swing by tens of percent on luck alone — that is math, not cheating.
- Stale and rejected shares are real losses. One or two percent is normal; consistently more — investigate the network and the overclock.
- Miner downtime is visible to the pool and invisible in the rig's average. Every restart is minutes of zero hashrate that the pool honestly counts.
- The pool fee is a separate line — absent from the "hashrate chart" but present in the payout (details in the pool article).
Two numbers, three ways of measuring
The miner measures hashrate directly: how many solutions per second the cards chew through. That is the reported hashrate. The pool sees something else: how many shares you submitted, converted to hashrate via difficulty. That is the effective hashrate. There is always a gap between them, and here is what it is made of:
- luck. Shares are a random process: like coin flips, a streak of "tails" cheats nobody. Over an hour the spread is large, over a day it compresses, over a week it nearly vanishes;
- averaging windows. The pool shows averages over 15 minutes, an hour, a day — a different number in each window. Comparing "current reported" with "hourly effective" is meaningless by definition;
- downtime. The miner restarted for ten minutes? Invisible in reported — it only measures while it runs. The pool sees the gap honestly.
The real losses: stales, rejects, downtime
Beyond statistical noise there are genuine losses — the ones worth minimizing:
- stale shares. The share was computed honestly but reached the pool after the job had changed. The cause is network delay: pool latency, lossy Wi-Fi (covered in the network article). A percent of stales is a straight percent off revenue;
- rejected shares. The pool received the share and turned it down: the solution did not check out. The typical source is an over-aggressive memory overclock: the card computes fast but with errors. Those shares were already paid for in electricity;
- restart downtime. Every miner restart, preset change, reboot — minutes of zero revenue. Five three-minute restarts a day is already a percent.
A simple benchmark: a daily effective-vs-reported gap within 1–3% is life; a consistent 5%+ means looking for the cause in the network, the overclock or the miner's stability.
How to compare honestly
- One window — one comparison. Daily effective against daily reported, week to week. Screenshots of "570 right now at 600" prove nothing.
- Count revenue, not hashrate. The final check is coins received per week versus the estimate. Formulas in the profitability article, live numbers in the calculator.
- Change one thing at a time. New pool, new overclock, new network — change everything at once and you will never learn what worked.
- Give a change time. A day at minimum, a week is better. Pool luck only evens out over long windows.
Where automation fits
Two of the three real losses — rejects from a greedy overclock and downtime from restarts — are exactly what OCBot suppresses by design: a preset is accepted only after a long stability run, so "fast but error-prone" does not survive selection, and the overclock is tuned to the specific card, not an "average from a forum". Fewer rejected shares and fewer restarts — and the effective hashrate creeps toward the reported one by itself.
This article is general information summarizing public practice; actual numbers depend on your pool, network and hardware. OCBot is an independent project: not affiliated with NVIDIA, HiveOS or Hiveon. Use at your own risk — see the disclaimer.