Der Messclient der Behörde, selbst gebaut — und dann waren es drei

Im ersten Teil habe ich mein Messwerkzeug ausgetauscht, weil das mitgelieferte um den Faktor vier danebenlag. Seitdem misst ein Ookla-Client alle 30 Minuten, und die Reihe ist gut.

Sie hat nur eine Eigenschaft, die man kennen muss: Sie gilt bei mir zu Hause. Ein Anbieter muss ihr nicht glauben, und das ist nicht einmal unfair. Ookla misst gegen irgendeinen Server, ausgewählt nach Nähe.

Also kam ein zweites Verfahren dazu. Und damit ein Problem, das ich nicht kommen sah.

Zwei Messverfahren, zwei verschiedene Fragen

In Österreich betreibt die Regulierungsbehörde einen eigenen Netztest. Er misst gegen ihre Server und meldet das Ergebnis an ihren Kontrollserver.

	Ookla	Netztest der Behörde
misst gegen	nächstgelegenen Server	Server der Behörde
Ergebnis bleibt	bei mir	auch dort
Takt	alle 30 Minuten	viermal täglich in Fenstern
taugt als	Anzeige	Beleg

Der Unterschied ist nicht die Genauigkeit. Es ist die Verankerung: Das Ergebnis liegt hinterher nicht nur in meiner Datenbank.

Den Befehlszeilenclient dazu gibt es offen. Im Kleingedruckten steht, er sei nur für Entwicklung und Überprüfung gedacht — kein Verbot, aber ein Hinweis darauf, was diese Messungen nicht sind. Dazu unten mehr.

Erst nachsehen, was die Nachbarschaft bekommt

Bevor ich etwas gebaut habe, habe ich die offenen Daten derselben Behörde abgefragt. Jede Messung ihres Netztests ist veröffentlicht, mit Ort, Anbieter und Technik.

Im Umkreis von acht Kilometern, nur 5G, nur mein Anbieter — 539 Messungen:

	Download
unteres Viertel	104,2 Mbit/s
Median	189,9
oberes Viertel	341,7
bestes Zehntel	487,7
unter 90 Mbit/s	22 % der Messungen

Damit war meine eigene Reihe zum ersten Mal eingeordnet statt bewertet. Die 242 bis 338 der guten Tage lagen zwischen Median und oberem Viertel — völlig unauffällig. Die 60 bis 95 der schlechten lagen unter dem unteren Viertel.

Das schwächt eine These, die ich schon fast geglaubt hatte: Wäre die Zelle grundsätzlich am Anschlag, läge die ganze Umgebung dort unten. Sie liegt es nicht.

Was diese Daten nicht hergeben

Im Fenster der letzten sieben Tage gab es zwei passende Messungen, in dreißig Tagen elf. Über das, was seit Dienstag passiert, sagen sie nichts.

Und es sind Handymessungen von wechselnden Orten, drinnen wie draußen. Sie beschreiben die Größenordnung der Gegend, nicht meine Zelle.

Drei Fallen der Schnittstelle, alle selbst hineingetappt

1. Der Umkreisparameter heißt radius, nicht distance. Mit dem falschen Namen kommt eine leere Liste zurück — das sieht aus wie „keine Daten in der Gegend“.
2. Das Ergebnisfeld kann null sein statt einer leeren Liste. Wer darüber iteriert, stürzt mitten in der Auswertung ab.
3. Die teuerste: Die Schnittstelle liefert gelegentlich eine leere Seite, obwohl es danach weitergeht. Meine Schleife brach daraufhin ab. Zwei identische Abfragen ergaben einmal 5000 und einmal 1000 Messungen.

Zu Nummer drei gehört das Eingeständnis: Ich habe innerhalb weniger Minuten erst „nur fünf Messungen, zu wenig für eine Aussage“ gemeldet und dann „118“. Dieselbe Gegend, nur verschieden tief abgefragt. Das Skript bricht jetzt erst nach drei leeren Seiten in Folge ab — und liefert 14.500 statt 1000.

