A firmware upgrade, overclock, underclock, or revised frequency profile should be evaluated as an operating-economics decision, not simply as a hashrate contest. The relevant question is not whether the miner dashboard displays more terahashes per second (TH/s). It is whether the new configuration improves realized profit after electricity, pool fees, firmware costs, downtime, cooling requirements, maintenance, and reliability are taken into account.
Bitcoin mining conditions can change while a test is running. Network difficulty retargets every 2,016 blocks, roughly every two weeks, so BTC earnings may change even when a miner's configuration stays the same. A controlled test should therefore separate configuration effects from changes in network and pool conditions.
The basic decision framework is incremental net profit:
Incremental net profit
= change in realized mining revenue
- change in electricity cost
- change in firmware or licensing fees
- change in maintenance and repair cost
- change in other operating costs
Use consistent definitions. If realized mining revenue already reflects pool fees, do not subtract those fees again. If downtime is already reflected in lower realized output, do not deduct the same lost production a second time. If a hosting bill already includes electricity or cooling, avoid counting those costs again as separate inputs.
A configuration that produces more TH/s can therefore be economically worse. Conversely, an underclock that reduces hashrate may improve profitability when electricity is expensive or when lower power draw materially improves efficiency and reliability.
Start With a Controlled Test
Establish a multi-day baseline before making a major change. Seven days can be a practical starting point where conditions are reasonably stable because it captures several daily operating cycles, but it should not be treated as a universal requirement.
Where fleet size permits, a concurrent control group is stronger than a simple before-and-after comparison. Apply the new configuration to a representative pilot group while keeping a matched group unchanged at the same site.
Match as closely as practical:
- ASIC model;
- manufacturing batch;
- cooling method;
- machine condition;
- power environment; and
- operating schedule.
This helps separate the effect of the configuration from changes in weather, network difficulty, transaction fees, curtailment, or site conditions.
Change one major variable at a time where practical. If the objective is to test new firmware, keep the power target and frequency profile close to the previous configuration at first. If the objective is to test a frequency or power target, keep firmware, pool endpoint, payment method, and cooling settings unchanged.
Record autotuning, reboot, and ramp-up periods separately. They may be excluded from steady-state efficiency calculations, but they still matter economically if they create repeated downtime.
Compare Local and Pool-Side Hashrate Correctly
Local hashrate and pool-side hashrate answer different questions.
Local hashrate is the miner's own estimate of the work it is performing. It is useful for evaluating hardware behavior, chip performance, frequency settings, and device-level efficiency.
Pool-side hashrate is estimated from valid shares observed by the pool over a defined time window. It is affected by the pool's averaging method as well as normal statistical variation in share submission.
ViaBTC explains that its real-time pool hashrate uses the average over the previous 10 minutes, while a mining machine may refresh its local estimate much more frequently.
For profitability analysis, compare:
- average local hashrate;
- average pool-side hashrate over a comparable period;
- accepted and rejected share counts;
- rejection reasons;
- uptime; and
- restart behavior.
Do not treat pool-side hashrate and accepted shares as interchangeable concepts. Pools receive and validate shares, then estimate hashrate from submitted work over time.
A basic rejection rate is:
Rejection rate = rejected shares / total submitted shares × 100
Where the pool provides rejection reasons, review stale, invalid, duplicate, and other rejected shares separately.
An overclock may increase local hashrate while producing a smaller improvement in pool-side hashrate if the new settings increase hardware errors, instability, or rejected shares.
See: Why Is the Hashrate Shown in the Mining Pool Lower Than That of the Mining Machine?
Use Measured Wall Power and Standard J/TH
ASIC-reported wattage is useful for diagnostics, but profitability analysis should preferably use measured wall power from a calibrated PDU, branch-circuit meter, or another reliable source.
For device-level efficiency:
J/TH = measured miner power in watts / average local hashrate in TH/s
Use averages from the same steady-state measurement window.
For example:
3,200 W / 200 TH/s = 16.00 J/TH
If an overclock increases average local hashrate to 215 TH/s while wall power rises to 3,700 W:
3,700 W / 215 TH/s = 17.21 J/TH
The miner produces 7.5% more local hashrate, while device efficiency worsens by about 7.6%.
Pool-side performance should be evaluated separately. Do not substitute a pool-estimated hashrate into the standard J/TH calculation in order to incorporate rejected shares or network behavior.
This separation makes diagnosis clearer:
- if J/TH worsens while pool-side performance remains normal, the issue may be the frequency-voltage-power curve;
- if local hashrate improves but pool-side hashrate does not improve proportionally, review rejected shares, instability, and connectivity;
- if both local and pool-side hashrate fall, investigate miner hardware, power, cooling, firmware, or tuning settings.
Convert Engineering Results Into Profitability
Whenever possible, calculate electricity expense from actual metered energy:
Electricity cost
= metered energy consumption in kWh
× effective electricity price per kWh
If interval energy data is unavailable:
Electricity cost
= average operating power in kW
× operating hours
× electricity price per kWh
Do not multiply by uptime again if the measured kWh already covers the entire test period.
The nominal utility rate may also differ from the site's effective power cost. Depending on the operation, miners may face delivery charges, hosting charges, demand charges, taxes, cooling charges, or other site-specific costs. Demand-based and fixed charges should be allocated consistently rather than automatically folded into a simple energy tariff.
Consider an illustrative air-cooled ASIC:
| Metric | Baseline profile | New frequency profile |
|---|---|---|
| Average local hashrate | 200 TH/s | 215 TH/s |
| Wall power | 3.20 kW | 3.70 kW |
| Device efficiency | 16.00 J/TH | 17.21 J/TH |
| Uptime | 99.5% | 98.5% |
| Daily electricity cost at $0.06/kWh | $4.59 | $5.25 |
The new profile costs about $0.66 more per machine per day in electricity. That additional cost must be recovered through higher realized mining revenue before considering any added firmware, maintenance, or reliability cost.
Three financial outputs are useful:
- BTC credited during the test period
- Normalized BTC yield per PH/s per day
- USD net profit per machine-day
When comparing USD results, use the same BTC reference price for both configurations or clearly separate mining-performance changes from price changes.
BTC price affects the fiat value of mining revenue. It does not by itself change the amount of BTC credited.
Normalize for Changing Network and Pool Conditions
A simple normalized production measure is:
Normalized BTC yield
= BTC credited during the period
/ average pool-side hashrate in PH/s
/ number of days
The pool-side hashrate and BTC credits must cover the same period.
If average pool-side hashrate already includes offline periods, do not multiply or divide by uptime again. Keep uptime as a separate diagnostic metric.
Normalized BTC yield can still change because of:
- network difficulty;
- transaction-fee conditions;
- the selected payment method;
- pool luck where PPLNS exposure applies;
- pool fee changes; and
- differences in the measurement window.
Under ViaBTC's current PPS+ structure, the block-reward component uses PPS and is paid hourly based on current difficulty, while the transaction-fee component uses PPLNS. Under PPLNS, both block rewards and transaction fees follow PPLNS rules after the relevant pool-found block reaches six confirmations.
See: How Are Profits Calculated?
Evaluate Reliability and Thermal Behavior
A profitable setting in a short benchmark may not remain profitable over several months.
Review:
- uptime;
- unplanned restarts;
- hashboard failures;
- chip-error counts;
- inlet, outlet, and board temperatures;
- thermal throttling;
- fan or pump behavior;
- power-supply alarms;
- maintenance labor;
- repair cost; and
- recovery time after power or network events.
Do not rely only on averages. A configuration that works well on the strongest miners but destabilizes weaker units may perform poorly when deployed fleet-wide.
Apply Deployment Controls Before Scaling
Firmware changes introduce software, compatibility, security, and recovery risks as well as performance changes.
Before scaling:
- verify the firmware source;
- confirm compatibility with the exact ASIC and control-board revision;
- preserve a rollback or recovery path;
- review administrative-access controls;
- confirm remote-management compatibility;
- review any effect on warranty or vendor support.
A staged rollout can move from a small verification group to a representative pilot, then to a larger cohort, and finally to full deployment after economic and reliability results are acceptable.
Exact cohort sizes and test periods should depend on fleet size and operational risk rather than being treated as universal standards.
Define stop conditions in advance, such as:
- a material increase in rejection rate;
- repeated thermal throttling;
- excessive restart frequency;
- unacceptable hardware errors;
- lower-than-expected pool-side hashrate; or
- negative incremental net profit.
Make the Decision With a Scorecard
For each tested profile, report:
Miner-side performance
- average local hashrate;
- wall power;
- J/TH;
- temperatures and hardware errors.
Pool-side performance
- average pool-side hashrate over a matching window;
- rejection rate;
- rejection reasons;
- connection stability.
Reliability
- uptime;
- restart frequency;
- thermal events;
- maintenance incidents.
Financial performance
- BTC credited;
- normalized BTC yield per PH/s per day;
- electricity cost;
- firmware or licensing fees;
- maintenance cost;
- net profit per machine-day.
Approve a configuration when the economic improvement remains positive after realistic costs and the reliability profile is acceptable.
The central principle is simple: higher hashrate is an input, not proof of higher profitability.
FAQ
How long should a firmware profitability test run?
Use a multi-day period long enough to capture normal operating variation. Seven days can be a practical starting point, but a matched control group or longer measurement period provides stronger evidence for larger deployments.
Should I compare local or pool-side hashrate?
Use both. Local hashrate helps evaluate miner performance and J/TH. Pool-side hashrate helps show how submitted work appears at the pool over a defined averaging window.
Is a lower J/TH profile always more profitable?
No. Lower J/TH improves device efficiency, but total profit also depends on hashrate, electricity price, uptime, BTC mining revenue, pool fees, firmware costs, maintenance, and reliability.
Why did my BTC earnings change even though my settings did not?
BTC-denominated mining earnings can change because of difficulty, transaction fees, payment method, pool luck where relevant, downtime, and normal mining variance. BTC price affects the fiat value of those earnings, not the BTC amount by itself.
Should I deploy new firmware to an entire farm at once?
For significant firmware or tuning changes, a staged deployment is generally safer. Use a representative pilot, verify recovery procedures, and expand only after performance and reliability are acceptable.