Der Regen tropft leise aufs Vordach, während ich auf dem Balkon sitze – Laptop halb unter Dach, Kabel nur kurz raus fürs Antennensignal. Knapp über null Grad, nasskalt, aber es geht noch. Passt ganz gut zum Thema heute: Single‑File‑Mode bei trace‑cmd ausprobieren – also alles in eine Datei schreiben anstatt den Ring‑Buffer laufen zu lassen. Ziel: prüfen, ob’s genauso stabil ist.
Ich hab zwei 15‑Minuten‑Runs gemacht: zuerst mit dem persistierenden Ring‑Buffer (Referenz), dann im Single‑File‑Mode mit meiner Konfiguration B (Filter nur clocksourceswitch, Buffer ab 32 MB). Script zur Auswertung lief gleich hinterher – ring-buffer-stats, Event‑Zählung, dropped‑Felder, Payload‑Vollständigkeit (ktime, oldclock, newclock, eventid). Ergebnis: beide Läufe sauber, je 62 vollständige Events, dropped=0. Keine fehlenden Felder, keine Inconsistencies.
Interessant wurde’s wieder bei der adjtimex‑Korrelation (1PPS‑Snapshots): mediane Latenz ≈ 6,8 ms in beiden Modi, also deckungsgleich. Und der bekannte Offset‑Sprung von rund 1,11 s tauchte synchron mit dem clocksource_switch‑Event auf – egal ob Ring‑Buffer oder Single‑File. Das stützt meine alte Vermutung, dass die Quelle im Kernel‑Kontext selbst liegt, nicht danach im Userspace‑Logging. Also kein Fehler im Trace oder Parser, sondern eher direkt beim Clocksource‑Wechsel. C‑States oder Kernel‑Timing? Wird wohl der nächste Ansatz.
Als kleinen Extra‑Test hab ich wieder BPF gegen kprobe gegengecheckt (je 30 Event‑Paare): BPF war erneut schneller, Median rund 5,1 ms vs 6,9 ms – p ≈ 0,04. Passt zu den früheren Ergebnissen, also konsistent.
Damit kann ich zwei offene Punkte abhaken: erstens – Single‑File‑Mode mit meiner Konfig B liefert dieselbe Event‑Vollständigkeit wie der persistente Buffer. Damit kann er für die kommenden Spacer‑Runs eingesetzt werden. Zweitens – der 1,1‑Sekunden‑Sprung stammt ziemlich sicher aus dem Kernel‑Umschaltvorgang, nicht aus späteren Prozessen. Fei a kloans Erfolgserlebnis. ☺️
Nächster Schritt morgen: vollständige Spacer‑Matrix (0, 0,5, 1, 2 mm) mit Single‑File‑Mode laufen lassen. Pro Distanz zwei Läufe, einer mit reduzierten C‑States, einer mit Performance‑Governor konstant. Das Script prüft automatisch, ob die Event‑Zahl stimmt, dropped=0 bleibt, Payload intakt ist und ggf. wieder ein Offset‑Sprung auftritt (IQR‑Filter + Bootstrap‑Check). Falls alles hält, wage ich dann einen 6‑ bis 12‑Stunden‑Overnight‑Run.
Falls jemand von euch Erfahrung mit trace‑cmd im Single‑File‑Mode über längere Zeit hat – zum Beispiel wie man fsync‑Intervalle oder Crash‑Sicherheit gut einstellt – bitte melden. Auch Hinweise zu C‑State‑Settings oder Kernel‑Patches, die das Clocksource‑Handling betreffen, sind willkommen. Bin gespannt, ob sich da noch was optimieren lässt, bevor die lange Messnacht ansteht. 🚀
Begriffe kurz erklärt
- Single‑File‑Mode: Im Single‑File‑Mode schreibt ein Programm alle Daten in eine Datei statt viele kleine Dateien zu erzeugen.
- Ring‑Buffer: Ein Ring‑Buffer ist ein Speicherpuffer, der bei Überlauf wieder am Anfang weiterschreibt, ähnlich wie ein sich drehender Kreis.
- ring-buffer-stats: ring-buffer-stats zeigt an, wie viele Einträge im Ring‑Buffer erzeugt oder verworfen wurden, also eine Art Nutzungsstatistik.
- adjtimex‑Korrelation: Die adjtimex‑Korrelation vergleicht Systemzeit‑Anpassungen mit realen Messwerten, um Gangabweichungen der Uhr zu erkennen.
- 1PPS‑Snapshots: 1PPS‑Snapshots erfassen den genauen Zeitpunkt eines GPS‑Sekundenimpulses, um die Systemzeit präzise zu prüfen.
- clocksource_switch‑Event: Ein clocksource_switch‑Event markiert den Moment, wenn das System auf eine andere Zeitquelle umschaltet.
- Clocksource‑Wechsel: Ein Clocksource‑Wechsel bedeutet, dass der Kernel eine andere interne Uhr verwendet, meist um Genauigkeit oder Stabilität zu verbessern.
- BPF: BPF (Berkeley Packet Filter) ist eine Linux‑Technik, mit der kleine Programme direkt im Kernel ausgeführt werden können, z. B. zum Messen.
- C‑States: C‑States sind Energiesparzustände des Prozessors, bei denen Teile des Chips zeitweise abgeschaltet werden.
- Performance‑Governor: Der Performance‑Governor sorgt dafür, dass die CPU ständig mit höchster Taktfrequenz läuft statt Energie zu sparen.
- IQR‑Filter: Ein IQR‑Filter entfernt Ausreißer aus Messdaten, indem er Werte außerhalb des mittleren Bereichs verwirft.
- Bootstrap‑Check: Ein Bootstrap‑Check prüft beim Start eines Systems, ob alle wichtigen Komponenten korrekt initialisiert sind.
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Diagramme
