# Analyse des Einflusses eines isolierten Toggles auf das Resonanzband (Run #24)

## Purpose

Dokumentation von Run #24 zur Prüfung des kausalen Zusammenhangs zwischen einem isolierten Step-Toggle und der Max-Outlier-Performance im Resonanzband.

**Problemstellung:** Klären, ob der im Cluster dominierende Step den Max-Outlier direkt beeinflusst oder ob das Resonanzband unabhängig von diesem Mechanismus besteht.

**Ziele:**
- Nachweis einer kausalen Beziehung zwischen Step und Max-Outlier-Werten
- Abgrenzung des Resonanzbands von unmittelbaren Step-Effekten
- Standardisierte Auswertung über identische Runs (#22/#23 vs. #24)

## Kontext & Hintergrund

Messdaten aus Cluster-Runs #22, #23 und #24 mit identischem Setup-Fingerprint und policy_hash.

**Gruppierung:**
- Run #22
- Run #23
- Run #24

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

**Domänenkontext:**
- Cluster-Performance
- Timing-Anomalien
- Workload-Verzögerungen

**Outlier-Definition:**
- Methode: Schwellenbasiert
- Beschreibung: Outlier werden definiert als Latenzen über 90 ms.
- Metrik: max_ms, retry_total_overhead_ms

**Motivation:**
- Reduktion von Latenz-Peaks in Cluster-Jobs
- Kausaltest statt Korrelationsannahme
- Identifikation des Steps als Ursache spezifischer Outlier

## Methode / Spezifikation

**Übersicht:**
- Vergleich dreier Runs mit identischem Setup und einzelnem Toggle am Step.
- Keine Änderungen in Schwellen, Logfeldern oder Policies.
- Bewertung anhand festgelegter Entscheidungstabelle (A, B, C).

**Algorithmen / Verfahren:**
- Deduplizieren von Max-only-Alerts pro Key pro Run.
- Berechnung der Outlier-Frequenz >90 ms.
- Erzeugung von Histogrammen und Quantilen für expires_at_dist_hours.
- Statistische Auswertung der retry_total_overhead_ms (p50/p95/p99/max).

## Input / Output

### Input-Anforderungen

**Hardware:**
- Cluster mit identischer Konfiguration über alle Runs

**Software:**
- Tracing- und Metriksystem mit unveränderten Schwellen

**Konfiguration:**
- Identischer setup_fingerprint und policy_hash

### Erwartete Rohdaten

**Felder pro Run:**
- max_ms
- outlier_count_90ms
- expires_at_dist_hours
- retry_total_overhead_ms

**Formatbeispiele:**
- {'max_ms': 84.2, 'outlier_count_90ms': 12, 'expires_at_dist_hours': [1.2,1.6,2.0], 'retry_total_overhead_ms': {'p95':38.4,'p99':71.8}}

**Trace-Daten:**
- Format: structured JSON traces
- Hinweis: Alle Runs verwenden gleiche trace schemas für Vergleichbarkeit.

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- Histogrammüberlagerung von expires_at_dist_hours
- Berechnung der Max-only-Alert-Kollapsrate

**Vergleichsausgaben:**
- Run #22 + #23 vs Run #24
  - Δ: Reduktion der >90 ms Outlier-Frequenz um signifikanten Anteil
  - CI(Δ): Nicht berechnet, da qualitative Beobachtung
  - RR: RR < 1 zeigt Verbesserung der Max-Latenz

- C-State-Korrelation: Nicht relevant für diesen Run
- Trace-Muster: Resonanzband unverändert, Max-Peak kollabiert

## Workflow / Nutzung

**Analyse-Workflow:**
- Setup-Fingerprint bestätigen
- Einzeltoggle am Step aktivieren
- Run #24 durchführen (4× parallel)
- Metriken gemäss Entscheidungstabelle A–C auswerten
- Vergleich mit Vorläuferruns

### Trace-Template-Anforderungen

**Ziel:** Vergleichbarkeit von Cluster-Traces über Runs

**Erforderliche Tags & Metadaten:**
- setup_fingerprint
- policy_hash
- metric_type
- job_id

**trace-cmd-Setup:**
- trace_cmd ohne zusätzliche Filter
- identische Sampling-Rate

**Run-Design für Contributors:**
- Nur ein Toggle-Parameter ändern
- Minimal-invasive Vergleiche für Kausalitätsschluss

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Resonanzband bleibt konstant: Timing-Phänomen durch 4×-Ausführung.
- Max-Outlier kollabiert: direkter Zusammenhang mit Step bestätigt.

**Implikationen für Experimente:**
- Step ist primärer Auslöser der extremen Latenzen.
- Resonanzband durch parallele Dynamik, nicht Step-initiiert.

**Planungsziel:**
- Ziel: Trennung von Step-bedingten und Lastverteilungs-bedingten Effekten.
- Vorgehen:
  - Einzeltoggle-Design
  - Identische Randbedingungen über Runs

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Beobachtungen basieren auf nur drei Runs
- Keine Bootstrap-Quantifizierung vorhanden

**Bootstrap-spezifische Limitationen:**
- Keine Resampling-Schätzung zur Unsicherheit genutzt

**Kausalität & Generalisierbarkeit:**
- Nur für N=1 Toggle getestet
- Ergebnisse gelten nur für gleiche Setup-Fingerprint-Konstellation

**Praktische Fallstricke:**
- Kleine Unterschiede im Scheduling können unbemerkt bleiben

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Run #25 mit alternativem Step-Toggle oder Scheduling-Isolation

**Analyseziele:**
- Verifizierung der Step-Kausalität bei alternativer Implementierung

**Regression & Modellierung:**
- Späteres Modeling von Resonanzband-Bedingungen möglich

**Community-Beiträge:**
- Diskussion über Ursachen von Timing-Resonanzen zwischen Step- und Cluster-Ebene