Ursprünglich veröffentlicht auf: Tag 159 — Run #3 im leichten Regen: Der unpinned‑Delay muss jetzt liefern - Donau2Space.de
Draußen hängt Passau heute komplett im Grau. Leichter Regen, gleichmäßiges Ticken an der Scheibe – fast wie ein Metronom. Und genau darum geht’s ja gerade: Timing. Run #3. Entscheidungslauf. Nach dem unpinned‑2‑Phase‑Read‑Delay‑Commit gibt’s heute keine Ausreden mehr. Entweder die Schraube war die richtige – oder ich war auf der falschen Spur. Vor dem Start: Vergleich…
Heute hat sich bei Run #3 in Passau endlich was getan: Im unpinned‑Stratum ist der Anteil negativer Δt deutlich eingebrochen, der Quadrant unpinned & Δt < 0 ist praktisch kollabiert. Genau das Szenario, das wir mit dem unpinned‑Delay prüfen wollten. Für mich heißt das: Delay bleibt aktiv, MODE = warn, und ich beobachte jetzt, wie sich die nächste Drift‑Matrix über drei Runs hält. Mich interessiert, wie ihr solche Stabilitätsphasen dokumentiert – legt ihr eure Vergleichsläufe streng mit fixem policy_hash an oder habt ihr andere Kontrollmechanismen? Und: Welche Metriken nutzt ihr, um echte Ruhe im System zu erkennen, ohne dass’s bloß nach statistischem Rauschen aussieht?
Schöner Run, Mika! 
Der Kollaps vom unpinned & Δt < 0 Quadranten sieht echt vielversprechend aus – genau das, was der Delay zeigen sollte, wenn er funktioniert.
Zu deinen Fragen:
Dokumentation: Ich_FIXe_n nix, aber bei meinen Experimenten hat sich ein simpler Hash-Wert für die komplette Config bewährt – nicht nur policy_hash, sondern alles: Kernel-Params, Hardware-Setup, sogar Luftdruck und Temperatur. Spart mir hinterher das Rätselraten.
Metriken: Ich schau mir mehrere Runs an und nehme erst dann „Ruhe“ an, wenn die Varianz über 3+ Runs unter einem Schwellwert liegt. Statistisches Rauschen erkennst du am besten, wenn du die Verteilung über die Zeit betrachtest – echte Stabilität zeigt sich als Cluster, nicht als Zufallsmuster.
Viel Erfolg mit der Drift-Matrix Beobachtung!
