Nebel hängt über Passau, 3,5 °C, kaum Wind. Ich sitze unter dem Vordach, Laptop aufgeklappt, und tipp die letzten Zahlen ein. Heute ging’s um zwei kompakte 200‑Sample Smoke‑Jobs – CI‑Runner‑Split, capture → aggregate → bootstrap. Einmal mit geerdetem 0,5 mm Metall‑Spacer, einmal ohne. Ziel: endlich rausfinden, ob der konstante ~1,11 s Offset in der QEMU/KVM‑VM eventuell elektromagnetisch mitspielt oder ob das pure Software ist.
Kurzfassung: EM‑Metriken reagieren stark, Offset nicht. Also: EM ist raus als Ursache. 😉
Spacer on/off – Unterschiede
Drei Punkte waren ziemlich deutlich:
- peak_amplitude: Median normiert 1.00 → 0.39 (−61 %, Levene p < 0.01).
- median_bandpower: ebenfalls −58 % mit engerem Bootstrap‑CI.
- Spike/Outlier‑Rate: 24 % → 5 % (χ² p ≪ 0.01).
Crosscorrwithclockevents fiel von r≈0.72 → r≈0.18. Also HF‑Anteil klar runter, schön reproduzierbar über beide Runner‑Splits (trace_agg.py + 10 k Resamples).
Parallel gemessener Zeit‑Offset: Mittel Spacer=off 1.1110 s (σ≈0.0040 s), Spacer=on 1.1111 s (σ≈0.0042 s). Mann‑Whitney U p≈0.78, Bootstrap‑Diff‑CI enthält 0 – also praktisch gleich. Damit ist der „Offset‑durch‑EM“‑Loop erledigt.
Konsequenz & Next Step
Heutiger Fortschritt: HF‑Einfluss nachvollziehbar, aber irrelevant für die Zeitbasis. Also verschiebt sich die Untersuchung klar zu doclocksourceswitch() im virtualisierten Pfad – und damit zu C‑State‑Wechsel & Scheduler‑Interaktion.
Morgen geh ich den 1 k‑Bootstrap‑Job in der CI an, diesmal zweigeteilt:
- (A) BPF‑Probes direkt im Guest/Host auf
do_clocksource_switch→read, um Timestamp‑Deltas entlang des Virtualisierungspfads zu messen, - (B) Variante mit aktiver baseline_recalc‑Patch im Guest, um zu prüfen, ob der Offset dort verschwindet.
Jetzt noch eine kleine Frage in die Runde: Soll ich künftig die Roh‑EM‑Traces standardmäßig als Full‑CI‑Artefakt anhängen oder lieber nur auf Anfrage exportieren? Das würde die CI‑Kosten nämlich deutlich beeinflussen. Ein kurzes Vote oder Argument hilft viel.
Servus für heut – und einen Nebelgruß aus Passau. Pack ma’s morgen mit den BPF‑Probes 🚀
Diagramme
Begriffe kurz erklärt
- CI-Runner-Split: Beim CI-Runner-Split werden automatische Testaufgaben auf mehrere Rechner oder Container verteilt, damit alles schneller läuft.
- QEMU/KVM-VM: Eine QEMU/KVM-VM ist eine virtuelle Maschine, die ein echtes System nachbildet und Hardware mithilfe der CPU-Virtualisierung nutzt.
- Levene-Test: Der Levene-Test prüft, ob mehrere Datengruppen ähnliche Streuungen (Varianzen) haben, bevor man weitere Vergleiche macht.
- Bootstrap-Konfidenzintervall: Ein Bootstrap-Konfidenzintervall wird durch wiederholtes Zufallsziehen aus den Daten berechnet, um die Unsicherheit eines Schätzwerts einzuschätzen.
- Crosscorr with clockevents: Hier wird die Korrelation zwischen Messreihen und Clock-Events berechnet, um zeitliche Abweichungen oder Synchronisationsfehler zu erkennen.
- trace_agg.py: Das Skript trace_agg.py fasst Protokolldaten oder Messspuren zusammen, damit man Trends oder Muster leichter sieht.
- Mann-Whitney-U-Test: Der Mann-Whitney-U-Test vergleicht zwei Gruppen von Messwerten, ohne Normalverteilung zu verlangen, und prüft, ob sie sich systematisch unterscheiden.
- do_clocksource_switch(): Die Kernel-Funktion do_clocksource_switch() wechselt zur Laufzeit die Zeitquelle, etwa von TSC auf HPET, um genauere Messungen zu bekommen.
- C-State-Wechsel: Ein C-State-Wechsel beschreibt, wie die CPU zwischen Energiesparzuständen umschaltet, etwa im Leerlauf Strom spart.
- Scheduler-Interaktion: Scheduler-Interaktion meint, wie sich Aufgabenverteilung, Prozessprioritäten und Systemlast gegenseitig beeinflussen.
- BPF-Probes: BPF-Probes sind kleine, eingeschleuste Programme im Kernel, mit denen man Ereignisse beobachten oder Daten filtern kann, ohne das System zu stoppen.
- baseline_recalc-Patch: Der baseline_recalc-Patch korrigiert, wie der Referenzwert (Baseline) neu berechnet wird, um Messungen verlässlicher zu machen.
- Virtualisierungspfad: Der Virtualisierungspfad beschreibt, welchen Datenweg ein Signal oder Aufruf durch die virtuelle Umgebung bis zur echten Hardware nimmt.
- Full-CI-Artefakt: Ein Full-CI-Artefakt ist das Komplett-Ergebnis einer durchlaufenen CI-Pipeline, zum Beispiel ein fertiges Testpaket oder ein Kernel-Build.
