The Bitaxe hash rate error explained: what the error value in AxeOS really means

In the AxeOS dashboard there are two numbers under the hash rate: the hash rate your Bitaxe is delivering right now, and underneath in green the expected one. The hash rate error is the gap between the two in percent. It is the most sensitive value in the whole dashboard – it shows problems before shares get rejected or the miner restarts. This article explains where the two numbers come from, which deviation is normal, and what to do at which value.

Where the two numbers come from

The expected hash rate is pure arithmetic: clock × number of compute cores in the ASIC. A BM1370 in a Bitaxe Gamma delivers around 1.2 TH/s at 525 MHz arithmetically, around 1.6 TH/s at 775 MHz. This number only changes when you change the frequency.

The delivered hash rate is not measured directly by AxeOS – it is extrapolated from the shares the ASIC found in the last few minutes. Shares are random hits; that is why the value in the chart swings by ±30 %, and why the hash rate error is worthless over one minute and meaningful over one hour.

If the delivered hash rate sits below the expected one for hours, the ASIC did not finish part of its work: computations that produced invalid results because of too little voltage or too much heat never show up as shares. If it sits above, you got lucky with shares – that is not an error.

Which deviation is normal

Important: the hash rate error is not the same as rejected shares. Rejected shares were valid work that reached the pool too late (stale block) – a network or latency matter. The hash rate error originates in the chip. A miner can have 0 % rejects and a 15 % hash rate error, or the other way round.

The four causes – in checking order

1. Voltage too low for the clock

The most common cause, almost always after an overclock. Every ASIC needs a minimum voltage for a given clock; below it, individual computations tip over. At factory a Gamma runs 525 MHz at 1,150 mV with headroom. 575 MHz runs at 1,200 mV, 625 MHz needs 1,250 mV – the steps from our overclocking guide. If the error rises after a clock change, raise the voltage by 20 mV or drop the clock by 25 MHz.

2. Heat

A hot ASIC computes less cleanly. In the dashboard: ASIC temperature above 65 °C, voltage regulator above 85 °C. Causes are placement (closed shelf, sunlight), a dusty heatsink, dried-out thermal paste or a fan not set to auto. From 70 °C the overheat protection kicks in and throttles the miner to a minimum – then the error shows 90 % and more. Remedies are in Making a Bitaxe quieter and cooler.

3. Power supply at its limit

If the input voltage sags under load, the voltage regulator does not get enough to hold the ASIC voltage. In the dashboard: input voltage below 4.8 V on 5 V devices, or a measured ASIC voltage more than 20 mV below the set one. The supplied power adapter is enough for factory settings; anyone overclocking or using a thin USB-C cable ends up here. Which power supply is enough when is covered in the power supply guide.

4. Wi-Fi dropouts

The rarest cause but a sneaky one: if the miner loses the connection for seconds, it keeps hashing on a stale work template, and those shares do not count. The error rises without temperature or voltage being unusual; at the same time rejects rise and the pool’s uptime display shows gaps. Fix: 2.4 GHz network without band steering, router closer, no repeater in between.

How to check in five minutes

1. Let the dashboard run for an hour, then compare the average (dashed line) with “expected”. Less than 10 % apart: done.
2. Look at frequency and voltage: if the frequency reads 50 MHz or the dashboard reports “Overheat”, it was the overheat protection → cause 2. If you overclocked → cause 1.
3. Read the input voltage under load: below 4.8 V → cause 3.
4. Read the temperatures: ASIC above 65 °C or VR above 85 °C → cause 2.
5. Open the logs: entries like “Stratum disconnected” or “reconnecting” → cause 4.
6. Change one thing only, wait an hour, compare again.

Why a stable 5 % is worth more than 0 % on a screenshot

An overclocked setting with 1.8 TH/s expected and a 15 % error really delivers 1.53 TH/s – at 30 W. The same hardware with 1.6 TH/s expected and a 3 % error delivers 1.55 TH/s at 24 W. The second setting mines more, uses less power and keeps the chip cooler. The hash rate error is the value that makes this difference visible; the hash rate tile alone hides it.