Stale Rate ist der Anteil von Ereignissen oder gewichteter Arbeit, die in einer genau abgegrenzten Menge als stale eingestuft werden. Hier geht es vor allem um Pool-Shares, die in einem veralteten Mining-Job-Kontext eintreffen oder verarbeitet werden.
Bei SetNewPrevHash verlangt Stratum V2 den Wechsel zum neuen Vorgängerhash; unter vorbereiteten Jobs bleibt nur die referenzierte job_id gültig. Ein Hash unter dem früheren Ziel garantiert daher noch keine Verwendbarkeit für aktuelle Arbeit. Zur Diagnose gehören Job-Kontext und Änderungen, nicht nur die Sendezeit. [Stratum V2 — Mining Protocol]
Beispiel: Von 100 Einsendungen gleicher Schwierigkeit werden 98 akzeptiert, 1 als stale und 1 aus anderem Grund abgelehnt. Abgelehnte stale ergeben 1%, alle Ablehnungen zusammen 2%. Das erklärt unterschiedliche Zähler, keine akzeptablen Betriebsgrenzen. F2Pool bezieht rejection rate auf sämtliche eingereichten Shares. [F2Pool — Rejection and Staled rates]
Braiins rechnet eine Share mit Schwierigkeit d in d Basiseinheiten Arbeit um. Enthält ein Beispiel eine stale Share mit Schwierigkeit 1 und eine akzeptierte mit Schwierigkeit 9, beträgt der Anteil nach Anzahl 50%, gewichtet aber 10%. Verglichene Zähler und Nenner müssen dieselbe Einheit und Schwierigkeitskonvention verwenden. [Braiins — Share difficulty accounting]
F2Pool unterscheidet dokumentierte vergütete “Staled”-Shares von abgelehnten stale Shares ohne Vergütung. Diese Regel gilt nicht automatisch für jeden Pool. Prüfe vor der Umrechnung eines Prozentsatzes in entgangene Einnahmen die konkrete Kategorie, Annahmeregeln und Abrechnung; der Kennzahlname genügt nicht. [F2Pool — Rejection and Staled rates]
Stratum V2 erlaubt gebündelte SubmitShares.Success. new_submits_accepted_count nennt die neu bestätigten Einsendungen, new_shares_sum deren Schwierigkeitssumme. Die Anzahl der Serverantworten entspricht also nicht der akzeptierten Shares. SubmitShares.Error enthält sequence_number und error_code; ohne Unterscheidung der Gründe darf nicht jeder Fehler stale heißen. [Stratum V2 — Mining Protocol]
BIP152 behandelt Compact Block Relay zwischen P2P-Knoten, nicht die Share-Abrechnung des Pools. Weniger übertragene Daten können die Blocklatenz beeinflussen, liefern allein aber keine Stale Rate eines Miners. Der Anteil konkurrierender Netzwerkblöcke ist kein Ersatz für den Anteil verspäteter Einsendungen eines bestimmten Workers. [BIP152 — Compact Block Relay]
Braiins-Monitoring unterscheidet shares_5m, shares_60m und shares_24h. Verwende für Zähler und Nenner dasselbe Zeitfenster und dieselbe Worker-Menge. Null beobachtete Einsendungen bedeuten keinen gemessenen Verlust von 0%; der Quotient ist undefiniert. Fehlende Antworten oder Monitoring-Lücken gehören nicht automatisch zu stale. [Braiins — Worker monitoring windows]
F2Pool verbindet stale mit Netzbedingungen, nennt für andere Ablehnungen aber Firmwarefehler und Übertaktung. Braiins trennt Erreichbarkeitstests des Servers von tatsächlicher Leistung. Prüfe Job-Logs, Ablehnungsgründe und Verbindungen desselben Zeitraums; Ping oder ein niedrigerer Gesamtanteil allein belegen keine beseitigte Ursache. [F2Pool — Rejection and Staled rates] [Braiins — Connection diagnostics]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Mining Share, Share Difficulty, Mining Latency, Pool Fee. Auf diesen Eintrag verweisen außerdem Mining Latency, Mining-Verfügbarkeit.