Why the two numbers differ
A mining machine and a mining pool do not measure performance in exactly the same way. A short pool-side dip does not, by itself, prove that a hashboard is faulty. Equally, a healthy-looking local dashboard does not prove that useful work reached the intended pool account. The practical question is whether the same worker, over the same interval, shows a persistent discrepancy supported by other evidence.
This guide is a diagnostic worksheet for Bitcoin ASIC operators, not a hardware acceptance certificate or a promise of mining income. It explains what to record before changing settings, how to separate a measurement mismatch from lost operating time, and what to send to support. The cover uses an illustrative product photograph, not a photograph of a tested installation.
Identify the metric before comparing it
Braiins documents nominal and effective hashrate separately. Nominal capability is not identical to a pool estimate derived from submitted work. Random variation and connection quality affect the pool figure; a short estimate can also exceed nominal performance. Treat a dashboard reading as a measurement with context, not as a replacement for the manufacturer's model specification.
| Reading | What to check beside the number | Useful comparison |
|---|---|---|
| Product specification | Exact model, variant and operating mode | A reference for that machine, not a live result |
| Local real-time rate | Timestamp and firmware definition | The machine's own recent history |
| Local average rate | Uptime and any restart | Another local average covering a comparable run |
| Pool effective rate | Worker, interval and pool definition | The same worker over the same observed period |
For ANTMINER interfaces covered by BITMAIN's status-page guide, the real-time and average fields are distinct, and the average relates to elapsed runtime. Accepted, stale and discarded work also have different meanings. Field names can vary with firmware: read the documentation for the installed version rather than interpreting every counter as a rejection.
Build one comparable observation window
Start a short incident record before rebooting anything. Write down the local time zone, capture time, worker name, machine identifier and firmware version. Save both views together. If one screenshot represents five minutes and the other covers a day, label the mismatch instead of computing a percentage loss from it.
Then make four checks:
- Identity: confirm that the configured pool account and worker match the dashboard being inspected. Keep credentials private; a support ticket needs identifying context, not a password.
- Scope: determine whether the displayed worker represents one machine or several. Do not compare a fleet total with one device.
- Clock and interval: record each dashboard's interval and update timestamp. Note the start and end of the observation separately from the screenshot time.
- Continuity: mark restarts, pool changes, network outages and planned stops within that window. Preserve logs before a change clears them.
Braiins' monitoring documentation explains that machines sharing a worker name are monitored together; distinct worker names allow device-level tracking. It also describes five-minute monitoring snapshots for its service. That cadence is pool-specific, not a universal waiting period or a guarantee that five minutes proves stability.
Do not confuse downtime with slow hardware
Consider a deliberately simplified example, not a measured product result. A fictional machine performs at a constant 200 TH/s while operating, runs for ten hours, and remains off for two hours during a twelve-hour observation. Its time-weighted contribution across that whole window is approximately 166.7 TH/s: 200 × 10 ÷ 12. A local average that excludes the stopped period could still describe the operating period differently.
The example illustrates a denominator problem. It does not predict any particular pool dashboard, which has its own estimation and averaging rules. Before deciding that a miner lost performance, ask whether the two numbers include the same stopped time. Repeatedly restarting a machine to make the local average look better also destroys the continuity needed to investigate the discrepancy.
Separate fluctuation from a persistent fault
Braiins' explanation of shares and estimated hashrate describes why share arrivals vary and why different share difficulties represent different amounts of work. Raw share counts from different difficulty settings are therefore not a useful like-for-like performance ranking. A larger count alone does not establish a faster machine.
Use the following worksheet as an investigation order, not an automatic fault diagnosis. There is no universal percentage threshold here: the relevant tolerance depends on the model, operating mode, measurement interval and service documentation.
| Observation | First evidence to collect | Next decision |
|---|---|---|
| Local rate steady; short pool estimate moves up and down | Matching intervals and successive observations | Check whether the difference persists over a longer documented window |
| Both views fall around the same time | Uptime, alarms and operating-change log | Investigate the recorded interruption rather than only the pool chart |
| Local rate appears normal; expected worker has no recent work | Configured endpoint, account, worker and timestamps | Verify identity and connection before changing performance settings |
| Reject or stale indicators increase | Counter definitions, reason messages and connection events | Ask the pool or manufacturer to interpret the specific evidence |
| Several machines share one worker | Machine-to-worker inventory | Separate the attribution problem from a device-performance claim |
Avoid changing pool, firmware and operating mode in one step. An intervention without a clear before-and-after record makes it harder to tell which change mattered. Do not raise voltage or frequency merely to compensate for a pool-side number. Hardware adjustments require the exact manufacturer's procedure and operating limits; this worksheet supplies neither tuning settings nor an electrical installation instruction.
Prepare a support record that answers a specific question
A useful ticket says what changed, when it changed and which comparison still fails. Include the model and variant, installed firmware, worker mapping, observation interval, local uptime, both rate readings with their labels, relevant counter deltas and redacted logs. State whether the issue affects one machine or several and list any action already taken. Remove passwords, tokens and unrelated account or customer information.
For an Antminer S21 XP listing, first confirm that the selected product option matches the physical unit. The listing identifies equipment; it is not evidence that your individual unit sustained that rate. If the pool configuration itself is unclear, the Parasite connection guide addresses that separate setup task. For purchasing or support coordination, contact LeedMiner with the observation record rather than a single cropped number.
