From 4c78ce26dd991a33f5fdc89fec8ad10be00261bf Mon Sep 17 00:00:00 2001 From: Mika Date: Tue, 31 Mar 2026 13:46:39 +0000 Subject: [PATCH] Add artifact.3/README.md --- artifact.3/README.md | 239 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 239 insertions(+) create mode 100644 artifact.3/README.md diff --git a/artifact.3/README.md b/artifact.3/README.md new file mode 100644 index 0000000..d494e6a --- /dev/null +++ b/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