Introduction
An ASIC miner's local web interface and a mining pool's worker dashboard measure different parts of the same operation. The local interface reports what the machine itself is calculating and sensing — temperature, fan speed, and a locally estimated hashrate. The pool dashboard estimates effective hashrate from accepted shares and their assigned difficulty over its own reporting window. Confusing these two sources can lead to unnecessary troubleshooting. This article explains how to read each of the three core signals — temperature, fan speed, and hashrate — and how to interpret the gap between a miner's local display and a pool's estimated hashrate.
Start With the Miner's Local Status Page
Before interpreting any single reading, confirm the basic operating context: miner model, firmware version, current operating mode (if the firmware supports multiple performance modes), and uptime since the last restart. A machine that has just powered on or changed mode will show unstable short-term readings for temperature, fan speed, and hashrate simply because it has not reached a steady state. Because operating limits, sensor placement, and protection thresholds differ by model and firmware version, the manufacturer's manual for the exact model is the correct reference for what a given reading should look like — this article does not set a universal "safe" number for any of the three signals.
How to Read ASIC Temperature
A temperature reading is only meaningful once its source is identified. Depending on the model and firmware, an ASIC interface may separately report:
- Ambient temperature — air temperature near the miner's intake, reflecting the surrounding environment rather than the hardware itself.
- Hashboard temperature — a board-level sensor reading.
- Chip temperature — a sensor reading or estimate associated with the ASIC chips directly.
- Inlet and outlet temperature — readings associated with the inlet and outlet locations. Their exact sensor meaning depends on the model and firmware; do not assume they measure air temperature or establish cooling effectiveness on their own.
- Coolant temperature — relevant only to hydro-cooled models, and not comparable to air-cooled fan or ambient data.
Bitmain’s Antminer CGI documentation, for example, exposes ambient temperature as a distinct field alongside chain-level data, illustrating that a single miner can report several temperature values with different meanings at once.
Do not compare ambient temperature against a chip-temperature limit, and do not apply one model's documented threshold to a different model. Useful diagnostic patterns include: temperature rising together with fan speed (often a normal cooling response); one hashboard running consistently hotter than its peers on the same unit; temperature-related warnings appearing in the miner's log; or a temperature increase accompanied by a hashrate reduction, which may indicate the firmware's thermal protection is throttling performance.
How to Read Fan Speed
Most air-cooled ASICs report fan speed in RPM, often for several fans, since many designs use separate intake and exhaust fans. Some firmware also exposes a separate fan-control PWM value, typically expressed as a percentage or a 0–100 duty-cycle figure. PWM is a control setting the firmware sends to the fan; RPM is the fan's actual measured rotational speed in response to that setting. The two are related but not interchangeable, and a discrepancy between an expected PWM setting and the reported RPM can itself be a useful diagnostic signal.
A practical reading sequence for fan data:
- Confirm that every expected fan position reports a value; a missing reading is worth investigating on its own.
- Compare each fan against its expected behavior for that model, position, and control setting. A large difference between equivalent fans is worth investigating; fans in different roles do not necessarily run at the same RPM.
- Read fan behavior together with temperature and hashrate rather than in isolation.
- Treat a sustained zero, missing, or clearly abnormal reading as a reason to physically inspect the unit and consult the manufacturer's troubleshooting guidance.
- Do not assume a high fan speed by itself indicates a defective fan. Elevated RPM can be a normal response to warmer intake air, dust accumulation restricting airflow, or a higher-performance operating mode.
For example, if fan RPM rises on a warm day while board temperatures stay within the manufacturer's documented range and the miner's longer-term local hashrate remains stable, the cooling system is likely responding normally to ambient conditions rather than signaling a fault. Conversely, if one fan's RPM departs sharply from its expected behavior while temperature or hashrate deteriorates, that specific fan, its connector, and the surrounding airflow path warrant closer inspection.
How to Read ASIC Hashrate
Hashrate measures hashes per second. GH/s means billion hashes per second, and TH/s means trillion hashes per second: 1 TH/s = 1,000 GH/s. Check the displayed unit and convert readings to the same unit before comparing them.
Miner interfaces commonly expose more than one hashrate figure, each with a different averaging basis. Bitmain’s CGI documentation, for instance, distinguishes a 5-second reading, a 30-minute reading, a longer-run average, and a separate theoretical ("ideal") hashrate calculated from the current configuration. These are four distinct fields, not four names for the same number:
| Reading | What it represents | How to use it |
|---|---|---|
| Short-interval local hashrate | A miner-side estimate over a very short window (e.g., 5 seconds) | Confirms the miner is actively hashing; naturally noisy from one refresh to the next |
| Longer local hashrate | A rolling reading over a longer window (e.g., 30 minutes) or a runtime average | Better indicator of whether the machine is tracking its expected performance over time |
| Theoretical hashrate | The rate calculated from the miner's current configuration | A local benchmark; it does not confirm that the pool has received matching work |
| Pool-side hashrate | An estimate derived from accepted shares and their assigned difficulty during the pool’s reporting window | Shows work accepted during that period; compare with a local figure over a similar period, allowing for share-discovery variation |
A nominal or theoretical hashrate figure is not a promise of what any single dashboard refresh will show. Meaningful comparisons should use readings averaged over comparable periods, not a one-off screen snapshot.
Why Pool Hashrate Can Differ From Local Hashrate
The local interface and the pool dashboard rarely use the same averaging window, so a difference between them is expected and not automatically a fault. ViaBTC, for example, calculates its real-time worker hashrate as the average over the preceding 10 minutes, and its daily hashrate as the average over the preceding 24 hours (ViaBTC Help Center). A miner that has just restarted, for instance, may already show a normal short-interval reading locally while its 24-hour pool figure remains depressed simply because the outage period is still inside that rolling window.
Even over matching time windows, pool and local estimates can differ because shares are found at irregular intervals. This normal variation can put the pool estimate above or below the local reading even when the miner and connection are healthy. Longer reporting windows generally reduce this variation.
The gap can also reflect the underlying share submission process. In pooled mining, a pool assigns miners an easier proof-of-work target than the Bitcoin network target, so that miners submit shares frequently enough for the pool to estimate their contribution (Bitcoin Developer Guide: Mining). A numerically higher target corresponds to lower difficulty; a pool's share target is set higher — and therefore easier — than the network's block target, while a valid Bitcoin block still requires meeting the much harder network target.
Not every share submitted is accepted. Rejection reasons can include stale, invalid, or duplicate submissions, but labels and counter grouping vary by pool and firmware. Some interfaces display stale shares separately from rejected shares, so check the field definitions before interpreting or combining counters. A sustained rise in rejected shares can help explain a persistent gap between local and pool-side hashrate, but a single brief spike should be interpreted cautiously — first check the reporting window and the specific rejection reason before drawing conclusions. ViaBTC's own documentation lists network latency, elevated rejection rates, firmware compatibility, hardware configuration, and other miner-side issues as possible contributors to this gap, rather than attributing it to any single cause.
A Practical Reading Order
When a reading looks unusual, working through the following order can help separate normal variation from a condition that merits further investigation:
- Confirm the miner is online and check its uptime since the last restart or reconfiguration.
- Identify which temperature is being displayed (ambient, board, chip, or coolant) and compare it against the same type of reading on similar units or boards.
- Check individual fan readings against expected behavior for their positions and control settings, and consider airflow conditions such as dust or restricted intake.
- Confirm that hashrate units match, then compare a longer local reading against the closest available pool reporting window. Allow for normal variation in share discovery.
- If a discrepancy persists, review rejection reasons and miner logs rather than assuming a single cause.
- Consult the manufacturer's model-specific documentation, or qualified service support, before adjusting frequency, voltage, or thermal protection settings.
Conclusion
Reading an ASIC's temperature, fan speed, and hashrate accurately starts with identifying exactly what each number measures and over what time window. Read the sensor label, check the cooling system's response, compare hashrate over matching time windows, and then review rejected shares and miner logs if a discrepancy persists. This order keeps troubleshooting focused on distinguishing normal operating variation from a condition that genuinely needs attention.
FAQ
What is the difference between ASIC hashrate and pool hashrate?
Local ASIC hashrate is an estimate of the device’s operation over a short interval or a longer averaging period. A theoretical or ideal hashrate is a separate benchmark based on the miner’s configuration. Pool hashrate is estimated from accepted shares and their assigned difficulty over the pool’s reporting window — for example, ViaBTC's real-time figure averages the preceding 10 minutes, and its daily figure averages the preceding 24 hours. Compare operational readings in the same units over similar time windows, allowing for normal variation in share discovery.
Is a higher fan speed always a problem?
No. Fan speed commonly rises in response to warmer intake air, dust buildup, or a higher-performance operating mode, and this can be a normal part of the cooling system's automatic response. Investigate when a fan departs sharply from its expected behavior for its position and control setting, or when rising fan speed accompanies temperatures approaching the manufacturer’s documented limits or a drop in hashrate.
Which ASIC temperature should I watch?
This depends on which sensors the specific model and firmware expose — commonly ambient, hashboard, and chip temperature, and additionally coolant temperature on hydro-cooled models. There is no single universal safe number across all ASIC models; the manufacturer's manual for the exact model is the correct source for its documented operating limits.
Why is my 24-hour pool hashrate lower after restarting a miner?
Because the pool's daily hashrate is an average over the preceding 24 hours, a restart or outage earlier in that window continues to pull the average down even after the miner has resumed normal local hashing. The local interface, by contrast, can show a stabilized short-interval reading almost immediately after the restart.
Can one bad fan reduce hashrate?
A failing or significantly underperforming fan can allow board or chip temperatures to rise, which may trigger the firmware's thermal protection and reduce hashrate as a result. Checking a fan’s RPM against its expected behavior, alongside temperature and hashrate, is a reasonable way to investigate this pattern.
Are rejected shares always caused by latency?
No. Network latency is one possible cause, but rejected shares can also result from firmware compatibility issues, hardware configuration, or other miner-side conditions. Rejection reasons can include stale, invalid, or duplicate submissions, but dashboards may group these differently or show separate counters. Check the exact reason and field definitions in the pool or miner documentation.
References
- ViaBTC Help Center, "Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine?"
- Bitcoin Developer Guide, "Mining"
- Bitmain, Antminer CGI Documentation