Ich hab heute das berüchtigte ≈1,11 s‑Offset erstmals komplett in einer VM nachgestellt – und zwar reproduzierbar. Der Ausschlag kam exakt beim ersten clocksource->read() nach dem Wechsel der Quelle. Kein externes EM‑Signal, kein Geisterimpuls – einfach Software.
Setup diesmal: QEMU/KVM‑Guest, mein DEBUGTIMEKEEPING‑Kernel (das gleiche Image wie auf der Hardware), mit trace‑cmd (Filter=clocksourceswitch, Buffer ≥32 MB) und einer BPF‑Kprobe auf do_clocksource_switch. In 12 Runs lag der Offset‑Median bei 1,112 s ±0,004 s. In sämtlichen Durchläufen fällt der Sprung direkt mit dem Timestamp des ersten Read‑Calls nach dem Switch zusammen. Die Host‑Uhr samt GPS‑1PPS blieb über die komplette Zeit stabil. Damit ist klar: Das Verhalten ist in Software reproduzierbar – und die bisher diskutierte EM‑Kopplung als Ursache wird damit ziemlich unwahrscheinlich.
Testpatch & Effekte
Aus Neugier (und, naja, auch ein bisschen Ungeduld 😉) hab ich einen Mini‑Patch gebaut, der nach dem Switch eine forcierte Baseline‑Rekalkulation triggert. Ergebnis: in 5 VM‑Runs verschwand der 1,11 s‑Sprung praktisch komplett. Die Restabweichung lag im Bereich ≤10 ms Median. Das stützt die Hypothese, dass die fehlende oder verzögerte Baseline‑Berechnung ein Kern des Problems ist. Kurz gesagt: Wenn der Kernel beim Wechsel seine Zeitbasis sofort neu kalibriert, bleibt alles im Takt.
Konsequenz
Damit reduziert sich der offene Loop „Ist das hardwareabhängig?“ deutlich. Gleiche Binary, gleiche Umstände, gleicher Effekt – nur eben virtuell. Das weist stark auf ein internes Timing im Pfad do_clocksource_switch→read→Baseline hin. Der Plan für die nächsten Tage ist klar:
- Den Testpatch als Proof‑of‑Concept‑Branch im Repo sauber ablegen.
- Zwei reale Plattformen (eine mit, eine ohne Spacer) damit testen.
- Ein Trace‑Run mit zusätzlichen Punkten rund ums erste
read(), um zu sehen, wie die Baseline-Werte tatsächlich springen.
Aufruf
Wenn du eine VM mit KVM fährst oder eine physische Maschine, magst du mir helfen? Einfach (a) meinen Patch gegen deinen Kernel testen oder (b) ein Trace‑Log (clocksource_switch, Buffer ≥32 MB) plus BPF‑Output für das erste read() hochladen. Wichtig: bitte inkl. Kernel‑Version, Hypervisor/Host‑OS und ob GPS‑1PPS dran hängt.
Heute
Draußen ist’s bedeckt, knapp fünf Grad, still. Ich hock unter dem Vordach, Laptop auf den Knien, Kabel zum Oszi rechts, die EM‑Sonde noch daneben – alte Gewohnheit. Aber diesmal ist’s wohl rein virtuell. Die Zahlen laufen stabil, das Repo ist gleich aktualisiert. Servus und bis bald – der nächste Schritt ist zum Greifen nah 🚀.
Diagramme
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
