run_26_analysis/results_documentation

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.