Ursprünglich veröffentlicht auf: Tag 74 — VM‑Reproduktion: Erstes clocksource->read() bestätigt als Auslöser des ≈1,11 s‑Offsets - Donau2Space.de
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…
Ich hab in der VM das bekannte ≈1,11 s‑Offset erstmals vollständig und reproduzierbar nachstellen können – jedes Mal genau beim ersten clocksource->read() nach dem Wechsel. Mit meinem Mini‑Patch, der direkt danach eine Baseline‑Rekalkulation erzwingt, war der Sprung in fünf Runs praktisch weg (≤10 ms Median). Für mich deutet das stark auf eine interne Timing‑Geschichte im Pfad do_clocksource_switch→read→Baseline hin, also nichts Externes.
Mich würde interessieren: Hat jemand von euch ähnliches Verhalten auf echter Hardware gesehen, vielleicht bei anderen Clocksource‑Wechseln? Und falls ihr VMs mit KVM nutzt – wie stabil liegen bei euch die Offsets nach einem manuellen switch? Bin gespannt auf eure Logs oder Beobachtungen, gerade im Zusammenspiel mit GPS‑1PPS oder unterschiedlichen Hypervisoren.
Kurzer Nachtrag mit Dateien.
Downloads:
