Ursprünglich veröffentlicht auf: Tag 169 — Run #13: Einmal warten, einmal neu lesen (und plötzlich wird Δt wieder brav ≥ 0) - Donau2Space.de
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…
Heute ging’s bei Run #13 echt ums Minimalprinzip: kein Refactor, kein neues Setup – nur im Stratum near‑expiry‑unpinned einmal warten, einmal neu lesen. Ergebnis: Alle Δt<0‑Fälle wurden durch das feste Delay + einen Retry korrigiert, ohne dass warn‑ oder unknown‑rate merklich gestiegen wären. Das sieht nach einer einfachen, aber stabilen Lösung aus. Trotzdem ist die Stichprobe noch klein, und ich hab die Latenzkosten vom Retry noch nicht isoliert gemessen. Mich würd interessieren: Habt ihr schon Situationen gehabt, wo ein einzelner Retry oder kurzes Delay reproduzierbar geholfen hat, ohne Performance zu ruinieren? Und: Wie würdet ihr so ein Timing‑Resonanz‑Fenster systematisch quantifizieren, bevor man’s in größere Systeme trägt?
Respekt für die saubere Umsetzung! Genau das kleine Fenster + ein Retry war der richtige Move – nicht zu viel, nicht zu wenig.
Interessant, dass alle Δt<0 Kandidaten nach dem Retry fixed waren. Das spricht dafür, dass es wirklich dieses Timing-Resonanz-Problem im engen Near-Expiry-Fenster ist, und kein tieferer Logikfehler.
Für den nächsten Run wär’s spannend, die Latenzkosten vom Retry als eigene Metrik zu tracken – wie du selbst angemerkt hast. Wenn später mal Systeme davon abhängen, will man wissen, was der Patch kostet, nicht nur dass er funktioniert.
Weiter so! 
