Mining Latency bezeichnet die Verzögerung in einem bestimmten Abschnitt des Mining-Betriebs, etwa zwischen dem Versand eines Auftrags durch den Pool und seiner Aktivierung in der Maschine. Sie ist keine universelle Eigenschaft der Verbindung. Übertragung, Warteschlangen, Verarbeitung und Bestätigung sind verschiedene Abschnitte mit unterschiedlichen Messverfahren.
Der Pool bereitet einen Auftrag für Petr vor und sendet ihn an die Mining-Software. Diese kann die Nachricht über einen Vermittler, einen Proxy, bis zum ASIC weitergeben, einem für das Mining entwickelten Chip. Entscheidend ist der tatsächliche Wechsel zum neuen Auftrag, nicht nur der Eingang einer Nachricht am Computer. Danach liefert die Maschine Shares, Teilergebnisse als Nachweis ihrer Arbeit für den Pool. Im Kommunikationsprotokoll Stratum V2 für Mining-Geräte ordnen channel_id und job_id Nachrichten dem richtigen Kanal und Auftrag zu. Ohne diese Zuordnung könnten wir den Anfang eines Auftrags mit dem Ende eines anderen messen. [1]
Petr verwendet ping nach der Diagnoseanleitung von Braiins. Damit prüft er, ob der Server antwortet und wie lange Anfrage und Antwort für Hin- und Rückweg benötigen: RTT, die round-trip time. Das ist ein nützlicher erster Schritt. Beide Richtungen können aber andere Wege und Warteschlangen haben; durch zwei zu teilen misst deshalb keine einseitige Verzögerung. Ping zeigt auch nicht, wie lange der Pool einen Auftrag vorbereitet oder der ASIC für dessen Start braucht. Ein guter Wert kann daher mit einem langsamen Auftragswechsel zusammenfallen. [2] [3]
In unserem Beispiel notiert der Sender Tsend = 1000 ms und der Empfänger Trecv = 1040 ms. Die Differenz beträgt 40 ms, doch die Empfängeruhr könnte um 30 ms vorgehen. Einfaches Subtrahieren ergibt dann nicht die tatsächliche Übertragungsdauer. ms steht für Millisekunden, also Tausendstelsekunden. Der Standard für Netzwerkmessungen RFC7679 berücksichtigt deshalb die Unsicherheit der Uhrensynchronisation und den Ort der Zeitstempel. Ohne diese Angaben belegt ein Unterschied zwischen Servern keinen Geschwindigkeitsgewinn; möglicherweise sind nur ihre Uhren anders eingestellt. [3]
Damit nach einem neuen Block nicht der vollständige Auftrag abgewartet werden muss, erlaubt Stratum V2 einen vorab gesendeten Future Job. Dieser ist für eine künftige Anknüpfung an die Kette vorbereitet, aber noch keine Aufforderung zum sofortigen Start. SetNewPrevHash aktiviert ihn mit dem richtigen Verweis auf den Vorgängerblock und der passenden job_id. Enthält der vorbereitete Auftrag Transaktionen, kann der neue Block einige davon für die erneute Verwendung unbrauchbar machen, etwa weil er sie bereits enthält. Der Wunsch nach weniger Latenz rechtfertigt nicht, diesen Konflikt zu ignorieren. Falsche Arbeit schnell zu beginnen spart nichts Sinnvolles. [1]
Petr sieht, dass eine Share versendet wurde, aber die Bestätigung kommt später. In Stratum V2 kann SubmitShares.Success mehrere angenommene Shares zusammenfassen; bewusstes Bündeln reduziert die Nachrichtenmenge. Die gesamte Wartezeit lässt sich daher weder der Übertragung zuschreiben noch als Beweis werten, dass der Pool das Ergebnis so lange nicht kannte. Auch SubmitShares.Error kann erst nach einer späteren Prüfung folgen. sequence_number hilft, Antworten den eingesendeten Ergebnissen zuzuordnen. Bei der Fehlersuche unterscheiden wir Empfang, Prüfung und Mitteilung. [1]
Mining ist auch darauf angewiesen, rasch von einem veröffentlichten Block zu erfahren. Das ist ein anderer Abschnitt als die Verbindung zwischen Maschine und Pool. BIP152 verringert die zwischen Knoten übertragene Datenmenge: Im Modus high-bandwidth kann ein Knoten direkt cmpctblock senden, eine kompakte Blockbeschreibung. Die meisten Transaktionen ergänzt der Empfänger aus eigenen Daten. Fehlende fordert er mit getblocktxn an und erhält sie in blocktxn, was einen weiteren Austausch nötig machen kann. Weniger Bytes bedeuten also nicht keine Wartezeit und ersetzen keine vollständige Validierung aller Blockregeln. [4]
Petr interessiert sich für den Normalbetrieb und für Momente, in denen etwas hängen bleibt. p50/p95 sind Perzentile: Sie beschreiben verschiedene Bereiche der Verteilung gemessener Zeiten statt nur einen Durchschnitt. Ordnet man die Zeiten von kurz nach lang, liegt p50 ungefähr in der Mitte und p95 nahe dem langsameren Ende: Rund 50 % der Werte liegen unter der ersten Grenze und 95 % unter der zweiten. So lassen sich typische Wartezeiten von langen Verzögerungen unterscheiden. Dabei muss klar sein, wie nicht zugestellte Nachrichten behandelt wurden. RFC7679 verwendet die Wartegrenze Tmax; eine Überschreitung ist keine gewöhnliche schnelle Messung. Bei der dortigen Perzentilberechnung werden undefinierte Verzögerungen als unendlich eingeordnet. Sie stillschweigend wegzulassen verbessert nur das Papierergebnis. Auch eine leere Stichprobe bedeutet keine Latenz von null, sondern fehlende Entscheidungsgrundlage. [3]
Petr vergleicht dieselben Abschnitte bei ähnlicher Last und über gleich lange Zeiträume. Zu jeder Messung in ms notiert er den Ort des Zeitstempels, die Unsicherheit der Uhren und die zugehörige job_id; ping und RTT erfasst er getrennt. Ausfälle und abgelehnte Ergebnisse gehören dazu, damit ein schneller Durchschnitt keine Unzuverlässigkeit verdeckt. So kann er untersuchen, ob ein anderer Server, ein anderes Netz oder eine Maschineneinstellung hilft. Ziel ist weniger Zeit für veraltete Arbeit, kein Versprechen auf einen Blockfund. Niedrige Latenz ändert weder den Zufall beim Mining noch die Gültigkeitsregeln. [1] [2] [3]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Stale Rate, Block Propagation, Stratum V2, Mining Pool, Bitcoin. Auf diesen Eintrag verweisen außerdem Stratum V2, Stale Rate.