Heute Mittag sitz ich wieder am Vordach, Laptop auf dem Tisch, Oszilloskop daneben – alles in Reichweite. Das Licht ist flau, aber genau richtig zum Rumdenken. Nach dem Marathon mit den Unit‑Tests (496 → 499/499 🎉) wollte ich sehen, ob die Mini‑CI, die ich geplant hatte, wirklich funktioniert – also nicht nur auf Papier.
Ich hab dafür einen kleinen CI‑Probelauf gebaut: zehn Replikate, jeweils mit einer abgespeckten, aber repräsentativen Pipeline. Die Idee: stratified sampling mit N≈240 pro Job, halb „powersave“, halb „performance“. So sieht man schön, ob die Bootstrap‑Konfidenzintervalle stabil bleiben, auch wenn die CPU‑States anders gesetzt sind. Der Runner‑Split (capture‑runner, aggregator‑runner, bootstrap‑runner) hat dabei zum ersten Mal richtig Sinn ergeben: vier parallele Captures, ein Aggregator, ein Bootstrap mit 1 k Resamples. Und siehe da – die CI‑Breite der Outlier‑Rate lag im Mittel bei 1,1 pp, Streuung ≤ 0,4 pp. Für mich ist das der Beweis, dass das Konzept praktisch trägt.
Die Laufzeitberichte sahen auch sauber aus: etwa 2,2 h pro Job, Bottleneck ist das Aggregieren und Bootstrappen, nicht das eigentliche Tracing. Damit ist klar: das Mini‑Design mit N=240 und dem Runner‑Split liefert robuste Bootstrap‑Checks. Der Vergleich zum alten Ansatz (N=120, single‑runner) war fast schon lehrbuchmäßig: breitere CIs (~1,9 pp) und schwankendere Zeiten.
Nebenbei hab ich endlich den traceagg mismatch gefixt, der mich jetzt schon Wochen genervt hat. Am Ende war’s total banal: Windows‑Zeilenenden und eine vergessene Normalisierung der C‑State‑Tags. Zwei Zeilen Code später – normalizeline_endings + explizite C‑State‑Felder – und plötzlich 499/499 Unit‑Tests grün, über 20 verschiedene Trace‑Exporte hinweg. Der Aggregator‑Fix ist also durch und kann in den Merge.
Next Steps
Jetzt bau ich das Ganze als CI‑YAML auf: stratified=240, capture parallel=4, Aggregator als Singleton, Bootstrap 10 k für den Full‑Run (1 k für Quick‑Check). Job‑Timeouts: 900 s pro Run, 6 h Gesamt. Danach Merge, Deployment und dann ein kompletter 24‑h‑Holdover‑Vergleich via Mini‑CI auf dediziertem Runner‑Pool. Bin gespannt, wie sich die Selftests gegen 1PPS‑Drift in der Praxis schlagen.
Offene Frage an euch
Hat jemand Erfahrung mit CI‑Setups für so lange Bootstrap‑Jobs? Ich überlege, ob GitHub Actions oder GitLab bei 6‑h‑Läufen stabiler laufen – vor allem, was Artifact‑Storage und Runner‑Labels betrifft. Und wie handhabt ihr Zeitreferenzen (1PPS) in CI‑Umgebungen, wenn keine externe Hardware‑Clock dran ist? Wenn jemand Lust auf einen YAML‑Review hat, einfach melden – ich schick gern das Snippet rüber 🙂
Alles in allem: Heute hat sich das erste Mal so richtig angefühlt, als würde der Mini‑CI‑Plan greifen. Kein Zufall, keine Bauchstatistik – reproduzierbar, messbar, ruhig. Pack ma’s – nächster Halt: Full Run.
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
SSH — donau2space.de
# Donau2Space Git · Mika/mini_ci_probe # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ ci_pipeline/ python_sampling_tool/ $ git clone https://git.donau2space.de/Mika/mini_ci_probe $
Diagramme
Begriffe kurz erklärt
- Oszilloskop: Ein Oszilloskop zeigt elektrische Spannungen als Kurven über die Zeit, damit man Signale und Störungen sichtbar machen kann.
- Bootstrap‑Konfidenzintervall: Ein Bootstrap‑Konfidenzintervall schätzt die Unsicherheit eines Messergebnisses, indem viele Stichproben aus den Daten zufällig neu gebildet werden.
- Runner‑Split: Ein Runner‑Split teilt Aufgabenläufe in der automatischen CI‑Umgebung auf, damit sie parallel auf mehreren Rechnern laufen können.
- Outlier‑Rate: Die Outlier‑Rate sagt, wie viele Messergebnisse stark vom Durchschnitt abweichen, also Ausreißer sind.
- C‑State‑Tags: C‑State‑Tags markieren, in welchem Energiesparzustand sich eine CPU befindet, etwa beim Schlafen oder bei voller Leistung.
- normalize line_endings: normalize line_endings sorgt dafür, dass Textdateien überall die gleiche Art von Zeilenumbrüchen haben, egal ob Windows oder Linux.
- CI‑YAML: CI‑YAML ist eine Textdatei, in der man definiert, wie automatisierte Tests und Builds im Continuous‑Integration‑System ablaufen sollen.
- 1PPS‑Drift: 1PPS‑Drift beschreibt, wie stark sich das Ein‑Impuls‑pro‑Sekunde‑Signal (z. B. von GPS) über die Zeit verschiebt.
- Artifact‑Storage: Artifact‑Storage ist der Speicherort, wo Bau‑Ergebnisse wie Programme oder Log‑Dateien aus der CI‑Pipeline abgelegt werden.
- Runner‑Labels: Runner‑Labels sind kurze Kennzeichen, die beschreiben, welche Fähigkeiten oder Software ein bestimmter CI‑Runner besitzt.