Eine Abbruchbedingung, die auf das erste Schweigen hört, macht aus einer Datenlücke eine Tatsachenbehauptung.

Was gebaut wurde

Add-on	reines Alpine, der C-Client fest auf einem Commit
Dienst	HTTP im Haus; ein Aufruf misst und antwortet als JSON
Zeitplan	alle 15 Minuten in vier Fenstern: 06–08, 11–13, 17–19, 23–01

Vier Fenster statt rund um die Uhr, weil jede Messung die Leitung wirklich belegt und weil der Tagesgang nur dann vergleichbar bleibt, wenn immer zur selben Zeit gemessen wird.

Der Client ist auf einen bestimmten Stand festgenagelt, nicht auf „neueste Fassung“. Bei einem Messgerät ist das keine Pedanterie: Ändert sich das Werkzeug mitten in der Reihe, vergleicht man hinterher zwei Dinge.

Die Position musste nachgerüstet werden

Hier wurde es interessant. Der Client sendet seine Standortangabe als leere Liste — fest eingebaut, ohne Schalter. Für eine Messung, die später einmal etwas belegen soll, ist das die falsche Voreinstellung: Ohne Ort ist sie eine Messung von irgendwo.

Ein kleines Skript greift deshalb beim Bauen an drei Stellen in den Quelltext ein und setzt die echten Felder ein.

Der Teil, auf den es ankommt: Es bricht ab, wenn eine der drei Stellen nicht exakt passt.

Ein halb angewandter Eingriff wäre schlimmer als gar keiner. Er würde bauen, laufen und messen — und niemand wüsste, was davon eingebaut ist.

Und die Feldnamen stammen nicht aus dem Gedächtnis, sondern aus dem Quelltext des Kontrollservers, der sie entgegennimmt. Das ist der Unterschied zwischen „müsste so heißen“ und „heißt so“.

Ehrlich dazu: Ob die Position wirklich ankommt, war an diesem Tag noch nicht bestätigt. Die offenen Daten hinken ein bis zwei Tage nach.

Vier Fehlschläge beim Bau

1. Das Basisabbild war undefiniert, weil eine Datei fehlte. Ohne sie ist nicht festgelegt, worauf gebaut wird.
2. Ein Paketkonflikt im fertigen Basisabbild. Es nagelt ein Paketarchiv fest, in dem zwei zusammengehörige Bibliotheken nicht zusammenpassen. Eine Aktualisierung half nicht — die Festnagelung bietet die neuere Fassung gar nicht an. Lösung: ein nacktes Alpine, dafür ohne die Hilfsbibliothek; die Einstellungen liest der Dienst selbst.
3. Ein Ersatz im Dockerfile, der nicht gegriffen hat — und ich habe „angepasst“ gemeldet, ohne nachzusehen. Der Bau scheiterte danach zweimal mit demselben Fehler. Seither: Datei neu schreiben statt daran schnitzen, und hinterher nachsehen.
4. Der Kontrollserver wies die erste Anfrage ab mit „deine Clientversion wird nicht unterstützt“. Das war eine falsche Fährte: Es lag nicht an der Version, sondern daran, dass zwei Pflichtfelder gar nicht mitgeschickt wurden. Mit ihnen antwortet er bei jeder Versionsangabe freundlich.

Nummer vier ist die lehrreichste. Die Fehlermeldung war wahr und irreführend zugleich — sie beschrieb, was der Server nicht erkennen konnte, nicht, warum.

Was das nicht ist

Keine zertifizierte Messung. Die geht nach den Regeln der Behörde nur über einen Browser am Rechner, bei sonst ungenutztem Anschluss, in drei Zyklen an drei verschiedenen Tagen — und begründet dann einen Anscheinsbeweis.

