Performance Metrics

Hash Rate

Hash rate measures how many hash calculations mining hardware can perform per second.

ASIC miner performance is commonly expressed in:

• TH/s — terahashes per second

• PH/s — petahashes per second

• EH/s — exahashes per second

For an individual modern ASIC, TH/s is commonly used.

For example:

150 TH/s

means the miner performs approximately 150 trillion hash attempts per second.

Hash rate is one of the most fundamental mining performance metrics.

Local Hash Rate

Local hash rate is calculated or estimated by the ASIC miner or its software.

It provides fast feedback about hardware performance.

For example:

Configured Performance: 150 TH/s

Local Hash Rate: 148 TH/s

This may indicate normal operation.

However, local hash rate does not directly prove that all useful work is reaching and being accepted by the mining pool.

Pool-Side Hash Rate

A mining pool estimates hash rate based on shares received from the miner.

This is often called:

• pool-side hash rate

• effective hash rate

• effective pool hash rate

Because share discovery is probabilistic, pool-side hash rate can fluctuate substantially over short periods.

Longer observation windows generally provide a more useful comparison with expected hardware performance.

Local vs Pool-Side Hash Rate

Both measurements are useful.

Local Hash Rate

Shows what the miner believes it is producing.

Pool-Side Hash Rate

Shows the mining work inferred by the pool from submitted shares.

A persistent difference can indicate problems.

For example:

Local: 150 TH/s

Pool-Side: 120 TH/s over a sufficiently long period

Possible causes may include:

• rejected shares

• stale shares

• network problems

• unstable mining

• inaccurate local reporting

Short-term differences alone do not necessarily indicate a problem.

Power Consumption

Power consumption measures how much electrical power a miner uses.

It is typically expressed in watts (W) or kilowatts (kW).

For example:

3,500 W = 3.5 kW

Power consumption is important because electricity is one of the major operating costs in Bitcoin mining.

Two miners with similar hash rates can have significantly different electricity requirements.

Energy Efficiency

Energy efficiency measures how much electrical energy is required to produce a unit of hashing performance.

For Bitcoin ASIC miners, it is commonly expressed in:

J/TH — joules per terahash

The simplified calculation is:

J/TH = Power (W) ÷ Hash Rate (TH/s)

Lower J/TH indicates better energy efficiency.

For example:

3,600 W ÷ 150 TH/s = 24 J/TH

compared with:

3,600 W ÷ 120 TH/s = 30 J/TH

The first configuration produces more hashing work from the same electrical power.

Hash Rate vs Efficiency

Higher hash rate does not automatically mean better efficiency.

Consider two operating profiles:

Profile A provides more hash rate.

Profile B provides better energy efficiency.

The appropriate profile depends on mining economics and facility constraints.

Accepted Shares

Mining pools assign work at a share difficulty below the Bitcoin network target so that miner contributions can be measured regularly.

When an ASIC finds a hash satisfying the assigned share target, it submits a share.

An accepted share is a submitted share that the pool accepts as valid for the assigned work.

Accepted shares provide evidence that useful mining work is reaching the pool.

Rejected Shares

A rejected share is work submitted by a miner but not accepted by the pool.

Reasons can include:

• stale work

• invalid submissions

• duplicate submissions

• communication problems

• configuration issues

The exact reason depends on the pool and protocol implementation.

An unusually high rejection rate can reduce effective mining performance.

Rejection Rate

A rejection rate can be calculated from share statistics.

A simplified representation is:

Rejected Shares ÷ Total Submitted Shares × 100%

For example:

20 rejected ÷ 2,000 submitted × 100% = 1%

Interpretation should consider the pool, network conditions, measurement period, and rejection reason.

A single universal acceptable rejection percentage should not be assumed for every mining environment.

Stale Share Rate

Stale shares are generally associated with work that is no longer current when it reaches or is evaluated by the pool.

They can occur around mining-job changes.

High stale rates may indicate:

• network latency

• unstable connectivity

• delayed job processing

• other communication problems

Tracking stale shares helps operators evaluate the quality of the connection between miners and pools.

Uptime

Uptime measures how long a miner or its software has been running without restarting.

For example:

Uptime: 17 days

Long uptime can indicate stability.

However, uptime alone is not enough.

A miner can technically remain online while operating at reduced hash rate.

Therefore:

Online ≠ Fully Productive

Uptime should be evaluated together with hash rate and other metrics.

