Wie wir testen, vollständig

Der Prüfstand

Gleiche Maschine, gleiche Leitung, gleicher Inhalt

Jeder Client in einem Vergleich läuft auf einer Maschine, gegen dieselben Provider, auf demselben Inhalt, innerhalb derselben Runde. Nichts wird von einem früheren Tag übernommen.

Die Maschinen. Ein Apple M1 Ultra an einer 10-GbE-Leitung in Europa und ein M3 Ultra an einer langsameren Leitung in den Vereinigten Staaten. Vergleiche mischen die beiden nie: eine Tabelle ist eine Maschine.
Die Leitung zählt mehr als der Prozessor. An einer 10-GbE-Leitung können die meisten Clients bei einem leichten Auftrag die Verbindung auslasten, weshalb die interessanten Szenarien die sind, in denen etwas anderes als rohe Bandbreite den Ausgang entscheidet.
Provider. Fünf kommerzielle Provider, für jeden Client dieselbe Auswahl, über TLS. Einen Provider schließen wir aus diesen Runden aus, weil er beschränkt, wie viele Standorte gleichzeitig verbinden dürfen, was eine geteilte Testmaschine für den Zweitlaufenden unfair machen würde.
Verbindungen. Jeder Client bekommt in einer Runde dieselbe Zahl pro Provider, und die Runde nennt welche. Mehr ist nicht automatisch besser; wir haben unseren eigenen Client gemessen, wie er über eine neunfache Änderung der Verbindungszahl dieselbe Endzeit hält.

Die Regel, die alles entscheidet

Ein Client wird an der Datei gemessen, nicht an seiner eigenen Statusmeldung

Das ist das Wichtigste auf dieser Seite. Jeder Durchgang endet damit, die größte vom Client erzeugte Datei irgendwo in seiner Ausgabe zu suchen und sie gegen eine bekannt gute Kopie zu hashen. Größe und MD5, bei jedem Durchgang, nicht stichprobenartig.

Wir tun das, weil der Erfolgsbericht eines Clients kein verlässlicher Beleg ist. Wir haben einen Client gemessen, der done meldete bei einem Auftrag, dessen Ausgabeverzeichnis leer war. Wir haben einen anderen gemessen, der Completed meldete, nachdem er rohe Archivbände geliefert hatte, die er nie entpackt hatte. Ein weit verbreitetes Reparaturwerkzeug beendet sich nach erfolgreicher Reparatur mit einem Fehlercode. Keiner dieser Clients hat gelogen; Statustexte bedeuten bei verschiedenen Autoren schlicht Verschiedenes, und ein Benchmark, der ihnen vertraut, misst Wortwahl statt Verhalten.

Die Ziellinie ist also für alle dieselbe: die Nutzdaten liegen vor, in der richtigen Größe, mit dem richtigen Hash. Hält ein Client vorher an, bekommt er keine Zeit, und die ganze Spalte wird gekennzeichnet statt stillschweigend weggelassen. Ein langsamer Client, der fertig wird, ist besser als ein schneller, der es nicht wird, und die Tabelle soll das sagen.

Die Folge daraus: ein Nichtankommen ist ein Ergebnis, kein Fehler unsererseits. Wenn wir eines veröffentlichen, beschreiben wir den Endzustand mit einfachen Worten, einschließlich allem, was darauf hindeutet, dass es für diesen Auftrag spezifisch statt allgemein ist, und wir sagen, was der Client stattdessen getan hat.

Reihenfolge und Wiederholung

Warum Durchgänge abwechseln, und warum Einzelläufe nicht veröffentlicht werden

Der Durchsatz der Provider schwankt von Minute zu Minute, manchmal um den Faktor zwei oder drei. Zwei Messungen zu verschiedenen Zeiten messen zum Teil das Wetter.

Clients laufen deshalb unmittelbar nacheinander und verschränkt, und die Reihenfolge kehrt sich zwischen den Wiederholungen um, damit kein Client immer derjenige ist, der als Erster auf eine warme oder kalte Leitung geht. Ein Ergebnis ist das Muster über die Wiederholungen hinweg, nicht der beste Lauf. Ist die Streuung groß, veröffentlichen wir den Bereich statt eines Mittelwerts, der sie verbergen würde, und wenn wir nicht wissen, warum die Zahlen eines Clients streuen, sagen wir das, statt eine Ursache zu erfinden.

Vergleiche über verschiedene Runden hinweg vermeiden wir, wo immer es geht. Braucht eine Aussage zwei Zahlen, lassen wir lieber beide in einer Runde neu antreten, als die Zahl des einen Tages von der des anderen abzuziehen, denn Prüfstandszustand, Providerbedingungen und Clientversionen driften allesamt. Wenn wir zwei eigene Builds vergleichen, laufen beide in derselben Runde, abwechselnd, auf demselben Inhalt.

