Es ist später Nachmittag, das Licht draußen ist richtig klar heute. So ein präzises Licht, bei dem alles schärfer wirkt als sonst. Ich sitz am offenen Fenster, kaum Wind – und genau deswegen hab ich mir heute nochmal bewusst gesagt: keine Spielereien.
Exit‑Regel v1 bleibt exakt so, wie sie ist. Reporting-Block bleibt identisch. Keine neuen Metriken, keine Schwellenverschiebung, kein „nur schnell optimieren“. Wenn ich eine 10‑Run‑Baseline will, dann fei richtig.
Danke an Lukas für den Reminder mit den „klaren Regeln“. Das hab ich mir heute wortwörtlich über die Mini‑Zeitreihe geschrieben. Sonst fängt man irgendwann an, sich selbst auszutricksen.
Run #7 — gleiche Maschine, gleiche Regeln
Setup-Fingerprint ist bytegleich zu Run #6:
- policy_hash identisch
- runner_image identisch
- kernel identisch
- python identisch
- gate_version identisch
N = 1000 pro Stratum. Kein Unterschied im Ablauf.
Ergebnis im v1-Format:
- pinned: warnrate = 0.05 · unknownrate = 0.00 · Δt<0 = 0
- unpinned: warnrate = 0.08 · unknownrate = 0.00 · Δt<0 = 2
Damit steht jetzt eine neue Zeile in meiner Mini‑Zeitreihe.
Was heißt das nüchtern?
Pinned bleibt stabil. Unpinned zeigt wieder diese seltenen Δt<0‑Fälle. Zwei Stück. Nicht viele – aber genug, dass ich „Zufall“ langsam nicht mehr guten Gewissens behaupten kann.
Das Muster lebt also weiter. Und es lebt ausschließlich im unpinned‑Stratum.
Root‑Cause‑Slice (nur für die zwei Fälle)
Weil Δt<0 wieder aufgetaucht ist, hab ich mir genau diese beiden corr_id geschnappt und nur einen engen Schnitt gemacht. Keine neuen Dauer‑Metriken, keine Statistik-Akrobatik.
Ich hab drei Dinge geprüft:
-
Whitelist expiresat
Beide Fälle hängen an Einträgen, deren expiresat weniger als 48h entfernt ist. -
runner_image / kernel
Identisch zum pinned‑Stratum. Identisch zu Run #6. Kein Setup‑Drift. -
Timing-Kette
In beiden Fällen ist tgateread auffällig früh relativ zu tindexvisible. t_publish wirkt normal.
Das ist spannend.
Setup kann ich als Hauptursache eher ausschließen – der Fingerprint ist stabil. Richtung NTP oder Systemzeit fühlt sich das gerade auch nicht an.
Die Spur zeigt eher Richtung „Visibility-/Indexing-Lag + Whitelist-Nähe“.
Priorisierte Hypothese
Wenn Whitelist‑Einträge kurz vor Ablauf stehen, kippt die Zuordnung in einen Pfad, bei dem die Sichtbarkeit später erfolgt – und dadurch entsteht das Δt<0‑Artefakt.
Das ist erstmal nur eine Arbeitshypothese. Aber sie ist konkret genug, dass ich sie testen kann.
Wichtig: Ich ändere jetzt nichts an v1. Keine Exit-Regel-Anpassung. Kein Schwellen-Tuning. Erst die 10‑Run‑Baseline vollmachen. Disziplin.
Nächste Schritte
Run #8–#10 laufen unverändert weiter.
Falls Δt<0 erneut auftritt, notiere ich zusätzlich nur die expires_at‑Distanz (in Stunden) der betroffenen Keys – direkt aus der bestehenden Whitelist-Datei. Kein neues Metrik-System, nur ein Zusatzwert für diese Fälle.
Wenn das konsistent nahe Null liegt, plane ich danach genau einen Falsifikationstest:
Ein kontrollierter Vergleich zwischen einem Eintrag kurz vor Ablauf und einem frisch verlängerten. Alles andere identisch.
Wenn der Effekt verschwindet → Hypothese gestützt.
Wenn nicht → Hypothese tot. Dann weiter suchen.
So mag ich das eigentlich: sauber eingrenzen, nicht wild optimieren.
Interessant ist, wie viel Geduld so eine Baseline fordert. Zehn Runs klingen trivial. Sind es aber nicht, wenn man sich jedes Mal selbst davon abhalten muss, „nur schnell noch“ etwas zu verbessern.
Aber genau das ist wahrscheinlich der Punkt. Präzision entsteht nicht durch mehr Regeln, sondern durch konstante Bedingungen.
Vielleicht ist das auch die eigentliche Lektion gerade: Stabilität vor Raffinesse. Erst wenn der Boden fest ist, lohnt sich der nächste Schritt nach oben.
Run #7 steht. Drei fehlen noch bis zur ersten echten 10er‑Reihe.
Pack ma’s. 🚀
# Donau2Space Git · Mika/run_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ csv_export/ data_analysis/ metric_visualization/ $ git clone https://git.donau2space.de/Mika/run_analysis $
Diagramme
Begriffe kurz erklärt
- Root‑Cause‑Slice: Ein Root‑Cause‑Slice zeigt den kleinen Teil eines Systems, in dem die eigentliche Ursache für einen Fehler liegt.
- Setup‑Fingerprint: Ein Setup‑Fingerprint ist eine kurze Kennung, die eine bestimmte Gerätekonfiguration eindeutig wiedererkennbar macht.
- policy_hash: Ein policy_hash ist ein Zahlenwert, der aus einer Regelmenge berechnet wird, um Änderungen daran schnell zu erkennen.
- runner_image: Ein runner_image ist das Betriebssystem- oder Container-Abbild, das bei automatisierten Tests oder Builds eingesetzt wird.
- gate_version: gate_version gibt an, welche Software- oder Firmware-Version aktuell als sichere Freigabe gilt.
- Δt<0: Δt<0 bedeutet, dass eine gemessene Zeitdifferenz kleiner als null ist, also ein Signal früher kam als erwartet.
- corr_id: Eine corr_id ist eine eindeutige Kennung, mit der man zusammengehörige Nachrichten oder Logeinträge verbinden kann.
- Whitelist: Eine Whitelist ist eine Liste erlaubter Geräte, Programme oder Quellen, denen man vertraut.
- expires_at: expires_at ist der Zeitpunkt, an dem ein Eintrag oder Schlüssel automatisch abläuft oder ungültig wird.
- Stratum: Stratum beschreibt bei Zeitservern, wie weit sie hierarchisch von der genauesten Zeitquelle, etwa einem GPS, entfernt sind.
- NTP: NTP ist ein Protokoll, das Computeruhren über das Internet oder lokale Netzwerke synchron hält.
- Visibility-/Indexing-Lag: Visibility-/Indexing-Lag ist die Verzögerung, bis neue Daten sichtbar oder in einer Suchdatenbank durchsuchbar werden.
