165 lines
4.9 KiB
Markdown
165 lines
4.9 KiB
Markdown
# Logging-Format für Run #13 (minimale Intervention mit Retry-Mechanismus)
|
||
|
||
## Purpose
|
||
|
||
Spezifikation des erweiterten Logging-Formats für die Messungen im Run #13 mit minimaler Intervention zur Behandlung von Δt<0-Fällen.
|
||
|
||
**Problemstellung:** In Run #13 wurde ein inkonsistentes Auftreten von negativen Δt-Werten beobachtet. Es wurde ein Retry-Mechanismus eingeführt, der exakt einmal bei Δt<0 greift. Das Logging-Format musste erweitert werden, um Retry-Aktivität und Korrekturstatus erkennbar zu machen.
|
||
|
||
**Ziele:**
|
||
- Kompatibilität mit Logging-Formaten der Runs #11 und #12 sicherstellen
|
||
- Integration zusätzlicher Felder zur Nachverfolgung des Retry-Mechanismus
|
||
- Analysefähigkeit für Δt<0-Kandidaten erhalten
|
||
|
||
## Kontext & Hintergrund
|
||
|
||
Zeitmessungen pro Stratum (fresh/near-expiry) und Pinning-Status (pinned/unpinned).
|
||
|
||
**Gruppierung:**
|
||
- fresh-pinned
|
||
- fresh-unpinned
|
||
- near-expiry-pinned
|
||
- near-expiry-unpinned
|
||
|
||
**Trace-Metadaten / zusätzliche Tags:**
|
||
- Messzeitpunkt
|
||
- Δt-Berechnung
|
||
- Retry-Zustand
|
||
|
||
**Domänenkontext:**
|
||
- Zeitmessstabilität bei near-expiry-Objekten
|
||
- Einflussfaktoren auf Δt-Streuung
|
||
- Laufzeitverhalten im Kurzfenster unter 200 ms
|
||
|
||
**Outlier-Definition:**
|
||
- Methode: Δt<0-Erkennung
|
||
- Beschreibung: Eine Messung gilt als Ausreißer, wenn die beobachtete Zeitdifferenz Δt negativ ist.
|
||
- Metrik: Δt
|
||
|
||
**Motivation:**
|
||
- Prüfen, ob minimaler Eingriff Fehlerfälle stabilisiert
|
||
- Systemverhalten bei near-expiry-unpinned-Stratum isoliert analysieren
|
||
- Kompatibilität der Messserien sicherstellen
|
||
|
||
## Methode / Spezifikation
|
||
|
||
**Übersicht:**
|
||
- Ein Retry-Mechanismus wird bei Δt<0 ausgelöst.
|
||
- Nach exakt einem Retry erfolgt erneute Messung.
|
||
- Das zweite Ergebnis ersetzt das erste.
|
||
- Keine Heuristiken oder mehrere Wiederholungen.
|
||
|
||
**Algorithmen / Verfahren:**
|
||
- Erfassen von Δt pro Messung.
|
||
- Prüfen auf Δt<0.
|
||
- Falls true: warten um festen Delay.
|
||
- Einmalige Wiederholung der Messung.
|
||
- Speichern des Retry-Zustands im Log.
|
||
|
||
## Input / Output
|
||
|
||
### Erwartete Rohdaten
|
||
|
||
**Felder pro Run:**
|
||
- timestamp
|
||
- Δt
|
||
- stratum
|
||
- pinned
|
||
- retry_taken
|
||
- retry_fixed
|
||
|
||
**Formatbeispiele:**
|
||
- {"timestamp":"2024-04-12T08:43:10.158Z","Δt":-18.2,"stratum":"near-expiry-unpinned","pinned":false,"retry_taken":true,"retry_fixed":true}
|
||
|
||
**Trace-Daten:**
|
||
- Format: JSON-Zeilenformat
|
||
- Hinweis: Die Felder retry_taken und retry_fixed sind nur im Stratum near-expiry-unpinned relevant.
|
||
|
||
### Analyse-Ausgaben
|
||
|
||
**Pro Gruppe / pro Governor:**
|
||
- warn_rate
|
||
- unknown_rate
|
||
- count(Δt<0_pre_retry)
|
||
- count(Δt<0_post_retry)
|
||
|
||
**Vergleichsausgaben:**
|
||
- Run #12 vs Run #13
|
||
- Δ: Δt<0-Inzidenz vor Retry vs. nach Retry
|
||
|
||
## Workflow / Nutzung
|
||
|
||
**Analyse-Workflow:**
|
||
- Filterung nach Stratum near-expiry-unpinned.
|
||
- Erkennen von Δt<0-Fällen.
|
||
- Überprüfen, ob retry_taken==true.
|
||
- Auswertung der retry_fixed-Raten.
|
||
- Vergleich mit Vorläufen #11 und #12 zur Stabilitätsbewertung.
|
||
|
||
### Trace-Template-Anforderungen
|
||
|
||
**Ziel:** Kompatibilität der Logstruktur zwischen den Runs.
|
||
|
||
**Erforderliche Tags & Metadaten:**
|
||
- timestamp
|
||
- Δt
|
||
- retry_taken
|
||
- retry_fixed
|
||
|
||
**trace-cmd-Setup:**
|
||
- Keine zusätzlichen Sensoren aktivieren.
|
||
- Standardbuffergröße beibehalten.
|
||
- Retry nur auf Δt<0 triggern.
|
||
|
||
**Run-Design für Contributors:**
|
||
- Run-Struktur nicht ändern.
|
||
- Messbedingungen gleich zu #11/#12 halten.
|
||
- Keine neuen Strata oder Schwellen einführen.
|
||
|
||
## Interpretation & erwartete Ergebnisse
|
||
|
||
**Kernbefunde:**
|
||
- Alle Δt<0-Kandidaten wurden durch einmaligen Retry korrigiert (retry_fixed=true).
|
||
- Kein Anstieg der warn_rate oder unknown_rate im Vergleich zu Vorläufen.
|
||
- Δt≥0 nach Retry in 100 % der beobachteten Fälle.
|
||
|
||
**Implikationen für Experimente:**
|
||
- Einmaliger Retry kann Δt-Stabilität im near-expiry-Bereich sicherstellen.
|
||
- Weitere Messungen mit größerer Stichprobe erforderlich zur Quantifizierung der Latenzkosten.
|
||
|
||
**Planungsziel:**
|
||
- Ziel: Nachweis, dass minimaler Retry lokale Instabilität zuverlässig eliminiert.
|
||
- Vorgehen:
|
||
- Target-Stratum begrenzen.
|
||
- Nur bei Δt<0 eingreifen.
|
||
- Base configuration unverändert lassen.
|
||
|
||
## Limitationen & Fallstricke
|
||
|
||
**Datenbezogene Limitationen:**
|
||
- Begrenzte Samplegröße reduziert Aussagekraft.
|
||
- Retry-Dauer bisher nicht als Messgröße enthalten.
|
||
|
||
**Kausalität & Generalisierbarkeit:**
|
||
- Ergebnis nur für near-expiry-unpinned-Stratum valide.
|
||
- Kein Nachweis für langfristige Stabilisierung oder andere Kontexte.
|
||
|
||
**Praktische Fallstricke:**
|
||
- Retry könnte in Lastsituationen Timingverhalten verzerren.
|
||
- Fehlende Quantifizierung der Retry-Latenz.
|
||
|
||
## Nächste Schritte & Erweiterungen
|
||
|
||
**Geplante Experimente:**
|
||
- Erweiterung der Stichprobe auf mehrere Tagesläufe.
|
||
- Direkte Messung der Retry-Latenzzeit.
|
||
|
||
**Analyseziele:**
|
||
- Quantitative Bewertung der Stabilisierung vs. Latenzkosten.
|
||
- Überprüfung der Robustheit gegen Zufallsfluktuationen.
|
||
|
||
**Regression & Modellierung:**
|
||
- Fit eines einfachen Modells zur Wahrscheinlichkeit Δt<0 vor und nach Retry.
|
||
|
||
**Community-Beiträge:**
|
||
- Bereitstellung der Logformate zur externen Validierung und Reanalyse.
|