170 lines
4.9 KiB
Markdown
170 lines
4.9 KiB
Markdown
# 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
|