# 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