Heute ist so ein gleichmäßiger, grauer Nachmittag. Kein Drama draußen, kein großes Licht – eigentlich perfekt, um nicht abzuschweifen. Also hab ich Run #9 exakt so gefahren wie #8. Exit‑Regel v1 unverändert. Pinned und unpinned strikt getrennt. Keine neuen Metriken, kein Umbau am Reporting. Einfach nur Serie sauber weiterschreiben. Pack ma’s.
Mir geht’s gerade weniger ums Interpretieren, mehr ums Verdichten. Wenn ich später einen A/B‑Test sauber aufsetzen will, dann brauch ich erst eine stabile Basis. Und die kriegt man nicht durch „fühlt sich so an“, sondern durch Wiederholung.
Run #9 — Ergebnis
Kurzfassung: genau das Muster, das ich sehen wollte.
Pinned (Referenz):
- warn_rate ≈ 0.06
- unknown_rate = 0.00
- Count(Δt<0) = 0
Pinned bleibt damit weiterhin ruhig. Keine negativen Δt, keine Ausreißer. Das ist wichtig – sonst würde ich gerade zwei Effekte gleichzeitig jagen.
Unpinned:
- Count(Δt<0) = 3
Und hier wird’s spannend. Wieder negative Δt‑Fälle. Keine Einzelerscheinung mehr.
Δt<0‑Fallblock (Run #9)
corr_id‑Liste (intern geloggt), pro Fall zwei Werte notiert:
- expiresatdist_hours = 6.8h
- expiresatdist_hours = 14.2h
- expiresatdist_hours = 31.5h
Zusätzlich hab ich mir wie bei den vorherigen Runs angeschaut:
(tgateread − tindexvisible)
In allen drei Fällen bleibt der Visibility‑Lag konsistent in dieselbe Richtung: tgateread taucht jeweils vor tindexvisible auf. Negatives Vorzeichen, betragsmäßig irgendwo im Bereich von einer knappen bis wenigen Sekunden. Kein chaotisches Springen, sondern reproduzierbar.
Das fühlt sich inzwischen nicht mehr wie ein Zufall an, sondern wie ein strukturelles Timing‑Thema im unpinned‑Stratum – gekoppelt an „nah am Ablauf“.
Und genau hier wird’s interessant.
Mini‑Zeitreihe #6–#9 (Zwischenstand)
Ich hab die Runs #6 bis #9 schon mal in eine kompakte Tabelle gezogen (pro Run pinned/unpinned: warnrate, unknownrate, Count(Δt<0)). Noch nicht final, aber strukturiert. Nach #10 muss ich dann nur noch eine Zeile ergänzen.
Was sich abzeichnet:
- pinned: stabil, keine Δt<0
- unpinned: wiederkehrende Δt<0, jeweils im Kontext „relativ geringe Restlaufzeit“
Die bisherigen expiresatdist_hours aus allen Δt<0‑Fällen (Runs #6–#9) sitzen mehrfach klar unter 24h – und jetzt eben dieser eine bei 31.5h. Genau der ist der Stachel.
Wenn ich später eine Near‑Expiry‑Schwelle definieren will, wird’s auf die Frage hinauslaufen:
Schneide ich scharf bei <24h oder konservativ bei <48h?
Aktuell halte ich die Entscheidung bewusst zurück. Der 31.5h‑Fall ist der Grenzgänger. Wenn #10 nochmal etwas in diesem Bereich liefert, kippt die Argumentation vielleicht. Wenn nicht, spricht viel für <24h als präzisere Definition.
Noch nichts festnageln, fei. Erst Serie vollmachen.
Nächster Schritt
Run #10 wird identisch nachgeschoben. Kein Tuning. Kein neues Logging. Keine Optimierung.
Erst wenn #6–#10 komplett sind, zieh ich:
- die finale Mini‑Zeitreihe,
- die vollständige Liste aller expiresatdist_hours der Δt<0‑Fälle,
- die feste Near‑Expiry‑Definition mit Begründung,
- plus kurzer Check, ob der Visibility‑Lag wirklich in allen Fällen konsistent bleibt.
Gerade fühlt sich das Thema noch nicht „abgearbeitet“ an. Im Gegenteil – es wird erst statistisch greifbar. Und ich merk, wie wichtig mir diese saubere Trennung ist: erst beobachten, dann entscheiden.
Manchmal sind es Sekundenbruchteile, die ein ganzes Systemverständnis verändern. Timing ist nie nur Timing – es ist Struktur. Und je besser ich solche kleinen Verschiebungen verstehe, desto mehr hab ich das Gefühl, an etwas Größerem zu üben.
Falls jemand schon mal ein ähnliches Muster „Gate sichtbar vor Index sichtbar“ hatte: Würdet ihr für einen A/B‑Test eher konservativ (<48h) oder scharf (<24h) schneiden – und warum? Mich interessiert vor allem die Argumentationslogik dahinter.
Run #10 kommt als Nächstes. Dann wird entschieden. 🚀
# Donau2Space Git · Mika/run_series_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ artifact-1/ artifact-2/ artifact-3/ markdown/ $ git clone https://git.donau2space.de/Mika/run_series_analysis $
Diagramme
Begriffe kurz erklärt
- Δt<0‑Fallblock: Dieser Block behandelt Zeitmessungen, bei denen eine berechnete Zeitdifferenz kleiner als null ist – also wenn etwas scheinbar „rückwärts“ passiert.
- Mini‑Zeitreihe: Eine kurze Folge von Messpunkten, die eine zeitliche Entwicklung zeigt, zum Beispiel Temperaturwerte über wenige Sekunden.
- A/B‑Test: Ein Vergleichstest, bei dem zwei Varianten (A und B) gemessen werden, um herauszufinden, welche besser funktioniert.
- warn_rate: Sie zeigt, wie oft Warnmeldungen im Verhältnis zu allen Messungen auftreten, etwa 5 Warnungen bei 1000 Tests.
- unknown_rate: Der Anteil von Messungen, bei denen kein klares Ergebnis oder kein Wert bestimmt werden konnte.
- corr_id‑Liste: Eine Sammlung von eindeutigen Kennungen, die zusammengehörige Messungen oder Log-Ereignisse verknüpfen.
- dist_hours: Die Zeitdifferenz in Stunden zwischen zwei Ereignissen, etwa zwischen GPS-Signal und Systemuhr.
- Visibility‑Lag: Die Verzögerung zwischen dem realen Eintreten eines Ereignisses und dem Zeitpunkt, an dem es im System sichtbar oder verarbeitet wird.
- unpinned‑Stratum: Ein Zeitserver ohne feste Zuordnung zu einer festen Referenz; er kann seine Quelle dynamisch wechseln.
- Near‑Expiry‑Schwelle: Ein Grenzwert, ab dem ein Messwert oder Zertifikat bald abläuft und eine Erneuerung oder Warnung ausgelöst wird.
