Steh grad auf dem Balkon, Laptop halb unter dem Vordach. Wolken hängen tief über Passau, -4 °C, kaum Wind. Man spürt richtig, wie die Luft alles klirrend klar macht – ideal, um endlich den offenen Loop mit trace‑cmd zu schließen.
Heute ging’s darum herauszufinden, welche Kombination aus Filter und Buffer‑Größe clocksource_switch‑Events wirklich vollständig mitschreibt. Ich hatte schon länger den Verdacht, dass meine bisherigen Messungen Drops produziert haben – besonders, wenn ich mehrere Event‑Typen gleichzeitig logge. Also zwei Setups gebaut und sequenziell laufen lassen.
Konfiguration A — breit gefiltert, kleiner Buffer
Kurz gefasst: trace-cmd record -e clocksource_switch -e timer_event --buffer-size=8M -o traceA.dat.
Laufzeit: 15 min, dabei gezielter Clocksource‑Switch (TSC↔HPET über Kernel‑Optionen). Erwartet waren etwa 60 Events. Ergebnis: 7 Verluste laut ringbufferstats, 5 inkonsistente Payloads im Extract (fehlende ktimegetns‑Einträge und Gaps in der Zeitreihe).
Das war fei deutlich sicht- und messbar: Die Payload‑Felder hatten mitten im Run plötzlich Lücken, was später jede Auswertung schief zieht.
Konfiguration B — schmaler Filter, größerer Buffer
Dann trace-cmd record -e clocksource_switch --buffer-size=32M -o traceB.dat — also gezielt nur die clocksource_switch‑Events und mehr Luft im Buffer.
Wieder 15 min mit denselben Bedingungen. Ergebnis: 62 vollständige Events (± Messrauschen), kein einziger Drop im ringbufferstat, vollständige Payloads inklusive DEBUG_TIMEKEEPING‑Felder und adjtimex‑Snapshots. Genau so soll’s aussehen.
Fazit & nächster Schritt
Unterm Strich lässt sich der offene Punkt jetzt schließen: Ein schmaler Filter und ein Buffer ≥ 32 MB machen das Logging bei diesen Event‑Bursts stabil. Die breitere Kombination mit nur 8 MB ist dagegen unzuverlässig. Für meine nächste Spacer‑Matrix‑Serie (0 / 0,5 / 1 / 2 mm, jeweils C‑State ON/OFF) kommt also Konfiguration B standardmäßig rein. Damit fällt eine Störquelle in der Messunsicherheit weg.
Demnächst will ich noch prüfen, ob sich das Verhalten beim Umschalten zwischen persistentem Ring und Single‑File‑Mode ändert. Falls jemand dazu eigene Erfahrung hat – etwa Grenzen, bei denen der Buffer trotz großer Größe überläuft – gebt gern Bescheid. Mich interessiert besonders, ob jemand minimalistische Filterausdrücke nutzt, die aber trotzdem alle relevanten Felder beibehalten.
Der Himmel ist noch genauso grau wie vorhin, aber innerlich ist’s grad hell: Drop‑Problem gelöst. Pack ma’s mit den Spacer‑Runs nächste Woche richtig an 🚀
Diagramme
Begriffe kurz erklärt
- trace-cmd: Ein Linux-Werkzeug, mit dem man Kernel-Abläufe aufzeichnen und später analysieren kann – wie eine Blackbox für den Systemkern.
- clocksource_switch: Ein Wechsel der Zeitquelle im Kernel, zum Beispiel von einer schnellen CPU-Zeitquelle zu einer stabileren Hardware-Uhr.
- timer_event: Ein Ereignis im System, das zu einem bestimmten Zeitpunkt ausgelöst wird, etwa um eine Aufgabe regelmäßig zu starten.
- Clocksource‑Switch: Bedeutet, dass der Kernel von einer Zeitquelle auf eine andere umschaltet, meist um genauere oder stabilere Takte zu bekommen.
- TSC↔HPET: Beschreibt den Wechsel zwischen zwei Zeitquellen: TSC (CPU‑Taktzähler) und HPET (präziser Hardware‑Timer).
- Kernel‑Optionen: Einstellungen, mit denen man beim Kernelstart bestimmte Funktionen aktiviert oder abschaltet, ähnlich wie Schalter im BIOS.
- DEBUG_TIMEKEEPING‑Felder: Interne Datenfelder, die Entwicklern helfen, Zeitmess‑ und Synchronisationsfehler im Kernel genauer zu untersuchen.
- adjtimex‑Snapshots: Aufnahmen des Kernel‑Zeitabgleichs, um zu sehen, wie sich Systemzeit und Referenzzeit (z. B. GPS) zueinander verändern.
- C‑State: Zustände, in denen eine CPU Energie spart; je tiefer der C‑State, desto weniger Stromverbrauch, aber längere Aufwachzeit.
- Single‑File‑Mode: Ein Modus, bei dem alle Ausgabedaten in genau eine einzige Datei geschrieben werden, statt sie zu verteilen.
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
