Seit der Zeitumstellung spuken mir wieder 2–18‑Sekunden‑Zeitsprünge ins System. GPS‑1PPS läuft stabil, keinerlei Drift – aber die Systemuhr entscheidet spontan, dass jetzt halt später ist. Heute will ich einkreisen, ob das tief im Kernel passiert oder irgendwo im User‑Space nachzieht.
Ich sitze unter dem Vordach; es ist bedeckt, die Luft leicht feucht, aber ruhig genug, um Oszi und Logger draußen zu lassen. Die Feuchte‑Logs laufen nebenher, so bleibt die Elektronik trocken. Ruhige Nachmittage sind perfekt, um Kernel‑Traces laufen zu lassen, ganz ohne Hektik.
Hypothesen über die Sprünge
Am wahrscheinlichsten: Clocksource‑Wechsel nach der Zeitumstellung (TSC ↔ HPET), oder C‑State‑Einflüsse, die den TSC entkoppeln. Alternativ: adjtimex bzw. systemd‑timesyncd, die nach der Umstellung zu früh ins Geschehen greifen. Der Sprung könnte aber auch direkt beim Apply einer TZ‑Änderung stattfinden – also ein simples Race zwischen slew und step. Klingt trivial, ist es meistens nicht.
Ich priorisiere heute:
- dmesg / journalctl – ob clocksource/clockevent‑Meldungen oder Kernel‑Warnings etwas sagen.
- timesync‑Logs (chrony, systemd‑timesyncd) – wer schubst zuerst?
- kernel‑tracepoints rund um
clock_set_timeundtimekeeping_adjust. - /sys/devices/system/clocksource – welcher Taktgeber zählt tatsächlich.
- TSC vs. RTC Snapshots aus meinem Logger – diesmal 1PPS‑synchronisiert.
- audit/udev – ob bei CPU‑C‑State‑Änderungen was auffällt.
- Und als Kontrolle: RF‑Sweep, obwohl bisher kein signifikanter Peak zu sehen war.
Kurzplan für den Nachmittag
Ich lasse gleich einen kurzen Trace laufen – trace-cmd auf den relevanten Punkten, parallel offene dmesg‑Ausgabe und periodisches adjtimex -p. Dann 30 Minuten Holdover ohne NTP, aber mit laufender IQR‑Maskierung. Ich will sehen, ob der Sprung im Kernel selbst entsteht oder erst, wenn das Userspace‑Tool eingreift. Wenn der Trace nichts hergibt, steht als Nächstes ein Kernel‑Build mit DEBUG_TIMEKEEPING an und ein VM‑Testlauf zur Reproduktion.
Nebenbei noch ein EM‑Precheck: Antenne in drei Spacer‑Positionen (0/0,5/1 mm) toggeln und RF‑Sweep mitschreiben. Beim letzten Versuch (Tag 47) war der Unterschied erstaunlich gering – vielleicht bestätigt sich das.
Frage in die Runde
Falls jemand ähnliche Zeitsprünge nach der Zeitumstellung gesehen hat – welche Logquelle hat euch zuerst weitergebracht? dmesg, chrony oder gleich das Kernel‑Tracing? Mich interessiert vor allem, ob der Fehlschluss zwischen UTC und lokaler TZ häufiger in den Logs landet, als man denkt.
Ich melde mich gegen 15:38 Uhr mit einer kurzen Statusnote, sobald der 30‑Minuten‑Holdover durch ist. Bis dahin läuft der Trace leise vor sich hin. Servus, pack ma’s. 🚀
