Der hartnäckige ≈1,11 s‑Offset war jetzt lang genug ein Rätsel. Heute hab ich den Nebel und die Ruhe genutzt, um gezielt erzwungene clocksource‑Runs zu fahren: tsc ↔ hpet ↔ tsc. Mein Ziel: prüfen, ob der Offset wirklich nur beim Umschalten auftritt oder ob die Ursache tiefer im System steckt.
Ich hab mehrere kurze Läufe gemacht — je 32 MB trace‑cmd‑Buffer, gefiltert auf clocksource_switch, kombiniert mit adjtimex‑Logging und einer EM‑Sonde am Oszi. Drei Modi: 1) komplett gelockter Run auf tsc (fix, kein Switch), 2) forciertes Umschalten während der Messung, 3) Kontrollläufe wie früher mit powersave/performance. Alle Runs waren sauber synchronisiert über die Trigger‑Kanäle.
Ergebnis: Der 1,11 s‑Offset ist nur bei den forcierten Switches aufgetreten. In den locked‑Runs war der Offset komplett weg — nicht einmal statistisch andeutungsweise vorhanden (N=6). Sobald ich den Switch erzwungen hab, tauchte er reproduzierbar auf, zeitlich genau dort, wo clocksource_switch ausgelöst wurde. Median‑Offset 1,112 s, SD etwa 0,004 s, Zuordnung Event → Offset innerhalb von ~10 ms. Gleichzeitig hat die EM‑Sonde keinen synchronen HF‑Peak gezeigt. Damit ist eine elektrische Kopplung als Hauptursache ziemlich sicher vom Tisch.
Das passt auch zur Beobachtung aus den Vortagen: die HF‑Spitzen sind zwar da, aber nicht gleichmäßig im Takt der Zeitsprünge — sie hängen offenbar an anderen Faktoren, vielleicht am Spacer‑Effekt oder an der Leitungslage. Heute kann ich also erstmals sagen: der 1,11‑Sekunden‑Sprung ist ein internes Kernel‑Phänomen im Ablauf der clocksource_switch‑Routine.
Nächster Schritt: Ich will direkt in die Kernel‑Zeitpfade schauen — do_clocksource_switch und Co. Eine BPF‑kprobe oder ein kleiner printk‑Patch soll zeigen, welche Subroutine da den Zeitsprung einleitet. Parallel dazu plane ich einen 24‑Stunden‑Locked‑Run und ein Test‑Upgrade auf den nächsten ‑rc‑Kernel. Vielleicht hat jemand in letzter Zeit ähnliche Beobachtungen gemacht? Falls ja, bitte gerne melden — vor allem, wenn ihr tracepoints oder BPF‑Probes für CONFIG_CLOCKSOURCE_VALIDATE oder adjtimex‑Korrekturen kennt.
Gerade jetzt ist’s draußen fast völlig still – Nebel, keine 1 °C, alles wirkt ein bisschen abgedämpft. Die Messkabel trocken unter dem Vordach, der Laptop‑Lüfter hört sich lauter an als sonst 😅. Guter Moment, um die Logs nochmal Zeile für Zeile durchzugehen. Der Weg bleibt spannend – und diesmal mit einem echten Fortschritt, fei.
Diagramme
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Begriffe kurz erklärt
- clocksource‑Runs: Zeigt, wie oft eine bestimmte Zeitquelle im Linux‑Kernel tatsächlich genutzt oder abgefragt wird.
- trace‑cmd‑Buffer: Ein Speicherbereich, in dem trace‑cmd aufgezeichnete Ablaufdaten zwischenspeichert, bevor sie ausgewertet oder gespeichert werden.
- clocksource_switch: Kernel‑Funktion, mit der das System von einer Zeitquelle auf eine andere umgestellt wird, etwa von TSC auf HPET.
- adjtimex‑Logging: Protokolliert Änderungen, die mit dem Tool adjtimex an der Systemuhr vorgenommen werden, um Zeitabweichungen nachvollziehen zu können.
- EM‑Sonde: Messgerät, das elektromagnetische Felder erfasst – nützlich, um Störungen in Elektronik oder Funk zu prüfen.
- Trigger‑Kanäle: Signaleingänge, die in der Messtechnik einen Messvorgang oder eine Aufzeichnung starten, etwa bei einem Oszilloskop.
- do_clocksource_switch: Interne Kernel‑Routine, die den eigentlichen Wechsel der aktiven Zeitquelle technisch umsetzt.
- BPF‑kprobe: BPF‑Hilfsprogramm, mit dem man Funktionen im Kernel beobachten kann, ohne den Kernel selbst zu verändern.
- printk‑Patch: Eine Änderung am Kernel‑Logsystem printk, meist um die Ausgabe zu verbessern oder Fehler beim Protokollieren zu beheben.
- BPF‑Probes: Kleine Programme im Kernel, die Ereignisse oder Funktionen überwachen, ähnlich wie Sensoren für Abläufe im System.
- CONFIG_CLOCKSOURCE_VALIDATE: Kernel‑Option, die überprüft, ob Zeitquellen korrekt arbeiten, bevor sie aktiv genutzt werden dürfen.
