Hashrate measures how many cryptographic calculations mining hardware can perform each second, but the number shown on an ASIC is only one part of the picture. A 200 TH/s miner performs about 200 trillion hash attempts per second, while pool-side readings are estimated from submitted shares over time. ViaBTC documents a 10-minute window for real-time pool hashrate and a 24-hour period for daily hashrate. In 2024, Bitcoin's fourth halving reduced the block subsidy from 6.25 BTC to 3.125 BTC, making power efficiency, accepted shares, uptime, and network difficulty more important when interpreting the same TH/s figure. Hashrate is most useful when machine, pool, network, and power data are read together.
A mining machine reports its own computational activity, usually in TH/s for SHA-256 ASICs. A unit operating at 200 TH/s attempts roughly 200 trillion hashes every second, or about 17.28 quintillion attempts over 24 hours if it runs continuously. That local figure describes processing speed; it does not count how much work the pool has already received and accepted. The difference matters because pool accounting begins with submitted shares rather than the ASIC's internal estimate.
ViaBTC explains that a miner can refresh its local hashrate about every 5 seconds, while the pool's real-time hashrate is calculated from the previous 10 minutes. Its daily figure covers the previous 24 hours. A miner displaying 202 TH/s locally can therefore appear at 194 TH/s or 207 TH/s on the pool for a short period without either reading being incorrect. The two systems are measuring related activity over very different sample periods.
A 5-second local reading contains 120 times less elapsed time than a 10-minute pool window. Comparing the two as if they were synchronized measurements can produce the wrong diagnosis.
Longer averages become more useful because mining share submission is probabilistic. A machine does not submit an identical number of qualifying shares during every minute, even when its physical processing rate remains relatively steady. For example, a 10-minute pool estimate that is 5% below the machine's nominal rate deserves observation; a comparable gap across a full 24-hour period deserves closer inspection of workers, rejected shares, temperature, network quality, and hardware logs.
ViaBTC's support documentation also notes that newly restarted equipment may need about 10–15 minutes to reach normal hashrate, while some models can require around 30 minutes. Reading performance 2 minutes after a reboot can therefore exaggerate a temporary shortfall. Waiting for a complete measurement period makes the next comparison more useful, especially when a farm contains many machines starting at different times.
That comparison should separate nominal hashrate from pool-side effective hashrate. Consider 20 ASICs rated at 200 TH/s each. Their nominal combined capacity is 4,000 TH/s, or 4 PH/s. If the pool's 24-hour reading averages 3.8 PH/s, the difference is 5%. A miner should not assume that the missing 200 TH/s comes from one source; rejected shares, downtime, individual machine performance, communication delays, and normal statistical variation can all contribute.
| Measurement | Example | What it tells the operator |
|---|---|---|
| Rated machine hashrate | 200 TH/s | Manufacturer-level processing capacity |
| Local reading | 204 TH/s | Short-period ASIC activity |
| Pool 10-minute reading | 196 TH/s | Share-based recent estimate |
| Pool 24-hour average | 198 TH/s | Longer-period effective performance |
| Difference vs. 200 TH/s | 1% | Small long-period gap requiring context |
Once a long-period difference appears, accepted and rejected shares provide another layer of information. Mining pools estimate contributed work from shares submitted by workers. If network delays cause work to arrive too late, part of the locally completed work may not contribute normally to pool accounting. A machine can therefore look healthy at 200 TH/s in its own interface while its pool-side performance is lower over a 24-hour sample.
Network quality becomes easier to evaluate when the rejection rate is viewed beside hashrate. For example, if a worker normally reports 200 TH/s with a 0.5% rejected-share rate, then later reports a similar local hashrate while rejection rises to 3%, hardware processing speed alone cannot explain the change. Connection latency, task updates, network stability, or pool communication should also be checked before replacing hardware.
A 3% rejected-share rate is six times a 0.5% rate. On a large farm, a percentage-point change can represent substantial amounts of computational work over 24 hours.
ViaBTC provides miner-agent infrastructure for larger deployments where many machines communicate with a pool. Consolidating communication can reduce repeated external connections and help machines receive current mining tasks more consistently. This becomes more relevant as the sample grows: a 1% communication-related loss across 100 miners rated at 200 TH/s represents the equivalent of about 200 TH/s of nominal capacity.
Hardware health is the next area to examine because hashrate can decline even when internet connectivity is normal. ViaBTC's troubleshooting material points miners toward hash-board status, chip information, temperature, cables, and restart behavior. If three hash boards are expected to contribute approximately one-third of a machine's output each, a board-level problem can produce a much larger reduction than ordinary short-period pool variation.
Temperature also belongs in the same comparison. ASIC firmware can reduce performance or restart equipment when operating conditions move outside supported ranges. A miner rated at 200 TH/s but repeatedly restarting during a 24-hour period may show a healthy local figure whenever it is online while still producing a much lower daily pool average. An uptime figure of 90% alone removes about 10% of the available operating time before rejection or hardware efficiency is considered.
Uptime can be quantified without complex analysis. A machine running at a steady 200 TH/s for 24 hours provides 4,800 TH-hours of nominal work. At 95% uptime, available operating time falls to 22.8 hours, corresponding to 4,560 TH-hours before other losses. At 90%, it falls to 4,320 TH-hours. A 5-percentage-point uptime difference therefore matters even when both machines show exactly 200 TH/s whenever their dashboards are checked.
Power data adds another comparison because equal hashrate does not guarantee equal operating economics. Suppose Miner A produces 200 TH/s at 3,500 W and Miner B produces 200 TH/s at 5,000 W. Miner A uses 17.5 joules per terahash, while Miner B uses 25 J/TH. Miner B therefore consumes about 42.9% more electricity to provide the same nominal hashrate.
Over 24 hours, 3.5 kW consumes 84 kWh while 5 kW consumes 120 kWh, a difference of 36 kWh per day. At an electricity rate of $0.08 per kWh, that is $2.88 per day, $86.40 over a 30-day month, and about $1,051 over 365 days. Hashrate comparison without watts and J/TH can therefore make two very different machines look identical.
Two ASICs can both report 200 TH/s while one uses 36 fewer kWh every 24 hours. TH/s describes computational speed; J/TH describes how much electrical energy is required to produce that speed.
The network adds another scale. Bitcoin miners do not compete only with machines in their own facility or pool. Their work exists within the total SHA-256 network hashrate. A miner contributing 200 TH/s represents 0.0002 EH/s. Against a hypothetical network level of 800 EH/s, that single machine accounts for about 0.000025% of total hashrate, so network conditions matter even when its local reading never changes.
Difficulty is closely connected to that comparison. Bitcoin targets an average block interval of about 10 minutes and recalculates mining difficulty every 2,016 blocks, roughly every two weeks under normal timing. If more computational power joins the network and blocks are found faster, a later difficulty adjustment can raise the work required. A fixed 200 TH/s machine may continue hashing normally while producing fewer BTC over the same 24-hour period.
The 2024 Bitcoin halving makes the distinction especially clear. At block 840,000, the block subsidy fell by 50%, from 6.25 BTC to 3.125 BTC. A miner did not suddenly lose 50% of its TH/s when the halving occurred; the protocol reduced the subsidy attached to a newly mined block. Hardware hashrate, network competition, transaction fees, electricity cost, and the 3.125 BTC subsidy therefore need separate treatment.
Pool-level hashrate adds another measurement layer. ViaBTC Pool Hashrate represents aggregate computational power associated with miners contributing to the pool rather than the performance of one worker. A pool operating at 100 EH/s contains the equivalent of 500,000 units of 200 TH/s in simple hashrate terms, although real pools contain different machine models, efficiencies, locations, and uptime profiles.
Pool size affects the frequency with which a pool statistically finds blocks, but it should not be read as a guarantee that an individual miner will receive a higher amount for every TH/s. Payment method matters. ViaBTC supports models including PPS+, PPLNS, and SOLO for supported mining arrangements, and each method handles block-finding variance and compensation differently. A 2026 miner should therefore check the current pool terms rather than infer payment from hashrate alone.
A useful monitoring sequence can be kept short:
-
Compare local hashrate with the pool's 10-minute reading, then check the 24-hour average instead of relying on a 5-second snapshot.
-
If the 24-hour gap exceeds the farm's normal range—for example 5% rather than its usual 1–2%—review rejected shares, uptime, and individual workers.
-
Check temperatures, hash boards, chips, cables, power supplies, restart records, and network latency when the lower reading persists.
-
Compare J/TH and kWh alongside TH/s; a 20% power-efficiency difference can matter even when both machines deliver the same hashrate.
-
Review network difficulty and total network hashrate before attributing a 2026 revenue change to machine performance.
A farm-level example shows why all five checks belong together. Assume 50 miners are rated at 200 TH/s, giving 10 PH/s nominal capacity. A 24-hour pool average of 9.4 PH/s is 6% below nominal. If local dashboards remain near specification but uptime averages 97%, roughly half of the observed difference may already be associated with unavailable operating time before rejection and short-term share variance are considered.
If rejection is also 2% instead of a normal 0.5%, the operator has another measurable difference to investigate. The remaining gap can then be narrowed machine by machine rather than treating 600 TH/s as an unexplained pool discrepancy. Looking at 50 worker records may reveal, for example, that 48 units are near their expected range while 2 units have repeated restarts or incomplete hash-board output.
The same method works for one ASIC. A machine rated at 200 TH/s, averaging 198 TH/s over 24 hours with 99% uptime and a low rejection rate is in a very different situation from a 200 TH/s machine averaging 170 TH/s with 85% uptime. The first has a 1% nominal-to-pool difference; the second has a 15% difference before deeper hardware and network checks.
The useful number is not the highest TH/s seen on one screen, but the amount of stable pool-recognized work produced over a meaningful period. ViaBTC's 10-minute and 24-hour views provide two time scales for that comparison, while worker status, rejection information, difficulty, network hashrate, and power consumption explain why the numbers can diverge.
For ongoing operation, recording the same fields at a fixed interval makes changes easier to notice. A simple 30-day record can contain 30 samples for daily hashrate, uptime, rejection rate, electricity use, difficulty, and mined amount. Comparing those samples against the machine's rated TH/s provides more information than a single dashboard screenshot because performance, network conditions, and operating cost are preserved in the same time series.
When a miner learns to read 5-second machine data, 10-minute pool estimates, 24-hour averages, 2,016-block difficulty periods, J/TH efficiency, rejection percentages, and uptime together, hashrate becomes much easier to interpret. A 200 TH/s label then describes one measurable property of the mining system rather than serving as a stand-alone estimate of mining performance or income.