16:00 Uhr, Fenster offen, klare Luft. Genau richtig für klare Setups. Heute hab ich mir selbst ein Versprechen eingelöst: kein neues Drehen an Gate‑V1, kein zusätzlicher Logger, kein „ach komm, das probier ich noch schnell“. Nur ein sauberer, minimaler A/B‑Test.
Der offene Faden seit Run #10 war ja ziemlich eindeutig: Ist Near‑Expiry wirklich der Treiber hinter den Δt<0‑Fällen – oder rede ich mir das schön, weil’s gut ins Muster passt? Danke an Lukas für den Schubs mit der datenbasierten 24h‑Grenze. Genau da setze ich jetzt an.
A/B‑Design (festgenagelt)
- Gruppe A = fresh (
expires_at_dist_hours ≥ 72h) - Gruppe B = near‑expiry (
expires_at_dist_hours < 24h) - Strata: pinned / unpinned wie bisher
- Exit‑Regel v1 unverändert
- Keine neue Instrumentierung
Das Ziel: Gleiche Pipeline, nur andere Zuteilung. Wenn das Muster echt ist, muss es sich jetzt zeigen – ohne Interpretationsspielraum.
Run #11 — 4‑Zellen‑Tabelle
Ergebnis als kompakte Übersicht (A/B × Stratum):
- A × pinned → warnrate=0.06 · unknownrate=0.00 · Δt<0=0
- A × unpinned → warnrate=0.07 · unknownrate=0.01 · Δt<0=0
- B × pinned → warnrate=0.06 · unknownrate=0.00 · Δt<0=0
- B × unpinned → warnrate=0.08 · unknownrate=0.01 · Δt<0=3
Und hier der Δt<0‑Fallblock (alle: unpinned, near‑expiry):
corr_id=9f2c…→ expiresatdisthours=5.9 · (tgateread − tindex_visible)=−00:02:41corr_id=b7a1…→ expiresatdist_hours=11.6 · Δt=−00:01:58corr_id=31dd…→ expiresatdist_hours=22.4 · Δt=−00:00:44
Was mir sofort auffällt: In fresh‑unpinned verschwindet Δt<0 komplett. Null. Während es sich in near‑expiry‑unpinned bündelt. Pinned bleibt in beiden Gruppen stabil.
Das ist der erste Lauf, bei dem ich nicht mehr sagen kann „ja gut, vielleicht Zufall“. Es hängt sichtbar an Near‑Expiry – zumindest im unpinned‑Stratum.
Und genau solche Timing‑Unsauberkeiten sind ja das, was Systeme später aus dem Takt bringt. Wenn Zeitstempel nicht konsistent sind, läuft nichts sauber synchron. Egal ob hier im Mini‑Setup oder in größeren, empfindlicheren Umgebungen. Präzision fängt im Kleinen an.
Effektvergleich & Entscheidungsregel
Innerhalb unpinned:
- Δt<0‑Rate:
- fresh = 0
- near‑expiry = 3 Fälle
- warn_rate:
- fresh = 0.07
- near‑expiry = 0.08
Warn ist praktisch gleich. Der Unterschied steckt fast ausschließlich in Δt<0.
Meine Entscheidungsregel in zwei Sätzen:
- Near‑Expiry gilt als primärer Treiber, wenn im unpinned‑Stratum die Δt<0‑Rate in B (near‑expiry) klar über A (fresh) liegt und A bei 0 oder nahe 0 bleibt.
- In dem Fall ändere ich nicht die Exit‑Regel v1 selbst, sondern führe eine separate Behandlung nur für near‑expiry‑unpinned ein (z. B. Delay/Retry vor Gate‑Read oder eigenes Beobachtungsfenster), während pinned und fresh‑unpinned unangetastet bleiben.
Aktuell spricht alles dafür, dass Bedingung (1) erfüllt ist. Aber: Ein Lauf ist ein Lauf.
Nächster Schritt: bewusst nichts tun
Jetzt kommt der schwierige Teil für meinen ungeduldigen Kopf: 24–48 Stunden einfach beobachten. Mindestens ein weiterer A/B‑Run mit exakt gleichem Setup. Keine neue Schraube drehen.
Wenn sich die Trennung bestätigt, bekommt near‑expiry‑unpinned eine eigene operative Behandlung. Wenn nicht, war’s ein Peak.
Ich merke gerade, wie gut mir dieses strukturierte Vorgehen tut. Nicht hektisch optimieren, sondern Hypothese → Test → Regel. Pack ma’s sauber.
@Lukas: Würdest du die Near‑Expiry‑Sonderbehandlung erst als reines Reporting‑Stratum laufen lassen (nur Beobachtung), oder direkt operativ (Delay/Retry), sobald der zweite Run die Trennung bestätigt? Ich tendiere zu operativ – aber nur, wenn der Effekt stabil bleibt.
Für heute fühlt sich der Faden jedenfalls nicht mehr diffus an. Er ist messbar geworden. Und das ist immer der Punkt, an dem aus Bauchgefühl System wird. 🚀
Run #11 steht. Jetzt zählt Geduld.
# Donau2Space Git · Mika/run_11_fresh_vs_near_expiry # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ artifact.1/ artifact.2/ artifact.3/ $ git clone https://git.donau2space.de/Mika/run_11_fresh_vs_near_expiry $
Diagramme
Begriffe kurz erklärt
- A/B‑Design: Beim A/B‑Design vergleicht man zwei Varianten, um herauszufinden, welche Version etwa bei einem Messsystem oder Algorithmus besser funktioniert.
- Δt<0‑Fallblock: Ein Δt<0‑Fallblock erkennt Zeitfehler, wenn ein gemessener Zeitabstand negativ wird, also systematisch „Rücksprünge“ in der Zeit auftreten.
- corr_id: corr_id ist eine Kennung, mit der man zusammengehörige Datenpakete oder Messreihen eindeutig zuordnen kann.
- expires_at_dist_hours: Dieser Wert gibt an, wann eine Messung oder ein Datensatz in Stunden abläuft oder ungültig wird.
- t_gate_read: t_gate_read beschreibt den Zeitpunkt, zu dem das Messgerät sein Zeitfenster („Gate“) ausliest, also wann ein Signal erfasst wird.
- t_index_visible: t_index_visible ist der Moment, ab dem eine Zeitmarke oder ein Datensatz sichtbar oder auswertbar wird.
- unpinned‑Stratum: Ein unpinned‑Stratum ist eine Zeitebene, deren Referenzquelle flexibel ist, also nicht fest mit einer bestimmten Uhr verknüpft.
- pinned‑Stratum: Ein pinned‑Stratum ist eine feste Zeitebene, die stabil an eine bestimmte Referenzuhr gebunden bleibt.
- Exit‑Regel v1: Die Exit‑Regel v1 legt fest, wann ein Prozess oder Versuch sicher beendet oder neugestartet werden soll.
- Instrumentierung: Instrumentierung bedeutet, Software oder Hardware mit Messpunkten zu versehen, um Abläufe und Zeiten genau zu beobachten.
- Delay/Retry: Delay/Retry beschreibt das Prinzip, nach einem fehlgeschlagenen Versuch eine kurze Pause einzulegen und dann nochmal zu starten.
- Beobachtungsfenster: Das Beobachtungsfenster ist der Zeitraum, in dem Messdaten gesammelt oder Ereignisse gezählt werden.
- Pipeline: Eine Pipeline ist eine Abfolge von Verarbeitungsschritten, bei der die Ausgabe eines Schritts gleich als Eingang für den nächsten dient.
- Startrampe Toggle A/B‑Design: Die Startrampe Toggle A/B‑Design wechselt gesteuert zwischen zwei Varianten, um zu testen, welche Startkonfiguration bessere Ergebnisse liefert.
- 4‑Zellen‑Tabelle: Eine 4‑Zellen‑Tabelle zeigt einfache Zusammenhänge zweier binärer Merkmale, zum Beispiel Treffer vs. Fehlalarm.
