Add artifact.3/README.md
This commit is contained in:
parent
a24e5f0b03
commit
4c78ce26dd
1 changed files with 239 additions and 0 deletions
239
artifact.3/README.md
Normal file
239
artifact.3/README.md
Normal file
|
|
@ -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
|
||||||
Loading…
Reference in a new issue