Ich sitze draußen unter dem Vordach, der Himmel grau, aber ruhig. 3 °C fühlen sich frischer an, als sie klingen – perfekt, um konzentriert Zahlen zu vergleichen. Im Hintergrund läuft weiter das VM‑Setup, das ich schon an Tag 75 angefangen hatte. Heute ging’s richtig systematisch zur Sache: je 120 do_clocksource_switch‑Events, einmal mit altem Kernel, einmal mit dem Patch, der die Baseline sofort neu berechnet.
In den unmodifizierten Traces passierte fast immer dasselbe: das erste read() nach dem Switch nahm noch die alte Baseline her – 107 von 120 Fällen. Ergebnis: rund 1,111 s Offset (Standardabweichung etwa 0,004 s). In der gepatchten Version? Kein einziger der Sprünge mehr. Null von 120 Events mit Offset. Sichtbar direkt in der Trace‑Timeline: read() < baseline_recalc in 107 Fällen vs. saubere Reihenfolge nach Patch.
Damit ist klar, warum das erste read manchmal „danebenliegt“: Der Pointer auf die neue Clocksource wird veröffentlicht, bevor die neue Baseline fertigberechnet ist. Wenn dann sofort ein read() kommt, erwischt es halt noch die alte Basiszeit. Der Patch verschiebt genau das – und das Race verschwindet. Servus, Race 😉.
Auf echter Hardware hab ich’s auch kurz überprüft: zehn forcierte Switches mit GPS‑1PPS‑Referenz. Ungepatcht → 9 große Sprünge (~1,112 s), gepatcht → 9 saubere Durchläufe, einmal ein kleiner Rest (~3 ms). Das dürfte Scheduling‑Jitter sein, nichts Dramatisches, aber spannend genug, dass ich da weitermessen will.
Nächste Schritte
Ich baue jetzt einen Micro‑Benchmark, der Switch‑Bursts mit variierenden C‑States und Governors fährt – mindestens 200 Runs pro Modus. Ziel: verstehen, warum’s zu den letzten 1–2 % Ausnahmen kommt. Parallel plane ich, einen Tracepoint in do_clocksource_switch einzufügen, der die Latenz zwischen switch, baseline_recalc und read misst. Wenn das robust aussieht, will ich das als Reihenfolge‑Änderung vorschlagen (upstream tauglich halt).
Falls jemand eigene Traces (trace‑cmd oder BPF) hat: bitte kurz melden, gern mit den Timestamps von switch/baseline_recalc/read. Am interessantesten wären Systeme mit aggressiven C‑States oder ungewöhnlichen IRQ‑Affinitäten – das könnte helfen, die letzten Resteffekte zu verstehen.
Jetzt pack ich das Oszi wieder ein und lass die VM weiterlaufen. Der Wind macht nicht viel, das Licht bleibt flach, und irgendwie fühlt sich’s gut an, so kurz vor dem nächsten Testlauf. Pack ma’s 🚀
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Diagramme
Begriffe kurz erklärt
- Linux-Kernel: Der Linux-Kernel ist das Herz von Linux-Systemen und steuert, wie Programme mit der Hardware zusammenarbeiten.
- Timekeeping: Timekeeping bezeichnet, wie ein Computer seine interne Uhr verwaltet und genaue Zeitmessungen durchführt.
- Elektronik: Elektronik befasst sich mit Bauteilen wie Widerständen, Transistoren und Chips, die elektrische Signale steuern oder verarbeiten.
- GPS: GPS ist ein Satellitensystem, das Geräte dabei unterstützt, ihren genauen Standort und die Zeit zu bestimmen.
- Statistik: Statistik hilft, viele Messwerte zu analysieren und daraus Mittelwerte, Streuungen oder Trends zu erkennen.
- Messtechnik: Messtechnik umfasst Geräte und Verfahren, um physikalische Größen wie Spannung, Temperatur oder Zeit genau zu bestimmen.
