mini_ci_probe/ci_pipeline

Mini-CI Probelauf mit stratified sampling, Runner-Split und Bootstrap-Checks

Purpose

Technische Dokumentation des Mini-CI-Probelaufs zur Validierung von Bootstrap-Konsistenz und Laufzeitstabilität im Vergleich zu einem Single-Runner-Ansatz.

Problemstellung: Vor dem Full-Run sollte überprüft werden, ob das geplante CI-Design mit stratified sampling und getrennten Runnern zuverlässig reproduzierbare Bootstrap-Ergebnisse liefert.

Ziele:

• Nachweis der Stabilität von Bootstrap-Konfidenzintervallen bei unterschiedlichen CPU-State-Konfigurationen
• Evaluation des Runner-Splits (capture, aggregator, bootstrap)
• Konfiguration eines skalierbaren Mini-CI-Designs für experimentelle Performance-Analysen

Kontext & Hintergrund

Jedes CI-Job-Run enthält Traces und Outlier-Raten, getrennt nach CPU-State-Profilen ('powersave' und 'performance').

Gruppierung:

• CPU-State-Gruppe
• Runner-Typ
• CI-Job

Trace-Metadaten / zusätzliche Tags:

• C-State-Tags
• Zeilenendungsformat
• Trace-Aggregator-Ausgabe

Domänenkontext:

• Continuous Integration
• Performance Tracing
• Bootstrap-Statistik
• System Benchmarks

Outlier-Definition:

• Methode: Bootstrap-Schätzung je Gruppe
• Beschreibung: Outlier-Rate basierend auf Job-Zeitverteilung pro CPU-State.
• Metrik: Prozentuale Abweichung der Outlier-Rate (pp)

Motivation:

• Reduktion der Streuung bei Bootstrap-Ergebnissen
• Getrennte Steuerung und Resampling zur Reduktion von Laufzeitvariabilität
• Validierung der CI-Tauglichkeit für lange Bootstrap-Läufe

Methode / Spezifikation

Übersicht:

• 10 Replikate je Run mit N≈240 pro Job
• Stratifizierung in 'powersave' und 'performance'
• Parallele Capture-Runner, zentraler Aggregator, separater Bootstrap-Runner

Algorithmen / Verfahren:

• Stratifiziertes Sampling nach CPU-State
• Aggregation und Normalisierung der Traces
• Bootstrap-Resampling mit 1000 Wiederholungen pro Probe

Bootstrap-Übersicht

Nichtparametrisches Resampling zur Schätzung stabiler Konfidenzintervalle der Outlier-Rate.

Zielgrößen:

• Outlier-Rate
• Intervallbreite
• Risikoquotient

Resampling-Setup

• 'powersave'
• 'performance'

Stichprobeneinheit: einzelner CI-Job-Run

Resampling-Schema:

• 1000 Bootstrap-Resamples je Gruppe

Konfidenzintervalle:

• Niveau: 0.95
• Typ: percentile CI
• Ableitung: empirisch aus Resampling-Verteilung

Abgeleitete Effektgrößen

Risk Difference (Differenz der Raten):

• Definition: Differenz der Outlier-Raten zwischen CPU-State-Gruppen in Prozentpunkten.
• Bootstrap: Schätzung des CI der Differenz via Bootstrap der Gruppenmittelwerte.

Risk Ratio:

• Definition: Quotient der Outlier-Raten zwischen 'performance' und 'powersave'.
• Bootstrap: Verteilung des Quotienten aus resampleten Gruppenraten.

C-State-Kontrolle

Ziel: Sicherstellung konsistenter Zuordnung von Traces zu CPU-State-Labels.

Vorgehen:

• Normalisierung der C-State-Tags im Aggregator
• Zeilenendungs-Normalisierung zur Vermeidung von Trace_Mismatch

Input / Output

Input-Anforderungen

Hardware:

• CI-Runner mit CPU-State-Steuerung
• Oszilloskoptracing-fähige Umgebung

Software:

• CI-System (GitLab CI oder GitHub Actions)
• Python/R Statistikbibliothek
• Trace-Aggregator

Konfiguration:

• stratified_sample_size=240
• capture_parallel=4
• aggregator_mode=singleton
• bootstrap_runs=1000 (Quick-Check) / 10000 (Full-Run)
• job_timeouts=900s pro Run

