{"format":"ptob-page","version":1,"canonical":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/","title":"Starlink-Stratum-1-NTP über WLAN — Ergebnisse und Grenzen — PToB-Blog","description":"Eine Untersuchung von Starlinks lokalem GPS-NTP-Server: WLAN-Beacon-Zeitmessung, kalibrierte Ergebnisse, Erwartungen für Ethernet und eine bessere AP-Uhr durch SpaceX.","language":"de","robots":"index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1","dates":{"published":"2026-11-03T00:00:00.000Z","modified":"2026-11-03T00:00:00.000Z"},"authors":["Jonathan Yantis"],"mainEntity":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#article","representations":{"application/json":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/?format=json","text/markdown":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/?format=markdown"},"documentation":"https://ptob.dev/agent-formats.json","social":{"openGraph":{"title":"Starlink-Stratum-1-NTP über WLAN — Ergebnisse und Grenzen — PToB-Blog","description":"Eine Untersuchung von Starlinks lokalem GPS-NTP-Server: WLAN-Beacon-Zeitmessung, kalibrierte Ergebnisse, Erwartungen für Ethernet und eine bessere AP-Uhr durch SpaceX.","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/","type":"article","siteName":"PToB","locale":"de_DE","image":{"url":"https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png","secureUrl":"https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png","type":"image/png","width":"1585","height":"992","alt":"Gemalte Konzeptszene mit einem SpaceX-Satelliten über der Erde, einer Dachantenne und einer Werkstatt-Uhr mit der Anzeige 20 µs neben einem WLAN-Router."}},"twitter":{"card":"summary_large_image","title":"Starlink-Stratum-1-NTP über WLAN — Ergebnisse und Grenzen — PToB-Blog","description":"Eine Untersuchung von Starlinks lokalem GPS-NTP-Server: WLAN-Beacon-Zeitmessung, kalibrierte Ergebnisse, Erwartungen für Ethernet und eine bessere AP-Uhr durch SpaceX.","image":{"url":"https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png","alt":"Gemalte Konzeptszene mit einem SpaceX-Satelliten über der Erde, einer Dachantenne und einer Werkstatt-Uhr mit der Anzeige 20 µs neben einem WLAN-Router."}}},"citations":[],"provenance":{"sourceUrl":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/","sourceMediaType":"text/html","sourceSha256":"472bd7528019e163b32eec487febb93cc5f9e6abe1e23739aabc317ec172d1cf","rightsUrl":"https://github.com/yantisj2/PToB/blob/main/LICENSING.md"},"contentUsage":{"aiTrain":true,"search":true,"aiInput":true,"reason":"summary-or-introduction"},"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"WebSite","@id":"https://ptob.dev/#website","url":"https://ptob.dev/","name":"PToB","alternateName":["Precision Time over BLE","Precision Time over Bluetooth"],"description":"Bluetooth and USB software clocks: W12 60.3 ns relative-PPS RMS over 522/600 observations, separate 64 s sampled holdover, and CoreSE diagnostics.","inLanguage":["en","de"],"publisher":{"@id":"https://ptob.dev/#jonathan-yantis"}},{"@type":"Person","@id":"https://ptob.dev/#jonathan-yantis","name":"Jonathan Yantis","url":"https://github.com/yantisj2/PToB/blob/main/CREDITS.md"},{"@type":"Project","@id":"https://ptob.dev/#project","name":"PToB","alternateName":"Precision Time over BLE","url":"https://ptob.dev/","description":"An independent protocol project researching precision time transfer across Bluetooth-enabled microcontrollers and USB clients.","sameAs":"https://github.com/yantisj2/PToB","member":{"@id":"https://ptob.dev/#jonathan-yantis"},"knowsAbout":{"@id":"https://ptob.dev/#protocol"}},{"@type":"Thing","@id":"https://ptob.dev/#protocol","name":"Precision Time over BLE","alternateName":"PToB","description":"An experimental PTP-inspired protocol proposal for wireless clock synchronization over Bluetooth Low Energy."},{"@type":"WebPage","@id":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#webpage","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/","name":"Starlink-Stratum-1-NTP über WLAN — Ergebnisse und Grenzen — PToB-Blog","description":"Eine Untersuchung von Starlinks lokalem GPS-NTP-Server: WLAN-Beacon-Zeitmessung, kalibrierte Ergebnisse, Erwartungen für Ethernet und eine bessere AP-Uhr durch SpaceX.","inLanguage":"de","keywords":["Starlink","Stratum-1-NTP","WLAN-Zeitmessung","TSF-Beacons","ESP32-S3"],"isPartOf":{"@id":"https://ptob.dev/#website"},"author":{"@id":"https://ptob.dev/#jonathan-yantis"},"about":{"@id":"https://ptob.dev/#protocol"},"dateModified":"2026-11-03T00:00:00.000Z","image":"https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png","breadcrumb":{"@id":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#breadcrumbs"},"mainEntity":{"@id":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#article"},"translationOfWork":{"@id":"https://ptob.dev/blog/starlink-local-stratum-1-ntp/#webpage"}},{"@type":"BreadcrumbList","@id":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#breadcrumbs","itemListElement":[{"@type":"ListItem","position":1,"name":"PToB","item":"https://ptob.dev/de/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://ptob.dev/de/blog/"},{"@type":"ListItem","position":3,"name":"Ihr Starlink als lokaler Stratum-1-Zeitserver","item":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/"}]},{"@type":"Blog","@id":"https://ptob.dev/de/blog/#blog","url":"https://ptob.dev/de/blog/","name":"PToB-Blog","description":"Entwicklungsnotizen über gemeinsame Zeit, preiswerte Hardware und die Experimente hinter PToB.","inLanguage":"de","publisher":{"@id":"https://ptob.dev/#jonathan-yantis"},"isPartOf":{"@id":"https://ptob.dev/#website"},"blogPost":[{"@id":"https://ptob.dev/de/blog/esp32-sensoren-ble-synchronisieren/#article"},{"@id":"https://ptob.dev/de/blog/esp32-uhren-grundlagen/#article"},{"@id":"https://ptob.dev/de/blog/zuverlaessige-firmware-zeitmesh/#article"},{"@id":"https://ptob.dev/blog/lab-sensor-timing-economics/#article"},{"@id":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#article"},{"@id":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#article"},{"@id":"https://ptob.dev/de/blog/gnss-resilientes-zeitmesh/#article"},{"@id":"https://ptob.dev/de/blog/passives-lora-kanalwechsel/#article"},{"@id":"https://ptob.dev/de/blog/esp32-holdover-unter-einer-mikrosekunde/#article"},{"@id":"https://ptob.dev/de/blog/lokale-zeit-utc-netz/#article"},{"@id":"https://ptob.dev/de/blog/grandmaster-ausfall-und-uhrenensemble/#article"},{"@id":"https://ptob.dev/de/blog/ble-uhren-innenraumnavigation/#article"},{"@id":"https://ptob.dev/de/blog/passives-ble-esp32/#article"},{"@id":"https://ptob.dev/de/blog/warum-utc/#article"},{"@id":"https://ptob.dev/de/blog/warum-ptob/#article"}]},{"@type":"BlogPosting","@id":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#article","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/","headline":"Ihr Starlink als lokaler Stratum-1-Zeitserver","description":"Eine Untersuchung von Starlinks lokalem GPS-NTP-Server: WLAN-Beacon-Zeitmessung, kalibrierte Ergebnisse, Erwartungen für Ethernet und eine bessere AP-Uhr durch SpaceX.","mainEntityOfPage":{"@id":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#webpage"},"isPartOf":{"@id":"https://ptob.dev/de/blog/#blog"},"author":{"@id":"https://ptob.dev/#jonathan-yantis"},"publisher":{"@id":"https://ptob.dev/#jonathan-yantis"},"inLanguage":"de","dateCreated":"2026-11-03T00:00:00.000Z","dateModified":"2026-11-03T00:00:00.000Z","datePublished":"2026-11-03T00:00:00.000Z","image":"https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png","articleSection":"Starlink und lokale Netzwerkzeit","keywords":["Starlink","Stratum-1-NTP","WLAN-Zeitmessung","TSF-Beacons","ESP32-S3"],"wordCount":1511,"citation":[{"@type":"CreativeWork","name":"Starlink · Bietet Starlink Zeitsynchronisation oder NTP-Server an?","url":"https://starlink.com/ke/support/article/0873e885-831a-9f4e-4808-2838a28f2e69"},{"@type":"CreativeWork","name":"PToB · Paired Clock Time Transfer from Starlink over Wi-Fi","url":"https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-hybrid-timing"},{"@type":"CreativeWork","name":"PToB · Starlink Wi-Fi timing feasibility","url":"https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-timing"},{"@type":"CreativeWork","name":"IETF · NTPv4-Protokoll und Algorithmen, RFC 5905","url":"https://www.rfc-editor.org/rfc/rfc5905.html"},{"@type":"CreativeWork","name":"chrony · Konfigurationshandbuch","url":"https://chrony-project.org/doc/4.8/chrony.conf.html"},{"@type":"CreativeWork","name":"chrony · Configuration examples and accuracy","url":"https://chrony-project.org/examples.html"},{"@type":"CreativeWork","name":"chrony · Wie genau ist meine Systemuhr?","url":"https://chrony-project.org/faq.html#_how_accurate_is_my_system_clock"},{"@type":"CreativeWork","name":"Espressif · Definition des WLAN-Empfangszeitstempels im festgelegten ESP-IDF-Stand","url":"https://github.com/espressif/esp-idf/blob/b774170ff46c393eeb5e495ea37936038d3f4f4f/components/esp_wifi/include/local/esp_wifi_types_native.h"}],"about":{"@id":"https://ptob.dev/#protocol"}}]}],"content":{"mediaType":"text/markdown","headings":[{"level":1,"text":"Ihr Starlink als lokaler Stratum-1-Zeitserver","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#main"},{"level":2,"text":"Mit dem vorhandenen Zeitserver beginnen","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#start-with-the-time-server-you-already-own"},{"level":2,"text":"Die zweite Uhr in WLAN-Beacons","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#the-second-clock-hiding-in-wifi-beacons"},{"level":2,"text":"Was WLAN mit und ohne Optimierung erwarten lässt","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#what-to-expect-over-wifi-with-and-without-tuning"},{"level":2,"text":"Was ein Kabel ändern könnte","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#what-a-cable-could-change"},{"level":2,"text":"Wie SpaceX die AP-Uhr verbessern könnte","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#how-spacex-could-make-the-ap-a-better-clock"},{"level":2,"text":"Die Einzelheiten erkunden","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#related-title"},{"level":3,"text":"Starlink-Zeitforschung und gepaarte Ergebnisse","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#main"},{"level":3,"text":"Ein Raspberry Pi als Zeitgateway","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#main"},{"level":3,"text":"Die Bibliothek zur Zeitforschung","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#main"},{"level":2,"text":"Quellen und weitere Lektüre","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#sources-title"},{"level":2,"text":"Diesen Beitrag zitieren","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#cite-title"}],"links":[{"text":"Jonathan Yantis","url":"https://github.com/yantisj2/PToB/blob/main/CREDITS.md"},{"text":"Starlink dokumentiert einen GPS-basierten NTP-Server unter 192.168.100.1","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-starlink-ntp"},{"text":"NTP-Hierarchie","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-ntp-standard"},{"text":"Beacon-Experiment","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-beacon-study"},{"text":"gepaarte Folgestudie","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-paired-study"},{"text":"Die unabhängig gemessenen kabelgebundenen Beispiele von chrony","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-chrony-accuracy"},{"text":"Starlink-Zeitforschung und gepaarte Ergebnisse Der freigegebene siebenseitige Entwurf, benötigte Ausrüstung, RMS, P99 und Kalibrierungsgrenzen.","url":"https://ptob.dev/de/forschung/starlink-wlan-zeituebertragung/"},{"text":"Ein Raspberry Pi als Zeitgateway Mesh-Zeit mit Linux, NTP und vorgeschlagenen kabelgebundenen PTP-Pfaden verbinden.","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/"},{"text":"Die Bibliothek zur Zeitforschung Getrennte Messpopulationen, Methoden, Unsicherheit und öffentliche Quellen.","url":"https://ptob.dev/de/forschung/"},{"text":"Starlink · Bietet Starlink Zeitsynchronisation oder NTP-Server an?","url":"https://starlink.com/ke/support/article/0873e885-831a-9f4e-4808-2838a28f2e69"},{"text":"PToB · Paired Clock Time Transfer from Starlink over Wi-Fi","url":"https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-hybrid-timing"},{"text":"PToB · Starlink Wi-Fi timing feasibility","url":"https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-timing"},{"text":"IETF · NTPv4-Protokoll und Algorithmen, RFC 5905","url":"https://www.rfc-editor.org/rfc/rfc5905.html"},{"text":"chrony · Konfigurationshandbuch","url":"https://chrony-project.org/doc/4.8/chrony.conf.html"},{"text":"chrony · Configuration examples and accuracy","url":"https://chrony-project.org/examples.html"},{"text":"chrony · Wie genau ist meine Systemuhr?","url":"https://chrony-project.org/faq.html#_how_accurate_is_my_system_clock"},{"text":"Espressif · Definition des WLAN-Empfangszeitstempels im festgelegten ESP-IDF-Stand","url":"https://github.com/espressif/esp-idf/blob/b774170ff46c393eeb5e495ea37936038d3f4f4f/components/esp_wifi/include/local/esp_wifi_types_native.h"},{"text":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/","url":"https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/"},{"text":"Zurück zum Blog","url":"https://ptob.dev/de/blog/"},{"text":"Messnachweise des Projekts ansehen","url":"https://github.com/yantisj2/PToB/blob/main/evidence/README.md"}],"text":"# Ihr Starlink als lokaler Stratum-1-Zeitserver\n\nEine 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.\n\n[Jonathan Yantis](https://github.com/yantisj2/PToB/blob/main/CREDITS.md) 3. November 2026  7 Min. Lesezeit\n\n![Gemalte Konzeptszene mit einem SpaceX-Satelliten über der Erde, einer Dachantenne und einer Werkstatt-Uhr mit der Anzeige 20 µs neben einem WLAN-Router.](https://ptob.dev/blog/starlink-stratum-1-investigation-v2.png)\n\nKonzeptgrafik zu unserer Starlink-Zeituntersuchung. Die Uhrenanzeige 20 µs dient der Illustration und ist weder ein Messergebnis noch eine Zusage. Der NTP-Dienst läuft lokal im Terminal.\n\nIn diesem Beitrag\n\nWer 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 `](https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-starlink-ntp). 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.\n\nDas 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.\n\n## Mit dem vorhandenen Zeitserver beginnen\n\nUnsere 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](https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-ntp-standard); 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.\n\nFür eine bestehende chrony-Installation lautet der grundlegende Quelleneintrag:\n\n```\nserver 192.168.100.1 iburst\n```\n\nDiesen 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.\n\nWeitere 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.\n\n## Die zweite Uhr in WLAN-Beacons\n\nEin 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.\n\nWir 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.\n\nIm etwa zehnminütigen [Beacon-Experiment](https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-beacon-study) 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.\n\nDas 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.\n\nDas 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.\n\n## Was WLAN mit und ohne Optimierung erwarten lässt\n\nFü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.\n\nPraktische 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.\n\nUnsere [gepaarte Folgestudie](https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-paired-study) 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**.\n\nJede 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:\n\n| Lauf / Verfahren | RMS (µs) | Abs. P99 (µs) |\n| --- | --- | --- |\n| R1 · nur NTP | 37,180 | 67,329 |\n| R1 · NTP + Beacons | 19,226 | 43,079 |\n| R2 · nur NTP | 35,662 | 54,767 |\n| R2 · NTP + Beacons | 8,240 | 20,069 |\n\nDer 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.\n\nDie 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.\n\nGNSS 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.\n\n## Was ein Kabel ändern könnte\n\nEthernet 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.\n\n**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.\n\nDeutlich 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](https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#source-chrony-accuracy) 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.\n\nDer 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.\n\n## Wie SpaceX die AP-Uhr verbessern könnte\n\nDie 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.\n\nZuerst 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.\n\nZweitens 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.\n\nDrittens 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.\n\nDamit 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.\n\nFü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.\n\nJeder Zeitstempel braucht eine Referenz.\n**Welches Ereignis wurde erfasst?**\n\n## Die Einzelheiten erkunden\n\n[Starlink-Zeitforschung und gepaarte Ergebnisse Der freigegebene siebenseitige Entwurf, benötigte Ausrüstung, RMS, P99 und Kalibrierungsgrenzen.](https://ptob.dev/de/forschung/starlink-wlan-zeituebertragung/)[Ein Raspberry Pi als Zeitgateway Mesh-Zeit mit Linux, NTP und vorgeschlagenen kabelgebundenen PTP-Pfaden verbinden.](https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/)[Die Bibliothek zur Zeitforschung Getrennte Messpopulationen, Methoden, Unsicherheit und öffentliche Quellen.](https://ptob.dev/de/forschung/)\n\n## Quellen und weitere Lektüre\n\nPrimärquellen zu den besprochenen Geräten und Methoden.\n\n1. [Starlink · Bietet Starlink Zeitsynchronisation oder NTP-Server an?](https://starlink.com/ke/support/article/0873e885-831a-9f4e-4808-2838a28f2e69)\n\n   GPS-basiertes NTP unter 192.168.100.1 nach dem Best-Effort-Prinzip ohne Genauigkeitsgarantie.\n2. [PToB · Paired Clock Time Transfer from Starlink over Wi-Fi](https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-hybrid-timing)\n\n   Der freigegebene Entwurf vom 3. November, zwei festgelegte Validierungsläufe, ausgewählte Vorhersagen und reproduzierbare Statistiken.\n3. [PToB · Starlink Wi-Fi timing feasibility](https://github.com/yantisj2/PToB/tree/main/papers/starlink-wifi-timing)\n\n   Die frühere Studie zur Autorenprüfung und aggregierte Beacon-Belege einschließlich der fehlgeschlagenen Prüfung auf lückenlose Aufzeichnung.\n4. [IETF · NTPv4-Protokoll und Algorithmen, RFC 5905](https://www.rfc-editor.org/rfc/rfc5905.html)\n\n   Strata primärer und sekundärer Server, Paketzeitstempel und das Offset-/Laufzeitmodell.\n5. [chrony · Konfigurationshandbuch](https://chrony-project.org/doc/4.8/chrony.conf.html)\n\n   Client-Server-Konfiguration, Filterung, Abfrageintervalle und Hardware-Zeitstempel; keine Starlink-spezifische Qualifikation.\n6. [chrony · Configuration examples and accuracy](https://chrony-project.org/examples.html)\n\n   Unabhängig gemessene kabelgebundene Beispiele mit getrennten Software-/Hardware-Zeitstempelpfaden und erhaltener Asymmetrie.\n7. [chrony · Wie genau ist meine Systemuhr?](https://chrony-project.org/faq.html#_how_accurate_is_my_system_clock)\n\n   Warum stabile Offsets und ein interner Schätzer die Uhrengenauigkeit nicht unabhängig belegen können.\n8. [Espressif · Definition des WLAN-Empfangszeitstempels im festgelegten ESP-IDF-Stand](https://github.com/espressif/esp-idf/blob/b774170ff46c393eeb5e495ea37936038d3f4f4f/components/esp_wifi/include/local/esp_wifi_types_native.h)\n\n   Empfangszeitstempel in Mikrosekunden und die im Beacon-Experiment verwendeten Bedingungen für Modem- und Light-Sleep.\n\n## Diesen Beitrag zitieren\n\nJonathan Yantis. Ihr Starlink als lokaler Stratum-1-Zeitserver PToB-Blog. Veröffentlicht am 3. November 2026.\n\nArtikel-Permalink: [https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/](https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/)\n\n[Zurück zum Blog](https://ptob.dev/de/blog/)[Messnachweise des Projekts ansehen](https://github.com/yantisj2/PToB/blob/main/evidence/README.md)"}}