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