Meine Reihe ist etwas anderes und etwas Bescheideneres: ein Verlauf mit einem anerkannten Werkzeug, der ein Gespräch versachlicht. Sie ersetzt kein Beweismittel. Wer das verwechselt, steht am Ende mit 300 Messungen da, die formal nichts gelten.

Zeitstempel in UTC, und warum das kein Detail ist

Der Behälter des Add-ons kennt keine Zeitzone, und die durchgereicht bekommt er auch nicht. In der Tabelle stand deshalb 05:15, während im Haus 07:15 war.

Jetzt steht überall UTC mit einem ausdrücklichen Z dahinter. Das kostet beim Lesen zwei Sekunden Kopfrechnen und spart zwei Dinge: einen Bruch bei der Zeitumstellung Ende Oktober — und einen Empfänger, der die Zone raten muss.

Wie teuer zwei Stunden Versatz werden können, habe ich an anderer Stelle bezahlt: Sie haben mich die ganze Schuldzuweisung gekostet .

Die Falle beim Erweitern der Tabelle

Als eine neue Spalte dazukam, wäre beinahe die komplette bisherige Reihe verschwunden. Der Leser verwarf Zeilen, deren Spaltenzahl nicht zum Kopf passte — ohne Fehlermeldung, einfach eine plötzlich viel kürzere Tabelle.

Jetzt werden fehlende Felder aufgefüllt. Verworfen wird nur, was zu lang ist, weil das auf ein Trennzeichen im Text hindeutet und dann alles verschoben stünde.

Und dann maßen drei

Die Beobachtung kam nicht aus einer Auswertung, sondern vom Draufschauen: um 5:00 und 5:30 nur geringer Durchsatz, und parallel misst Ookla zur Behördenmessung.

Das stimmte. Auf dieser Leitung maßen inzwischen drei Systeme: der Behördenclient in seinen Fenstern, Ookla alle 30 Minuten rund um die Uhr, und die Antenne selbst zweimal täglich.

Jede zieht die Leitung für 20 bis 45 Sekunden voll. Laufen zwei gleichzeitig, teilen sie sich die Bandbreite und beide melden die Hälfte.

Der Beleg

107 Messungen des Behördenclients, eingeteilt nach ihrem zeitlichen Abstand zum nächsten Ookla-Lauf:

Abstand	n	runter, Median	hoch, Median
echt gleichzeitig, unter 20 s	3	75	29
knapp daneben, 20–90 s	8	208	98
getrennt, 90–300 s	25	112	94
weit weg, über 300 s	71	126	98

Und jetzt der Satz, auf den es ankommt: Der niedrigste Download der ganzen Reihe und der niedrigste Upload der ganzen Reihe stehen beide in diesen drei Zeilen — von 107. Dass beide Extremwerte zufällig in dieselben drei fallen, hat eine Wahrscheinlichkeit von unter einem Promille.

Diese drei Ergebnisse zeigen nicht, was die Leitung kann. Sie zeigen, was passiert, wenn man sie dreifach belegt.

Zwei Fehlgriffe auf dem Weg dorthin

Erst nach der Minutenzahl gruppiert — :00 und :30 gegen :15 und :45 — und „kein Effekt“ herausbekommen.

Falsche Einteilung. Ookla läuft nicht fest auf der halben Stunde, sondern driftet um rund 25 Sekunden je Lauf und wandert dadurch langsam durch die Uhr. Von 43 vermeintlichen Begegnungen waren nur drei echte; die anderen 40 haben den Effekt zugedeckt.

Dann „überlappt ja oder nein“ mit 90 Sekunden Toleranz — und wieder nichts gefunden, diesmal sogar andersherum. Auch falsch: Bei 90 Sekunden Abstand sind beide Messungen längst fertig. Erst die Staffelung nach Abstand zeigt es.

Zweimal habe ich dieselbe Frage falsch gestellt und beide Male eine saubere Antwort bekommen. Eine Auswertung sagt nicht, dass die Einteilung falsch war. Sie rechnet, was man ihr gibt.

