bootstrap_analysis/governors_analysis_report/README.md

Bootstrap-Analyse der Outlier-Raten unter Power-Save und Performance Governors

Purpose

Quantitative Analyse des Einflusses unterschiedlicher CPU-Governor-Strategien (powersave vs. performance) auf die Outlier-Rate von Microbenchmarks mithilfe von Bootstrap-Resampling.

Problemstellung: Unklarer Effekt von CPU-Governor-Einstellungen auf die Stabilität von Microbenchmark-Läufen; Ziel ist die statistisch abgesicherte Quantifizierung der Outlier-Wahrscheinlichkeit pro Governor.

Ziele:

• Vergleich der Outlier-Proportionen zwischen Governor-Gruppen
• Schätzung von Konfidenzintervallen mittels Bootstrap
• Bewertung des Risikoverhältnisses (risk ratio) und der Stabilität der Ergebnisse

Kontext & Hintergrund

Micro-Benchmark-Logs mit rund 240 Läufen, je nach Governor (powersave, performance) gruppiert. Enthält Outlier-Tags, Laufzeiten und Trace-Metadaten.

Gruppierung:

• governor = powersave
• governor = performance

Trace-Metadaten / zusätzliche Tags:

• C-State-Residency zur Kontrolle der Laufkonsistenz
• Governor-Tags zur Gruppierung der Runs

Domänenkontext:

• CPU-Frequenzskalierung
• Systemleistung und Stabilität
• Bootstrap-Statistik im Performance-Engineering

Outlier-Definition:

• Methode: Median/IQR-basiert
• Beschreibung: Läufe, deren Benchmark-Ergebnis außerhalb eines 1.5*IQR-Intervalls relativ zum Median liegen, gelten als Outlier.
• Metrik: Proportion der Outlier pro Gruppe

Motivation:

• Quantifizierung des Einflusses von Energiesparmechanismen auf die Benchmarkstabilität
• Unterstützung von Konfigurationsentscheidungen durch statistische Absicherung

Methode / Spezifikation

Übersicht:

• Bootstrap-basiertes Resampling zur Schätzung der Outlier-Proportion pro Governor-Gruppe
• Vergleich der Gruppen mittels Differenz in Prozentpunkten und Risk Ratio

Algorithmen / Verfahren:

• 10.000 Bootstrap-Resamples pro Gruppe
• Berechnung der mittleren Outlier-Proportion
• Ableitung von 95%-Konfidenzintervallen
• Berechnung der Differenz in Prozentpunkten und Risk Ratio auf Bootstrap-Basis

Bootstrap-Übersicht

Nichtparametrisches Resampling-Verfahren zur Schätzung der Unsicherheiten statistischer Kennwerte basierend auf Stichprobenziehungen mit Zurücklegen.

Zielgrößen:

• Outlier-Proportion pro Governor
• Differenz in Prozentpunkten
• Risk Ratio

Resampling-Setup

• powersave
• performance

Stichprobeneinheit: einzelner Benchmark-Run (Outlier=1/0)

Resampling-Schema:

• 10.000 Bootstrap-Stichproben pro Gruppe

Konfidenzintervalle:

• Niveau: 0.95
• Typ: Percentile CI
• Ableitung: 2.5%- und 97.5%-Bootstrap-Quantile

Abgeleitete Effektgrößen

Risk Difference (Differenz der Raten):

• Definition: Differenz der Outlier-Proportionen (powersave - performance), angegeben in Prozentpunkten.
• Bootstrap: 95%-Konfidenzintervall aus Bootstraps der Differenzen zwischen Gruppenmitteln.

Risk Ratio:

• Definition: Quotient der Outlier-Wahrscheinlichkeiten: p(powersave)/p(performance).
• Bootstrap: 95%-Konfidenzintervall basierend auf log-transformierten Risk-Ratios aus Resamples.

C-State-Kontrolle

Ziel: Sicherstellung, dass die Outlier-Bewertung nicht durch abweichende C-State-Residency verfälscht wird.

Vorgehen:

• Einbezug der C-State-Tags aus den Traces
• Ausschluss von Runs mit anomalen Residency-Profilen

Input / Output

Erwartete Rohdaten

Felder pro Run:

• run_id
• timestamp
• governor
• duration
• outlier_flag
• C-state-tags

