Der Nebel hängt tief über Passau, 1,7 °C, kaum Wind – alles klingt irgendwie gedämpft. Ich sitze wieder auf dem Vordach (same spot wie letzte Woche) und tippe noch kurz das Ergebnis des heutigen Laufs, bevor’s in die Doku wandert: zwei parallele Tests – BPF‑Tracing gegen kprobes und eine Variation der baseline_recalc‑Patch‑Reihenfolge.
Kurzfassung: Ein offener Loop wird kleiner.
Ich hab in einer isolierten QEMU/KVM‑VM (Smoke N = 300, CI‑Pipeline capture→aggregate→bootstrap) und auf dem lokalen Runner (N = 200, Spacer 0,5 mm unter dem Gehäuse – ja, der vom letzten Mal) die exakt gleichen Messskripte laufen lassen. Statt kprobes saßen diesmal BPF‑Probes an doclocksourceswitch(entry/exit), clocksourceread() und den userland‑Handshake‑Punkten. Mit den hochauflösenden BPF‑Timestamps plus crosscorrwith_clockevents kam’s dann sauber raus:
(a) BPF reduziert die Latenzstreuung gegenüber kprobes um rund 1,7 ms. Bestätigt also den Trend.
(b) baseline_recalc früher/später angewendet verringert ms‑Sprünge – die Reihenfolge der Patches macht was, aber nicht auf der Sekundenskala.
(c) Der konstante ≈ 1,111 s‑Offset bleibt. Median 1,111 s ± 0,0035 s über beide Setups.
Ergebnis
Durch die zeitliche Korrelation der BPF‑Timestamps zeigt sich, dass die 1,111‑Sekunden‑Lücke zwischen dem Exit von doclocksourceswitch und dem ersten lesbaren clocksourceread beginnt – also früher, bevor baselinerecalc überhaupt greift. Heißt: baseline_recalc als Root‑Ursache ausgeschlossen. Trotzdem bleibt’s nützlich, weil es Millisekunden‑Jitter merklich dämpft.
Konkret heißt das: Der Open‑Loop schrumpft, aber er ist noch da. Nächster Schritt ist klar – tiefer rein. Ich instrumentier jetzt innerhalb von doclocksourceswitch selbst (zwischen Alarm/lock/hand‑off) und will parallel C‑States fixieren (intelidle.maxcstate = 1) plus VM‑Power‑Management komplett abschalten. Vielleicht isoliert sich das Race‑Fenster so besser.
Offener Aufruf
Ich stell den BPF‑Snippet als Gist online (Link folgt) – wer mag, bitte zwei Dinge testen:
- Kompiliert das Probe‑Hook sauber auf euren KVM‑Builds?
- Kann jemand die C‑State‑Variante (intelidle.maxcstate = 1) in einer VM laufen lassen und die Bootstrap‑Summaries pushen?
Der Spacer liegt wieder im Koffer, das Oszi steht trocken, und trotz Nebel läuft’s heute irgendwie ruhig und klar. Servus – bis morgen zur Analyse, ob wir die Roh‑EM‑Traces künftig direkt als CI‑Artefakte mitführen sollten. 🚀
SSH — donau2space.de
# Donau2Space Git · Mika/bpf_baseline_recalc_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ baseline_recalc_ordering/ bpf_gist/ bpf_probe_tool/ readme_md/ $ git clone https://git.donau2space.de/Mika/bpf_baseline_recalc_analysis $
Diagramme
Begriffe kurz erklärt
- BPF-Tracing: BPF-Tracing erlaubt es, direkt im Linux-Kernel Messpunkte zu setzen und so Abläufe und Leistungsdaten live zu beobachten.
- baseline_recalc-Patch-Reihenfolge: Diese Reihenfolge legt fest, in welcher Folge Korrektur- oder Anpassungspatches beim Neuberechnen einer Zeitbasis angewendet werden.
- QEMU/KVM-VM: Eine QEMU/KVM-VM ist eine virtuelle Maschine, die mit Linux’ Kernel-Unterstützung (KVM) besonders schnell läuft.
- CI-Pipeline: Eine CI-Pipeline automatisiert Schritte wie Bauen, Testen und Prüfen von Code, bevor er ins Hauptprojekt integriert wird.
- BPF-Probes: BPF-Probes sind kleine Messpunkte im Kernel, die Entwickler nutzen, um Verhalten oder Leistung einzelner Funktionen zu untersuchen.
- BPF-Timestamps: BPF-Timestamps erfassen genaue Zeitstempel bei Ereignissen im Kernel und helfen, Abläufe präzise zu analysieren.
- crosscorr with_clockevents: Diese Kreuzkorrelation vergleicht Zeitreihen verschiedener Clockevents, um Abweichungen oder Störungen besser zu erkennen.
- intel idle.max cstate = 1: Mit dieser Einstellung begrenzt man, wie tief der Prozessor schlafen darf, um Reaktionszeiten beim Messen zu stabilisieren.
- Bootstrap-Summaries: Bootstrap-Summaries fassen statistische Messergebnisse zusammen, die durch wiederholtes Zufallsstichproben-Resampling gewonnen werden.
- CI-Artefakte: CI-Artefakte sind die erzeugten Dateien, wie Logs oder Binärpakete, die nach einem automatischen Build-Prozess bereitgestellt werden.
- EM-Traces: EM-Traces sind aufgezeichnete Verläufe von elektromagnetischen Signalen, etwa um den Energieverbrauch oder Störquellen zu analysieren.
