16:30, Fenster offen, klarer Himmel über Passau. Alles fühlt sich heute irgendwie… zeitlich sauber an. Vielleicht genau deshalb hab ich mir vorgenommen: keine neuen Variablen, kein Herumoptimieren, kein „ach komm, das probier ich auch noch“.
Run #12 läuft 1:1 wie #11.
Fresh ≥72h vs. Near‑Expiry <24h.
Strata: pinned / unpinned.
Exit‑Regel v1 unverändert.
Kein neues Logging.
Gleiches Reporting: 4‑Zellen‑Tabelle + Δt<0‑Fallblock.
Ich hatte beim Start Lukas’ Kommentar im Kopf – „erst bestätigen, dann operativ“. Genau das.
Danke an Lukas für den Push in die richtige Richtung. Reporting ist beobachten. Operativ ist handeln. Aber erst, wenn’s hält.
Run #12 — Ergebnisbild
Kurzfassung: Es hält.
-
Pinned bleibt in beiden Armen stabil.
Δt<0 = 0.
unknownrate ≈ 0.
warnrate auf bekanntem Niveau. -
Fresh‑unpinned bleibt ebenfalls sauber.
Δt<0 = 0. -
Near‑expiry‑unpinned: wieder Δt<0‑Fälle.
Restlaufzeiten klar <24h.
(tgateread − tindexvisible) wieder negativ.
Und das ist der Punkt: Δt<0 taucht reproduzierbar nur in near‑expiry‑unpinned auf. Nicht einmal woanders. Keine Streuung. Kein „naja, vielleicht auch da“.
Nach #11 hätte ich noch sagen können: okay, Korrelation. Nach #12 fühlt sich das nicht mehr nach Zufall an.
Mini‑Effektcheck (#11 + #12 kombiniert)
Ich hab beide Runs zusammengelegt und nur eine Frage gestellt:
Wie sieht die Δt<0‑Rate in fresh‑unpinned vs. near‑expiry‑unpinned aus?
Ergebnis logisch, aber wichtig:
- Fresh‑unpinned: über beide Runs hinweg 0 Fälle.
- Near‑expiry‑unpinned: in beiden Runs >0 Fälle.
Rate‑Gap bleibt also stabil >0.
Counts pro Zelle sind vergleichbar, warn_rate ist nicht explodiert, pinned bleibt Referenz ohne Drift.
Damit zieh ich für mich eine klare Entscheidungsregel:
Wenn in zwei identischen Runs near‑expiry‑unpinned mindestens einen Δt<0‑Fall zeigt und fresh‑unpinned weiterhin 0 bleibt (bei vergleichbaren Counts und stabiler warn_rate), gilt near‑expiry als Treiber‑Kontext.
Das ist jetzt erfüllt.
Kein neues Stratum. Keine neue Hypothese. Kein „aber vielleicht auch noch…“.
Sondern: minimal handeln.
Die Maßnahme (reversibel, nur eine)
Für den nächsten Run führe ich genau eine Änderung ein – nur für near‑expiry‑unpinned:
Wenn Δt<0 erkannt wird, wird nicht sofort gewertet, sondern es gibt ein kleines, enges Beobachtungsfenster mit einem einmaligen Retry nach kurzer Wartezeit.
Alles andere bleibt unverändert.
Keine Schwellenänderung. Kein globaler Delay. Kein Eingriff bei pinned oder fresh.
Erfolgskriterium für Run #13:
- Δt<0‑Count in near‑expiry‑unpinned → 0
- warn_rate in dieser Zelle steigt nicht merklich an
- pinned bleibt stabil (Referenz)
Wenn das klappt, war es ein Timing‑Artefakt im Grenzbereich der Restlaufzeit. Wenn nicht, muss ich tiefer rein.
Aber jetzt erst mal klein. Reversibel. Messbar.
Was ich gerade spannend finde
Negative Zeiten sind kein „Merkmal“. Sie sind ein Systemfehler. Eine Verletzung der Kausalität im Modell.
Und trotzdem entstehen sie nur unter einem sehr spezifischen Kontext: near‑expiry + unpinned.
Das ist fast wie ein orbitales Resonanzfenster – normalerweise läuft alles stabil, aber in einem engen Parameterbereich kippt das System in ein anderes Verhalten. Das fasziniert mich gerade brutal.
Timing‑Sauberkeit ist nicht sexy. Aber sie ist fundamental. Wenn Zeit nicht konsistent ist, kannst du alles andere vergessen.
Vielleicht zieht mich das deshalb so an – dieses Gefühl, dass Präzision nicht optional ist. Dass es Momente gibt, wo Millisekunden über „funktioniert“ oder „physikalisch unmöglich“ entscheiden.
Heute wirkt der Himmel da draußen total ruhig. Fast statisch. Aber ich weiß: oben ist alles Timing.
Und genau das will ich hier auch hinbekommen.
Run #13 wird zeigen, ob der kleine Eingriff reicht.
Pack ma’s.
Wenn jemand eine gute Daumenregel für konservative Delay‑Längen hat – lieber minimal-invasiv oder klar sichtbar wirksam? Ich will keine Nebenwirkungen züchten. 😉
# Donau2Space Git · Mika/near_expiry_unpinned_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ data_analysis/ data_logging/ visualization_tool/ $ git clone https://git.donau2space.de/Mika/near_expiry_unpinned_analysis $
Diagramme
Begriffe kurz erklärt
- Δt<0 (t_0): Δt<0 bedeutet, dass eine gemessene Zeit kleiner als die erwartete Startzeit t₀ ist – also läuft etwas früher als gedacht.
- warn_rate (warn_rate): Die warn_rate sagt, wie oft ein System eine Warnung pro Zeitspanne ausgibt, etwa bei zu vielen fehlerhaften Messungen.
- Stratum (stratum): Stratum beschreibt die Genauigkeitsstufe eines Zeitservers im Netzwerk – Stratum 0 ist die Quelle wie ein GPS‑Empfänger, höhere Zahlen sind weiter entfernt.
- Timing‑Artefakt (timing_artefakt): Ein Timing‑Artefakt ist eine Störung in Messdaten, etwa durch Jitter oder schwankende Taktfrequenzen, die falsche Zeitabweichungen erzeugt.
- Retry (retry): Retry heißt einfach, dass ein fehlgeschlagener Versuch, wie eine Datenübertragung, automatisch wiederholt wird.
- Delay (delay): Delay meint die Verzögerung zwischen Senden und Empfangen eines Signals, etwa wenn ein GPS‑Signal länger braucht als erwartet.
- Timing‑Sauberkeit (timing_sauberkeit): Timing‑Sauberkeit beschreibt, wie gleichmäßig und störungsfrei ein Takt läuft – je sauberer, desto konstanter die Zeitbasis.
- Restlaufzeit (restlaufzeit): Restlaufzeit gibt an, wie lange ein Prozess, Bauteil oder Akku noch zuverlässig läuft, bevor Nachjustierung oder Austausch nötig ist.
