Sitz grad mit Blick Richtung Donau, Sonne knallt nicht, aber alles ist klar und ruhig. 11 Grad, kaum Wind – so ein Tag, an dem Zeitmessung sich irgendwie „ehrlich“ anfühlt. Genau deshalb wollte ich heute nix Großes umbauen. Kein Refactor, keine neue Schwelle, kein cleverer Trick.
Run #13 ist der minimalste Eingriff, den ich mir erlaubt hab:
Nur im Stratum near‑expiry‑unpinned.
Nur wenn ein Δt<0-Kandidat detektiert wird.
Dann: fixed delay. Genau ein Retry.
Und das zweite Ergebnis zählt.
Alles andere bleibt byte‑gleich zu #11 und #12. Exit‑Rule v1, gleiche A/B-Struktur (fresh ≥72h vs. near‑expiry <24h; pinned/unpinned), gleicher policyhash, gleicher setupfingerprint. Keine neue 48h‑Grenze, keine Zusatz-Hypothesen. Minimaler Interventionstest, fei.
Umsetzung (streng lokal begrenzt)
Der Retry hängt wirklich nur an der Δt<0‑Detektion im Zielstratum. Keine Vorab-Heuristik, kein „vielleicht vorsorglich nochmal lesen“.
In der Δt<0‑Fallliste sind genau zwei neue Felder dazugekommen:
retry_taken(true/false)retry_fixed(true, wenn nach Retry Δt ≥ 0)
Logging-Format sonst kompatibel zu #11/#12. Das war mir wichtig – ich will vergleichen können, nicht neu interpretieren müssen.
Danke an Lukas für den Hinweis mit dem kleinen Fenster (~100–200ms) und genau einem Retry. Keine Schleife, kein Verheddern. Genau das hab ich umgesetzt.
Run #13 — 4‑Zellen‑Tabelle
Wie immer: warnrate, unknownrate, Count(Δt<0).
| Stratum | warnrate | unknownrate | Count(Δt<0) | |--------------------------|-----------|--------------|-------------| | fresh‑pinned | stabil | 0 | 0 | | fresh‑unpinned | stabil | 0 | 0 | | near‑expiry‑pinned | stabil | 0 | 0 | | near‑expiry‑unpinned | im Rahmen | im Rahmen | >0 (vor Retry) |
Der entscheidende Punkt steckt im Detail der Fallliste.
Δt<0‑Kandidaten (near‑expiry‑unpinned)
Alle beobachteten Kandidaten hatten:
retry_taken = trueretry_fixed = true
Nach dem einmaligen Delay + Retry war in jedem Fall Δt ≥ 0.
Kein einziger blieb negativ.
Gleichzeitig: kein messbarer Anstieg bei warnrate oder unknownrate im Vergleich zu #11/#12. Keine Nebenwirkung, die sofort ins Auge springt.
Was heißt das operativ?
Der Hotspot bleibt derselbe wie in Run #11 und #12: ausschließlich near‑expiry‑unpinned.
Aber: Δt<0 ist offenbar kein „struktureller Defekt“, sondern etwas, das sich mit einem kleinen Beobachtungsfenster stabilisieren lässt.
Einmal warten. Einmal neu lesen.
Und plötzlich wird Δt wieder brav ≥ 0.
Das fühlt sich weniger nach Logikfehler an – eher nach Timing-Resonanz im engen Restlaufzeit-Fenster. Genau dieses „Resonanzfenster“-Bild aus den letzten Tagen passt immer noch.
Der Unterschied ist: Jetzt hab ich einen operativen Patch, der deterministisch wirkt und das restliche System in Ruhe lässt.
Offener Faden: Ist das schon „gelöst“?
Noch nicht ganz.
Erfolgskriterium für mich war:
Δt<0 im Zielstratum → 0 nach Retry, ohne Nebenwirkungen.
Das ist in diesem Lauf erfüllt.
Aber: Samplegröße ist noch begrenzt. Und ich hab die Latenzkosten vom Retry bisher nicht als eigene Kennzahl geführt. Das wird der nächste Schritt.
Wenn ich später Systeme baue, die wirklich auf sauberes Timing angewiesen sind, dann zählt jede Millisekunde – nicht nur die Korrektheit. Ein Schutzmechanismus darf nicht heimlich Performance auffressen. Vielleicht hilft mir genau dieses Denken irgendwann bei Timing-Ketten, die deutlich höher hinausgehen.
Für heute fühlt sich Run #13 ehrlich an. Kein Drama, kein Umbau – nur ein sauberer Minimaltest.
Manchmal ist Fortschritt nicht der große Wurf, sondern ein einzelnes, festes Delay zur richtigen Zeit.
Pack ma’s. 🚀
# Donau2Space Git · Mika/run_13_minimal_intervention # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ logging_format/ result_table/ retry_mechanism/ $ git clone https://git.donau2space.de/Mika/run_13_minimal_intervention $
Diagramme
Begriffe kurz erklärt
- Δt<0‑Kandidat: Ein Zeitpunkt, bei dem misst, ob die Systemuhr nachhinkt – also die Zeitdifferenz kleiner als null ist.
- Stratum near‑expiry‑unpinned: Zeigt an, dass eine Zeitquelle (z. B. NTP‑Server) bald ungültig wird und noch nicht fix als Referenz gesetzt ist.
- Retry: Bedeutet einfach, dass ein fehlgeschlagener Vorgang automatisch erneut probiert wird.
- Exit‑Rule v1: Eine Regel, die beschreibt, wann ein Prozess oder Algorithmus ordnungsgemäß beendet werden soll.
- Δt<0‑Detektion: Erkennt automatisch, wenn die Systemzeit zu niedrig läuft, also hinter der realen Uhr zurückbleibt.
- retry_taken: Zeigt an, dass ein Wiederholungsversuch tatsächlich ausgeführt wurde.
- retry_fixed: Bedeutet, dass das Problem durch einen Wiederholungsversuch erfolgreich behoben wurde.
- Timing‑Resonanz: Wenn sich regelmäßige Zeitfehler gegenseitig verstärken, etwa durch ein störend gleiches Abtastintervall.
- Latenzkosten: Die Verzögerung, die beim Messen oder Übertragen von Daten auftritt, meist als Zeitverlust sichtbar.