Erwartete Rohdaten

Felder pro Run:

• job_id
• cpu_state
• runtime_s
• outlier_flag
• trace_path

Formatbeispiele:

• {'job_id': 1, 'cpu_state': 'powersave', 'runtime_s': 814, 'outlier_flag': false}

Trace-Daten:

• Format: JSON/CSV mit Zeit- und State-Feldern
• Hinweis: Zeilenenden müssen normalisiert sein.

Analyse-Ausgaben

Pro Gruppe / pro Governor:

• mean_runtime
• outlier_rate
• ci_width_pp

Vergleichsausgaben:

• powersave vs performance

  • Δ: 1.1
  • CI(Δ): [0.7;1.5]
  • RR: 0.97
  • CI(RR): [0.93;1.02]

• C-State-Korrelation: Pearson-Korrelation zwischen Outlier-Rate und C-State-Verteilung pro Runner

• Trace-Muster: Erkennung von systematischen Trace-Mismatches nach Normalisierung 0%

Workflow / Nutzung

Analyse-Workflow:

• Trigger eines Mini-CI-Runs mit definierten Stratified-Jobs
• Paralleles Capture der Traces (4 Runner)
• Zentrale Aggregation und Normalisierung
• Bootstrap-Resampling und CI-Auswertung
• Vergleich mit vorherigen Runs (Single-Runner-Referenz)

Trace-Template-Anforderungen

Ziel: Reproduzierbare Traces mit eindeutigen CPU-State-Tags

Erforderliche Tags & Metadaten:

• cpu_state
• timestamp
• runner_type
• trace_source

trace-cmd-Setup:

• --normalize-line-endings
• --tag-cstate
• --runner-label=<capture|aggregator|bootstrap>

Run-Design für Contributors:

• je 10 Replikate pro State-Klasse
• N=240 pro Gruppe
• Runner-Labels nach Typ zuweisen

Interpretation & erwartete Ergebnisse

Kernbefunde:

• Stratifiziertes Mini-CI-Design bietet stabile Bootstrap-CIs (Breite ≈1.1pp)
• Runner-Split reduziert Streuung signifikant gegenüber Single-Runner-Setup
• Bottleneck liegt im Aggregator und Bootstrapping, nicht im Tracing selbst

Implikationen für Experimente:

• Runner-Trennung ist für Langzeit-Bootstrap-Läufe sinnvoll
• Job-Design mit N≈240 ist statistisch hinreichend und ressourcenschonend

Planungsziel:

• Ziel: Planung eines Full-Runs über 24h
• Vorgehen:
  • Erhöhung der Bootstrap-Wiederholungen auf 10k
  • Überwachung der Drift (1PPS) im Selftest

Limitationen & Fallstricke

Datenbezogene Limitationen:

• Empfindlich gegenüber falscher CPU-State-Zuordnung
• Trace-Mismatch kann CI-Breite verfälschen

Bootstrap-spezifische Limitationen:

• Bei niedriger N kann die CI-Schätzung instabil werden
• Starker Einfluss von Gruppenungleichgewicht auf Risk-Ratio

Kausalität & Generalisierbarkeit:

• Ergebnisse beschränken sich auf Mini-CI-Setups mit ähnlichem Runner-Layout
• Keine Übertragbarkeit auf heterogene Multi-Host-Szenarien

Praktische Fallstricke:

• 6h-Job-Limits erfordern robustes Artifact-Handling
• Langlaufende CI-Systeme sind abhängig von zuverlässigen Runnern und Storage

Nächste Schritte & Erweiterungen

Geplante Experimente:

• Full-Run mit 10k Bootstrap-Resamples über 24h auf dediziertem Runner-Pool
• Drift-Vergleich mittels 1PPS-Selbsttest

Analyseziele:

• Untersuchung der Stabilität über Langzeitintervalle
• Korrelation Bootstrap-Varianz zu Trace-Dauer

Regression & Modellierung:

• Modellierung der CI-Breite als Funktion der Bootstraps und der CPU-State-Varianz

Community-Beiträge:

• Vergleich GitHub vs. GitLab CI für lange Jobs
• YAML-Konfigurationsreview durch andere CI-Setups