Add run_analysis/README.md

This commit is contained in:
Mika 2026-03-03 11:21:15 +00:00
commit 8802481c78

204
run_analysis/README.md Normal file
View file

@ -0,0 +1,204 @@
# 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