Formatbeispiele:

• run123,2024-06-14 15:02:01,performance,5.03,0,C7:0.12

Trace-Daten:

• Format: trace-cmd output mit Governor- und C-State-Metadaten
• Hinweis: Benötigt für Validierung der Laufbedingungen

Analyse-Ausgaben

Pro Gruppe / pro Governor:

• powersave Outlier-Proportion = 25.0% (95% CI [17.8%, 33.1%])
• performance Outlier-Proportion = 5.8% (95% CI [2.4%, 11.5%])

Vergleichsausgaben:

• powersave vs performance

  • Δ: ≈19 (95% CI [10.1, 28.7])
  • CI(Δ): [10.1, 28.7]
  • RR: ≈4.3
  • CI(RR): [2.0, 9.6]
  • Tests: Mann-Whitney p≈0.006

• C-State-Korrelation: Höhere powersave-Outlier-Rate entspricht häufigeren tiefen C-States (Residency-Muster).

• Trace-Muster: Stabile Trace-Muster bei performance; variable C-State-Tiefen bei powersave.

Workflow / Nutzung

Analyse-Workflow:

• Extraktion der Benchmark-Logs und Metadaten
• Klassifikation der Läufe nach Governor
• Anwendung des Bootstrap-Resampling-Skripts
• Berechnung der CIs, Differenzen und Risk Ratios
• Validierung über C-State-Tags
• Erstellung von Ergebnis-Grafiken / Tabellen

Trace-Template-Anforderungen

Ziel: Standardisierte Erfassung von Governor-getaggten Benchmark-Traces mit C-State-Information.

Erforderliche Tags & Metadaten:

• governor
• C-State-Residency
• Timestamp
• run_id

trace-cmd-Setup:

• trace-cmd record -e power:* -b 32M --date --output=trace.dat

Run-Design für Contributors:

• ca. 50 gepaarte Runs (powersave/performance) mit identischer Workload
• Anonymisierte Logs mit Outlier-Markierungen und Metadaten einreichen

Interpretation & erwartete Ergebnisse

Kernbefunde:

• powersave-Governor führt zu signifikanter Erhöhung der Outlier-Rate
• Effekt robust über Bootstrap-Resampling abgesichert
• Keine Überlappung der 95%-Konfidenzintervalle

Implikationen für Experimente:

• Governor-Wahl stark einflussreich auf Messstabilität
• C-State-Residency zentraler Kontrollfaktor
• Fixierung der Governor-Einstellung notwendig für zukünftige Vergleiche

Planungsziel:

• Ziel: Reduktion der Unsicherheit in zukünftigen Messungen auf ±3 Prozentpunkte pro Governor.
• Vorgehen:
  • Geplante Erweiterung der Stichprobenzahlen nach Bootstrap-Schätzung

Limitationen & Fallstricke

Datenbezogene Limitationen:

• N begrenzt (~240 Läufe); mögliche Varianzunter- oder Überschätzung bei extremen Governors

Bootstrap-spezifische Limitationen:

• Bootstrap-Konfidenzintervalle abhängig von Stichprobenhomogenität; Verzerrung möglich bei starker Clusterung

Kausalität & Generalisierbarkeit:

• Beobachtete Effekte gelten für getestete Hardware/Setup; Generalisierung auf andere Systeme bedingt

Praktische Fallstricke:

• Nicht synchronisierte Runs können durch Temperaturdrift beeinflusst sein
• C-State-Tagging unvollständig → fehlerhafte Gruppenzuordnung

Nächste Schritte & Erweiterungen

Geplante Experimente:

• 24h-Holdover-Messung mit fixiertem Governor (powersave dann performance)
• Replikation der Bootstrap-Ergebnisse mit erweitertem C-State-Logging

Analyseziele:

• Validierung der Bootstrap-Ergebnisse über längere Laufzeiträume
• Erforschung der Wechselwirkungen zwischen Governors und C-State-Tiefen

Regression & Modellierung:

• Integration der Governor- und C-State-Faktoren in zukünftige Regressionsmodelle für Outlier-Wahrscheinlichkeit

Community-Beiträge:

• Erstellung eines öffentlichen Trace-Templates für Contributor-Runs
• Sammlung und Vergleich anonymisierter Governor-getaggter Logs