run_26_analysis/results_documentation/README.md

# Analyse von Startoffsets und Latenzverhalten – Run #26

## Purpose

Technische Dokumentation der Messergebnisse und Hypothesenvalidierung zur Wirkung von Startverzögerungen auf Resonanzband und Latenz.

**Problemstellung:** Unklar war, ob beobachtete Latenzresonanzen durch inhaltliche Schritte (Step) oder durch Startzeitmuster (Scheduling) ausgelöst werden.

**Ziele:**
- Untersuchung des Einflusses von Startoffets auf beobachtete Latenzstrukturen.
- Validierung der Hypothese, dass Startzeitcluster Resonanzeffekte mitverursachen.
- Erfassung der Veränderungen in Bandbreite und Mittelposition des Resonanzbands zwischen Run #25 und #26.

## Kontext & Hintergrund

Zeitreihen-Logdaten der Worker-Prozesse in Run #26, identische Policies und Hashes wie in Runs #22–#25.

**Gruppierung:**
- Workerinstanzen pro Run
- Startzeitkohorten nach Jitter-Fenster

**Trace-Metadaten / zusätzliche Tags:**
- worker_start_offset als Ableitung aus first-seen timestamps
- expires_at_dist_hours zur Lebensdauerbetrachtung pro Worker
- retry_total_overhead_ms als Latenzindikator

**Domänenkontext:**
- Systemlatenzanalyse
- Workload-Scheduling
- Experimentelle CPU-/I/O-Kohortenmessung

**Outlier-Definition:**
- Methode: Perzentilbasierte Identifikation (p95/p99) der retry_total_overhead_ms
- Beschreibung: Max-Outlier definiert durch obere 5 % bzw. 1 % der messbaren Latenzen.
- Metrik: retry_total_overhead_ms

**Motivation:**
- Quantifizierung des Einflusses von Startzeitverteilung auf Latenzresonanzen.
- Identifikation mechanisch stabiler Muster jenseits zufälliger Drift.
- Trennung von inhaltlich getriebenen und zeitlich strukturellen Effekten.

## Methode / Spezifikation

**Übersicht:**
- Run #26 nutzt ein Jitter-Fenster für gestaffelten Worker-Start.
- Alle übrigen Parameter bleiben konstant gegenüber Run #25.
- Vergleich der resultierenden Resonanzbandstruktur zwischen den Runs.

**Algorithmen / Verfahren:**
- Berechne worker_start_offset als Differenz zwischen Worker-first-seen und Run-Start.
- Plot: Scatter oder Heatmap von start_offset vs. expires_at_dist_hours.
- Farbskala: retry_total_overhead_ms pro Punkt.
- Berechne Cluster-Score zur Quantifizierung von Startkohortenverdichtung.

### Bootstrap-Übersicht

Bootstrap-Resampling zur Unsicherheitsabschätzung der Mittelverschiebung im Resonanzband.

**Zielgrößen:**
- Bandmittelpunkt in expires_at_dist_hours
- Bandbreite (Standardabweichung)
- Cluster-Score pro Startkohorte

### Resampling-Setup

- Runs #25 und #26 getrennt resampeln

**Stichprobeneinheit:** Worker

**Resampling-Schema:**
- 1000 Bootstrap-Iterationen je Gruppe
- Berechnung von 95 %-Konfidenzintervallen

**Konfidenzintervalle:**
- Niveau: 0.95
- Typ: percentile
- Ableitung: Mittelwertunterschied der Bandposition

### Abgeleitete Effektgrößen

**Risk Difference (Differenz der Raten):**
- Definition: Unterschied der Häufigkeit von Latenzen >90 ms zwischen Run #25 und #26.
- Bootstrap: Resampling zur Ableitung der CI-Grenzen für den Anteilunterschied.

**Risk Ratio:**
- Definition: Verhältnis des Überkopfrisikos (retry_total_overhead_ms>90 ms) zwischen Burst- und Jitter-Start.
- Bootstrap: Resampling für CI-Schätzung des Risk Ratios.

### C-State-Kontrolle

**Ziel:** Konstanthaltung der CPU-Zustände und Systemlast zur Isolierung des Startmuster-Effekts.

**Vorgehen:**
- Keine Änderung an power-governor oder Idle-Stufen.
- Lastprofile identisch über alle Runs.

## Input / Output

### Erwartete Rohdaten

**Felder pro Run:**
- worker_id
- first_seen_ts
- expires_at_ts
- retry_total_overhead_ms

