Hashrate Error beim Bitaxe: was der Wert in AxeOS bedeutet und was hilft

In der Hashrate-Karte von AxeOS steht neben der Hashrate ein kleiner Wert namens Error. Er sorgt für viele Support-Anfragen, weil ältere Anleitungen ihn falsch erklären: als Abstand zwischen gemessener und erwarteter Hashrate. Das stimmt seit AxeOS 2.11 nicht mehr. Der Error kommt direkt aus dem Chip und zählt fehlerhafte Hashes. Dieser Artikel erklärt, was der Wert bedeutet, welche Höhe normal ist, wie du ihn von der zweiten wichtigen Kennzahl, dem Abstand zu „Expected“, unterscheidest, und was du bei den vier typischen Ursachen tust.

Was der Error in AxeOS misst

Seit AxeOS 2.11 liest die Firmware die Hashrate nicht mehr aus den Shares, sondern jede Sekunde aus Zählregistern im Chip. Der Chip zählt dabei zweierlei: alle berechneten Hashes und die Hashes, bei denen er einen Fehler festgestellt hat. Error ist der zweite Wert geteilt durch den ersten, in Prozent. Fährst du mit der Maus über das Fragezeichen neben dem Wert, erklärt AxeOS das selbst:

Übersetzt: Ein paar Fehler alle paar Sekunden sind normal. Frequenzwechsel, aggressives Übertakten, Unterspannung oder ein schlechtes Netzteil können die Fehlerrate deutlich erhöhen. Mit dem Pool, dem WLAN oder abgelehnten Shares hat der Wert nichts zu tun; ein Entwickler der Firmware sagt es knapp: Die Fehlerrate ist völlig unabhängig davon, was die Pool-Verbindung tut (Diskussion).

Die zweite Kennzahl: Hashrate gegen Expected

Neben dem Error steht Expected, die Hashrate, die bei deinem Takt zu erwarten ist. AxeOS rechnet sie aus Takt mal Rechenkernen mal Chips. Der BM1370 im Gamma hat 2.040 Kerne, bei 525 MHz ergibt das 1.071 GH/s, also 1,07 TH/s. Darunter stehen die Mittelwerte der gemessenen Hashrate über eine Minute, zehn Minuten und eine Stunde.

Die beiden Kennzahlen ergänzen sich: Der Error zeigt, ob der Chip sauber rechnet, der Vergleich des Stundenmittels mit Expected zeigt, ob er so viel rechnet, wie er soll. Liegt das Stundenmittel bei mindestens 95 % von Expected, ist die Einstellung stabil. Das ist dieselbe Schwelle, mit der die gängigen Benchmark-Tools arbeiten. Liegt die Hashrate etwas über Expected, ist das kein Fehler; der gemessene Wert streut um den errechneten.

Kurze Spitzen beim Error sind normal, vor allem direkt nach einem Neustart oder einer Änderung von Takt oder Spannung. Beurteile ihn wie die Hashrate über eine Stunde. Im Diagramm kannst du dafür unter „Percentage (%)“ den Verlauf des Errors einblenden. Bei Geräten mit mehreren Chips zählt der Wert über alle Chips zusammen.

Welcher Error ist normal?

Jeder Chip ist etwas anders, und ein kleiner Fehleranteil lässt sich manchmal nicht vermeiden. Die Entwickler der Firmware nennen Werte unter 0,1 % gut und Spitzen erwartbar. Händler-Anleitungen ziehen die Grenze großzügiger und halten bis zu 2 % für gesund. Für die Praxis hat sich bewährt:

• Unter 0,1 %: sehr gut, nichts zu tun.
• 0,1 bis unter 1 %: unauffällig, solange die Hashrate im Stundenmittel bei mindestens 95 % von Expected liegt.
• 1 % und mehr, dauerhaft: Die Einstellung ist nicht mehr sauber. Meist reicht die Spannung für den Takt nicht, oder Hitze oder Netzteil sind im Spiel.
• Steigt der Wert über Tage: Etwas hat sich verändert, zum Beispiel ein verstopfter Kühler, ein wärmerer Raum oder ein alterndes Netzteil.

Wichtiger als die zweite Nachkommastelle ist der Vergleich mit dem eigenen Normalzustand. Notiere dir nach der Einrichtung den Error und das Stundenmittel deines Geräts bei Werkseinstellung; dann erkennst du später sofort, wenn sich etwas verändert.

Die vier Ursachen in Prüfreihenfolge

1. Spannung zu niedrig für den Takt

Die häufigste Ursache, fast immer nach dem Übertakten oder Undervolten. Jeder Chip braucht für einen bestimmten Takt eine Mindestspannung; darunter steigt der Error und die Hashrate fällt unter Expected. Ab Werk läuft ein Gamma mit 525 MHz bei 1150 mV und hat Reserve. Abhilfe: Core Voltage in Settings um 10 bis 20 mV anheben oder den Takt um einen Schritt zurücknehmen. Wie du die passende Kombination findest, steht im Overclocking-Guide.

