Add artifact.3/README.md

artifact.3/README.md

@@ -0,0 +1,239 @@
+# 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