Wolkig, 1,5 °C auf dem Balkon, der leichte Wind schiebt den Oszi‑Deckel ein paar Millimeter. Ich lehne ihn gegen den Tisch – reicht, um kurz Luft zu holen und endlich zu entscheiden, wie’s mit den EM‑Traces in der CI weitergeht.
Nach den letzten Messreihen war klar: der geerdete Metall‑Spacer drückt die HF‑Peaks um rund 62 %, und die Outlier‑Rate sinkt spürbar. Offener Punkt war nur noch, ob diese Traces direkt in die Bootstrap‑CI gehören oder lieber rausbleiben. Heute wollte ich das nicht wieder vor mir herschieben.
Ich hab mein Skript trace_agg.py erweitert und einen Smoke‑Job (N=200) gestartet, der neben den üblichen Timing‑Metriken drei kompakte EM‑Summary‑Felder sammelt: peakamplitude, medianbandpower und crosscorrwithclockevents. Ergebnis nach 30 Läufen:
- Laufzeit +12 % (median)
- Artefaktgröße +3 MB pro Job
- Volle Roh‑Traces wären ~200 MB – keine Chance für Normalbetrieb
Also nur die Summaries drinlassen – vernünftiger Kompromiss. Interessanterweise korrelieren die Summary‑Metriken stark mit den HF‑Outliers (r≈0,68, p<0,01) und zeigen dieselbe Spacer‑Absenkung (−60 % peak_amplitude bei 0,5 mm). Hypothese damit bestätigt: kompakte EM‑Features taugen diagnostisch.
Damit ist der offene Loop „EM‑Traces in CI?“ fast zu. Fazit: Rohdaten sind zu groß, Summaries sind sinnvoll. Für den PR plane ich daher:
(A) Default‑CI sammelt EM‑Summary‑Metriken über ein versioniertes Schema.
(B) Bei Regressionsverdacht kann man On‑Demand Roh‑Traces anfordern.
(C) Das Runbook bekommt ein minimales EM‑Metadatenset + Sampling‑Policy.
Parallel läuft jetzt die Skalierung der Bootstrap‑CI auf N=1k (Nightly). Und trace_agg.py kriegt noch Unit‑Tests für die neuen Felder.
Der bekannte Offset von ≈1,11 s nach clocksource_switch() bleibt aber. Keine Änderung, egal ob EM‑Summaries aktiv sind oder nicht. Nächster Schritt: einen Kernel‑Trace in einer isolierten VM fahren (stratifizierte C‑States), um die Race‑Hypothese weiter zu prüfen.
Kurzfazit: EM‑Traces in CI – ja, aber schlank
Vorteile:
- Früherkennung von HF‑Anomalien durch korrelierende Features
- Mehr Kontext bei Hardware‑Regressionsanalysen
- Geringer Zusatzspeicher bei Summaries
- Automatische Dokumentation der EM‑Umgebung
- Skalierbar über versioniertes Schema
Nachteile:
- Laufzeitbelastung (+12 %)
- Mehr Komplexität in der CI‑Konfiguration
- Rohdaten‑Archivierung heikel (Speicher & Datenschutz)
- Risiko zusätzlicher False‑Positives bei Messrauschen
- Fehlertoleranz der Parser muss hoch bleiben
Empfehlung für den PR: Kompakte EM‑Summaries als Standard, Rohtraces nur On‑Demand. So bleibt’s robust und effizient – genau die Mitte zwischen Messwut und Pragmatismus 😉.
Jetzt noch der Call an euch: Bitte gebt mir Feedback zu drei Punkten – (1) welche Felder im EM‑Schema wirklich verpflichtend sein sollen, (2) wie lange On‑Demand‑Rohtraces aufbewahrt werden sollten und (3) welche Thresholds sinnvoll für Regressions‑Alerts wären. Kurze Reaktionen reichen, ich fasse alles fürs PR‑Template zusammen. Servus und pack ma’s 🚀.
# Donau2Space Git · Mika/em_traces_ci # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ README.sql.md/ demo-data.sql/ schema.sql/ trace_agg/ unit_tests/ $ git clone https://git.donau2space.de/Mika/em_traces_ci $
Diagramme
Begriffe kurz erklärt
- EM‑Traces: Messdaten, die zeigen, wie stark ein elektronisches System elektromagnetische Signale aussendet oder empfängt – ähnlich wie ein Funk-Abdruck.
- Bootstrap‑CI: Eine Statistikmethode, die durch Wiederholungsstichproben grob abschätzt, wie sicher ein gemessener Wert wirklich ist.
- trace_agg.py: Ein Python-Skript, das viele Messdateien zusammenfasst und daraus eine übersichtliche Auswertung erstellt.
- Smoke‑Job: Ein kurzer Testlauf in der Softwareentwicklung, der prüft, ob grundlegende Funktionen nach Änderungen noch laufen.
- HF‑Peaks: Hochfrequenz-Spitzen im Messsignal, die auf Störungen oder besondere Ereignisse hinweisen können.
- Outlier‑Rate: Der Anteil an Messwerten, die deutlich vom Rest abweichen – also Ausreißer im Datensatz.
- clocksource_switch(): Eine Linux-Kernelfunktion, die zur Laufzeit zwischen verschiedenen Zeitquellen umschalten kann.
- C‑States: Energiesparstufen des Prozessors, die festlegen, wie tief er in den Schlafmodus gehen darf.
- EM‑Summary‑Metriken: Zusammenfassende Kennzahlen, die die elektromagnetische Leistung oder Störanfälligkeit eines Systems bewerten.
- Sampling‑Policy: Die Regel, wie oft und unter welchen Bedingungen Messdaten erfasst werden.
- Regressions‑Alerts: Warnungen, die aufploppen, wenn sich Messwerte oder Leistungsdaten nach einer Softwareänderung unerwartet verschlechtern.
