aux_comparison_freeze_band/results_report/README.md

# Vergleich der aux=2 und aux=3 Systeme im Freeze-Band (Preflight-Gate-Auswertung)

## Purpose

Dokumentation und Analyse der Freeze-Band-Versuche mit den aux=2 und aux=3 Systemen, einschließlich Preflight-Gating und auswertungsrelevanter Kennzahlen.

**Problemstellung:** Es soll überprüft werden, ob aux=3 unter Freeze-Band-Bedingungen eine signifikant andere Performance gegenüber aux=2 zeigt, unter identischen Setup-Parametern und validem Gating.

**Ziele:**
- Validierung der Freeze-Bedingungen für aux=3 im Vergleich zu aux=2
- Quantifizierung der Stabilität und Wiederholbarkeit des Preflight-Gates
- Erstellung einer Δ-Tabelle zur direkten Vergleichbarkeit relevanter Metriken

## Kontext & Hintergrund

Preflight-Datensätze aus den Runs #40, #41b und #42, jeweils mit Messungen zu measured_p, freeze_ok, setup_fingerprint und policy_hash.

**Gruppierung:**
- aux=2
- aux=3

**Trace-Metadaten / zusätzliche Tags:**
- setup_fingerprint
- policy_hash

**Domänenkontext:**
- Systemvergleich unter Freeze-Band-Bedingungen
- Stabilitätsanalyse von Preflight-Gates

**Outlier-Definition:**
- Methode: Toleranzprüfung
- Beschreibung: Ein Run gilt als Ausreißer, wenn measured_p außerhalb des Freeze-Ziels von 0.10 ± 0.02 liegt.
- Metrik: measured_p

**Motivation:**
- Reduktion zufallsbasierter Messabweichungen durch Serienvalidierung
- Prüfung von Systemrobustheit unter identischen Bedingungen
- Entwicklung reproduzierbarer Vergleichsmethoden

## Methode / Spezifikation

**Übersicht:**
- Preflight-Versuche werden sequentiell protokolliert.
- Ein Run darf nur stattfinden, wenn zwei aufeinanderfolgende freeze_ok=1 gemessen werden.
- Alle Messungen erfolgen mit identischem setup_fingerprint und policy_hash.

**Algorithmen / Verfahren:**
- Messung von measured_p für jede Preflight-Sequenz
- Validierung des Freeze-Gates durch Zählen der aufeinanderfolgenden erfolgreichen (ok) Versuche
- Statistische Auswertung von retry_tail_p99, band_width und Δband_width

### Bootstrap-Übersicht

Bootstrap-Resampling zur Schätzung der Unsicherheit in Δ(aux3 − aux2).

**Zielgrößen:**
- retry_tail_p99
- band_width

### Resampling-Setup

- aux=2
- aux=3

**Stichprobeneinheit:** Run

**Resampling-Schema:**
- 1000-faches Bootstrap-Resampling der Run-Level-Metriken

**Konfidenzintervalle:**
- Niveau: 0.95
- Typ: percentile CI
- Ableitung: Empirische Verteilung der resampleten Differenzen

### Abgeleitete Effektgrößen

**Risk Difference (Differenz der Raten):**
- Definition: Differenz in der Trefferwahrscheinlichkeit innerhalb des Freeze-Bands.
- Bootstrap: Resampling über die proportion ok pro Run

**Risk Ratio:**
- Definition: Verhältnis der Erfolgswahrscheinlichkeiten freeze_ok(aux3) / freeze_ok(aux2).
- Bootstrap: Resampling zur CI-Schätzung des Verhältnisses

### C-State-Kontrolle

**Ziel:** Reduktion nichtvergleichbarer CPU-Zustände über Setup-Konstanz.

**Vorgehen:**
- Verwendung identischer policy_hash-Werte
- Vergleich nur innerhalb identischer setup_fingerprint-Konfigurationen

## Input / Output

### Input-Anforderungen

**Hardware:**
- identisches Testsystem pro aux-Gruppe

**Software:**
- gleiche Mess- und Logging-Software-Version

**Konfiguration:**
- identischer policy_hash
- identischer setup_fingerprint

### Erwartete Rohdaten

**Felder pro Run:**
- timestamp
- measured_p
- freeze_ok
- setup_fingerprint
- policy_hash

