6.5 KiB
Analyse der Runs #6–#10 zur Definition der Near‑Expiry‑Schwelle
Purpose
Auswertung der Runs #6–#10 zur Identifikation stabiler Timing-Muster und Definition einer datenbasierten Near‑Expiry‑Schwelle.
Problemstellung: Untersuchung negativer Zeitdifferenzen (Δt<0) zwischen Gate‑Read und Index‑Visibility unter verschiedenen Bedingungen (pinned/unpinned), um deterministische Fehlerquellen zu erkennen.
Ziele:
- Überprüfung der Stabilität zwischen pinned und unpinned Runs
- Quantifizierung und Klassifizierung der Δt<0‑Fälle
- Ableitung einer Schwelle für Near‑Expiry‑Definition (<24h)
Kontext & Hintergrund
Fünf Runs (#6–#10) unter identischer Instrumentierung und Exit‑Regel v1. Jeder Run zeichnet Metriken für pinned und unpinned Kontexte auf.
Gruppierung:
- pinned
- unpinned
Trace-Metadaten / zusätzliche Tags:
- corr_id zur Identifikation einzelner Fälle
- expires_at_dist_hours als Distanz bis Ablaufzeit
- Lag‑Vorzeichen aus Differenz (t_gate_read − t_index_visible)
Domänenkontext:
- Verteilte Systeme mit zeitkritischen Sichtbarkeitsfenstern
- Fehleranalyse durch Latenzsignale in synchronisierten Prozessen
Outlier-Definition:
- Methode: Schwellenbasiert
- Beschreibung: Fälle werden als Ausreißer markiert, wenn expires_at_dist_hours > 24h bei Δt<0 auftritt.
- Metrik: expires_at_dist_hours
Motivation:
- Stabilisierung von Systemtimings durch präzise Definition von Near‑Expiry‑Zonen
- Schaffung einer reproduzierbaren Baseline für A/B‑Tests
Methode / Spezifikation
Übersicht:
- Vergleich von pinned und unpinned Runs hinsichtlich Δt<0‑Fällen
- Konsolidierung der Einzelereignisse über die Runs #6–#10
- Analyse des Verteilungsverhaltens von expires_at_dist_hours
Algorithmen / Verfahren:
- Zählen der Δt<0‑Fälle pro Run und Stratum
- Prüfen des Vorzeichens von (t_gate_read − t_index_visible)
- Zuordnung nach expires_at_dist_hours
- Ableitung der Near‑Expiry‑Schwelle basierend auf Häufigkeitsverteilung
Bootstrap-Übersicht
Nicht angewandt
Zielgrößen:
Resampling-Setup
Resampling-Schema: Konfidenzintervalle:
- Niveau: 0.95
Abgeleitete Effektgrößen
Risk Difference (Differenz der Raten):
- Definition: Vergleich der Δt<0‑Inzidenz zwischen pinned und unpinned Runs.
- Bootstrap: Nicht durchgeführt, da Stichprobenumfang gering.
Risk Ratio:
- Definition: Quotient aus unpinned‑Δt<0‑Rate zu pinned‑Δt<0‑Rate über Runs #6–#10.
- Bootstrap: Nicht angewandt.
C-State-Kontrolle
Ziel: Minimierung von Timing‑Drift durch stabile Prozessbedingungen.
Vorgehen:
- Alle Runs unter identischer Prozess‑ und Regelkonfiguration
- Keine Änderungen der Instrumentierung oder Exit‑Regel
Input / Output
Input-Anforderungen
Hardware:
- Standardisierte Umgebung pro Run, konstant gehalten
Software:
- Instrumentierung für Gate‑ und Index‑Timing‑Messungen
- Datenlogging für corr_id und expires_at_dist_hours
Konfiguration:
- Exit‑Regel v1 unverändert in allen Runs
Erwartete Rohdaten
Felder pro Run:
- run_id
- stratum
- corr_id
- t_gate_read
- t_index_visible
- expires_at_dist_hours
Formatbeispiele:
- run: #8, stratum: unpinned, corr_id: U8-A, expires_at_dist_hours: 12.1, sign: negativ
Trace-Daten:
- Format: Tabellarisch pro Run mit konsolidierter Δt‑Zählung
- Hinweis: Δt<0 markiert Vorzeichenwechsel in Sichtbarkeitszeitpunkt
Analyse-Ausgaben
Pro Gruppe / pro Governor:
- warn rate ≈ 0.06 (pinned)
- unknown rate ≈ 0.00 (pinned)
- Δt<0-Fälle: 0 (pinned), 1–2 (unpinned)
Vergleichsausgaben:
-
pinned vs unpinned
- Δ: +15–20 Prozentpunkte Δt<0‑Inzidenz
- RR: >5x
-
C-State-Korrelation: Nicht signifikant oder konstant über Runs.
-
Trace-Muster: Unpinned zeigt konsistentes negatives Lag‑Vorzeichen über alle Runs.
Workflow / Nutzung
Analyse-Workflow:
- Importiere Run‑Logs #6–#10
- Filtere nach Δt<0‑Fällen
- Klassifiziere pro Stratum (pinned/unpinned)
- Berechne expires_at_dist_hours‑Verteilung
- Setze Near‑Expiry‑Grenze bei <24h
- Überführe Schwelle in A/B‑Test‑Design
Trace-Template-Anforderungen
Ziel: Konsistente Erfassung von Timing‑Differenzen zur Erkennung strukturierter Latenzmuster.
Erforderliche Tags & Metadaten:
- corr_id
- expires_at_dist_hours
- t_gate_read
- t_index_visible
trace-cmd-Setup:
- Verwende identische Sampling‑Intervalle und Log‑Frequenz pro Run
Run-Design für Contributors:
- Keine Regeländerung zwischen Runs innerhalb der Baseline
- Separate Kennzeichnung für pinned und unpinned Sessions
Interpretation & erwartete Ergebnisse
Kernbefunde:
- Δt<0‑Fälle treten ausschließlich im unpinned‑Stratum auf.
- 6 von 7 Δt<0‑Fällen liegen unter 24h expires_at_dist_hours.
- Kein einziger Fall mit positivem Lag‑Vorzeichen.
Implikationen für Experimente:
- Die Near‑Expiry‑Schwelle <24h wird als stabile Entscheidungsbasis übernommen.
- Baseline‑Runs #6–#10 liefern konsistentes Muster für weitere Tests.
Planungsziel:
- Ziel: Definition einer datenbasierten Schwelle für Near‑Expiry‑Regeln.
- Vorgehen:
- Empirische Aggregation von Δt<0‑Fällen über Serien‑Runs
- Auswahl konservativer Schwelle zur Minimierung von False Positives
Limitationen & Fallstricke
Datenbezogene Limitationen:
- Kleine Stichprobe (nur 7 Δt<0‑Fälle)
- Kein separates Validierungsset außerhalb Runs #6–#10
Bootstrap-spezifische Limitationen:
- Keine Bootstrap‑Verfahren angewandt, daher keine Konfidenzintervalle
Kausalität & Generalisierbarkeit:
- Kausalität nur innerhalb identischer Regelkonfigurationen prüfbar
- Ergebnisse gelten nicht für geänderte Instrumentierungsvarianten
Praktische Fallstricke:
- Verwechslung von Lag‑Vorzeichen durch Messlatenz möglich
- Beobachtungszone 24–48h darf Entscheidungslogik nicht beeinflussen
Nächste Schritte & Erweiterungen
Geplante Experimente:
- A/B‑Test mit Near‑Expiry‑Schwelle <24h vs. Kontrollgruppe ohne Schwelle
Analyseziele:
- Überprüfung der Reproduzierbarkeit des Lag‑Musters
- Test auf Stabilität der Warn‑Rate bei neuen Runs
Regression & Modellierung:
- Erweiterung zur Trendanalyse über mehrere Baselines
- Modellierung der Lag‑Verteilung über expires_at_dist_hours
Community-Beiträge:
- Dokumentation der Near‑Expiry‑Heuristik im internen Knowledge‑Repo
- Veröffentlichung der Run‑Datenstruktur für Replikationsstudien