Ihr Starlink als lokaler Stratum-1-Zeitserver
Eine vorhandene Antenne bietet eine lokale Zeitquelle. Wir untersuchen, was gewöhnliches WLAN liefert, was Beacon-Zeitmessung ergänzt und welches Potenzial ein Kabel oder ein besser nachgeführter Access Point eröffnet.
Wer bereits Starlink besitzt, hat möglicherweise den teuersten Teil einer lokalen Zeitquelle schon im Freien installiert. Starlink dokumentiert einen GPS-basierten NTP-Server unter 192.168.100.1. Ein lokaler Client kann die Zeit vom Terminal abfragen, ohne diese NTP-Anfrage über die Satellitenverbindung an einen Zeitserver im Internet zu senden. Der Dienst arbeitet nach dem Best-Effort-Prinzip und bietet keine Genauigkeitsgarantie.
Das ist ein interessanter Ausgangspunkt für eine Werkstatt, ein Heimlabor oder einen abgelegenen Standort. Wir wollten wissen, wie weit preiswerte Client-Hardware damit kommt: zunächst mit gewöhnlichem NTP, dann mit den feinen Uhreninformationen, die WLAN-Beacons bereits enthalten. Die Ergebnisse sprechen dafür, eine nützliche lokale Quelle weiter zu untersuchen. Sie zeigen zugleich, warum eine Stratum-Zahl und eine ruhige Zeitanzeige erst der Anfang sind.
Mit dem vorhandenen Zeitserver beginnen
Unsere erste Aufzeichnung akzeptierte 37 NTP-Antworten, die sämtlich Stratum 1 meldeten. Ihre Umlaufzeiten lagen zwischen 3,289 und 26,439 ms. Stratum 1 bezeichnet einen primären Server in der NTP-Hierarchie; es bescheinigt keinen bestimmten Fehler an Ihrem Computer. Ein Rechner, der sich mit diesem Server synchronisiert, wird normalerweise zu Stratum 2. Versorgt er weitere Rechner, kommt für deren Clients eine weitere Ebene hinzu.
Für eine bestehende chrony-Installation lautet der grundlegende Quelleneintrag:
server 192.168.100.1 iburstDiesen Quelleneintrag ergänzt man in einer geeigneten bestehenden Konfiguration; er ist keine vollständige Serverkonfiguration. Prüfen Sie, ob das Terminal aus Ihrem LAN erreichbar ist, protokollieren Sie seinen gemeldeten Zustand und vergleichen Sie es mit anderen Referenzen. iburst beschleunigt die anfängliche Erfassung; es stellt nicht den unten verwendeten eigenen Beacon-Schätzer bereit. Es gibt keinen Grund, eine Stratum-Zahl zu erzwingen oder chronys davon unabhängige Option local stratum einzuschalten.
Weitere geeignete Zeitquellen ermöglichen eine Gegenprüfung, wenn sich der Zustand des Terminals ändert. Wir haben diese Installation weder bei GNSS-Verlust noch bei WAN-Ausfällen oder in jedem Router-Modus qualifiziert; auch ihre Authentifizierungsmöglichkeiten haben wir nicht festgestellt. Eine lokale Adresse allein belegt keine vertrauenswürdige Zeit.
Die zweite Uhr in WLAN-Beacons
Ein Access Point sendet regelmäßig ein Beacon mit seinem Zähler der Timing Synchronization Function, kurz TSF. Ein kompatibler Empfänger erhält damit eine Beobachtung der lokalen AP-Uhr. Daraus allein geht nicht hervor, welche UTC-Sekunde diese Uhr darstellt.
Wir verwendeten einen ESP32-S3 W12 mit Empfangsereignis-Zeitstempeln des Treibers und deaktivierten Energiesparfunktionen. Ein aus früheren Beacon-/Empfangspaaren gebildetes Modell sagte jede neue Beobachtung voraus, bevor sie in die Anpassung einging. So wird ein verspäteter Software-Callback nicht mit dem Funkereignis gleichgesetzt.
Im etwa zehnminütigen Beacon-Experiment ergaben 5.858 protokollierte Beobachtungen einen relativen Vorhersage-RMS von 0,409 µs, einen absoluten P99 von 0,969 µs und ein Maximum von 1,346 µs. Alle 40 Residuen oberhalb einer Mikrosekunde bleiben enthalten. Eine getrennte Anpassung anhand der Software-Callback-Zeit hatte einen RMS von 5,427 µs: Der Zeitstempelpfad ist entscheidend.
Das sind lokale Vorhersageresiduen und keine UTC-Genauigkeit. In der Aufzeichnung fehlte außerdem ein Rohdatensatz unter 5.859 akzeptierten Probennummern; damit scheiterte die strenge Prüfung auf Lückenlosigkeit. Eine unabhängige Wiederholung rekonstruierte 5.602 Vorhersagen; für 256 protokollierte Zeilen fehlte die vollständige Vorgeschichte. Weder diese Lücken noch feste Verzögerungen verschwinden durch eine gut aussehende Anpassung.
Das Experiment zeigte, dass Beacons nützliche feine Uhreninformationen tragen. Es zeigte nicht, dass der AP GPS-geregelt war. Die NTP-Uhr des Terminals, der AP-Zähler und die Zähler des Clients sind verschiedene beobachtbare Uhren; ihre physikalischen Beziehungen sind weiterhin ungeklärt.
Was WLAN mit und ohne Optimierung erwarten lässt
Für einen gewöhnlichen Software-NTP-Client auf einer nicht charakterisierten WLAN-Verbindung setzen wir als vorsichtige Planungsschätzung ein Fehlerbudget von unter einer bis zu wenigen Millisekunden an; unter Last sind größere Ausschläge einzukalkulieren. Das ist eine technische Planungsannahme, kein gemessenes Ergebnis eines Standardclients und keine Starlink-Spezifikation. In den späteren Läufen hatten einzelne akzeptierte NTP-Beobachtungen etwa 3,9–4,6 ms Residuenstreuung. Ein geregelter Client kann verrauschte Beobachtungen mitteln, aber dabei keinen konstanten Fehler durch einseitige Laufzeit erkennen.
Praktische Optimierung beginnt mit einem stetig laufenden Client, einem sauberen Funkpfad, sinnvollen Abfrageintervallen und einer ausgereiften Uhrenregelung. Vergleichen Sie ruhige und stark ausgelastete Phasen, untersuchen Sie Energiesparfunktionen und ändern Sie möglichst nicht mehrere Einstellungen zugleich. Kürzere Abfrageintervalle können Drift schneller erfassen; längere Mittelung unterdrückt Rauschen. Das richtige Verhältnis hängt von Uhr und Verbindung ab. Unser eigener Pfad benötigt zusätzlich Zugriff auf Empfangsereignis-Zeitstempel, den gewöhnliche Smartphone- und Laptop-Apps möglicherweise nicht bieten.
Unsere gepaarte Folgestudie verwendete in jedem der beiden Läufe 900 Sekunden Training und anschließend 900 Sekunden Auswertung. Die reine NTP-Kontrolle war bereits optimiert: eine AP-freie lokale Uhrenschätzung über 900 Sekunden mittels gewichteter kleinster Quadrate, WLS900 genannt. Der Hybrid kombinierte NTP mit AP-Uhreninformationen und einem robusten Filter. Das waren keine Tests von Standard-chrony gegen optimiertes chrony.
Jede Methode erhielt zunächst ihre eigene feste, mit GNSS gemessene Phasenkorrektur. Mit dieser vorab bestimmten Korrektur ergaben dieselben 900 zukünftigen PPS-Zeugen je Lauf:
| Lauf / Verfahren | RMS (µs) | Abs. P99 (µs) |
|---|---|---|
| R1 · nur NTP | 37,180 | 67,329 |
| R1 · NTP + Beacons | 19,226 | 43,079 |
| R2 · nur NTP | 35,662 | 54,767 |
| R2 · NTP + Beacons | 8,240 | 20,069 |
Der Hybrid verbesserte den RMS in beiden Läufen. Im ersten entstand der Gewinn durch einen geringeren Bias, während sich die zentrierte Streuung leicht verschlechterte; im zweiten verbesserten sich beide. Gewöhnliche AP-Anpassungen und Regler lieferten gemischte Ergebnisse. Zwei Zeitfenster innerhalb eines Bootvorgangs sind ermutigende Beobachtungen, aber keine allgemeine Leistungsverteilung.
Die Kalibrierungsbedingung verändert die Erwartungen für Anwender. Ohne die vorherige GNSS-Phasenkorrektur betrug der RMS der rohen Phase beim reinen NTP 224,160/226,778 µs und beim Hybrid 217,046/218,521 µs. Auch diese Rohwerte sind Beobachtungen dieses Aufbaus und keine übertragbare UTC-Grenze. Wer die korrigierten Ergebnisse im Bereich einiger zehn Mikrosekunden reproduzieren will, muss die Phasenbasis von Client, Pfad und Modell messen; sie lässt sich nicht einfach auf eine andere Installation übertragen.
GNSS lieferte diese Phasenbasis und den Validierungszeugen, niemals das Frequenztraining. Die Werte werden weder durch nachträgliche Zentrierung noch durch Trendabzug im zukünftigen Fenster verbessert. Eine vollständige Bewertung von 900/900 belegt keine durchgehende Dienstverfügbarkeit. Für die laufend aktualisierten Modelle gilt weiterhin eine Quellenberechtigung von 60 Sekunden; eine gute Vorhersage einer eingefrorenen Uhr verlängert sie nicht. Frühere fehlgeschlagene und unvollständige Experimente bleiben im Paper erhalten.
Was ein Kabel ändern könnte
Ethernet dürfte WLAN-Konkurrenz um den Kanal, Wiederholungen und Funkeffekte durch Energiesparen aus dem Client-Pfad entfernen. Es kann auch bessere Paketzeitstempel ermöglichen. Einen verzerrten Serverzeitstempel, einen Fehler der Terminal-Uhr oder asymmetrische Verzögerungen an anderer Stelle beseitigt es nicht.
Unsere kabelgebundene Schätzung, an dieser Starlink-Installation noch ungetestet: Ein ruhiger kabelgebundener Software-Client könnte einige zehn Mikrosekunden relativer Uhrenübereinstimmung als sinnvolles erstes Ziel erreichbar machen, mit etwa 10–100 µs als anfänglichem technischen Zielbereich, nicht als vorhergesagtem RMS oder P99. Dominiert die Zeitstempelbildung oder die Uhr des Terminals, könnte die Verbesserung klein bleiben. Wir würden weder ein entsprechendes absolutes UTC-Ergebnis noch einen festen Verbesserungsfaktor gegenüber WLAN zusagen.
Deutlich bessere Zeitübertragung über Ethernet ist möglich, wenn Server, Client und Zeitstempelpfad dafür ausgelegt sind. Die unabhängig gemessenen kabelgebundenen Beispiele von chrony zeigen bei einem Software-Client-Aufbau etwa 2 µs Stabilität mit ungefähr 5 µs Bias und mit Hardware-Zeitstempeln an beiden Enden wesentlich feinere Übertragung. Das sind andere Systeme. Eine geeignete Netzwerkkarte am Client allein verschafft einem Starlink-Terminal keinen kalibrierten NTP-Dienst mit Hardware-Zeitstempeln.
Der nächste sinnvolle Test verwendet dasselbe Terminal mit WLAN- und Ethernet-Clients, fester Kalibrierung, vergleichbaren Ruhe- und Lastfenstern sowie einer unabhängigen PPS-Referenz. RMS, P99, Maximum, Lücken und Erholung müssen erhalten bleiben. Dann können wir den Zielbereich durch ein Messergebnis ersetzen.
Wie SpaceX die AP-Uhr verbessern könnte
Die Chance liegt darin, zwei bereits vorhandene Elemente der Installation zu verbinden: eine GPS-basierte Zeitquelle im Terminal und häufige AP-Beacon-Ereignisse. Wir haben nicht festgestellt, wie SpaceX diese Uhren derzeit miteinander verknüpft. Der folgende Entwurf ist ein Vorschlag, der geeignete zugängliche Zeitsignale in der Hardware voraussetzt.
Zuerst müsste die Referenz des Terminals über eine vermessene Uhrenbrücke in den Router gelangen: einen Austausch mit Hardware-Zeitstempeln, einen PPS-Anschluss, falls vorhanden, oder einen anderen kalibrierten Pfad für Kreuzzeitstempel. Gelegentliches Lesen einer Software-Uhr ließe unbekannte Übertragungsverzögerung bestehen.
Zweitens ließe sich der AP-Oszillator behutsam nachführen oder eine laufend verfolgte Abbildung seines TSF-Zählers auf Referenzzeit pflegen. Die WLAN-Synchronisationssemantik muss erhalten bleiben, statt TSF willkürlich auf eine UTC-Epoche zu setzen. Eine konstante Frequenzabweichung zu korrigieren reicht nicht aus; das System muss langsame Schwankungen verfolgen und Resets erkennen.
Drittens müsste diese Abbildung geeigneten Clients bereitgestellt und an das tatsächliche MAC-Sendeereignis gebunden werden. Sie benötigt eine Referenzepoche, die Beziehung von Offset und Rate, Unsicherheit, Alter und einen klaren Zustand für Referenzverlust und Holdover. NTP kann der breit kompatible Einstieg bleiben, während Metadaten zu präzisen Ereignissen Clients dienen, die diese erfassen können. Der Empfangs-/Sendezeitstempelpfad des NTP-Dienstes im Terminal verdient dieselbe sorgfältige Kalibrierung.
Damit könnten häufige Beacons den Takt einer referenzierten Uhr tragen, während ein langsamerer Austausch ihre Zeitkoordinate festlegt. Unser relatives Beacon-Residuum von 0,409 µs macht Zeitübertragung im Mikrosekundenbereich zu einem lohnenden Forschungsziel für einen solchen Entwurf. Es liefert weder die fehlende UTC-Kalibrierung noch den Nachweis unabhängiger Clients oder eine Messung des physikalischen Ausgangs.
Für Anwender ist der preiswerte erste Schritt heute, den bereits in der Antenne vorhandenen NTP-Dienst zu bewerten. Unser nächster Schritt ist zu messen, was über die vollständige Kette vom Terminal über den AP bis zum Client erhalten bleibt. Ein nachgeführter AP könnte diese Kette deutlich nützlicher machen, ohne neben jedem Gerät im Gebäude eine eigene GNSS-Antenne anzubringen.