**Formatbeispiele:**
- 2024-06-02T12:45:03Z, 0.083, 0, a19cf3, 9fba00
- 2024-06-02T12:47:10Z, 0.118, 1, a19cf3, 9fba00

**Trace-Daten:**
- Format: CSV oder JSON pro Preflight-Sequenz
- Hinweis: Jeder Preflight wird als eigene Zeile dokumentiert, keine Aggregation im Rohdatensatz.

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- Median retry_tail_p99
- IQR retry_tail_p99
- band_width
- Δband_width

**Vergleichsausgaben:**
- aux=2 (#40) vs aux=3 (#42)
  - Δ: Δband_width(aux3−aux2)
  - CI(Δ): 95%-CI über 1000 Resamples
  - RR: ratio freeze_ok(aux3)/freeze_ok(aux2)
  - CI(RR): 95%-CI über Bootstrap-Resamples
  - Tests: zweiseitiger Test optional

- C-State-Korrelation: Korrelation zwischen policy_hash und gemessenem retry_tail_p99
- Trace-Muster: Analyse von Setup-Konstanz über Runs

## Workflow / Nutzung

**Analyse-Workflow:**
- Erfassen aller Preflight-Ergebnisse als Einzelzeilen
- Berechnen von freeze_ok-Streaks pro Run
- Validieren der 2×-ok-Gate-Regel
- Auswerten von retry_tail_p99 und Bandmerkmalen
- Berechnen der Δ(aux3−aux2) für alle Zielmetriken

### Trace-Template-Anforderungen

**Ziel:** Reproduzierbare Freeze-Gate-Auswertung und Vergleichbarkeit zwischen aux-Konfigurationen

**Erforderliche Tags & Metadaten:**
- timestamp
- measured_p
- freeze_ok
- setup_fingerprint
- policy_hash

**trace-cmd-Setup:**
- logge alle Preflights separat
- prüfe setup_fingerprint auf Konstanz

**Run-Design für Contributors:**
- mindestens zwei aufeinanderfolgende freeze_ok erforderlich
- dokumentiere alle Versuchswerte lückenlos

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Run #42 (aux=3) erfüllt alle Validitätsbedingungen und bleibt innerhalb des Freeze-Bands.
- aux=3 zeigt wiederholt höhere retry_tail_p99-Werte im Hotspot-Bereich als aux=2.
- band_width und Δband_width unterscheiden sich nur geringfügig zwischen Konfigurationen.

**Implikationen für Experimente:**
- aux=3 hat unter kontrollierten Freeze-Bedingungen eine messbar ungünstigere Stabilität.
- Die Wiederholung des Effekts unter 2×-ok-Gating bestätigt die Robustheit der Beobachtung.

**Planungsziel:**
- Ziel: Absicherung der Vergleichsbedingungen zwischen Systemkonfigurationen.
- Vorgehen:
  - verstärktes Preflight-Gating
  - ausschließliche Vergleichsfreigabe bei Setup-Identität
  - Bootstrapping zur Unsicherheitsquantifizierung

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Kleine Stichprobengröße (nur drei Haupt-Runs)
- keine vollständige Zufallsverteilung der Freeze-Bedingungen

**Bootstrap-spezifische Limitationen:**
- Unsicherheit der CI bei geringer Anzahl von Runs

**Kausalität & Generalisierbarkeit:**
- Korrelation zwischen aux-Wert und Performance, keine kausale Schlussfolgerung möglich

**Praktische Fallstricke:**
- Fehlende Daten aus Wiederholungsläufen können Varianz verzerren
- Unterschiedliche Umgebungsbedingungen trotz identischem fingerprint möglich

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Erweiterung um zusätzliche Runs mit aux=3 unter gleichen Gating-Regeln
- Validierung von aux=2 und aux=3 unter variierenden Freeze-Zielbereichen

**Analyseziele:**
- Erweiterung der Δ-Tabelle mit Durchschnitts- und Streumaßen
- Quantitative Bewertung des 2×-ok-Gates auf Stabilität und Trefferquote

**Regression & Modellierung:**
- Regression von retry_tail_p99 gegen measured_p zur Sensitivitätsanalyse

**Community-Beiträge:**
- Bereitstellung der Rohdaten und Δ-Tabellen zur Peer-Überprüfung im Lab-Repository