| .. | ||
| README.md | ||
Interaktion von Affinität und Parallelität im Verteilungssystem
Purpose
Analyse der Wechselwirkungen zwischen Affinität und Parallelität in einem verteilten System hinsichtlich Bandbreite (IQR) und Retry‑Tail (p99‑Metrik).
Problemstellung: Der bisherige Affinitäts‑Effekt skaliert nicht linear mit Parallelität; es ist unklar, ob dieser Effekt durch Systemlast (Queueing) verstärkt wird.
Ziele:
- Quantifiziere den Einfluss der CPU‑Affinität auf Bandbreite und Tail‑Latenzen unter variierender Parallelität.
- Untersuche, ob sich Affinitäts‑ und Parallelitäts‑Effekte additiv oder interaktiv verhalten.
- Validiere, ob Queueing‑Sättigung den Affinitäts‑Effekt moduliert.
Kontext & Hintergrund
Laufdaten der Runs #28–#30 mit Metriken für Bandbreite als IQR (in Stunden) und retrytail_p99 relativ zu einer Baseline.
Gruppierung:
- Affinitäts‑Zustände (enforced, randomized)
- Parallelität (2×, 4×)
Trace-Metadaten / zusätzliche Tags:
- setup_fingerprint
- policy_hash
- Burst‑Start‑Fenster
Domänenkontext:
- Verteilte Systeme
- CPU‑Affinität
- Thread‑Parallelität
- Queueing‑Effekte
Outlier-Definition:
- Methode: IQR‑Methode
- Beschreibung: Bandbreite als Interquartilsabstand (IQR) über Messlaufzeit.
- Metrik: band_width (h)
Motivation:
- Erkennen von Interaktionen zwischen Scheduling‑Mechanismen und Laststeuerung.
- Ableitung stabiler Performance‑Regionen bei verschiedenen Parallelitätsstufen.
Methode / Spezifikation
Übersicht:
- Drei Runs (#28–#30) mit variierender Parallelität und Affinität.
- Vergleich der relativen band_width (IQR) und retrytail_p99 gegen Baseline.
- Berechnung der Effektgrößen (Differenzen und Prozentveränderungen).
Algorithmen / Verfahren:
- Identifiziere Baseline Run (#28 randomized, 4×).
- Berechne Δband_width und Δretrytail_p99 für Varianten.
- Interpretation der Interaktionsstärke als Abweichung vom additiven Modell.
Bootstrap-Übersicht
Nicht durchgeführt; analytische Betrachtung auf aggregierten Einzelwerten.
Zielgrößen:
- band_width
- retrytail_p99
Resampling-Setup
- Run‑Level (Affinität × Parallelität)
Stichprobeneinheit: Einzel‑Run
Resampling-Schema: Konfidenzintervalle:
- Niveau: 0.95
- Typ: analytisch (nicht berechnet)
Abgeleitete Effektgrößen
Risk Difference (Differenz der Raten):
- Definition: Nicht relevant; Kennzahlen sind kontinuierlich.
Risk Ratio:
- Definition: Nicht anwendbar; relative Effekte als Prozentdifferenzen notiert.
Input / Output
Input-Anforderungen
Hardware:
- Mehrkernprozessor mit konfigurierbarer Thread‑Affinität
Software:
- System‑Scheduler mit Affinitätssteuerung
- Messframework zur Laufzeitüberwachung
Konfiguration:
- Parallelitätslevels (2×, 4×, geplant 8×)
- Affinitätsmodi: enforced, randomized
Erwartete Rohdaten
Felder pro Run:
- run_id
- affinity_mode
- parallelism
- band_width_iqr_h
- retrytail_p99_delta
Formatbeispiele:
- #29, enforced, 2x, 3.9, -18%
Trace-Daten:
- Format: CSV
- Hinweis: Kompakte Effekt‑Tabelle mit Zeitmetriken und Relativwerten.
Analyse-Ausgaben
Pro Gruppe / pro Governor:
- band_width_iqr
- retrytail_p99_delta
Vergleichsausgaben:
-
#28 randomized 4× vs #28 enforced 4×
- Δ: band_width −1.7 h, retrytail_p99 +11%
-
#29 enforced 2× vs #30 randomized 2×
- Δ: band_width +0.3 h, retrytail_p99 +4%
-
Trace-Muster: Veränderte Queue‑Sättigung korreliert mit verringertem Affinitäts‑Einfluss.
Workflow / Nutzung
Analyse-Workflow:
- Definiere Baseline mit randomized Affinität und 4× Parallelität.
- Führe Runs mit variierender Affinität (enforced/off) bei fixierter Parallelität durch.
- Vergleiche Mittelwerte der Kennzahlen über Runs.
- Bewerte, ob Δband_width und Δretrytail_p99 proportional, subadditiv oder superadditiv interagieren.
Trace-Template-Anforderungen
Ziel: Erfassung konsistenter Performance‑Kennzahlen über Runs.
Erforderliche Tags & Metadaten:
- run_id
- affinity_mode
- parallelism
- retrytail_p99
- band_width_iqr_h
trace-cmd-Setup:
- Verwende identisches setup_fingerprint, policy_hash und Burst‑Start‑Fenster pro Vergleichsgruppe.
Run-Design für Contributors:
- Ändere pro Run nur einen Parameter (Single‑Toggle‑Prinzip).
Interpretation & erwartete Ergebnisse
Kernbefunde:
- Affinitäts‑Effekt nimmt mit steigender Parallelität zu.
- Bei 2× Parallelität ist der Einfluss von Affinität auf performance‑tails gering.
- Bei höherer Systemlast (4× oder mehr) verstärkt Queueing den Affinitäts‑Effekt.
Implikationen für Experimente:
- Affinitätssteuerung sollte je nach Lastgrad unterschiedlich bewertet werden.
- Eine isolierte Tuning‑Bewertung ohne Queueing‑Kontext kann zu Fehlschlüssen führen.
Planungsziel:
- Ziel: Vorbereitender Hochlast‑Test bei 8× Parallelität zur Validierung der Nichtlinearität.
- Vorgehen:
- Wiederholung der Vergleichsreihe bei 8×.
- Überprüfung, ob Effekte superlinear wachsen.
Limitationen & Fallstricke
Datenbezogene Limitationen:
- Kleine Stichprobengröße (drei Runs) limitiert statistische Aussagekraft.
Bootstrap-spezifische Limitationen:
- Keine Resampling‑Analyse durchgeführt.
Kausalität & Generalisierbarkeit:
- Kausalitäten angenommen, aber nicht experimentell isoliert bestätigt.
Praktische Fallstricke:
- Scheduler‑Bias möglich, wenn Threads nicht gleichmäßig verteilt werden.
Nächste Schritte & Erweiterungen
Geplante Experimente:
- Hochlast‑Run mit 8× Parallelität zur Überprüfung der Hypothese.
Analyseziele:
- Validiere Superlinearität des Affinitäts‑Einflusses auf band_width.
Regression & Modellierung:
- Erstellen eines einfachen Interaktionsmodells (Affinität × Last).
Community-Beiträge:
- Diskussion möglicher Visualisierungen (Differenz‑von‑Differenzen, Elastizitäts‑Plots).