Miner vs. pool hashrate: compare the same work before changing the fleet

Your ASIC dashboard shows 200 TH/s. The pool shows less. A firmware change happened earlier, and the team wants to know whether it helped or hurt.

The difference between those two screens does not answer that question yet. You need to establish which devices, which interval and which measurement each number represents.

For a farm operator, the useful first result is a comparison another person can reproduce. Here is a read-only workflow for building one from information already available in your monitoring tools. It is VNISH GLOBAL's suggested observation method, not a manufacturer repair procedure.

Start with the meaning of the number

BITMAIN's API documentation distinguishes five-second, thirty-minute, average and theoretical hashrate. Its status-page guide describes average hashrate over elapsed runtime. These are different fields, even when the screen gives them similar visual prominence. Names and availability depend on the device and firmware. BITMAIN API documentation, status-page definitions.

Before comparing values, fill in four labels:

For example, 200,000 GH/s equals 200 TH/s. Converting the units does not reconcile a five-second reading with a one-hour average.

Also separate speed from accounting. An estimated revenue figure, accrued balance and completed payment are different observations. Identify which one you are reading and its applicable period before using it in a performance discussion.

Keep downtime inside the window

Consider a fictional one-hour interval. A miner does no hashing for thirty minutes, then hashes at a constant 200 TH/s for thirty minutes.

Time-weighted hashing activity:
(0 TH/s × 30 min + 200 TH/s × 30 min) / 60 min = 100 TH/s

At the end, a short local reading could show 200 TH/s. The hour still contains thirty minutes without hashing. Both facts can be true.

This is illustrative arithmetic, not a forecast of a pool's estimator or a measured firmware result. Its practical lesson is to select a common start and end time, then retain all known interruptions inside it. Cropping out the restart on one side changes the question.

If one tool cannot provide the same interval, mark the comparison incomplete. Do not manufacture a matching window by treating a current screenshot as historical data. Keep capture time separate from the period the displayed number summarizes.

Check the work, not just the connection

The Bitcoin developer guide explains that a pool assigns a share target and receives shares as evidence of contributed work. Different pools use different reward distribution systems. Consequently, a share count needs its difficulty context, and a local speed reading is not itself a payment record. Bitcoin developer guide: pool mining.

Read your pool's definition of the metric being compared. Record how it treats accepted work and which interval it uses. Avoid assuming that every dashboard's “real-time” label means the same calculation.

BITMAIN separately documents connection status, accepted shares and stale work. A reachable pool and accepted work are therefore separate observations to record. BITMAIN's pool-status definitions.

Use counter changes within your selected interval, with the start and end readings retained. If a restart resets a counter, split the observation at that reset; subtracting across it would create a misleading result. If share difficulty changed, do not treat each raw share as equal work without accounting for that change. These are comparison rules, not a new hashrate estimator.

Make the conclusion narrower than the evidence

“The worker is missing from the pool export between 10:05 and 10:17 UTC” is an observation. “The firmware caused twelve minutes of lost hashing” requires additional evidence. A missing report alone does not establish the device's physical state or the cause.

After aligning scope, units and time, classify the result:

• Comparison incomplete: a definition, interval or device-to-worker mapping is missing. Obtain that specific item.
• Difference explained by scope or timing: retain the matched observations and the explanation. This resolves that comparison, not every possible device fault.
• Difference still unexplained: preserve the interval, relevant logs and share information for the responsible support team. Do not infer a fleet-wide cause from this comparison alone.

Copy this observation worksheet

Use internal labels where possible. Leave unknowns explicit; completing the worksheet does not require opening hardware or changing settings.

Observation ID:
Device/group label and pool-worker mapping:
Model, board and firmware build (or unknown):

Shared interval: [start] to [end], timezone:
Miner: [field] [value] [unit] [averaging window]
Pool:  [field] [value] [unit] [averaging window]
Metric definitions/source links:
Capture times, separately from the shared interval:

Share counters at start/end; difficulty context:
Counter resets, restarts or connection events:
Missing information:
Conclusion: incomplete / explained / unexplained
Evidence supporting that conclusion:
Next specific question and responsible person:

For firmware information and published support entry points, continue at VNISH GLOBAL. Bring the worksheet and a reviewed excerpt covering the same interval. Remove credentials and unnecessary private infrastructure details before sharing externally.

Disclosure: This article was drafted by AI agents for VNISH GLOBAL using the linked primary references. The example is fictional arithmetic; no physical miners were inspected or tested for this article.