Availability

Availability measures how much of a defined period mining equipment is available for productive operation.

A simplified calculation is:

Availability = Operating Time ÷ Total Time × 100%

For example, if a miner is available for 23 hours during a 24-hour period:

23 ÷ 24 × 100% ≈ 95.8%

At fleet scale, availability can help operators understand how much installed mining capacity is actually usable.

Uptime vs Availability

The terms are related but not identical.

Uptime

Often describes how long a specific miner or process has been running since its last restart.

Availability

Describes the proportion of time equipment is available for productive operation.

A miner may reboot occasionally while still maintaining high overall availability.

Hardware Error Rate

ASIC hardware can generate incorrect computational results.

Firmware may report these as HW errors.

Possible causes include:

• excessive frequency

• insufficient voltage

• overheating

• unstable chips

• hardware faults

Raw cumulative error counts can be misleading because they increase with operating time.

A normalized error rate or trend is generally more useful.

Temperature Metrics

Temperature is primarily a health and operating-condition metric, but it strongly affects performance.

Depending on hardware, telemetry may include:

• ASIC die temperature

• hashboard temperature

• other internal sensor readings

• intake or environmental temperature

Excessive temperature can lead to:

• instability

• higher error rates

• throttling

• shutdown

Temperature should be interpreted according to the specific ASIC model and sensor implementation.

Fan Speed

Air-cooled ASIC miners commonly report fan speed in RPM.

Fan-speed metrics help identify:

• failed fans

• abnormal cooling behavior

• unusually high cooling demand

However:

RPM ≠ Airflow

Actual airflow also depends on:

• fan design

• static pressure

• filters

• heat sinks

• ducts

• system resistance

Fan RPM is therefore an operational indicator rather than a complete measurement of cooling performance.

Hashboard Performance

Monitoring per-hashboard performance can help identify partial miner failures.

For example:

Board 1 → 50 TH/s

Board 2 → 49 TH/s

Board 3 → 0 TH/s

Total miner performance may fall from approximately 150 TH/s to approximately 100 TH/s.

A total hash-rate metric reveals the performance loss.

Per-board metrics help locate it.

ASIC Chip Metrics

Some firmware provides chip-level or chip-group performance information.

Depending on the implementation, operators may be able to observe:

• detected chips

• unstable chips

• error behavior

• frequency

• tuning parameters

This information is particularly useful for autotuning and hardware diagnostics.

Performance Metrics and ASIC Tuning

ASIC tuning changes operating parameters such as:

• frequency

• voltage

• power limit

Performance metrics provide the feedback needed to evaluate those changes.

A typical tuning process is:

Change Settings → Measure Hash Rate → Measure Power → Check Errors → Check Temperature → Evaluate Pool Performance

Without measurement, operators cannot determine whether a tuning change actually improved the miner.

Performance Metrics and Overclocking

Overclocking can increase hash rate by operating ASIC hardware at higher frequencies.

For example:

150 TH/s → 170 TH/s

But the operator should also examine:

• power increase

• J/TH

• temperatures

• HW errors

• pool-side performance

• stability

If power increases disproportionately, the miner may become less efficient even though its hash rate increases.

Performance Metrics and Undervolting

Undervolting reduces ASIC operating voltage where hardware and firmware permit it.

A successful configuration may reduce:

• power consumption

• heat

while maintaining acceptable hash rate.

The relevant question is not:

“Did power decrease?”

but:

“How did power decrease relative to useful hash rate and stability?”

This is why J/TH and pool-side performance are important.

Performance Metrics and Power Limits

Mining operators may configure miners to operate within defined power limits.

For example:

Power Target: 3,000 W

The tuning system can adjust frequency and voltage to find a stable operating point within that target.

Performance metrics then determine:

• resulting hash rate

• J/TH

• temperature

• errors

• stability

This is useful when facilities have electrical or cooling constraints.

Performance Metrics and Thermal Throttling

Some ASIC systems reduce performance when thermal conditions become unsafe.

A monitoring system might observe:

Temperature Rises → Frequency Reduced → Power Falls → Hash Rate Falls

Looking only at hash rate could make the event appear to be a hardware failure.

Combining performance and thermal metrics reveals a more complete picture.

Performance Metrics and Monitoring Systems

A monitoring system collects performance metrics from many miners.

A fleet dashboard may display:

• total hash rate

• total power

• fleet J/TH

