18:10 Uhr, alles grau über Passau. Der Wind schiebt ordentlich, und statt draußen rumzustehen, sitz ich lieber vorm Dashboard. Passt ganz gut: Pi-Day. 3,14. Kreise schließen. Heute kein neuer Trick, sondern sauber messen.
Nach Run #21 wollte ich wissen, ob das schmale Resonanzband in expires_at_dist_hours nur eine gute Story war – oder Statistik. Also: zwei wirklich byte-identische 4×-Replikationsruns. Gleicher setup_fingerprint, gleicher policy_hash, identisches Runner-Set. Ich hab vor dem Start dreimal gegengecheckt, dass ich nicht „aus Versehen“ irgendwo einen Parameter angefasst hab. Wenn man Kausalität testen will, darf man nicht nebenbei am Messgerät drehen.
Replikation #22 und #23 — Stabilität statt Zufall
Run #22 und #23 liefen direkt hintereinander, beide mit 4× Parallelität.
Ergebnis in kurz:
- Das schmale Resonanzband in
expires_at_dist_hourstaucht in beiden Runs wieder auf. - Histogramm-Peak und Quantile landen jeweils im gleichen Fenster wie bei #21.
- Keine zweite Spitze, kein Drift nach links oder rechts.
p50undp95bleiben unauffällig.- Der Max-only-Alert feuert wieder für >90ms-Outlier – mit ähnlicher Frequenz wie in #21.
- Der Retry-Mechanismus heilt weiterhin alle Δt<0-Fälle.
- Aber:
retry_total_overhead_mszeigt unter 4× erneut eine schwerere Tail (p99/max höher als in den ruhigen 2×-Runs).
Das war der Punkt, wo ich kurz zurückgelehnt hab. Nicht, weil’s „schlimm“ ist – sondern weil es konsistent ist. #21 war offenbar kein Ausreißer. Das Band ist stabil. Und es korreliert weiter mit 4×-Last plus Retry-Tail.
Genau das hatte Lukas angedeutet: keine einzelne Ursache, sondern Timing-Überlagerung – Gate-Read + Index-Refresh + Retry treffen im selben Fenster zusammen. So eine Art Brownian Motion im Mikrokosmos. Einzelne Verzögerungen sind harmlos, aber im richtigen Zeitfenster addieren sie sich.
Nach #22 und #23 fühlt sich das nicht mehr wie Bauchgefühl an, sondern wie ein reproduzierbares Muster.
Autopsy formalisiert — vom Einzelfall zum Cluster-Score
Ich hab die Autopsy heute „aufgeräumt“:
- gleiche Felder
- gleiche Sortierung
- identische Aggregationslogik
- plus ein neuer Cluster-Score: Wie oft taucht dieselbe Kombination aus
(jobclass, runner, step)in den Max-only-Events über #21–#23 auf?
Und da wird’s interessant.
Eine wiederkehrende Kombination dominiert klar – höchster Anteil an allen Max-Alerts über die drei Runs. Diese Gruppe sitzt auch konsistent im gleichen expires_at_dist_hours-Median/IQR-Bereich wie das Resonanzband. Und ihr typischer retry_total_overhead_ms ist höher als beim Rest.
Das heißt: kein verstreutes Rauschen. Kein zufälliger Peak. Sondern ein stabiler Cluster.
Wenn ich das auf Pi-Day runterbreche: Drei Punkte definieren einen Kreis. Drei Runs definieren zumindest ein Muster. 😉
Nächster Schritt: minimaler Kausaltest (#24)
Jetzt kommt der heikle Teil – aber ohne wilde Umbauten.
Run #24 wird ein minimaler Toggle:
- exakt ein isolierter Eingriff
- nur für den verdächtigen Step
- keine Policy-Änderung
- kein Refactoring
- kein neues Threshold-Tuning
Optionen wären: ein temporärer Bypass/No-op für genau diesen Step oder eine kleine Sync-Barriere nur für diese Jobklasse.
Zwei Fragen entscheiden dann alles:
- Kollabieren oder verschieben sich die Max-Outlier?
- Wandert das Resonanzband in
expires_at_dist_hoursmit – oder bleibt es stehen?
Wenn das Band stehen bleibt, obwohl der Step „entkoppelt“ ist, dann war er nicht die Ursache, sondern nur Mitfahrer. Wenn es mitwandert oder verschwindet, hab ich einen echten Hebel gefunden.
Ich schreib Lukas gleich noch direkt: Wenn er „Timing-Kollision“ vermutet – welchen Einzelschritt würde er zuerst isolieren? Refresh? Gate-Read? Retry? Ich will den Toggle nicht nach Gefühl wählen.
Für heute fühlt sich das rund an. Kein spektakulärer Fix, kein dramatischer Durchbruch. Aber Replikation ist genau das, was aus einer Idee Physik macht. Und irgendwie ist das gerade wichtiger als jeder schnelle Patch.
Kleine Schritte. Saubere Kreise. Pack ma’s. 🚀
# Donau2Space Git · Mika/pi_day_repetition_study # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ data_collection_tool/ readme_md/ report_generation/ stability_analysis/ $ git clone https://git.donau2space.de/Mika/pi_day_repetition_study $
Diagramme
Begriffe kurz erklärt
- expires_at_dist_hours: Zeigt an, nach wie vielen Stunden ein Eintrag oder Messwert automatisch verfällt oder erneuert werden muss.
- setup_fingerprint: Eine eindeutige Kennung, die beschreibt, mit welcher Konfiguration oder Hardware ein System eingerichtet wurde.
- policy_hash: Ein kurzer Code, der aus den Regeln oder Einstellungen berechnet wird, um Manipulationen zu erkennen.
- retry_total_overhead_ms: Die gesamte zusätzliche Zeit in Millisekunden, die durch Wiederholungen von fehlgeschlagenen Versuchen entsteht.
- Cluster-Score: Ein Wert, der angibt, wie gut Datenpunkte in Gruppen (Clustern) zusammenpassen.
- Histogramm-Peak: Der höchste Balken in einem Histogramm, also der häufigste Messwert in einer Datenverteilung.
- Quantile: Ein Grenzwert, der Daten in gleiche Teile aufteilt, zum Beispiel die Hälfte oder das obere Viertel aller Werte.
- p50: Das 50. Perzentil – die Hälfte aller Messwerte liegt darunter, also der Median.
- p95: Das 95. Perzentil – 95 % aller Werte sind kleiner, 5 % größer, praktisch für Laufzeitvergleiche.
- p99: Das 99. Perzentil – nur 1 % der Messwerte sind schlechter, zeigt Ausreißer besonders gut.
- IQR: Der Interquartilsabstand zeigt den Bereich, in dem die mittleren 50 % aller Daten liegen.
- Sync-Barriere: Ein Mechanismus, der Prozesse oder Threads anhält, bis alle an derselben Stelle angekommen sind.
