run_29_single_toggle_parallelitaet/artifact.3/README.md

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