Add artifact3/README.md

artifact3/README.md

@@ -0,0 +1,170 @@
+# 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