Die unglamourösen Prüfungen

Was vor und während jedem Durchgang läuft

Die meisten gibt es, weil ein stiller Fehler einmal eine gesund aussehende, veröffentlichungsreife, falsche Zahl erzeugt hat. Jede läuft nun automatisch und stoppt die Runde, statt zu warnen.

Jeder Provider antwortet, bevor der Durchgang startet. Ein Durchgang, der läuft, während zwei Provider ausgefallen sind, misst einen Ausfall, und das sieht genau aus wie ein langsamer Client.
Die Binärdatei wird vor jedem Durchgang per Hash identifiziert, nicht per Dateiname oder Versionstext. Zwei unserer Builds meldeten dieselbe Versionsnummer und unterschieden sich doch um 88 Commits; nur der Hash trennt sie, und die Tabellen führen ihn an.
Jeder Client läuft als nativer Code. Auf Apple-Maschinen kann ein falsch gebautes Hilfsprogramm still unter Übersetzung laufen, was Prozessorzeit kostet, die unserer Verpackungsentscheidung gehört und nicht dem Code des Clients. Wir prüfen den laufenden Prozess, nicht nur die Datei.
Die Grenzen für offene Dateien werden für alle gleich angehoben. macOS startet Programme mit einer Grenze von 256 offenen Dateien, die ein voller Satz Verbindungen überschreiten kann. Ein Client, der daran stößt, verschwindet meist ohne Absturzbericht, was sich genau wie ein Versagen der Software liest. Das scheinbare Nichtankommen eines Mitbewerbers erwies sich als genau das; angehoben, war derselbe Auftrag in 44 Sekunden fertig.
Plattenverkehr wird pro Durchgang aufgezeichnet, was zugleich als Prüfung dient, dass nichts anderes die Maschine benutzt hat. Diese Zähler erfassen die ganze Platte statt eines Programms, wenn also ein zweiter Auftrag liefe, erschiene seine Arbeit in unseren Messungen. Flache Werte über eine Runde hinweg sind, woran wir erkennen, dass ein Ergebnis zu dem Client gehört, den es nennt.
Jeder Client schreibt in seinen eigenen Ausgabebaum, und der Baum wird vor jedem Durchgang gelöscht, damit kein Lauf durch die Datei eines früheren Laufs erfüllt werden kann.

Wo ein Client bestimmte Einstellungen braucht, um gut zu arbeiten, bekommt er sie, und die Runde nennt welche. Beispiele: Anfrage-Pipelining eingeschaltet, wo ein Client es ausgeschaltet ausliefert, Duplikatprüfung abgeschaltet, wenn derselbe Auftrag wiederholt geladen wird, und Entpackhelfer aus dem eigenen Paket des Clients statt aus einer Systemkopie. Ziel ist, dass jeder Client von seiner besten Seite gemessen wird statt an seinen Voreinstellungen, denn Voreinstellungen sind eine andere Debatte als Leistungsfähigkeit.

Was wir nicht tun werden

Die Grenzen dieser Zahlen

Wir veröffentlichen keine Zahl, die wir nicht gemessen haben. Ist eine Zahl abgeleitet statt beobachtet, wird sie als abgeleitet gekennzeichnet, und wir lassen lieber eine Lücke, als sie mit Rechnerei zu füllen, die sich wie eine Messung liest.
Wir bessern ein verlorenes Ergebnis nicht still nach. Ein Durchgang, den wir verlieren, bleibt veröffentlicht, bis ein neuer Lauf ihn ersetzt, und wenn aus einer Niederlage ein Sieg wird, bekommt die Änderung eine Erklärung neben der Tabelle statt einer stillen Korrektur.
Die Provider-Durchgänge sind noch nicht unabhängig reproduzierbar, weil der Inhalt nicht uns gehört und nicht weitergegeben werden darf. Die Komponententests, die erzeugten Inhalt verwenden, sind es. Wir bereiten Testdateien vor, die wir veröffentlichen können, damit auch die Provider-Durchgänge überprüfbar werden.
Das sind unsere Benchmarks fremder Software. Jede Version wird genannt und datiert, und wenn ein Client eine neue Fassung herausbringt, lassen wir die betroffenen Durchgänge neu laufen, statt einen veralteten Vergleich stehen zu lassen. Wenn du meinst, ein Ergebnis sei falsch, sind Einstellungen und Versionen veröffentlicht, sodass man konkret dagegen argumentieren kann.