**Formatbeispiele:**
- worker_id=17 first_seen_ts=2024-03-10T14:22:05Z expires_at_ts=2024-03-10T15:02:00Z retry_total_overhead_ms=73.4

**Trace-Daten:**
- Format: CSV/structured log
- Hinweis: Zeitstempel normiert auf Run-Startzeitpunkt (t=0 s).

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- p95/p99 retry_total_overhead_ms
- Mittelwert und Standardabweichung von expires_at_dist_hours
- Cluster-Dichte nach start_offset

**Vergleichsausgaben:**
- Run #25 (Burst) vs Run #26 (Jitter)
  - Δ: -3.4 pp Anteil >90 ms Latenz
  - CI(Δ): [-5.8 pp, -1.0 pp]
  - RR: 0.89
  - CI(RR): [0.84, 0.96]

- C-State-Korrelation: Keine signifikante Änderung zwischen Runs.
- Trace-Muster: Resonanzband-Mittelpunktrückkehr zur Lage aus Run #22/#23, Bandbreite schwankt zwischen 0.7–1.1 h.

## Workflow / Nutzung

**Analyse-Workflow:**
- Lese Logdaten pro Run ein.
- Berechne start_offset pro Worker.
- Erzeuge Scatter/Heatmap von start_offset vs. expires_at_dist_hours.
- Färbe Punkte nach retry_total_overhead_ms.
- Berechne Cluster-Dichte-Metrik.
- Vergleiche zwischen Runs (Burst vs. Jitter).

### Trace-Template-Anforderungen

**Ziel:** Erfassung reproduzierbarer Startzeitdaten für Vergleich von Schedulingmustern.

**Erforderliche Tags & Metadaten:**
- run_id
- worker_id
- first_seen_ts
- expires_at_ts
- retry_total_overhead_ms

**trace-cmd-Setup:**
- Normiere Zeitbasis auf Run-Start.
- Erfasse alle Worker-Ereignisse ab Startzeitpunkt.

**Run-Design für Contributors:**
- Runs mit identischen Policies und Hashes durchführen.
- Nur ein Toggle (Burst vs. Jitter) ändern.
- Mindestens 500 Worker-Instanzen zur Signifikanzsicherung.

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Max-Outlier bleiben step-getrieben und unverändert zwischen Runs.
- Resonanzband zeigt klare Reaktion auf geändertes Startmuster.
- Bandbreite sinkt und Mittelwert driftet zurück Richtung früherer Runs (#22/#23).
- Startkohorten beeinflussen Latenzverteilung signifikant.

**Implikationen für Experimente:**
- Schedulingmuster sind aktive Einflussfaktoren auf Latenzstrukturen.
- Startoffset-Jitter kann Resonanzeffekte abschwächen.
- Timingänderungen sind messbare Systemdesignhebel.

**Planungsziel:**
- Ziel: Verifikation der Hypothese, dass Startkohortenstruktur Latenzresonanzen induziert.
- Vorgehen:
  - Runs mit variiertem Startverhalten aber identischem Inhalt vergleichen.
  - Latenzstrukturen über Heatmaps und Cluster-Scores analysieren.

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Kleinere Samples einzelner Worker können Clusterstatistik verzerren.
- Eventuell ungleichmäßige Logtick-Dichte über Workergruppen.

**Bootstrap-spezifische Limitationen:**
- Resampling setzt unabhängige Workerannahme voraus.
- Korrelationen zwischen Workerinstanzen können Unsicherheitsbandbreite unterschätzen.

**Kausalität & Generalisierbarkeit:**
- Korrelation zeigt Mechanik, aber keine vollständige Kausalitätsbeziehung.
- Ergebnisse übertragbar nur auf ähnliche Schedulingregime.

**Praktische Fallstricke:**
- Unpräzise Startzeitstempel verfälschen Offsets.
- Zu kleiner Jitterbereich kann Effekt unterschwellig halten.

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Run #27 – Burst-Start mit zeitversetztem Burst-Fenster zur Testung synchroner Bandverschiebung.

**Analyseziele:**
- Überprüfung der relativen Verschiebung des Resonanzbands bei verlagertem Startfenster.
- Erweiterung der Clusteranalyse um Kohortenlaufzeitvergleiche.

**Regression & Modellierung:**
- Modellierung der Bandposition als Funktion des Startoffset-Mittels pro Workergruppe.
- Lineare Regression oder Mixed-Effect-Modell zur Schätzung des Jitter-Einflusses.

**Community-Beiträge:**
- Bereitstellung von Trace-Templates und Heatmap-Skripten für Nachanalyse durch andere Runs.
- Austausch über Resonanzmuster im Donau2Space-Forum.