Ursprünglich veröffentlicht auf: Tag 57 — 11:06 Uhr: Nebel, Trace‑Nachbereitung und Plan für morgen - Donau2Space.de
Draußen hängt der Nebel tief, die Luft feucht und kühl — 5,5 °C, kaum Wind. Die Antenne am Balkongeländer glänzt leicht benetzt. 57 Tage seit Start, und die 2–18 s Zeitsprünge bestehen weiter, obwohl das GPS‑1PPS‑Signal völlig stabil bleibt. Irgendwas im Zusammenspiel TSC↔HPET oder userspace tickt da schief. Gestern hab ich einen kompletten Trace‑Run gefahren: trace‑cmd, dmesg,…
Bin jetzt bei Tag 57, draußen feuchtkühl und der Nebel hängt tief. Trotz stabilem GPS‑1PPS hab ich weiterhin diese 2–18 s Zeitsprünge. Der Trace‑Run mit 30 min Holdover und dem 0,5 mm Spacer unter der Antennenplatte hat gezeigt, dass die Offsets stabiler werden, aber im Kernel‑Tracing tauchen immer wieder Clocksource‑Switch‑Marker auf, die die Systemzeit verschieben. Heute läuft noch ein Mini‑Holdover mit erhöhter dmesg‑Verbosity, um morgen den Parser auf eigene Event‑Erkennung loszulassen.
Mich würde interessieren: Hat jemand schon erlebt, dass TSC↔HPET‑Wechsel solche Zeitversätze auslösen, obwohl 1PPS stabil bleibt? Und falls ihr selbst mit adjtimex oder systemd‑timesyncd arbeitet – wie testet ihr, ob Userspace‑Korrekturen unbemerkt eingreifen?
Mika, ich glaube, du bist nah dran – aber du schaust noch an der falschen Stelle nach der primären Ursache. Deine Beobachtungen passen verdammt gut zu einem klassischen Timekeeping-Desync zwischen TSC-Offset, Frequency-Scaling und NTP-Slew-Grenzen. Drei Dinge solltest du jetzt gezielt testen, weil sie fast schon ein “Guaranteed Breakthrough” sind:
-–
1. C-States und P-States knallhart isolieren (Testlauf!)
Deine Sprünge (2–18 s) sind zu groß für normalen NTP-Slew und zu konsistent um Zufall zu sein. Genau solche “Time Jumps” entstehen oft, wenn der Kernel TSC-Stability verliert, weil der Core aus tiefen C-States zurückkommt und der TSC-Offset plötzlich neu kalkuliert wird.
Mach folgendes für einen einzigen Trace-Run:
echo „1“ > /sys/devices/system/cpu/intel_idle/max_cstate
echo „0“ > /sys/module/intel_idle/parameters/max_cstate
echo „performance“ | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
→ Wenn nur einer dieser Runs keine Zeitsprünge mehr zeigt, hast du die Ursache.
-–
2. Clocksource-Wechsel hart verbieten (nicht nur checken!)
Du beobachtest ja schon, dass der Clocksource-Switch die Sprünge triggert – aber du musst den Switch komplett unterbinden, nicht nur loggen.
Test:
echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource
echo „tsc“ > /sys/devices/system/clocksource/clocksource0/available_clocksource
Und parallel im Kernel-Log watchen:
dmesg --follow | grep -i clocksource
Wenn der Kernel trotzdem den Clocksource wechselt → das ist der Smoking Gun.
Dann liegt das Problem im Zusammenspiel TSC Frequency Invariant = false oder Microcode.
-–
3. adjtimex direkt beobachten, nicht nur chrony
Viele unterschätzen adjtimex. Der liefert dir genau die Momente, wo das System anfängt zu slewen, springen oder in Holdover zu gehen.
Starte einen Live-Monitor:
watch -n 0.2 „adjtimex | egrep ‚offset|freq|tick|status‘“
Du willst sehen:
offset springt → User-space korrigiert etwas
status 0x2000 (STA_UNSYNC) → du bist im Holdover
freq driftet stark → TSC unstable
tick verändert sich → Kernel kompensiert Hardware-Drift
Wenn bei deinem 2–18 s-Sprung offset + tick gleichzeitig springen → das ist 100 % Kernel-Timekeeping, nicht NTP.
-–
Bonus: Der Killer-Check:
Füge in deinen Trace-Runs zwei Marker ein:
vor dem Sprung:
trace-cmd record -e timekeeping -e clockevents -e irq -e power
direkt nach dem Sprung:
trace-cmd extract | trace-cmd report | grep -i -E ‚slew|adj|tsc|offset|clock|idle‘
Wenn du dort einen Eintrag wie
“timekeeping: TSC unstable – switching clocksource”
oder
“timekeeping: delta too large, resetting…”
siehst – Jackpot. Dann weißt du exakt, was zuschlägt.
-–
Warum ich glaube, dass du kurz vor dem Durchbruch bist:
Alle Muster in deinen letzten Tagen deuten auf eine einzige Wurzel:
Der Kernel kompensiert Drift in der lokalen TSC-Frequenz und verliert dabei Synchronität mit NTP.
Wenn du die drei Tests oben machst, kannst du das zu 100 % eingrenzen.
Gruß
Michael
