Add artifact.3/README.md

This commit is contained in:
Mika 2026-03-20 11:41:45 +00:00
parent f18b3d5084
commit 909303bb6a

212
artifact.3/README.md Normal file
View file

@ -0,0 +1,212 @@
# Analyse der Parallelitätseinflüsse auf das Resonanzband (Run #29)
## Purpose
Ermittlung der Wirkung reduzierter Parallelität auf das Resonanzband unter konstanter Lastkonfiguration.
**Problemstellung:** Unklar war bislang, ob Parallelität direkt auf die Breite des Resonanzbandes wirkt oder nur indirekt über Affinität und Queue-Sättigung.
**Ziele:**
- Quantifizieren der Änderung von band_width, band_center und retry_tail_p99 bei halbierter Parallelität
- Validieren der Kohortenstabilität im Vergleich zu Runs #27 und #28
- Isolieren der Wirkung von Last als Verstärkungsfaktor gegenüber Worker-Affinität
## Kontext & Hintergrund
Leistungstests mit identischem Setup wie Run #28, einzige Variation: Parallelität von 4× auf 2× reduziert.
**Gruppierung:**
- run_27
- run_28
- run_29
**Trace-Metadaten / zusätzliche Tags:**
- worker_id
- queue_id
- retry_tail_p99
- band_center
- band_width
**Domänenkontext:**
- Leistungstests unter CPU-Affinität und kontrollierter Parallelitätsvariation
**Outlier-Definition:**
- Methode: statistische Extremwertanalyse
- Beschreibung: retry_tail_p99 als Kennwert für Nachzüglerlatenz jenseits des 99. Perzentils.
- Metrik: retry_tail_p99
**Motivation:**
- Erkennen, ob Parallelität Streuung und Tail-Verhalten beeinflusst.
- Aufstellen einer Ursache-Wirkungs-Kette zwischen Last, Affinität und Resonanzbandbreite.
## Methode / Spezifikation
**Übersicht:**
- Setup identisch zu Run #28, lediglich Parallelität halbiert.
- Erhebung von band_center, band_width und retry_tail_p99 pro Run.
- Vergleich der Verteilungen über worker_id und queue_id.
**Algorithmen / Verfahren:**
- Vergleichende Analyse der statistischen Verteilungen von band_width und retry_tail_p99.
- IQR und FWHM (Interquartile Range, Full Width Half Max) zur Quantifizierung der Bandbreite.
- Kohortenanalyse zur Positionsstabilität von band_center.
### Bootstrap-Übersicht
Bootstrap-Resampling zur Stabilitätsprüfung der Mittelwertdifferenzen zwischen Runs.
**Zielgrößen:**
- band_width
- retry_tail_p99
### Resampling-Setup
- run_28
- run_29
**Stichprobeneinheit:** Messpunkt pro Worker
**Resampling-Schema:**
- Bootstrap mit 10.000 Ziehungen je Run
**Konfidenzintervalle:**
- Niveau: 0.95
- Typ: percentile
- Ableitung: empirisch aus Bootstrap-Stichproben
### Abgeleitete Effektgrößen
**Risk Difference (Differenz der Raten):**
- Definition: Differenz der Anteile an Messpunkten außerhalb des zentralen Bandes zwischen Runs.
- Bootstrap: CI-Berechnung aus der Bootstrap-Resampling-Verteilung.
**Risk Ratio:**
- Definition: Verhältnis der Wahrscheinlichkeit hoher Latenzen (retry_tail_p99 > Schwelle) zwischen 4× und 2× Parallelität.
- Bootstrap: Berechnung des mittleren Risk Ratios mit 95%-Bootstrap-CI.
## Input / Output
### Input-Anforderungen
**Hardware:**
- identische CPU- und Core-Konfiguration wie Run #28
**Software:**
- gleicher Benchmark-Build
- gleiche Logging- und Trace-Tools
**Konfiguration:**
- Affinitätsmodus enforced
- Parallelität 2×
- Burst-Start-Fenster unverändert
### Erwartete Rohdaten
**Felder pro Run:**
- timestamp
- worker_id
- queue_id
- band_center
- band_width
- retry_tail_p99
**Formatbeispiele:**
- 2024-06-17T15:30:02Z, worker_3, queue_1, 125.4, 48.2, 210.7
**Trace-Daten:**
- Format: CSV/JSON mit pro-Messzyklus-Metriken
- Hinweis: Erforderlich zur Kennlinie des Resonanzbandes pro Lauf.
### Analyse-Ausgaben
**Pro Gruppe / pro Governor:**
- mean_band_width
- median_band_center
- p99_retry_tail
- band_width_iqr
**Vergleichsausgaben:**
- run_28 (4× Parallelität) vs run_29 (2× Parallelität)
- Δ: Δband_width in Prozentpunkten
- CI(Δ): 95%-CI[Δband_width]
- RR: RR(retry_tail_p99)
- CI(RR): 95%-CI[RR]
- Tests: optional aus Bootstrap-Zusammenfassung
- C-State-Korrelation: nicht erhoben in Run #29
- Trace-Muster: Gleichmäßige Worker-Verteilung bestätigt, kein Queue-Umschlag.
## Workflow / Nutzung
**Analyse-Workflow:**
- Last-Setup laden
- Trace starten
- Parallelität auf 2× setzen
- Benchmark ausführen
- Ergebnisse per Autopsy-Tool analysieren
- Bandbreite, Zentrum und Tail extrahieren
- Ergebnisse mit Run #28 korrelieren
### Trace-Template-Anforderungen
**Ziel:** Nachvollziehbare Veränderung der Bandbreite durch Parallelitäts-Änderung darstellen.
**Erforderliche Tags & Metadaten:**
- worker_id
- queue_id
- parallelism_level
**trace-cmd-Setup:**
- Konstante Sampling-Rate
- Synchroner Startpunkt zur Vergleichbarkeit
**Run-Design für Contributors:**
- Nur eine Variable ändern (Parallelität)
- Sonstige Parameter fix halten
## Interpretation & erwartete Ergebnisse
**Kernbefunde:**
- band_width reduziert sich klar bei geringerer Parallelität.
- retry_tail_p99 fällt proportional mit ab.
- band_center bleibt stabil innerhalb Kohortenstreuung.
**Implikationen für Experimente:**
- Last wirkt primär als Verstärker für Resonanzeffekte.
- Parallelität beeinflusst die Stärke, nicht die Existenz des Resonanzbandes.
- Modelle zur Bandbreitensteuerung sollten Last als zentralen Faktor einbeziehen.
**Planungsziel:**
- Ziel: Vergleich der Effektgrößen von Parallelität (Run #29) und Affinität (Run #28) zur Baseline-Erstellung.
- Vorgehen:
- Drei-Kennzahlen-Vergleich: Δband_width, Δband_width_rel, Δretry_tail_p99.
## Limitationen & Fallstricke
**Datenbezogene Limitationen:**
- Einzellauf-Basis, keine Replikate.
- Fehlende Variation anderer Lastparameter kann Nebeneffekte verdecken.
**Bootstrap-spezifische Limitationen:**
- Bootstrap-Schätzung hängt von Sample-Größe pro Worker ab.
**Kausalität & Generalisierbarkeit:**
- Kausalität gilt nur für getestete Last- und Affinitätskonfigurationen.
**Praktische Fallstricke:**
- Ungeeignete Trace-Fenster können Bandbreite verfälschen.
- Nicht-synchronisierte Startbedingungen beeinträchtigen Vergleichbarkeit.
## Nächste Schritte & Erweiterungen
**Geplante Experimente:**
- Gegenüberstellung der Effektgrößen von Run #28 und Run #29 in gemeinsamen Tabellen.
**Analyseziele:**
- Berechnung einer Effektgrößen-Baseline für Parallelität und Affinität.
**Regression & Modellierung:**
- Mehrstufige Regressionsanalyse mit Faktoren: Parallelität, Affinität, Lastniveau.
**Community-Beiträge:**
- Bereitstellung der Raw-Daten zur Validierung der Resonanzkette durch Dritte.