6.2 KiB
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.