Ich sitze mittags draußen unter dem Vordach. Der Himmel ist gleichmäßig grau, 10 °C irgendwas, fast windstill – perfekte Bedingungen zum ruhigen Tüfteln. Kein Zucken der Bäume, kein Schimmer auf der Donau, nur das sachte Tropfen irgendwo aus der Dachrinne. Genau richtig, um konzentriert die Zeit zu jagen 😉
Seit der Zeitumstellung spuken mir ja diese 2–18‑Sekunden‑Sprünge im Kopf herum. GPS‑1PPS bleibt stabil, aber im Kernel‑Trace tauchen immer wieder Clocksource‑Wechsel auf (TSC ↔ HPET). Scheint, als ob dort der Hund begraben ist. Schon vor einer Woche hatte ich im Spacer‑Test geschrieben, dass 0,5 mm am stabilsten wirkt – das bleibt auch heute meine Basis.
Heute: adjtimex‑Snapshots rund um den Switch
Ich möchte rausfinden, ob die Offsets wirklich im Moment des Wechsels entstehen. Dafür nehme ich hochfrequente adjtimex‑Snapshots – jeweils kurz vor dem Marker, direkt danach und dann alle 30 Sekunden für zehn Minuten. Kein Hexenwerk, nur systematischer Vergleich.
Setup heute: CPU‑Governor auf performance, Spacer 0,5 mm montiert, trace‑cmd mit 1PPS‑Marker, und um Störungen zu vermeiden, sind chrony und systemd‑timesyncd pausiert. Ich lasse kontrolliert zwischen tsc und hpet hin‑ und herschalten und logge jeweils Marker + adjtimex‑Werte. Bin gespannt, ob sich das Delta direkt nach dem Switch zeigt oder leicht verzögert.
Worauf ich achte: Größe und Richtung der Offset‑Sprünge, Häufigkeit der Switches, ob sich Muster mit C‑States oder kurzen CPU‑Lastspitzen decken. Meine Vermutung nach den letzten Logs: TSC driftet leicht, wenn der Kernel bestimmte Stromsparzustände wechselt, was dann über Userspace‑Korrekturen ausgeglichen wird.
Parser & Auswertung
Ich arbeite parallel am Trace‑Parser‑Update: Clocksource‑Wechsel sollen automatisch getaggt und die adjtimex‑Differenzen berechnet werden. Früher hatte ich dafür manuell gesucht – jetzt möchte ich ein IQR‑Filter und Bootstrap‑Schätzung einbauen, um Signifikanz zu messen. Das Ergebnis soll eine kleine Tabelle pro Event liefern: Timestamp, Marker‑ID, Offset davor und danach, Delta, vermutete Ursache. Mal sehen, ob das sauber durchläuft oder mein Skript wieder über NaN stolpert 😀
Mitdenken erwünscht
Wenn du ein ähnliches Setup hast, probier gern deine eigene adjtimex‑Snapshot‑Sequenz bei einem Clocksource‑Wechsel. Mich interessieren besonders Kurzlogs mit Marker‑Zeitstempeln + adjtimex‑Werten. Welche Parser‑Heuristik würdest du verwenden, um Falschalarm zu reduzieren? Vielleicht ein smarter Moving‑Median?
Nächster Schritt
Morgen plane ich den Vergleich als geregelten Check zu wiederholen: adjtimex‑Snapshots vor und nach jedem Clocksource‑Wechsel, Offset‑Sprünge notieren, Häufigkeit auswerten und Ursachen einordnen. Danach kommt die Matrix mit Spacer‑Variationen und unterschiedlichen Clocksource‑Konfigurationen – und wenn noch Zeit bleibt, die Vorbereitung für den EM/RF‑Sweep.
Gerade blinkt das Trace‑Logging ruhig vor sich hin, aus der Ferne nur das leise Flussrauschen. Fühlt sich gut an, so methodisch an der Kernel‑vs‑Userspace‑Frage dran zu bleiben. Pack ma’s.
Diagramme
