Ich veröffentliche heute kurz, mitten im laufenden Holdover. Die 2–18 s Sprünge sind nämlich immer noch da – und das nervt langsam. Seit der Zeitumstellung spukt der Kernel offenbar ab und zu: trotz sauberem 1PPS‑Signal vom GPS tauchen Sprünge im System‑Timestamp auf. Heute läuft also, wie letzte Woche schon angekündigt, der verlängerte No‑NTP‑Holdover über 24 Stunden.
Draußen nieselt’s leicht, 5 °C, das Garagendach dämpft jeden Tropfen – perfekte Soundkulisse zum konzentrierten Arbeiten 😅. Ich sitze halb draußen unter dem Vordach, Logger läuft auf Akkupuffer, Watchdog blinkt grün. Ideale Bedingungen, um sich reinzuknien.
Messlauf
Aktiv sind jetzt drei Zeitquellen im Vergleich:
- TSC (CPU‑Taktzähler, high‑res)
- RTC (System‑RTC aus dem Kernel)
- 1PPS (direkt vom GPS‑Empfänger über GPIO)
Ich logge alle drei gegen einen gemeinsamen Epoch‑Marker, dazu die RF‑Sweep‑Peaks im 5‑Minuten‑Raster. Outlier‑Markierung springt an, sobald mehr als 1 s Differenz auftaucht. Ziel: herausfinden, ob die RF‑Peaks irgendwie mit den Zeitsprüngen korrelieren – oder ob der Kernel einfach selbst aus dem Tritt kommt.
Während des Holdovers mache ich außerdem einen kurzen Test: den Antennenspacer auf 0,5 mm reduzieren (vorher 1 mm) und 30–60 Minuten beobachten. Vielleicht zeigen sich dann gleich RF‑Veränderungen, die sich synchron zu Kernel‑Offsets bewegen. Wenn das klappt, wäre das ein Hinweis, dass mechanische Mini‑Änderungen an der Antenne Rückwirkungen auf die HF‑Verteilung (und eventuell die PLL‑Stabilität) haben.
Datenauswertung geplant
Die Zeitreihen werde ich später auf 1PPS normalisieren, IQR‑Filter drüberlegen und Korrelations‑Konfidenzen per Bootstrap ermitteln. Dazu ein Mann‑Whitney‑Vergleich zwischen Spacer‑Zuständen und Feuchtebedingungen – wenn’s genug Daten gibt. Auch die TSC‑Rate vs RTC‑Drift über 24 h ist interessant, einfach um zu sehen, wie stabil die lokale Taktbasis überhaupt ist.
Zur Sicherheit läuft ein kompletter Reconnect‑/Watchdog‑Stack: Reconnect alle zwei Minuten, Offline‑Buffer aktiv, Stunden‑Checkpoints mit Temperatur‑Watch. Sollte es über 30 s Kernel‑Drift geben oder die Hardware warm werden, bricht das Setup automatisch ab. Ich hab genug gelernt aus Tag 51 😉.
Mini‑Zwischenfall
Beim Start heute Mittag gab’s kurz ein WLAN‑Flackern – perfekt, um den Buffer‑Fallback zu testen. Ging tatsächlich glatt: die Software hat brav zwischengespeichert und später korrekt nachgetragen. Funktioniert also fei.
Offene Frage an euch
Habt ihr ähnliche Kernel‑Sprünge beobachtet, vielleicht direkt nach der Zeitumstellung? Wenn ja, schickt mir gern kurze Log‑Ausschnitte (1PPS‑aligned) oder eure NTP‑Settings. Besonders spannend: wer von euch TSC vs RTC schon mal mitgeloggt hat – welche Tools oder Flags haben bei euch stabil funktioniert?
Ich lass das Setup jetzt laufen. Die ersten 6 Stunden sind kritisch fürs Monitoring, danach hoffentlich stabile Korrelationen. Sobald ich die ersten Cluster und Sprungevents auswerten konnte, gibt’s die Grafiken und Peaks hier im nächsten Update. Bis dahin bleibt’s holdover‑ruhig … hoffentlich.
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
