| .. | ||
| README.md | ||
Vergleichsanalyse der Läufe #28, #31a und #31b mit Fokus auf Bandbreite und Retry-Tailp99
Purpose
Technische Vergleichsdokumentation der Replikationsläufe #28, #31a und #31b mit Identifikation von Mustern in Bandbreite und retry_tailp99.
Problemstellung: Bei Verdopplung der Parallelität von 4× auf 8× zeigte sich ein erhöhter retry_tailp99. Es soll überprüft werden, ob dieser Effekt reproduzierbar ist und welche Mechanismen ihn verursachen.
Ziele:
- Feststellen, ob Experiment #31b das Ergebnis von #31a repliziert
- Analyse des Zusammenhangs zwischen Parallelität, Bandbreite und Retry-Tailp99-Verhalten
- Bewertung des Tail-Risk für 8×-Parallelität
Kontext & Hintergrund
Drei Läufe (#28 randomized 4×, #31a 8×, #31b 8×) mit identischem Setup-Fingerprint und Policy-Hash.
Gruppierung:
- Baseline (#28)
- Replikation (#31a, #31b)
Trace-Metadaten / zusätzliche Tags:
- setup_fingerprint
- policy_hash
- windowing/exiting rules
Domänenkontext:
- Replikationsexperimente im Netzwerk- oder IO-Performance-Kontext
- Analyse von Sättigungs- und Queueing-Effekten bei Parallelitätssteigerung
Outlier-Definition:
- Methode: Proportionale Schwellenprüfung
- Beschreibung: Ein Lauf gilt als kritisch, wenn retry_tailp99 ≥15 % über Baseline liegt.
- Metrik: retry_tailp99
Motivation:
- Nachweis, ob die beobachtete Tail-Verschlechterung systematisch oder zufällig ist
- Bewertung, ob 8×-Parallelität als stabiles Betriebsregime geeignet ist
Methode / Spezifikation
Übersicht:
- Standardisierte Auswertung mit gleichbleibenden Skripten über drei Runs
- Messung von Bandbreite (h), retry_tailp99 und delta_vs_baseline
Algorithmen / Verfahren:
- Vergleich der Runs unter identischen Bedingungen
- Berechnung der Differenzen zu Baseline (#28)
- Segmentierung nach Strata: near-expiry-unpinned vs. Rest
Input / Output
Erwartete Rohdaten
Felder pro Run:
- run_id
- parallelism
- bandwidth
- delta_vs_baseline
- retry_tailp99
- retry_tailp99_threshold
Formatbeispiele:
- {"run_id": "31b", "parallelism": 8, "bandwidth": 6.2, "delta_vs_baseline": -0.6, "retry_tailp99": "+17%", "retry_tailp99_threshold": 15}
Analyse-Ausgaben
Pro Gruppe / pro Governor:
- mittlere Bandbreite (h)
- Delta vs. Baseline
- retry_tailp99-Anstieg relativ zur Schwelle
Vergleichsausgaben:
-
#28 vs #31a
- Δ: Bandbreite -0.7h, retry_tailp99 +18%
-
#28 vs #31b
- Δ: Bandbreite -0.6h, retry_tailp99 +17%
-
Trace-Muster: Hotspot im Stratum near-expiry-unpinned identifiziert
Workflow / Nutzung
Analyse-Workflow:
- Verifizieren der Setup-Identität (Fingerprint, Policy-Hash, Skripte)
- Auswertung von Bandbreite und retry_tailp99 pro Lauf
- Vergleich der 8×-Runs mit Baseline
- Segmentanalyse (near-expiry-unpinned vs. Rest)
- Interpretation der Ursache (Queueing/Sättigung vs. Scheduling/Mixing)
Interpretation & erwartete Ergebnisse
Kernbefunde:
- retry_tailp99 steigt bei 8× reproduzierbar über 15 % an
- Bandbreite bleibt stabil, kein Kollaps
- Hotspot: near-expiry-unpinned trägt Hauptanteil am Tail-Anstieg
Implikationen für Experimente:
- Replikation bestätigt den Tail-Risk bei 8×
- Mechanismus wahrscheinlich Queueing-bedingt, nicht Scheduling-bedingt
Planungsziel:
- Ziel: Identifikation und Isolierung des kritischen Strata mit Tail-Instabilität
- Vorgehen:
- Gezielte Entkopplung von near-expiry-unpinned
- Vermeidung globaler Parameteränderungen
Limitationen & Fallstricke
Datenbezogene Limitationen:
- Nur drei Runs, begrenzte Stichprobe
- Keine zusätzlichen Metriken zur Latenzverteilung
Kausalität & Generalisierbarkeit:
- Effekt kausal plausibel, aber experimentell eng begrenzt auf aktuelle Strukturen
Praktische Fallstricke:
- 8×-Parallelität kann je nach Systemzustand variabel reagieren
- Segmentierung erforderlich, sonst Gefahr der Fehlinterpretation
Nächste Schritte & Erweiterungen
Geplante Experimente:
- Isolierter Testlauf ausschließlich im near-expiry-unpinned-Segment mit 8×
Analyseziele:
- Validierung der Entkopplung durch Segment-spezifisches Limit
Regression & Modellierung:
- Modellierung des Queueing-Verhaltens bei erhöhter Nachfrage im Tail
Community-Beiträge:
- Verifikation durch unabhängige Replikationen mit identischem Setup