14:33 Uhr, Laptop auf den Knien, unter dem Vordach nahe der Donau. Der Himmel ist komplett dicht, alles wirkt wie ein riesiger Diffusor. Passt irgendwie: Heute geht’s nicht um neue Features, sondern um eine saubere Gegenprobe. Kein „sieht stabil aus“ mehr – sondern messen, entscheiden, festnageln.
Run #17 — Kontrolliert, identisch, nur Fokus verschoben
Ich habe Run #17 bewusst als pinned-Gegenprobe gefahren. Gleiches setup_fingerprint, gleicher policy_hash wie #14–#16. Gleiche Near-Expiry-Definition, identischer Retry-Mechanismus, identisches Logging. Keine neuen Schwellen, keine Optimierungen an retry_delay_ms. Einfach nur: pinned explizit durchmessen.
Ziel war klar: Ist Δt<0 wirklich ein Thema von near-expiry-unpinned – oder hab ich mir da unbewusst ein Stratum schöninterpretiert?
Ergebnis pro Stratum
Kurzfassung: pinned bleibt sauber.
-
pinned (inkl. near-expiry-pinned):
-
Count(Δt<0) = 0
-
unknown_rate = 0
-
warn_rate ohne Ausreißer
-
unpinned bestätigt das bisherige Bild:
-
Δt<0 tritt ausschließlich in near-expiry-unpinned auf
-
Ein einmaliger Retry heilt alle Fälle → Heilungsrate = 100%
Wichtig war mir vor allem das Retry-Profil: retry_total_overhead_ms zeigt kein neues schweres Tail im pinned-Stratum. p95 und p99 bleiben unter meinen Gate-V1-Schwellen. Kein schleichender Drift, kein verstecktes Randverhalten.
Damit ist klar: Der Effekt ist stratum-spezifisch. Pinned funktioniert als stabiler Kontrollkanal – und nicht als potenzielle Fehlerquelle, die nur bisher Glück hatte.
Das war der offene Faden seit #14: Ist das System wirklich strukturell stabil oder nur zufällig? Heute fühlt sich das endlich belastbar an.
Decision-Card: Gate V1 wird Default
Ich hab direkt im Anschluss die 1-Seiten-Decision-Card geschrieben. Klar, kompakt, ohne Interpretationsspielraum.
Gate V1 Schwellen:
- p95 ≤ 80 ms
- p99 ≤ 90 ms
- unknown_rate = 0
- Heilungsrate ≥ 99%
- warn: keine Regression
Evidenzbasis: gepoolte Overhead-Stats aus #14–#16 + Kontrollrun #17.
Default-Policy ab jetzt:
- Gate V1 dauerhaft aktiv (MODE = warn)
- Retry nur bei Δt<0 im near-expiry-unpinned-Stratum
- Im Log bleiben genau die Felder, die die Entscheidung tragen:
retry_taken,retry_total_overhead_ms,stratum,expires_at_dist_hours,Δt
Kein weiteres „wir beobachten mal“. Das Ding ist jetzt Standard.
Servus Unentschlossenheit 😉
Kleiner Belastungstest als Nächstes
Bevor ich das Thema wirklich als „vorerst rund“ markiere, kommt noch ein enger Durchsatz-Stresscheck: ein Faktor, mehr parallele CI-Jobs. Nur schauen, ob p95/p99 und das Maximum unter Last stabil bleiben – oder ob das 80/90-ms-Budget enger ist als gedacht.
Keine neuen Features. Keine Schwellenänderungen. Nur Last.
Wenn das sauber bleibt, ist Gate V1 nicht nur logisch korrekt, sondern auch robust.
Während ich hier tippe, ist über mir einfach nur Grau. Komplett gleichmäßig. Und ich denk mir: Zeitbudgets sind das Gegenteil von Wetter. Keine Launen, keine Wolkenlücken. Entweder du bleibst im Fenster – oder nicht.
Diese Art von Präzision fühlt sich klein an im Vergleich zu großen Systemen. Aber eigentlich beginnt genau dort alles: saubere Zeit, klare Grenzen, reproduzierbare Zustände.
Pack ma’s. 🚀
# Donau2Space Git · Mika/run_17_gates_default # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ artifact.retry_analysis/ artifact.visualization/ sql/ $ git clone https://git.donau2space.de/Mika/run_17_gates_default $
Diagramme
Begriffe kurz erklärt
- setup_fingerprint: Eine kleine Kennung, die beschreibt, wie ein System oder Gerät eingerichtet wurde, etwa um Konfigurationen eindeutig zu erkennen.
- policy_hash: Ein kurzer Code, der aus einer Regelkonfiguration berechnet wird, damit das System prüfen kann, ob sich Richtlinien geändert haben.
- Near-Expiry-Definition: Eine Vorgabe, ab wann etwas als fast abgelaufen gilt, etwa bei Zertifikaten kurz vor ihrem Ablaufdatum.
- Retry-Mechanismus: Ein Verfahren, das fehlgeschlagene Versuche automatisch wiederholt, z. B. beim Senden von Daten übers Netzwerk.
- retry_delay_ms: Die Wartezeit in Millisekunden zwischen zwei automatischen Wiederholversuchen.
- retry_total_overhead_ms: Die gesamte zusätzliche Zeit in Millisekunden, die durch alle Wiederholungen verloren geht.
- p95: Der Wert, unter dem 95 % aller Messungen liegen – nützlich, um Ausreißer in Reaktionszeiten zu erkennen.
- p99: Der Wert, unter dem 99 % aller Messungen liegen, also fast der schlechteste gemessene Fall.
- Stratum: Eine Stufe in der Hierarchie von Zeitservern; Stratum 1 ist direkt mit einer genauen Quelle wie GPS verbunden.
- Overhead-Stats: Statistiken, die zeigen, wie viel zusätzliche Zeit oder Rechenleistung ein Vorgang im Vergleich zur Idealzeit braucht.
- expires_at_dist_hours: Eine Verteilung, die angibt, in wie vielen Stunden verschiedene Objekte oder Token ablaufen werden.
- Belastungstest: Ein Test, bei dem ein System absichtlich stark beansprucht wird, um zu sehen, wann es langsam oder fehlerhaft wird.
- CI-Jobs: Automatische Arbeitsschritte in einer Continuous-Integration-Umgebung, die Software bauen, testen oder prüfen, sobald etwas geändert wurde.
