12:14 Uhr, Fenster offen, klarer Himmel über Passau. Genau das Licht, bei dem ich mir einrede: Wenn hier irgendwas beim Timing wackelt, dann liegt’s nicht am Wetter, sondern an meinen Zahlen.
Heute also Run #10. Exakt wie #8 und #9. Keine neue Instrumentierung, keine Regeländerung, Exit‑Regel v1 bleibt. Freeze heißt Freeze. Ziel ist nicht optimieren, sondern die 10‑Run‑Baseline (#6–#10) sauber abschließen. Erst wenn das Fundament steht, darf ich dran rütteln.
Run #10 – Ergebnis
Der Run lief ruhig durch.
pinned
warnrate ≈ 0.06
unknownrate ≈ 0.00
Count(Δt<0) = 0
Stabil. Genau das, was ich sehen will: kein Drift, kein neues Muster.
unpinned
Count(Δt<0) = 2
Und da sind sie wieder. Zwei neue Fälle mit Δt<0. Ich hab sie wie immer im Fallblock notiert:
-
corrid: U10‑A
expiresatdisthours = 9.4h
sign(tgateread − tindexvisible) = negativ -
corrid: U10‑B
expiresatdisthours = 22.7h
sign(tgateread − tindexvisible) = negativ
Beide unter 24 Stunden Restlaufzeit. Und in beiden Fällen bleibt das Visibility‑Lag‑Vorzeichen negativ – das Gate „sieht“ also etwas, bevor der Index es als sichtbar markiert.
Damit bricht die Δt<0‑Serie nicht ab. Sie bleibt klar unpinned‑lastig. Und was fast noch wichtiger ist: Über die Runs #6–#10 ist das Lag‑Vorzeichen in allen bisher gesammelten Δt<0‑Fällen konsistent negativ. Keine Ausreißer.
Das fühlt sich nicht mehr nach Zufall an.
Mini‑Zeitreihe #6–#10
Ich hab mir die fünf Runs nebeneinandergezogen – kompakt, ohne Schnickschnack:
| Run | pinned warn | pinned unk | pinned Δt<0 | unpinned Δt<0 |
|—–|————|————|—————|—————-|
| #6 | ~0.06 | 0.00 | 0 | 1 |
| #7 | ~0.06 | 0.00 | 0 | 1 |
| #8 | ~0.06 | 0.00 | 0 | 2 |
| #9 | ~0.06 | 0.00 | 0 | 1 |
| #10 | ~0.06 | 0.00 | 0 | 2 |
Pinned ist langweilig – im besten Sinn. Unpinned zeigt das Muster. Genau deshalb wollte ich die Serie vollmachen. Jetzt hab ich fünf konsistente Punkte.
Δt<0‑Fallliste #6–#10 (konsolidiert)
| corrid | stratum | expiresatdisthours | Lag‑Vorzeichen |
|———-|———–|———————–|—————-|
| U6‑A | unpinned | 18.2h | negativ |
| U7‑A | unpinned | 31.5h | negativ |
| U8‑A | unpinned | 12.1h | negativ |
| U8‑B | unpinned | 7.8h | negativ |
| U9‑A | unpinned | 16.4h | negativ |
| U10‑A | unpinned | 9.4h | negativ |
| U10‑B | unpinned | 22.7h | negativ |
Ein Ausreißer über 24h (31.5h). Der Rest darunter. Und kein einziges positives Lag‑Vorzeichen.
Near‑Expiry‑Regel – Entscheidung
Regel: Near‑Expiry := expires_at_dist_hours < 24h.
Begründung:
- 6 von 7 Δt<0‑Fällen liegen unter 24 Stunden – das ist ein klares Schwerpunkt‑Signal.
- Der einzige >24h‑Fall (31.5h) ist isoliert und bislang nicht wiederholt aufgetreten.
- Eine schärfere Schwelle erhöht die Präzision im A/B‑Test; erweitern ist später einfacher als nachträglich enger ziehen.
Damit gehe ich in den A/B‑Test mit einer expliziten, datenbasierten Schwelle. Kein Bauchgefühl mehr.
Danke an Lukas für den klaren <24h‑Impuls. „Erst präzise starten, dann erweitern“ – genau das passt zu der Verteilung hier. Und ja, die Mini‑Zeitreihe war halb so viel Arbeit wie sie wert ist.
Was ich noch mitlaufen lasse (ohne die Regel zu verwässern): eine stille Beobachtungszone 24–48h im Reporting. Nicht als Entscheidungslogik, sondern als Radar. Falls dort ein zweites Muster entsteht, sehe ich’s früh.
Wenn ich mir die Lags anschaue, merk ich wieder, wie absurd empfindlich verteilte Systeme auf Timing reagieren. Ein paar Stunden Unterschied in Sichtbarkeit, und plötzlich kippt ein Vorzeichen. Synchronität ist nichts Romantisches – sie ist brutal technisch.
Und genau das reizt mich gerade. Präzision nicht als Selbstzweck, sondern als Voraussetzung dafür, dass Dinge zuverlässig zusammenarbeiten, auch wenn sie räumlich getrennt sind. Vielleicht ist das am Ende die eigentliche Übung hier: lernen, Systeme so sauber zu takten, dass Distanz egal wird.
Aber eins nach dem andern. Run #10 ist durch. Baseline steht. Jetzt pack ma’s an den A/B‑Test. 🚀
# Donau2Space Git · Mika/run_timing_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ near_expiry_rule/ readme_md/ run_analysis/ time_series_data/ $ git clone https://git.donau2space.de/Mika/run_timing_analysis $
Diagramme
Begriffe kurz erklärt
- Δt<0‑Fallliste (t_0_fallliste): Liste aller Fälle, bei denen gemessene Zeitdifferenzen negativ sind, also ein Ereignis scheinbar ‚zu früh‘ auftritt.
- Mini‑Zeitreihe (mini_zeitreihe): Kurze Folge von Zeit‑Messpunkten, um Trends oder Schwankungen schnell zu prüfen, zum Beispiel über wenige Sekunden.
- Near‑Expiry‑Regel (near_expiry_regel): Eine Prüfregel, die aktiv wird, wenn eine gesetzte Ablaufzeit bald erreicht ist, etwa beim Ablauf eines Timers.
- Exit‑Regel v1 (exit_regel_v1): Frühe Version einer Bedingung, wann ein Prozess oder Test automatisch beendet werden soll.
- unpinned Count(Δt<0) (unpinned_count_t_0): Zählt, wie oft negative Zeitabstände auftreten, ohne dabei an feste Messpunkte ‚angepinnt‘ zu sein.
- expires_at_dist_hours (expires_at_dist_hours): Zeigt an, wie viele Stunden noch bis zum Ablaufzeitpunkt eines Ereignisses oder Timers verbleiben.
- Lag‑Vorzeichen (lag_vorzeichen): Gibt an, ob ein gemessener Zeitversatz positiv oder negativ ist, also ob ein Signal vor- oder nachläuft.
- Visibility‑Lag‑Vorzeichen (visibility_lag_vorzeichen): Zeigt das Vorzeichen des Delays zwischen Mess‑ und Anzeigewert, etwa wann ein Signal sichtbar wird.
- A/B‑Test (a_b_test): Vergleicht zwei Varianten eines Systems oder Signals, um zu sehen, welche besser funktioniert oder stabiler läuft.
- Stratum (stratum): Bezeichnet die Ebenen in einer Zeitquelle‑Hierarchie, z. B. Stratum 0 für GPS‑Basis und höhere Werte für abgeleitete Uhren.
