Autotuning is the process of adjusting operating parameters to find a usable balance between hashrate, power and hardware errors. It can be valuable when a miner has different chip quality or when an operator needs a lower-power profile, but it is not a magic profitability switch. The result has to be measured at the wall and compared with the machine’s full operating cost.
Build a baseline before touching the profile
Record the miner model, firmware version, pool, accepted hashrate, wall power, temperature, hardware errors, rejected shares, fan behavior and uptime. Note the electricity rate, pool fee, developer fee, hosting charge and any cooling cost that belongs in the comparison.
Use the same measurement definitions before and after. Software-reported power can be useful for a quick view, but wall power is the number that reaches the electricity bill. Accepted hashrate is more useful than an advertised maximum because it reflects submitted work that the pool accepts.
Test conservatively
Start with one miner. Keep the environment stable and change one profile at a time. A short test can show whether the device starts, but it may not show thermal drift, error accumulation or intermittent pool problems. Let the machine run long enough for the conditions you care about, then compare the same metrics with the baseline.
If temperature or error rates move in the wrong direction, return to the last stable profile. Do not interpret a higher number as an improvement when the machine is unstable or when the extra output is offset by power and downtime.
Daily electricity-cost formula
Power cost per day equals watts divided by 1,000, multiplied by 24 hours, multiplied by the electricity rate. For a 3,000-watt miner at $0.08 per kWh: 3,000 ÷ 1,000 × 24 × $0.08 = $5.76 per day. Monthly electricity can be approximated by multiplying the daily cost by the number of operating days, but a real log should account for downtime and changing conditions.
If a profile adds 200 watts, the increment is 0.2 × 24 = 4.8 kWh per day. At $0.08 per kWh, that extra draw costs $0.384 per day. Whether the profile is worthwhile depends on the additional accepted revenue after fees, not on the percentage increase in hashrate by itself.
Before-and-after worksheet
| Measure | Before | After | What to look for |
|---|---|---|---|
| Wall draw | Record watts | Record watts | Include the full change in energy cost |
| Accepted hashrate | Record pool value | Record pool value | Use accepted, not advertised, output |
| Hardware errors | Record count/rate | Record count/rate | Reject unstable profiles |
| Temperature | Record range | Record range | Check the warmest period |
| Uptime | Record period | Record period | Downtime reduces real output |
| Fees | Record all | Record all | Include pool and developer terms |
How to interpret the result
A good profile is not necessarily the one with the highest hashrate. It is the profile that produces a repeatable, accepted result at a cost and temperature your operation can support. Electricity prices, coin prices, network difficulty, pool payout rules, cooling and hardware condition can change the result after the test.
Use the firmware and compatibility rubric when a result raises questions about model support, recovery or safety. Keep a dated record of the firmware version, profile, environment and measurements so a later comparison is not based on memory.
Revenue is not a net result
A calculator or pool dashboard can show projected or gross revenue, while the decision should use what remains after operating costs. Include electricity, pool and developer fees, hosting, cooling, withdrawal costs, maintenance, downtime and hardware depreciation when relevant. Keep assumptions beside the calculation and label vendor estimates separately from wall-meter or pool observations.
Efficiency and operating envelope
Joules per terahash is useful, but it does not replace a stability check. Two profiles can show similar efficiency while one has more errors or downtime. A profile that works in a cool test room may behave differently in a dense rack or warm season. Check the power supply and circuit, not only the miner’s nominal wattage.
Read the comparison in order
First check whether the test conditions are comparable. Note changes in pool, coin price, network difficulty and ambient temperature. Next check whether the window includes ordinary interruptions. Then review accepted hashrate, wall watts, errors, temperature and uptime together. Only after that compare cost and output.
Sensitivity checks
Change one assumption at a time. Recalculate at a higher electricity rate, 95% uptime and with a previously omitted fee. These checks do not predict the market; they show which assumptions drive the decision. Record negative results too: a rejected profile defines a useful boundary for the next test.
When not to tune
Do not tune while the miner has an unresolved hardware fault, unstable power, inadequate cooling, missing recovery access or an unknown control-board revision. Fix the measurement problem first. Autotuning can optimize observed conditions, but it cannot repair a hash board or make an overloaded circuit safe.
Choose the objective before the profile
There is no single best profile without an objective. A maximum-hashrate objective prioritizes output within thermal and electrical limits. An efficiency objective prioritizes joules per terahash. A noise or heat objective may accept lower output to make a room, circuit or hosting arrangement workable. State the objective first, because it determines which trade-offs count as improvements.
Define a constraint separately from the objective. For example, maximize accepted hashrate while staying below a wall-power limit and a temperature limit. This is clearer than saying “make it more profitable,” which can conceal a rise in fees, downtime or operational risk. A profile that wins one metric while violating a hard constraint is not a successful result.
Measure at the wall and at the pool
Wall power should be measured with a suitable meter and recorded with the time window. Pool results should use accepted hashrate and, where possible, accepted shares over a meaningful period. Firmware estimates can help with quick diagnostics but should not be treated as an electricity bill. Also record whether the meter includes the whole power supply path and whether the pool dashboard uses a short or long averaging window.
Account for stability
Stability has an economic value. A profile that needs frequent restarts or produces many errors can reduce realized output even when its instantaneous hashrate looks attractive. Include uptime, rejected shares, hardware errors, fan behavior and thermal excursions in the comparison. If a profile requires constant manual attention, that labor is part of its operational cost even when it is not visible in a calculator.
Use staged tuning
Change one parameter or one bounded profile at a time. Start conservatively, allow the device to stabilize and compare against the current baseline. If the result is acceptable, keep it as a candidate and test it again under another ordinary condition. Avoid applying a new value to an entire fleet after one successful unit; silicon variation, cooling and power delivery can produce different outcomes.
Explain uncertainty honestly
Profitability changes with coin price, network difficulty, pool luck, fees, electricity and uptime. A field note should therefore describe measured conditions and assumptions rather than promise a permanent return. Use sensitivity checks to show what happens if the electricity rate rises, uptime falls or a fee is added. The aim is a better operating decision, not a false sense of precision.