Mika/affinity_and_parallelism_interaction
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
affinity_and_parallelism_in.../experiment_documentation/README.md

5.9 KiB
Raw Permalink Blame History

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).