# Analyse der aux-Worker-Konfiguration (aux=1–3)

## Purpose

Vergleichsanalyse der Leistungswirkung verschiedener aux-Worker-Konfigurationen, um eine belastbare Standardkonfiguration für Log-Analyseprozesse festzulegen.

**Problemstellung:** Erhöhung der aux‑Worker‑Anzahl verbessert möglicherweise log‑basiertes I/O‑Verhalten, kann aber durch erhöhte Streuung und sinkende Effizienz saturieren. Ziel war, die optimale Anzahl von aux‑Workern zu bestimmen.

**Ziele:**
- Messung der Wirksamkeit zusätzlicher aux-Worker auf Hotspot‑Tail‑Latenzen
- Ermittlung von Varianz‑ und Bandbreitenänderungen bei Skalierung von aux‑Worker‑Anzahl
- Festlegung einer stabilen Betriebsregel auf Basis statistischer Schwellen

## Kontext & Hintergrund

Drei Messläufe (#34, #36, #37) mit identischer Messmethodik, variierender aux‑Worker‑Anzahl (1, 2, 3).

**Gruppierung:**
- aux=1
- aux=2
- aux=3

**Trace-Metadaten / zusätzliche Tags:**
- epoch_ms
- monotonic_ns
- tz_offset_minutes
- run_id
- step_id

**Domänenkontext:**
- Leistungsanalyse asynchroner Log-Verarbeitungs-Worker
- Bewertung von I/O-Lastverteilung und Timing-Streuung

**Outlier-Definition:**
- Methode: Interquartilsabstand (IQR)
- Beschreibung: Abweichungen jenseits des 1,5×IQR‑Bereichs gelten als Ausreißer im Latenzverhalten.
- Metrik: retry_tail_p99

**Motivation:**
- Reduktion der Latenzspitzen in near‑expiry‑unpinned Hotspots
- Vermeidung von Drift in band_width bei zunehmender Parallelität
- Entwicklung reproduzierbarer, regelbasierter Skalierungsentscheidungen

## Methode / Spezifikation

**Übersicht:**
- Vergleichsanalyse über drei Runs mit variierender aux‑Worker‑Zahl
- Auswertung mittels Median und Interquartilsabstand (IQR)
- Trennung der Metriken nach Hotspot‑Tail, Rest‑Tail und band_width

**Algorithmen / Verfahren:**
- Erfassen der Log‑Metriken unter identischen Rahmenbedingungen
- Berechnen von Median und IQR pro Kennzahl und aux‑Worker‑Gruppe
- Vergleich von Δp99 zwischen Runs
- Bewertung der Unterschiede anhand der IQR‑Spanne (Signifikanzkriterium Δ > IQR/2)

### Bootstrap-Übersicht

Verteilungsschätzung möglicher Stichprobenmedian‑Differenzen durch wiederholtes Resampling.

**Zielgrößen:**
- retry_tail_p99_Hotspot
- retry_tail_p99_Rest
- band_width

### Resampling-Setup

- aux=1
- aux=2
- aux=3

**Stichprobeneinheit:** Run‑Fenster (Zeitintervallmessung)

**Resampling-Schema:**
- bootstrap resampling
- 1.000 Wiederholungen pro Gruppe

**Konfidenzintervalle:**
- Niveau: 0.95
- Typ: percentile-based
- Ableitung: empirische Quantile der bootstrapped Differenzen

### Abgeleitete Effektgrößen

**Risk Difference (Differenz der Raten):**
- Definition: Differenz der relativen Häufigkeit hoher Latenzwerte zwischen Vergleichsgruppen.
- Bootstrap: Schätzung der CI der Differenz aus resampled Anteil hoher p99‑Werte.

**Risk Ratio:**
- Definition: Verhältnis der Wahrscheinlichkeit erhöhter Latenz bei höherer aux‑Zahl.
- Bootstrap: Resampling‑basierte Schätzung der Verteilungsverhältnisse.

### C-State-Kontrolle

**Ziel:** Sicherstellen, dass beobachtete Unterschiede nicht durch CPU‑Stromsparmodi beeinflusst werden.

**Vorgehen:**
- Fixieren der CPU‑C‑States während der Läufe
- Überwachung über Trace‑Metadata
- Dokumentation des setup_fingerprint zur Vergleichbarkeit

## Input / Output

### Input-Anforderungen

**Hardware:**
- Mehrkern‑CPU mit mindestens 4 Kernen
- Stabile I/O‑Speicherumgebung

**Software:**
- eigener Logger mit Sanity‑Header
- Telemetrie mit setup_fingerprint
- Statistikmodul zur Median/IQR‑Analyse

**Konfiguration:**
- aux‑Worker‑Zahl parametrierbar (1–3)
- identische Fensterung und Messperiode je Run

### Erwartete Rohdaten

**Felder pro Run:**
- epoch_ms
- monotonic_ns
- tz_offset_minutes
- run_id
- step_id
- retry_tail_p99
- band_width

**Formatbeispiele:**
- 1705123145,512312233122,60,36,12,0.015,3.5e+06

**Trace-Daten:**
- Format: CSV oder JSON‑Logdateien mit fixem Header
- Hinweis: setup_fingerprint dient zur Absicherung parametergleicher Läufe

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- Median
- IQR
- p99
- Drift‑Indikator (relative Varianz)

**Vergleichsausgaben:**
- aux=1 vs aux=2
  - Δ: deutliche Verbesserung von Hotspot‑p99
  - CI(Δ): positiv außerhalb IQR
  - RR: unter 1
  - CI(RR): eng, stabil
- aux=2 vs aux=3
  - Δ: gering, innerhalb IQR
  - CI(Δ): überlappt Null
  - RR: ≈1
  - CI(RR): breit, unsicher

- C-State-Korrelation: keine signifikanten Korrelationen beobachtet
- Trace-Muster: leicht erhöhte band_width‑Varianz bei aux=3

## Workflow / Nutzung

**Analyse-Workflow:**
- Parameterwahl (aux‑Worker‑Anzahl setzen)
- Run‑Durchführung mit identischen Bedingungen
- Log‑Erfassung und Sanity‑Header‑Validierung
- Statistische Auswertung (Median/IQR, Bootstrap optional)
- Sättigungskriterium prüfen (Δ < IQR/2)
- Default‑Entscheidung aktualisieren

### Trace-Template-Anforderungen

**Ziel:** Vergleichbare Runs ohne Tuning‑Artefakte erzeugen.

**Erforderliche Tags & Metadaten:**
- setup_fingerprint
- run_id
- aux_worker
- time_window_id

**trace-cmd-Setup:**
- fixierte CPU‑C‑States
- identische Logger‑Konfiguration
- synchronisierte Startbedingungen

**Run-Design für Contributors:**
- jeweils 1 Parameteränderung pro Run
- mindestens 3 Wiederholungen für Medianstabilität

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- aux=1 → aux=2 führt zu klar verbessertem Hotspot‑Tail (p99‑Verringerung außerhalb IQR)
- aux=2 → aux=3 zeigt keine signifikante Verbesserung, jedoch erhöhte Varianz in band_width
- Sättigungseffekt ab aux≥3 erkennbar

**Implikationen für Experimente:**
- aux=2 als stabiler Default sinnvoll
- weiteres Hochskalieren ohne strukturellen Vorteil
- Fokus künftig auf Steuerungsalgorithmik statt Worker‑Zahl

**Planungsziel:**
- Ziel: Definieren reproduzierbarer Entscheidungsregeln für Worker‑Skalierung.
- Vorgehen:
  - Vergleich ΔHotspot‑P99 gegen IQR/2‑Schwelle
  - Zusätzliche Driftbewertung von band_width in Frühfenstern

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- nur drei Runs, begrenzte Stichprobentiefe
- keine externe Replikation auf anderer Hardware

**Bootstrap-spezifische Limitationen:**
- Verteilungsschätzungen sensitiv für kleine Stichproben
- breite CI erschwert sichere Interpretation bei Δ≈0

**Kausalität & Generalisierbarkeit:**
- Resultate gelten nur für identische Logger‑ und I/O‑Profile
- keine direkte Generalisierung auf andere Task‑Typen

**Praktische Fallstricke:**
- unentdeckte Seiteneffekte bei paralleler Instrumentierung
- Verwechslung von Drift und Messrauschen bei kurzen Runs

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Analyse alternativer Scheduling‑Strategien für aux‑Worker
- Erweiterung durch präzisere Latenz‑Vorhersagemodelle

**Analyseziele:**
- Quantifizierung der band_width‑Driftursachen
- Messung der Trade‑offs zwischen Parallelität und Stabilität

**Regression & Modellierung:**
- Aufbau eines Regressionsmodells für aux‑Worker‑Effekte auf Latenzmetriken

**Community-Beiträge:**
- Bereitstellung der setup_fingerprint‑Methodik als offenes Vergleichsinstrument für ähnliche Experimente