Two mining machines can report the same hashrate while drawing different amounts of power. Two operating profiles on the same machine can do the same. That is why an ASIC comparison needs an energy-efficiency measure alongside its headline performance number. Joules per terahash, usually written J/TH, is useful because it relates energy consumed to hashing work rather than presenting either number alone.
This guide explains the arithmetic, then turns it into a measurement method. The examples are invented for learning, not benchmark results or equipment recommendations. The goal is to make your next efficiency comparison reproducible and honest about what it includes.
Understand the units before the ranking
A watt is a joule per second. A hashrate in TH/s is terahashes per second. Dividing watts by TH/s cancels the seconds, leaving joules per terahash. Under the same measurement conditions, a lower J/TH value means less energy is used for each terahash. The Braiins hardware purchasing guide identifies hashrate, power, and efficiency as separate specifications to examine.
Suppose a fictional miner reports 200 TH/s while measured power is 4,000 W. Dividing 4,000 by 200 gives 20 J/TH. Another fictional profile reports 180 TH/s at 3,240 W, giving 18 J/TH. The second profile uses less energy per unit of hashing work, but also produces fewer hashes per second. That distinction is the start of the decision, not its conclusion.
Define the measurement boundary
Before comparing values, ask where the power measurement came from. A figure reported by firmware, a meter at the device supply, and a meter for an entire rack do not necessarily describe the same boundary. Rack power may include networking, circulation pumps, or other equipment. Device estimates may omit components outside their own measurement scope.
Write the boundary next to every result. Use labels such as device input power, rack input power, and site total power. Do not compare a narrow boundary for one option with a broad boundary for another and call the difference an improvement. For a purchasing conversation, request both the specification's testing conditions and a description of what its published power figure includes.
Align the observation windows
Pair energy and work from the same time interval. A recent power sample divided by yesterday's average hashrate creates a number, but not a meaningful controlled comparison. Likewise, a short burst immediately after startup may not represent an operating profile once it has settled. Choose the window before you inspect the outcome.
For an illustrative test, compare two profiles over equal observation periods with similar ambient conditions and no intentional changes to other settings. Record missing readings instead of interpolating them silently. If a significant outage occurs during one run, describe it and decide whether the test must be repeated. The fleet monitoring page demonstrates why data freshness belongs beside each operational metric.
Use weighted fleet arithmetic
Fleet efficiency is not generally the simple average of individual efficiency ratios. Consider two hypothetical machines: one produces 100 TH/s at 2,000 W, and the other produces 200 TH/s at 5,000 W. Their individual values are 20 and 25 J/TH. Averaging those ratios gives 22.5, but the fleet calculation is 7,000 divided by 300, or approximately 23.33 J/TH.
The larger machine contributes more hashing work, so it must contribute more weight to the combined ratio. Sum compatible power measurements and compatible hashrates first, then divide. Apply the same discipline to grouping by room, firmware profile, or hardware family. Never combine hashrates from different algorithms into one total merely because the display units happen to match.
Handle stopped and missing machines carefully
When hashrate is zero, power divided by hashrate is undefined. Do not display a reassuring zero J/TH or an arbitrary maximum value. Use an explicit unavailable state with an explanation. A powered but non-hashing device is still operationally important, even though its individual efficiency ratio is not a finite useful number.
Missing telemetry is a different condition from an observed zero. Keep them distinct in storage and presentation. For a fleet energy calculation, actual power consumed by stopped equipment still matters if it lies within the defined boundary. For a machine-level ratio, display the missing or stopped status. A chart that silently excludes every troubled worker may make the remaining fleet look more efficient while concealing real energy use.
Translate efficiency into a scenario
Suppose a hypothetical operation needs 600 TH/s and can achieve it at either 20 or 18 J/TH. Those assumptions imply device power of 12,000 W or 10,800 W. The difference is 1.2 kW. Over an assumed 24-hour day, that is 28.8 kWh. At an illustrative flat energy rate of $0.10 per kWh, the device-energy difference would be $2.88 per day.
This calculation intentionally holds hashrate constant. It does not establish that an actual machine can deliver either profile, nor does it include equipment prices, downtime, cooling, taxes, or a complete tariff. Use the electricity cost framework to expand the boundary. Keep every assumption visible so another reader can change one input without misunderstanding the result.
Design a reversible operating experiment
Start from a documented baseline and a manufacturer-supported configuration. Define a narrow question, such as whether a supported lower-power profile improves measured device efficiency under your conditions. Decide in advance which observations would stop the test: instability, missing measurements, unacceptable temperature behavior, or another condition specified by the responsible operator.
Change one supported parameter set at a time, preserve the previous configuration, and assign a person who can restore it. Observe accepted work as well as reported hashrate. Avoid treating this as permission to exceed hardware limits or bypass protective controls. Our ASIC hardware overview emphasizes inventory, measurement, and maintainable operating profiles rather than unverified tuning recipes.
Keep measurement uncertainty visible
A result displayed to four decimal places can look more reliable than the instruments and sampling process justify. Record meter resolution, sampling interval, and the extent of missing data. Where uncertainty is not quantified, say that the comparison is observational rather than presenting it as a laboratory benchmark. Rounding should reflect the evidence, not the available space in a dashboard.
Repeat a promising test before adopting it broadly. A profile that looks better during one cool morning may not behave the same way during a hotter period or a different workload pattern. Keep a record of both successful and unsuccessful runs. Selective reporting makes optimization harder because the next operator cannot see the conditions under which a result failed to repeat.
Separate operational and purchasing decisions
Choosing a setting for hardware you already own is different from choosing new equipment. An operating decision may focus on a supported profile's measured behavior. A purchasing decision must also consider acquisition cost, installation compatibility, support terms, repairability, and whether the machine fits your available power and cooling infrastructure.
Do not turn a lower J/TH value into a universal buying recommendation. A specification can be technically attractive while the proposed installation is inappropriate. Prepare a comparison sheet with a column for unknowns and a separate column for evidence. Ask suppliers to identify the exact variant and conditions behind their figures. Without that information, close-looking efficiency numbers may not be comparable at all.
Make efficiency a traceable result
A useful efficiency record contains a device or fleet identifier, algorithm, time interval, power boundary, hashing-work measure, configuration, environmental context, and any exclusions. Store the inputs alongside the ratio. When a number changes unexpectedly, you should be able to reconstruct the calculation rather than guessing which dashboard transformation produced it.
J/TH is powerful precisely because the underlying mathematics is simple. The difficult part is choosing compatible observations and interpreting the tradeoffs. Start with matched measurements, calculate totals correctly, and preserve the context. That turns an attractive specification into a result another operator can understand, challenge, and reproduce.