Und ein Satz, der seit vier Tagen falsch dastand

In drei Dateien stand seit dem Bau: „Während eines Fensters schweigt der eigene Sensor.“

Das war nie gebaut. Die Bedingung, die das hätte leisten sollen, kam in keiner einzigen Automatisierung außerhalb ihrer eigenen Datei vor. Die Absicht war richtig aufgeschrieben und nie umgesetzt — und weil sie dastand, hat niemand mehr nachgesehen.

Das ist die unangenehmste Zeile dieses Artikels. Eine Dokumentation, die eine Absicht als Zustand beschreibt, ist schlimmer als keine.

Der feste Takt

Ein Versatz allein hätte nicht gereicht: Die Ookla-Integration misst in einem Intervall, nicht zu festen Uhrzeiten, und driftet deshalb zwangsläufig wieder in die Viertelstunden der anderen Messung.

Also wurde ihre eigene Abfrage abgeschaltet und der Takt von außen gesetzt:

Behördenclient   :00  :15  :30  :45      nur in den vier Fenstern
Ookla            :07       :37           rund um die Uhr, wie bisher
Antenne          08:07 und 20:07         außerhalb aller Fenster

Sieben Minuten Abstand bei Messungen von unter einer Minute Dauer.

Zwei Nachsorgen gehören dazu:

Nachgemessen, dass Ookla ohne eigene Abfrage überhaupt noch misst. Eine abgeschaltete Abfrage ist ein guter Weg, eine Messreihe still zu beenden. Also angestoßen und 30 Sekunden später den neuen Wert gesehen.

Und eine Meldung, falls der Takt ausfällt. Kommt drei Stunden lang kein neuer Wert, sagt das System Bescheid. Ein Zeitplan, der stillschweigend aussetzt, ist genau die Sorte Fehler, die man erst beim Auswerten bemerkt.

Nebenbei ist die Morgenmeldung von 07:30 auf 08:15 gewandert und misst nicht mehr selbst, sondern liest den Wert von 08:07 vor. Mein erster Anlauf hätte nur die Messung entfernt und die Meldung stehen gelassen — dann hätte sie den Wert vom Vorabend vorgelesen, elf Stunden alt.

Was ich dir rate

1. Nimm ein zweites Verfahren, wenn du etwas belegen willst. Deine eigene Reihe ist eine Anzeige. Ein anerkanntes Werkzeug ist ein Argument.
2. Sieh nach, was die Nachbarschaft bekommt, bevor du den Anbieter verdächtigst. Offene Daten gibt es; sie ordnen deine Zahlen ein.
3. Nagel dein Messwerkzeug auf einen Stand fest. Ein Werkzeug, das sich mitten in der Reihe ändert, macht aus einer Reihe zwei.
4. Lass einen Eingriff abbrechen, wenn er nicht exakt passt. Halb angewendet ist schlimmer als gar nicht — es läuft ja.
5. Zähl deine Messgeräte. Jedes belegt die Leitung. Drei auf einer Leitung messen sich gegenseitig.
6. Schreib nur auf, was gebaut ist. Eine Absicht, die wie ein Zustand dasteht, beendet jede weitere Prüfung.

Und was heißt das?

Ich bin angetreten, um meine Messungen belastbarer zu machen, und habe sie dabei zuerst unbrauchbarer gemacht. Das dritte Messgerät hat die drei schlechtesten Werte der ganzen Reihe erzeugt — und zwar genau die Werte, die ich sonst am lautesten vorgezeigt hätte.

Was geblieben ist, sind zwei Dinge. Ein Verlauf mit einem Werkzeug, das nicht mir gehört. Und ein Takt, in dem sich die drei nicht mehr begegnen.

Der Rest ist die alte Lehre in neuer Verkleidung: Ein Beobachter, der im Weg steht, misst sich selbst mit.

Was die saubere Reihe dann gezeigt hat, steht im dritten Teil: Der schwächere Mast war der bessere.