• availability

• offline miners

• temperature warnings

• miners below expected performance

Operators can then move from:

Fleet → Site → Rack → Miner → Hashboard

to locate performance problems.

Performance Metrics and Telemetry

Telemetry is the mechanism through which many performance metrics are collected and transmitted.

The relationship is:

ASIC Hardware → Telemetry → Performance Metrics → Monitoring → Analysis

Telemetry provides the raw operational information.

Performance metrics turn selected measurements into useful indicators of miner behavior.

Performance Metrics and Alert Systems

Performance metrics can trigger alerts.

Examples include:

Hash Rate Below Expected Range → Alert

Efficiency Deteriorates → Warning

Temperature Too High → Alert

Hardware Error Rate Increases → Warning

Miner Offline → Critical Alert

Thresholds should account for the specific miner model and normal operating behavior.

Performance Metrics and Log Files

Metrics show measurable conditions.

Logs provide event context.

For example:

Metric: Hash rate dropped at 13:42.

Log: Hashboard 2 failed initialization after a restart at 13:41.

Combining metrics and logs makes troubleshooting more effective.

Performance Metrics and ASIC Diagnostics

Performance metrics help identify abnormal miners.

For example:

Normal Power + Low Hash Rate + High HW Errors

suggests a different problem from:

Low Power + Missing Hashboard + Low Hash Rate

Diagnostics then determines the root cause.

Performance metrics are therefore an important input to diagnostics rather than a replacement for it.

Performance Baselines

A baseline represents the expected performance of a miner or group of miners under defined conditions.

For example:

Expected Hash Rate: ~150 TH/s

Expected Power: ~3,600 W

Expected Efficiency: ~24 J/TH

Actual values can then be compared with the baseline.

Baselines should account for:

• ASIC model

• firmware

• tuning profile

• operating environment

This is more useful than comparing every miner with one universal standard.

Performance Trends

A single measurement provides only a snapshot.

Historical trends can reveal gradual deterioration.

For example:

Month 1 → 150 TH/s

Month 2 → 148 TH/s

Month 3 → 144 TH/s

If the change is persistent, operators can investigate possible causes such as:

• cooling degradation

• tuning changes

• hardware instability

• hashboard problems

Trend analysis is particularly useful for preventive maintenance.

Miner-Level vs Fleet-Level Metrics

Performance can be measured at different levels.

Miner-Level

Examples:

• miner hash rate

• miner power

• miner J/TH

Rack-Level

Examples:

• combined hash rate

• combined power

• number of offline miners

Site-Level

Examples:

• total site hash rate

• total power

• fleet availability

• average efficiency

The same performance principles can therefore be applied from a single ASIC to an industrial mining facility.

Performance Metrics and Mining Economics

Technical performance should ultimately be considered alongside mining economics.

For example, an operator may choose between:

Higher Hash Rate + Higher Power

and:

Lower Hash Rate + Better Efficiency

The preferred operating point can change with:

• electricity price

• Bitcoin mining revenue

• network difficulty

• hardware efficiency

• cooling constraints

• power availability

Performance metrics provide the technical measurements needed to evaluate these choices.

Performance Metrics at Mining-Farm Scale

At industrial scale, performance metrics create a measurable operating model.

A simplified architecture is:

ASIC Miners → Telemetry → Metrics Database → Monitoring → Analytics → Optimization

Operators can use this system to identify:

• best-performing miners

• inefficient miners

• unstable tuning profiles

• problematic racks

• cooling issues

• recurring hardware failures

This makes optimization possible across thousands of machines rather than one miner at a time.

Benefits of Performance Metrics

Performance metrics provide:

• objective measurement of ASIC performance

• energy-efficiency tracking

• hardware health visibility

• tuning feedback

• pool-performance analysis

• faster identification of underperforming miners

• historical trend analysis

• fleet-level comparison

They allow mining decisions to be based on measurable operating data rather than assumptions.

Limitations of Performance Metrics

Metrics must be interpreted carefully.

Potential limitations include:

• sensor inaccuracies

• different firmware calculation methods

• short-term hash-rate fluctuations

• incomplete power measurements

• delayed telemetry

• inconsistent sampling intervals

A single metric can also be misleading when viewed in isolation.

For example:

Higher Hash Rate

does not automatically mean:

Better Efficiency, Stability, or Profitability

Mining performance is best evaluated using several related metrics together.