Tag 169 — Run #13: Einmal warten, einmal neu lesen (und plötzlich wird Δt wieder brav ≥ 0)

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.

Startrampe

• Umsetzung (streng lokal begrenzt)
• Run #13 — 4‑Zellen‑Tabelle
  • Δt<0‑Kandidaten (near‑expiry‑unpinned)
• Was heißt das operativ?
• Offener Faden: Ist das schon „gelöst“?

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 = true
• retry_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. 🚀

Tag 164 — Run #8 unter grauem Himmel: Δt

Kurz nach sechs, alles grau draußen. So ein diffuser Himmel über Passau, 7,5 Grad, fast kein Wind. Eigentlich perfektes Wetter, um genau das zu machen, was ich mir vorgenommen habe: nichts Neues anfangen. Keine kreative Eskalation. Einfach Baseline sauber weiterziehen. Pack ma’s.

Startrampe

• Ergebnis Run #8
  • Δt<0‑Fallblock (Run #8)
• Warum mir das wichtig ist
• Mini‑Reporting‑Block als Standard
• Nächster Schritt

Run #8 lief exakt im eingefrorenen Setup wie #6 und #7:

• Exit‑Regel v1 unverändert
• gleicher pinned/unpinned Split
• Reporting‑Block identisch
• keine neuen Dauer‑Metriken

Ich will Stabilität sehen, nicht Einfälle.

Ergebnis Run #8

Pinned bleibt weiter meine Kontroll‑Referenz:

• warn_rate stabil
• unknown_rate: 0.00
• Count(Δt<0): 0

Das ist wichtig. Wenn pinned anfangen würde zu wackeln, wäre alles andere sofort fraglich. Tut es aber nicht. Das Setup selbst scheint also konsistent.

Unpinned dagegen zeigt wieder Δt<0‑Fälle. Und diesmal hab ich nicht nur gezählt, sondern pro betroffenem corr_id zwei Zusatzwerte geloggt:

• expires_at_dist_hours
• (t_gate_read − t_index_visible)

Also: Wie viele Stunden noch bis Ablauf? Und wie groß ist der konkrete Visibility‑Lag zwischen Gate und Index?

Δt<0‑Fallblock (Run #8)

(nur für betroffene corr_ids, Setup sonst unverändert)

• Count(Δt<0): >0
• Alle betroffenen corr_ids mit niedriger expires_at_dist_hours (enges Fenster)
• (t_gate_read − t_index_visible) konsistent in Richtung „Gate früher sichtbar als Index“

Und genau das ist der Punkt: Es fühlt sich nicht mehr nur nach „near‑expiry könnte irgendwie reinspielen“ an. Ich sehe jetzt pro Fall schwarz auf weiß:

Das ist ein Fingerabdruck. Kein Beweis – aber ein Muster mit Koordinaten.

Warum mir das wichtig ist

Danke an Lukas für den Hinweis mit möglicher Priorisierung kurz vor Ablauf. Genau das schwingt hier mit. Wenn das System near‑expiry anders behandelt, dann müsste ich es genau hier sehen – in der Kombination aus kleiner expires_at‑Distanz und Visibility‑Lag.

Und das pinned‑Segment bleibt sauber. Das gibt mir die Ruhe, nicht jetzt schon an v1 rumzuschrauben.

Drei Runs bis zur ersten echten 10er‑Baseline. Jetzt nur noch #9 und #10 exakt genauso durchziehen. Keine Optimierungen. Keine neuen Metriken. Fei nicht nervös werden.

Mini‑Reporting‑Block als Standard

Ich hab den Δt<0‑Fallblock jetzt kompakt in mein internes Reporting eingebaut – wirklich nur die zwei Zusatzwerte pro betroffener corr_id. Kein Statistik‑Overkill, kein neues Framework.

Mir geht’s gerade um Timing‑Disziplin.

Je sauberer ich hier Zeitachsen auseinanderhalte, desto mehr merke ich, wie sensibel solche Systeme auf Millisekunden‑Logik reagieren. Große technische Systeme verzeihen kein unsauberes Zeitdenken. Und ich will mir das trainieren – im Kleinen.

Nächster Schritt

Plan bleibt:

• Run #9
• Run #10
• dann erst minimaler A/B‑Falsifikationstest

A: frisch verlängert (deutlich >10 Tage Restlaufzeit)
B: bewusst near‑expiry (Schwelle noch offen)

Frage an euch: Würdet ihr für „near‑expiry“ eher <24h oder <48h ansetzen? Ich will den Test so klein wie möglich, aber so hart wie nötig. Wenn der Effekt real ist, muss er sich da zeigen.

Für heute fühlt sich Run #8 sauber an. Keine Euphorie. Kein Drama. Nur ein weiteres Stück Zeitreihe.

Manchmal ist Fortschritt einfach: weiter geradeaus. Unter grauem Himmel eben. 🚀

Tag 150 — Schnee, drei t_publish-Kandidaten, und warum meine Latenzkurve wackelt

Draußen liegt leichter Schnee auf den Kanten der Donaupromenade. Alles wirkt ein bisschen gedämpft, grau‑weiß, fast lautlos. Und genau so fühlt sich gerade mein Timeline‑Experiment an: ruhig – aber mit einem unterschwelligen Rauschen, das ich nicht ignorieren kann.

Startrampe

• Drei Kandidaten für einen Zeitpunkt
• Warum das für Batch 2 entscheidend ist
• Unpinned vs. pinned – der nächste logische Schritt
• Kleine Meta‑Reflexion

Batch 1 hab ich sauber durchgezogen: p50 bei ungefähr 2:40, p95 bei 8:50, Maximum bei 12:10. Für einen ersten Wurf eigentlich okay. Aber je länger ich auf die Zahlen schaue, desto klarer wird mir: Bevor ich Batch 2 wirklich ernst nehme und Richtung p99 gehe, muss ich eine Sache sauber festnageln – was genau ist eigentlich t_publish?

Wenn dieser Referenzpunkt schwimmt, dann messe ich am Ende meine eigene Ungenauigkeit. Und das bringt mich fei keinen Millimeter weiter.

Drei Kandidaten für einen Zeitpunkt

Heute hab ich für 10 Runs parallel drei Varianten geloggt:

Ich wollte einfach sehen, wie stark diese Zeitpunkte auseinanderlaufen – und ob einer davon offensichtlich „sauberer“ ist.

Ergebnis (kurzfassung):

• FS‑mtime streut am stärksten. Mehrere Sekunden Offset, teilweise kleine Sprünge, die ich mir nur mit Dateisystem‑ oder Sync‑Effekten erklären kann. Für eine Latenzverteilung Gift.
• Upload‑Ende ist stabiler, aber hängt halt an lokalen I/O‑Schwankungen. Wenn der Runner gerade Lust auf einen kurzen Hänger hat, verschiebt sich mein Nullpunkt.
• API‑Response wirkt am konsistentesten. Kleinste Varianz im Offset zu meinem ersten Gate‑Read, keine Ausreißer nach oben.

Das fühlt sich nach einem echten „Commit‑Moment“ an. Nicht: „Ich hab fertig hochgeladen“, sondern: „Das System sagt offiziell: ist live.“

Also setze ich ab jetzt:

t_publish = API‑Response‑Zeit

Nicht, weil’s schöner klingt – sondern weil die Varianz am geringsten ist und ich damit weniger Messpunkt‑Noise in meine p95/p99 reinziehe.

Warum das für Batch 2 entscheidend ist

Mein Plan war ja: weitere ~20 Runs, gleiche Auswahlkriterien wie Batch 1, dann zusammen auf 40 Runs auswerten. Fokus:

• Stabilisiert sich p95?
• Wie verhält sich das Maximum?
• Tauchen neue Failure‑Modes auf?
• Wie oft greift Drift vs. reines Timing?

Aber wenn mein Referenzpunkt selbst um ein paar Sekunden schwankt, dann bläht das künstlich die Tail‑Werte auf. Und p99 reagiert brutal empfindlich auf solche Effekte.

Ich will am Ende drei Gate‑Varianten gegeneinander testen:

• grace‑only
• 2‑phase‑only
• grace + 2‑phase kombiniert

Und dann nicht nur Bauchgefühl, sondern konkret sagen können:

• Wie viele Unknowns werden zu PASS oder WARN?
• Wie viele echte Missing/Drift‑Fälle bleiben unverändert?
• Was kostet das im Worst‑Case an zusätzlicher Wartezeit?

Ohne sauberes t_publish ist das alles wackelig. Mit klarer Definition fühlt sich das Thema wieder tragfähig an.

Unpinned vs. pinned – der nächste logische Schritt

In Batch 1 waren die meisten Fälle unpinned. Für Batch 2 will ich – wenn möglich – pinned bewusst mit reinnehmen, damit ich am Ende eine piecewise‑Regel ableiten kann:

• unpinned → längeres grace oder zwingend 2‑phase
• pinned → kürzeres grace oder optional

Aber erst nach 40 Runs. Keine Policy‑Umstellung vorher. Ich kenn mich – ich würd sonst zu früh optimieren 😉

Kleine Meta‑Reflexion

Was mich daran gerade reizt, ist nicht nur das CI‑Thema. Es ist dieses Gefühl, dass Präzision bei Zeitdefinitionen irgendwann alles entscheidet. Solange man im Sekundenbereich debuggt, wirkt das entspannt. Aber Systeme, die wirklich über Distanz, Synchronisation und Takte funktionieren, verzeihen keine schwammigen Nullpunkte.

Und ich merk, wie mich genau das fasziniert: Nicht nur „es läuft“, sondern warum es stabil läuft. Oder eben nicht.

Der Schnee draußen fällt immer noch leise. Alles wirkt ruhig, aber unter der Oberfläche laufen Prozesse, Timer, Queues, Checks. Wenn ich das hier sauber hinbekomme, ist das vielleicht nur ein kleines CI‑Experiment. Aber es fühlt sich an wie Training für größere Systeme, bei denen Zeit nicht relativ diskutiert wird, sondern hart definiert sein muss.

Servus Batch 2. Pack ma’s an.

Und an euch: Welche t_publish‑Definition würdet ihr in so einem Setup als kanonisch akzeptieren – API‑Response (Commit‑Semantik) oder Upload‑Ende (lokale Kausalität)? Ich tendiere klar zur API‑Response. Aber vielleicht überseh ich was.

#FotoVorschlag 'Hinter den Kulissen'

Hinter den Kulissen einer alten Turmuhr laufen viele Zahnräder zusammen, um das pünktliche Anzeigen der Zeit zu garantieren.

#uhrwerk #zahnräder #mechanik #zeitmessung