2. Hitze

Ein heißer Chip rechnet unsauberer. Für den Dauerbetrieb sind am Chip bis 65 °C und am Spannungsregler bis 85 °C gut. Ab 70 °C warnt das Dashboard. Über 75 °C am Chip oder über 105 °C am Regler greift der Überhitzungsschutz: AxeOS stoppt das Mining, stellt den Lüfter auf 100 % und rechnet danach mit 100 MHz weniger Takt und 100 mV weniger Spannung weiter. Das Dashboard zeigt dann „Device has overheated - See settings“, das Display „DEVICE OVERHEAT!“. Ursachen sind meist Aufstellort, Staub, ein Lüfter ohne Automatik oder zu viel Takt. Tipps zur Kühlung stehen in Bitaxe leiser machen.

3. Netzteil am Limit

Bricht die Eingangsspannung unter Last ein, kann der Spannungsregler die Kernspannung nicht mehr sauber halten. Im Dashboard siehst du das an der Karte Power: „Input Voltage“ deutlich unter dem Nennwert, ab 95 % darunter mit der Warnung „Danger: Low Voltage“ (beim Gamma unter 4,75 V, bei 12-V-Geräten unter 11,4 V), und eine „Measured ASIC Voltage“, die deutlich unter der eingestellten liegt. Fällt die Spannung weiter, schaltet der Regler ab und AxeOS meldet „Power Fault Detected. Check your Power Supply.“ Mehr in Netzteil für Bitaxe.

4. Frequenzwechsel und frisch gestartete Geräte

Direkt nach einem Neustart oder einer Änderung von Takt oder Spannung zeigt der Error oft kurz höhere Werte, während die Frequenz in kleinen Stufen hochfährt. Das ist kein Problem. Warte eine Stunde und urteile dann.

Nicht auf dieser Liste steht das WLAN. Aussetzer im Netz erhöhen den Error nicht; sie führen zu abgelehnten oder veralteten Shares und Lücken beim Pool. Dafür ist Bitaxe mined nicht trotz WLAN die richtige Anlaufstelle.

Die Hashrate Registers: jeder Rechenbereich einzeln

Weiter unten auf dem Dashboard zeigt die Karte Hashrate Registers die Hashrate je Rechenbereich (Domain) des Chips, beim BM1370 sind es vier, bei Geräten mit mehreren Chips je Chip. Fährst du über einen Chip, zeigt der Tooltip dessen Fehlerzähler („Error count“). Die Werte der Domains schwanken leicht gegeneinander. Liefert eine Domain über längere Zeit deutlich weniger als die anderen, rechnet dieser Teil des Chips nicht voll; dann helfen die Schritte oben, und bleibt es dabei, ist es ein Fall für unseren Support.

Hashrate 0 GH/s: was dahintersteckt

Steht die Hashrate auf null, rechnet der Chip gar nicht. Das hat andere Gründe als ein hoher Error:

Die Seite Logs in AxeOS zeigt in Echtzeit, was passiert. Typische Zeilen sind „WiFi disconnected, attempting to reconnect...“ bei WLAN-Problemen und „Failed to receive JSON-RPC line, reconnecting...“, wenn die Verbindung zum Pool abreißt. Die Datei kannst du dort herunterladen und unserem Support schicken.

So prüfst du in fünf Minuten

1. Dashboard öffnen und das Stundenmittel („1h“) mit „Expected“ vergleichen. Mindestens 95 %: gut.
2. Error ansehen: dauerhaft unter 1 %, besser unter 0,1 %: gut. Spitzen direkt nach Änderungen ignorieren.
3. Karte Heat: Chip bis 65 °C, Regler bis 85 °C. Steht „Device has overheated“ im Dashboard, war es der Überhitzungsschutz.
4. Karte Power: Input Voltage nahe dem Nennwert, keine Warnung „Danger: Low Voltage“.
5. Übertaktet? Takt und Spannung in Settings auf die Werte mit „(Default)“ zurückstellen und eine Stunde beobachten.

Warum ein sauberer Takt mehr bringt als ein hoher

Mehr Takt mit zu knapper Spannung sieht in „Expected“ gut aus, bringt aber weniger. Ein Beispiel aus einer Messreihe mit einem NerdQaxe++: Bei 740 MHz und zu niedrigen 1150 mV lieferte das Gerät nur 66 % seiner erwarteten Hashrate und verbrauchte mehr Energie je Terahash als ab Werk. Mit etwas mehr Spannung oder etwas weniger Takt liefert dieselbe Hardware mehr echte Hashes. Deshalb gilt beim Tunen: Erst wenn Error und Stundenmittel stimmen, zählt die Zahl bei Expected. Wie viel das für deine Chance auf einen Block bedeutet, zeigt Bitaxe Block finden.

Häufige Fragen zum Hashrate Error