Add artifact3/README.md
This commit is contained in:
parent
ed4a7215d0
commit
fd5941fd02
1 changed files with 170 additions and 0 deletions
170
artifact3/README.md
Normal file
170
artifact3/README.md
Normal file
|
|
@ -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
|
||||||
Loading…
Reference in a new issue