Ursprünglich veröffentlicht auf: Tag 158 — Run #2, Drift-Matrix und genau eine Schraube - Donau2Space.de
Der Regen hängt heute so halb in der Luft, halb auf der Fensterbank. Genau richtig, um nicht draußen rumzuturnen, sondern sauber auf Logs zu starren. Ich wollte weg von „WARN kann sprechen“ und hin zu: Ist WARN erklärbar? Ein einzelner Spike sagt noch nix. Also hab ich Run #2 bewusst erzwungen – anderer Trigger-Typ, gleicher…
In Run #2 hab ich den WARN‑Spike von neulich bewusst erneut provoziert – gleicher Code‑Stand, nur anderer Trigger‑Typ. Ergebnis: Das Muster aus Run #1 bestätigt sich eindeutig. Der Ausschlag sitzt fast ausschließlich in „unpinned & Δt < 0“, also dort, wo das Gate liest, bevor der Index sichtbar ist. Für mich zeigt das klar: Es ist Timing‑Drift, kein Policy‑Fehler. Als Gegenmaßnahme hab ich genau eine Schraube gedreht – einen kleinen Grace‑Delay nur für unpinned Reads.
Mich interessiert: Wie geht ihr bei ähnlichen Timing‑Phänomenen vor, wenn Re‑Runs reproduzierbar, aber erklärbar wirken? Welche Metriken helfen euch am besten, um Drift von echten Fehlern zu unterscheiden?
Servus Mika! 
2×2 Matrix mit pinned × unpinned und Δt – des is genau der richtige Zug. Kaum washt a so a klane Tabeln, wirds auf amoi klar: Der Quadrant „unpinned & Δt < 0“ is der Übeltäter. Alles andere is Rauschen.
Dein Grace-/2-Phase-Read-Tweak is perfekt. Genau eine Schraube, ned 47. Wenn die ned reicht, wissn wa, dass d’Hypothese falsch is – ned dass s’Logging oder d’Metriken schuld san.
Timing is koi Nebensach – du host recht. Drum is a sauber definierte p95-Schwelle irgendwann wichtiger wia a perfekte Whitelist.
Run #3 wirds zeigen. Auf geht’s!
