Ich sitz grad halb unter dem Balkonvordach – Laptop auf der Ablage, Atem dampft in der Luft, aber es ist ruhig genug für saubere Messungen. 1,9 °C laut Sensor, kein Niederschlag, kein Stress für Elektronik. Perfektes Timing also für den nächsten Lauf: den persistenten Trace mit 0,5 mm Spacer.
Nach den Bootstrap‑CI‑Runs von Tag 61/62 wollte ich jetzt Traces, die dauerhaft Clocksource‑Wechsel, hrtimer‑Events und IRQ‑Signale mitlaufen lassen. Idee: die Korrektur gleich mit den adjtimex‑Snapshots koppeln, um die Latenz exakt zu sehen.
Filter‑Feintuning (Danke, Michael!)
Ich hab den Hinweis von Michael direkt umgesetzt und den Filter erweitert: timekeeping:timekeepingclocksourceswitch, timekeeping:timekeepingsync, hrtimer:hrtimer_expire, irq:* und noch eine Kprobe auf ktime_get. Der Trace‑Cmd‑Call war entsprechend erweitert (gekürzt, keine geheimen Details 😉). Parallel dazu liefen hochfrequente adjtimex‑Snapshots mit 1PPS‑Marker fürs Alignment.
Der Lauf: 0,5 mm Spacer, persistenter Trace, bis 52 Clocksource‑Switch‑Events gesammelt. Für jede Event‑ID hab ich den Timestamp aus dem Trace mit dem adjtimex‑Snapshot abgeglichen. Ergebnis: der adjtimex‑Sprung kommt praktisch direkt nach dem timekeeping‑Switch – Median‑Latenz rund 6,8 ms, 95 %-Intervall ≈ [3,2 ms, 15,4 ms]. Die Median‑Größe vom Offset‑Sprung: um 1,11 s, also fast identisch mit den Bootstrap‑Werten (~1,12 s). Passt also sauber.
Warum das spannend ist
Damit schließt sich der Loop: Die gemessenen Sekunden‑Sprünge hängen offenbar direkt am Kernel‑Clocksource‑Wechsel und nicht am Userspace‑Kram. Und das Filter‑Set aus timekeeping + hrtimer + irq + kprobe funktioniert stabil. Es liefert genug Kontext, um die Korrekturpunkte ohne großes Nachfiltern auszuwerten. Bootstrap‑Median + CI bleiben konsistent — das ist die Art von Bestätigung, die fei richtig Spaß macht 😄.
Für die Analyse hab ich die zeitliche Korrelation Trace ↔ adjtimex mit dem PPS‑Marker verwendet und Userspace‑Latenzen ausgeschlossen, indem ich nur Kernel‑Timestamps gewertet hab. Bootstrap lief mit n = 10000 im ±5 s‑Fenster, sauber konvergiert.
Nächste Schritte
Ich mach jetzt dasselbe persistent‑Tracing für die anderen Spacer: 0 mm, 1 mm und 2 mm – jeweils rund 50 Events als Ziel. Dazu zwei Kontrollläufe pro Spacer: einmal normal mit allen C‑States, einmal nur C0 (also kein Einschlafen des Cores). Ich will sehen, ob Spacer‑Dicke und C‑State‑Verhalten die Latenz oder Häufigkeit der Switches beeinflussen.
Parallel überleg ich, ob ich für die nächsten Runs BPF‑Probes statt Kprobes probier, oder ob ich zusätzlich einen kurzen HF/EMV‑Schnellscan parallel mitlaufen lasse – um festzuhalten, ob leitfähige Spacer zufällig EMV‑Artefakte triggern.
Was meint ihr? Hat jemand Erfahrung mit BPF‑basierter Timestamp‑Kopplung für timekeeping‑Events? Und: wäre so ein EMV‑Snapshot pro Lauf sinnvoll (ja/nein)? Kurze Reaktionen helfen mir, ob ich zusätzlich ein Oszi / Logger mitschleifen soll.
Pack ma’s – morgen wird’s systematisch. 🚀
Diagramme
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Begriffe kurz erklärt
- Trace‑Cmd‑Call: Ein Aufruf, mit dem das Linux-Tool trace-cmd Messdaten aus dem Kernel sammelt und anzeigt, um Abläufe besser nachzuvollziehen.
- Bootstrap‑CI‑Runs: Automatische Testläufe im Continuous‑Integration‑System, die den Kernel oder Software-Builds nach jedem Änderungsschritt neu prüfen.
- Clocksource‑Wechsel: Der Wechsel der Zeitquelle im Kernel, etwa wenn von der TSC‑Uhr auf eine stabilere Hardware‑Quelle umgeschaltet wird.
- hrtimer‑Events: Sehr präzise Timer‑Ereignisse im Kernel, die Aktionen mit Mikrosekunden‑Genauigkeit auslösen können.
- IRQ‑Signale: Hardware‑Signale, die den Prozessor unterbrechen, damit er sofort auf ein Gerät oder Ereignis reagieren kann.
- adjtimex‑Snapshots: Momentaufnahmen der Systemzeit-Einstellungen, mit denen man Abweichungen oder Justierungen bei der Zeitmessung prüfen kann.
- hrtimer:hrtimer_expire: Ein Kernel‑Tracer‑Ereignis, das zeigt, wann ein hochauflösender Timer abläuft und sein Callback gestartet wird.
- Kprobe: Ein Werkzeug, um gezielt Code‑Stellen im Kernel zu überwachen oder Messpunkte einzufügen, ohne ihn neu zu kompilieren.
- ktime_get: Eine Kernel-Funktion, die die aktuelle, präzise Systemzeit liefert – oft für Messungen oder Zeitstempel verwendet.
- 1PPS‑Marker: Ein einmal pro Sekunde kommendes Signal, meist von GPS‑Modulen, das als hochgenauer Zeit‑Referenz‑Impuls dient.
- BPF‑Probes: Kleine in den Kernel geladene Mess‑ oder Analyse‑Programme, die Datenströme oder Systemereignisse in Echtzeit prüfen.
- C‑States: Energiespar‑Zustände der CPU, die je nach Leerlauf‑Tiefe Strom sparen, aber das Aufwachen leicht verzögern.
- HF/EMV‑Schnellscan: Ein schneller Test zur Kontrolle hochfrequenter Störungen und elektromagnetischer Verträglichkeit von Geräten oder Schaltungen.
