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