An ASIC dashboard, a pool dashboard and a payout record observe the same operation from different places and over different windows. A credible firmware benchmark must reconcile local work, accepted shares, credited work, wall power, heat and uptime before it declares a winner.
The miner says 200 TH/s. The pool says 193. Who is lying?
Probably nobody.
Treating those screens as interchangeable is how a five-minute screenshot becomes a “performance result”-and how a promising profile gets scaled before anyone knows whether it is stable.
This matters after any material change: a new power profile, a firmware update, a repair, a PSU swap, a different cooling configuration or a pool-routing change. The correct question is not “Which screen has the real hashrate?” It is “What does each screen measure, and do the measurements reconcile over a controlled window?”
Hashrate one: what the machine believes
Device-side hashrate is the firmware’s local view of work. Depending on the implementation and selected window, it may reflect chip activity, nonce processing, board-level estimates or a smoothed calculation. It is close to the source and useful for immediate diagnostics.
It is not automatically the work a pool accepted.
A local number can react quickly when a profile changes. That makes it tempting: set a target, watch the line rise, take a screenshot. But a short local window may not reveal reboots, thermal drift, intermittent boards, network loss or a rejection problem that appears later. “Current,” “average,” “requested” and “observed” can also mean different things. Record the label and window; do not preserve only the number.
The distinction is visible in modern control surfaces. The VNISH platform page describes requested and observed hashrate alongside watts, measured efficiency, temperatures, fan response, board state and the active profile. Its interface is explicitly presented with example data, not as a performance promise. That is the right mental model for a dashboard: a set of signals for a decision, not a certificate of earnings.
Hashrate two: what the pool can infer
A pool does not stand inside the ASIC and count every hash. It receives qualifying proofs of work called shares. From the amount and difficulty of valid work arriving during a window, it estimates the hashrate that probably produced it.
The Stratum V2 Mining Protocol specification makes the accounting boundary unusually clear. A miner submits results; the server validates them. A successful acknowledgement includes the number of new accepted submits and the sum of the difficulty of the acknowledged shares. Incorrect submits receive errors. The precise messages differ across protocol versions, but the operating principle is durable: accepted work is observed at the server, not inferred from the miner’s local speedometer.
Share arrivals are random. Even when the machine’s underlying work rate is steady, the number of qualifying shares observed in a short interval can land above or below expectation. In a simplified Poisson model, relative noise falls as the number of observations grows. Fewer shares-because the test is short, the cohort is small or share difficulty is high-mean a wider-looking pool estimate.
This is why a pool line can swing while the device line looks calm. The Braiins Farm Proxy FAQ explains this effect in its specific proxy context: aggregating many downstream share processes produces a flatter view, while fewer, higher-difficulty upstream processes appear more volatile. Its approximate three-hour convergence comment belongs to that illustrated proxy configuration. It is not a universal rule for one S21, every pool or every share difficulty.
Hashrate three: the work that is credited
Accepted work and paid work are connected, but they are not identical dashboard concepts.
The payout method determines how valid shares become account credit. Fees, timestamps, payout windows, pool methodology and, for some methods, block-finding luck affect the accounting. A pool’s estimated hashrate chart may be a rolling visualization; the credited-work record is the ledger used under the pool’s rules.
That distinction is easy to miss in a short comparison. Hashrate Index’s August 5 analysis of pool “bake-offs” shows why raw short-window outcomes can rank high-variance results as winners or losers even when their long-run expected value is the same. The article addresses pool comparison, not firmware benchmarking, but the measurement lesson transfers: a noisy outcome should not be mistaken for a structural advantage.
For a firmware or profile test, record both accepted shares and the credited work produced under one unchanged payout method. Do not change pools halfway through and attribute the accounting difference to firmware.
The fourth number: wall power
Hashrate without power is output without cost.
Joules per terahash is calculated as watts divided by TH/s. Hashrate Index’s August 12 J/TH explainer lays out the arithmetic: a 3,000-watt machine producing 100 TH/s runs at 30 J/TH. The denominator must be named. Local TH/s, pool-estimated TH/s and accepted-work-derived TH/s can produce different efficiency readings over a short window.
Use an appropriate, verified wall-power measurement and time-align it with the hashrate window. A firmware estimate can be operationally useful, but do not silently compare estimated watts in one run with external-meter watts in another.
For context, the official ANTMINER S21 specification lists 200 TH/s, 3,500 watts and 17.5 J/TH at 25°C. It also lists a 0-45°C operating range and reduces the highest operating temperature above 900 metres. Those are specified reference conditions, not proof that every S21 in every room will reproduce one exact result.
Why 24 hours is a checkpoint-not a law
A full day is far more informative than a five-minute screenshot. It can expose day/night inlet changes, pool reconnects, thermal settling, reboots and differences between local and pool windows. It is a useful minimum operational checkpoint for a stable, properly instrumented canary.
It is not always statistically sufficient.
A single machine, high share difficulty, an interrupted window or an unusually quiet or noisy share sequence can leave pool-estimated hashrate uncertain after 24 hours. If the result is close to the decision threshold, if the cohort is small or if variance remains high, extend the run to 48-72 hours or longer. More time reduces random noise; it does not repair a biased test design.
The best protection is a simultaneous control. Two comparable cohorts exposed to the same pool, network path and inlet conditions help separate a profile effect from weather, pool variance or a site event. When only one machine is available, use a sequential baseline and test, but state the limitation plainly.
The reproducible canary protocol
- Freeze the identityRecord the exact model, control board, current build, target build, filename and SHA-256. Confirm the install route, board-appropriate recovery path and rollback owner.
- Choose comparable hardwareUse a test cohort and an untouched control of the same model, control-board family and broadly similar service condition. Avoid selecting only the best machine.
- Define the boundaryName the data source for requested and observed TH/s, pool window, accepted/rejected/stale shares, credited work, external wall watts, temperatures, fans, board errors, uptime and reboots.
- Hold conditions steadyUse the same pool account, endpoint, payout method, worker pattern and network route. Keep input power and cooling comparable; record inlet temperature and variable share difficulty.
- Warm up before the clockAllow first boot, autotuning where applicable and thermal settling to complete. Confirm every expected board and chip, accepted pool work and stable power.
- Observe at least 24 hoursPreserve time-series data, not just screenshots. Compare matched daytime, nighttime and stable-inlet slices; extend to 48-72 hours when uncertainty remains.
- Reconcile-do not cherry-pickExplain the gap among local, pool-estimated and credited work. Calculate J/TH with declared boundaries and review rejects, stale shares, heat, fan response, errors, resets and lost minutes.
A higher local TH/s is not a win if accepted work, power efficiency or stability moved the wrong way.
Applying the protocol to VNISH 1.3.5
As of this review, the official release page identifies VNISH 1.3.5 as stable and published in July 2026. It lists 47 model families, 75 exact NAND routes and a published SHA-256 for every listed build. The release notes say S21 presets were reworked and advise budgeting for preset retuning after the update; installation, autotuning and final stabilization are separate stages.
Those facts make route identity part of the benchmark. “S21 on 1.3.5” is incomplete. Record the exact model, control board, filename, build and checksum. Verify support for that exact combination. Keep recovery available and start with a canary.
Decision card: Go, Hold or Stop
| Decision | Use it when |
|---|---|
| GO | The route and recovery are verified; the canary stayed inside predefined limits; accepted and credited work support the local result; the improvement survives meaningful time slices. Expand only to the next controlled cohort. |
| HOLD | The direction looks promising, but variance remains wide, the result is close to the threshold, conditions moved, telemetry has gaps or test and control were not comparable. Extend or redesign the test. |
| STOP | Identity or rollback is uncertain; local power or temperature limits are crossed; boards disappear; errors, resets, rejects or stale shares rise materially; accepted work fails to support the local dashboard. |
ROI ASIC is part of the VNISH ecosystem. Aftermarket firmware and changed profiles alter operating conditions and may affect stability, power draw, temperature, component lifespan, manufacturer warranty or support. Results depend on silicon, PSU and board condition, cooling, input power, network path, pool behavior, share difficulty and ambient conditions. No hashrate, efficiency, uptime, margin, revenue or savings result is guaranteed. Verify the exact model, control board, build and checksum; preserve a tested recovery path; use qualified personnel.
Scale evidence-not screenshots
The responsible next step is small: run one measured canary, reconcile all three hashrates and obtain the exact verified build only after the route and recovery plan are clear.
Five minutes can show that a machine is alive. Twenty-four hours can show whether the operating direction is credible. A controlled test that survives the pool, the meter, the heat and the night shift is what earns the right to scale.
Review six source-linked performance reports before converting a reported TH/s, watt or J/TH figure into an economic assumption. Open the independent field reports.
Sources and data freshness
- Hashrate Index, “Measuring Bitcoin Mining Efficiency: J/TH Explained,” August 12, 2026. Industry explainer (checked August 20, 2026). Definitions used; vendor performance claims were not imported.
- Hashrate Index, “Comparing Mining Pool Payouts: Two Pitfalls to Avoid During a Bake-Off,” August 5, 2026. Pool-measurement analysis (checked August 20, 2026). Only the short-window variance lesson is transferred.
- Stratum V2, Mining Protocol specification, sections 5.3.11-5.3.14. Living specification (checked August 20, 2026).
- Braiins Academy, Farm Proxy FAQ. Living technical FAQ (checked August 20, 2026). The proxy example is not generalized into a universal duration rule.
- BITMAIN, S21 Specification, updated April 8, 2024. Manufacturer documentation (checked August 20, 2026).
- VNISH GLOBAL, Operational control in one interface and VNISH 1.3.5 release identity (checked August 20, 2026). Demo values are examples, not performance proof.
- ROI ASIC, official VNISH distribution and model/control-board/build lookup (checked August 20, 2026). Used for ecosystem and route disclosure only.
Published by the ROI ASIC Analytics Desk. ROI ASIC is part of the VNISH ecosystem. This article is evidence-led operational guidance; it does not promise a performance or financial result.