// blog · · by Nathan Baldwin
// Hashrate looks great until 2 percent of shares get rejected. Why HW error rate matters more than raw TH/s on your Bitaxe — with real CSV examples.
Two Bitaxe Gammas, both reporting 1.45 TH/s on the dashboard, both pulling 19W from the wall. One earns ~8% more BTC per month than the other. The difference is hardware error rate — one is at 0.3%, the other is at 2.1%. The dashboard doesn’t tell you that. The pool does.
If you tune by looking at the hashrate number on AxeOS, you’ll convince yourself you’re winning while quietly throwing away shares.
When a Bitaxe finds a nonce that meets its assigned difficulty, it computes the SHA256 hash twice and submits the result. A “hardware error” happens when that double-SHA, redone on the host side or the pool side, doesn’t match what the chip claimed. The nonce is invalid. The share is rejected.
The chip “found” something. It just found something wrong.
The cause is almost always voltage/frequency margin. The ASIC is running at the edge of stability, a bit flip happens somewhere in the pipeline, and the chip outputs a result that doesn’t survive verification. Higher temperature makes it worse. Higher frequency makes it worse. Lower voltage makes it worse.
AxeOS counts these as “HW Errors” and shows the rate as a percentage on the dashboard. A healthy Gamma sits well under 0.5%. Anything above 1% means your stability margin is gone.
AxeOS reports the chip’s claimed hashrate, computed from how often it submits results that meet the assigned difficulty. It doesn’t know which of those results are valid until the pool tells it. So a chip cranking out nonces at 1.5 TH/s but failing verification 5% of the time still shows 1.5 TH/s on the OLED — even though only 1.425 TH/s of that is actually earning shares at the pool.
The pool’s number is the truth. Most pool dashboards show “valid shares per hour” or an estimated hashrate based on share submission rate over an hour. Compare that to AxeOS over the same hour. The delta is your real error rate, including network drops, stale submissions, and HW errors.
For a 1.2 TH/s Gamma on Public-Pool, you should see roughly 60-70 valid shares per hour at the default difficulty. If your AxeOS shows 1.45 TH/s and the pool shows 50 shares per hour, you’re producing 30% junk somewhere. Most of that is HW errors.
Pull a 24-hour CSV from Bitaxe Baller (or scrape /api/system/info yourself every minute and dump to a file). Filter to the rows where the device was at steady state. You’re looking at five columns: timestamp, hashrate, ASIC temp, HW errors, and accepted shares.
A clean Gamma at Tier 2 (550 MHz / 1180 mV) over 24 hours:
total accepted shares: 1,612
total HW errors: 3
HW error rate: 0.19%
estimated revenue: $0.21
The same Gamma, pushed to Tier 4 (625 MHz / 1250 mV) for 24 hours:
total accepted shares: 1,824
total HW errors: 42
HW error rate: 2.30%
estimated revenue: $0.24
The Tier 4 device produced 13% more accepted shares than Tier 2 — but consumed 25% more power and ran the VR 18°C hotter. The aggressive tune is paying for itself in raw share count, barely, but only by burning the regulator faster. Run the J/TH math at your power cost and the picture often inverts.
A bad tune — same board, 600 MHz at 1190 mV, voltage just a touch under what the silicon needs:
total accepted shares: 1,503
total HW errors: 204
HW error rate: 11.95%
estimated revenue: $0.19
Lower hashrate than stock, twelve times the errors, lower revenue, higher power. This is what happens when you push frequency without giving the chip the voltage it needs. The dashboard might show 1.4 TH/s — the pool sees a device that’s hashing worse than stock.
The AxeOS dashboard updates the HW error counter every poll. The OLED shows it on the “Best Difficulty” screen as a percentage. What you want to watch is the trend over 10-15 minutes, not the instantaneous number.
A clean device looks like this on a chart:
A device on the edge looks like this:
A device past the edge looks like this:
The cluster pattern is the giveaway. Stable random noise doesn’t cluster. Clusters mean the chip hit a thermal or voltage condition that triggered a burst of bad submissions.
Set your HW error rate target at 0.5% and tune everything else to hold it. If you’re at 0.3% you have headroom to bump frequency. If you’re at 0.8% you should bump voltage 10 mV. If you’re at 1.5% you’re past the practical ceiling for your specific silicon at your current cooling.
This is the metric that matters because it’s the one the pool cares about. Hashrate gets you optimism. Error rate gets you BTC.
Find your HW error rate column in AxeOS right now. Write down the percentage. If you don’t have a CSV history, start one — every Bitaxe Baller install dumps a per-device CSV automatically. Look at the next 24 hours and you’ll see whether your current tune is actually in the sweet spot or just looks like it is.
If the rate is above 1%, drop frequency by 25 MHz. If it’s below 0.2% and your VR is under 65°C, you’ve got room to push frequency 25 MHz up. Iterate weekly. Watch the pool side, not the chip side.
Try it yourself: Bitaxe Baller is a free Mac app that surfaces these recommendations automatically across your fleet — live monitoring, tuning suggestions, pool config, all in a native window. Open source on GitHub.