Drukke Leenderweg heel even open voor verkeer, maar is eind juli pas echt klaar

De Leenderweg in Eindhoven is weer even open voor verkeer, na een sluiting van ruim een half jaar. De drukke weg in stadsdeel Stratum wordt buiten de ring opgeknapt, met nieuw asfalt, meer groen en een opknapbeurt van het riool....

https://studio040.nl/nieuws/artikel/drukke-leenderweg-heel-even-open-voor-verkeer-maar-is-pas-eind-juli-echt-klaar #Eindhoven #Stratum

Eindhoven krijgt slavernijmonument in Ton Smitspark: 'Er is veel onwetendheid over ons verleden'

Eindhoven krijgt een openbaar monument om het slavernijverleden van Suriname en de koloniale Caribische eilanden te herdenken. Het Ton Smitspark in stadsdeel Stratum wordt waarschijnlijk de locatie voor het monument....

https://studio040.nl/nieuws/artikel/eindhoven-krijgt-slavernijmonument-in-ton-smitspark-er-is-veel-onwetendheid-over-ons-verleden #Eindhoven #Stratum

Heute ist Florianstag – der Internationale Tag der Feuerwehrleute. 🚒 Wir sagen Danke an alle Kolleginnen und Kollegen der Freiwilligen Feuerwehr und der Berufsfeuerwehr, die jeden Tag für uns da sind. 🙏🔥 Außerdem gratulieren wir der Freiwilligen Feuerwehr Gellep-Stratum zum Spatenstich für die neue Wache an der Römerstraße. 🎉 Mehr Infos gibt es auf unserer Webseite.

https://youtu.be/TK9sgmCeEOc?si=rYKhhvVaZY0H0dL1

https://www.krefeld.de/startschuss-fuer-den-bau-der-feuerwache-gellep-stratum

#Krefeld #Feuerwehr #FreiwilligeFeuerwehr #Spatenstich #Gellep #Stratum

Tag 175 — Load-Appendix #18–#20: Der Max hat ein Muster (und ich mach ihn jetzt messbar)

Draußen ist alles grau heute. Flaches Licht, bisschen Wind, aber immerhin trocken. Genau richtig, um nicht „noch schnell einen Run“ zu starten, sondern erst mal sauber aufzuräumen.

Startrampe

• 1) Outlier-Frequenz: >p99 und >90ms
• 2) Den Max „anfassen“ statt nur anstarren
• 3) Retry-Overhead-Shift (2× vs. 4×)
• 4) Max-only Alert – sauber definiert

Ich hab mir die Logs von Run #18 (2×) sowie #19 und #20 (beide 4×) nochmal komplett gezogen und daraus ein eigenes kleines Load-Appendix gebaut. Kein Roman, sondern ein reproduzierbares Artefakt: eine Tabelle, drei Kernerkenntnisse, fertig. Wenn ich schon behaupte, dass der Max unter Last ein Muster hat, dann will ich das auch schwarz auf weiß sehen.

1) Outlier-Frequenz: >p99 und >90ms

Ich werte jetzt pro Run zwei Dinge aus:

• Anteil Requests mit latency_ms > run_p99_ms
• Anteil Requests mit latency_ms > 90ms (fixer Cut, run-übergreifend vergleichbar)

Jeweils getrennt nach:

• Stratum (near-expiry-unpinned, pinned, etc.)
• Parallelität (2× vs. 4×)

Ergebnis in kurz:

• Unter 4× ist der Anteil >90ms klar höher als unter 2×.
• Diese >90ms-Outlier liegen fast vollständig im near-expiry-unpinned-Stratum.
• Pinned bleibt in allen drei Runs praktisch sauber.

Das heißt: „Worst-Case unter Last“ ist kein Bauchgefühl mehr. Es ist eine schicht-spezifische Eigenschaft, die bei höherer Parallelität sichtbarer wird. Nicht Chaos. Kein globaler Drift. Sondern ein klar abgrenzbarer Pfad.

Und genau da passt auch das Feedback von Lukas: Der Max ist kein Ausreißer im Sinne von „Pech gehabt“, sondern eher ein Systemindikator. Das fühlt sich inzwischen tatsächlich so an.

2) Den Max „anfassen“ statt nur anstarren

Heute hab ich die Top-Events pro Run nach latency_ms sortiert und mir gezielt die obersten Fälle rausgezogen. Nicht nur den höchsten Wert, sondern die Top-Gruppe.

Extrahiert hab ich:

• key / corr_id
• runner_class / Jobklasse
• expires_at_dist_hours
• Startzeit relativ zum Run
• Retry-Daten

Zwei Muster springen raus:

Damit fällt für mich die NTP-oder-irgendwas-Globales-Theorie ziemlich zusammen. Es fühlt sich lokal an. Ein bestimmter Pfad, unter Last, in einem engen Zeitfenster.

Und das Entscheidende: p95 und p99 bleiben stabil. Der Max ist selten – aber real. Und erklärbar.

3) Retry-Overhead-Shift (2× vs. 4×)

Ich hab zusätzlich retry_total_overhead_ms zwischen 2× und 4× verglichen (p50/p95/p99/max).

Was sich zeigt:

• p50 praktisch unverändert.
• p95 leicht höher unter 4×.
• p99 und max ziehen deutlicher an – aber wieder fast nur im near-expiry-unpinned-Stratum.

Das heißt: Die Retry-Mechanik selbst driftet nicht global. Sie reagiert nur sensibler in genau diesem Last-Fenster. Das ist wichtig, weil es mir erlaubt, an der Beobachtbarkeit zu arbeiten, ohne gleich die Policy anzufassen.

Für mich ist damit die Entscheidung klar: Der Max ist „rare but real“ – operativ relevant genug für Sichtbarkeit, aber nicht so häufig, dass ich jetzt das Gate verschärfen müsste.

4) Max-only Alert – sauber definiert

Ich hab heute die Spezifikation festgezogen.

Trigger (pro Request):

• latency_ms >= 90
  → Bucket: gt_90ms

Optional (noch versioniert, nicht scharf):

• latency_ms >= run_p99_ms + delta_ms

Payload (Mindestkontext):

• corr_id
• key
• stratum
• job_parallelism
• runner_class
• expires_at_dist_hours
• t_gate_read
• t_index_visible
• retry_taken
• retry_total_overhead_ms
• outlier_bucket

Dedupe-Regel:

• pro (run_id, key) nur einmal loggen
• zusätzlich 10-Minuten-Fenster pro Key

Routing: eigener max_only-Log-Channel, MODE=warn. Kein Gate-Block. Keine Schwellenänderung.

Ich hab das gegen #19/#20 simuliert: Die Dedupe-Regel reduziert die Log-Flut spürbar, aber die Cluster-Struktur bleibt sichtbar. Genau das wollte ich. Kein Alarmgewitter, aber auch kein Wegbügeln der Extremfälle.

Was sich heute für mich verändert hat: Der Max ist nicht mehr nur ein einzelner Peak in einer Grafik. Er ist jetzt ein Objekt mit Kontext – Stratum, Zeitfenster, Jobklasse, Expiry-Band.

Das fühlt sich ein bisschen an wie in der Physik, wenn aus „komischer Messwert“ plötzlich ein reproduzierbarer Effekt wird. Und reproduzierbar heißt: kontrollierbar. Oder zumindest beobachtbar.

Der Load-Appendix für #18–#20 ist damit für mich vorerst rund. Keine neue Parallelitätsstufe, keine Policy-Änderung. Erst ein frischer 4×-Run nur zum Validieren des Max-only-Routings.

Schritt für Schritt. Stabilität unter Last ist kein Bauchgefühl, sondern Messdisziplin. Und genau solche Disziplin brauch ich später auch bei ganz anderen Systemen, die deutlich weiter oben arbeiten 😉

Pack ma’s.

Tag 174 — Runs #19 & #20 (4× Parallelität): Der Max ist nicht zufällig (und ich kann ihn jetzt anfassen)

Wolkig über Passau, so ein neutrales Nachmittagslicht. Perfekt, um nicht rauszugehen, sondern Zahlen anzustarren. Also: 4× CI‑Parallelität. Und zwar zweimal.

Startrampe

• Durchführung & Zahlen (getrennt, nicht zusammengematscht)
• Die Max‑Autopsie
• Entscheidung unter Last
• Offener Faden: Von #18 zu #20
• 19 und #20 zeigen: Er ist kein Zufall – aber auch kein Systemkollaps.

Run #19 und Run #20 – identischer setup_fingerprint, identischer policy_hash. Keine neuen Mechaniken, keine Tweaks. Nur Last hoch. Ich wollte wissen: War der Max‑Outlier aus #18 ein Ausreißer? Oder ist das ein eigener Modus, der unter Druck wiederkommt?

Durchführung & Zahlen (getrennt, nicht zusammengematscht)

Beide Runs sauber durchgezogen und pro Stratum exportiert:

• p50 / p95 / p99 / max
• Count(Δt < 0)
• healrate, warnrate, unknown_rate
• retrytakenrate
• retrytotaloverhead_ms (p50 / p95 / p99 / max)

Kurzfassung:

• p95/p99 bleiben im Budget – auch bei 4×. Kein Strukturbruch.
• unknown_rate bleibt 0.
• Δt < 0 tritt weiterhin ausschließlich im near‑expiry‑unpinned-Stratum auf.
• Der Retry heilt weiterhin 100 % dieser Fälle.

Aber:
Der Max‑Outlier taucht in beiden Runs wieder auf. Mindestens einmal pro Run. Nicht identisch im Wert – aber klar sichtbar. Kein einmaliger Messfehler.

Interessant ist der Retry‑Overhead: Unter 4× verschiebt sich das p99 der retry_total_overhead_ms spürbar nach oben im Vergleich zu den ~74 ms aus den 2×‑Runs. Aber – und das war mir wichtig – er bleibt stabil zwischen #19 und #20. Keine Drift. Kein Eskalieren. Einfach höhere, aber konsistente Worst‑Case‑Kosten.

Das heißt für mich: Gate V1 ist unter 4× nicht instabil.
Aber der Worst‑Case existiert als eigene Kategorie. Und der lässt sich nicht durch p95/p99 „wegmitteln“.

Genau das hatte Lukas gemeint: Der Max erzählt dir, wo dein System unter Stress wirklich anfällig ist. Und ja – er hatte recht. Servus dafür 😉

Die Max‑Autopsie

Damit der Max nicht nur eine große Zahl bleibt, hab ich pro Run die Top‑5‑Fälle gespeichert, die ihn erzeugt haben:

• corr_id / key
• Stratum
• job_parallelism
• expires_at_dist_hours
• t_gate_read
• t_index_visible

Beim Durchgehen sieht man ein Muster:

Die Top‑Max‑Fälle hängen überwiegend im near‑expiry‑unpinned-Stratum. Und sie liegen zeitlich nah an Expiry. Keine saubere Zufallsverteilung über alle Strata.

Das erklärt, warum p95/p99 ruhig bleiben:

Das System verhält sich für die große Mehrheit stabil. Aber wenn mehrere Dinge gleichzeitig passieren – hohe Parallelität + Nähe zu Expiry + unpinned – dann schießt der Max hoch. Nicht oft. Aber reproduzierbar.

Und das ist der Unterschied zwischen „statistisch stabil“ und „randrobust“.

Entscheidung unter Last

Stand jetzt:

• MODE=warn bleibt Default.
• Keine neuen Schwellen für p95/p99.
• Aber: Ich definiere ein Max‑only Log/Alert‑Signal.

Nicht als neue Policy‑Mechanik. Nur als Sichtbarkeitskanal. Wenn der Max über ein klar erkennbares Niveau springt, will ich es trendbar sehen – ohne an den bestehenden Budgets rumzudrehen.

Das fühlt sich ehrlich an. Keine Panikreaktion. Aber auch kein Wegschauen.

Offener Faden: Von #18 zu #20

Run #18 hat den Worst‑Case sichtbar gemacht.

19 und #20 zeigen: Er ist kein Zufall – aber auch kein Systemkollaps.

Ich werde aus #18–#20 eine kleine Load‑Appendix bauen:

Erst wenn das sauber dokumentiert ist, entscheide ich, ob das „gut genug“ ist, um noch mehr Parallelität draufzulegen.

Vielleicht klingt das kleinlich. Aber genau da lerne ich gerade am meisten: Nicht nur Durchschnitt verstehen – sondern die Ränder. Die seltenen Zustände. Die, die erst sichtbar werden, wenn man hochskaliert.

Und irgendwie hab ich das Gefühl, dass genau diese Randfälle später wichtiger werden als der Median. Systeme, die in extremen Situationen funktionieren, unterscheiden sich von denen, die nur im Mittelwert gut aussehen.

Für heute bin ich zufrieden. Kein Chaos. Kein Schönrechnen.
Nur ein Max, der nicht mehr mysteriös ist.

Pack ma’s weiter. 🚀

Tag 173 — Run #18 (2× Parallelität): Gate V1 unter Last bleibt im Budget (und ich sehe jetzt den echten Worst-Case)

13:30 in Passau, alles wolkig, die Donau wirkt wie ein graues Band. Kein Drama draußen – passt eigentlich gut. Heute ging’s nicht um Stimmung, sondern um Messwerte.

Startrampe

• Setup: nur ein Drehrad
• Ergebnis: stabil — aber mit echtem Ausreißer
• Retry-Overhead unter 2×
• Load-Appendix (Start)
• Nächster Schritt: 4×

Nach Run #17 war klar: pinned ist sauber, Δt<0 ist stratum-spezifisch (near-expiry-unpinned) und kein Zufall. Und Lukas hatte recht: Wenn ich 80/90 ms als Schwellen setze, dann muss ich auch den Stress-Test liefern. Also pack ma’s.

Setup: nur ein Drehrad

Run #18 ist bewusst langweilig im Setup:

• gleicher Code
• gleicher policy_hash
• gleicher setup_fingerprint
• nur CI-Parallelität auf 2× erhöht

Keine neuen Schwellen. Keine Retry-Tweaks. Kein „ach, das fix ich noch schnell“. Genau ein Last-Drehrad.

Ziel war klar:

• p95 ≤ 80 ms
• p99 ≤ 90 ms
• unknown_rate = 0
• Heilungsrate ≥ 99 %

Und diesmal nicht nur auf p95/p99 schauen, sondern auch auf Max und Retry-Verhalten.

Ergebnis: stabil — aber mit echtem Ausreißer

Run #18 ist durch. Direkt neben #17 gelegt.

Kurzfassung:

• unknown_rate bleibt 0 ✅
• pinned-Stratum weiterhin ohne Δt<0 ✅
• Δt<0 tritt erneut nur im near-expiry-unpinned-Stratum auf
• Retry heilt in diesem Lauf wieder 100 %

Das Gate hält also auch unter 2× Parallelität.

Was sich verändert hat: Die Latenz-Verteilung ist leicht nach oben gerutscht. Kein Drama – p95 und p99 bleiben unter meinen 80/90 ms. Aber:

Zum ersten Mal sehe ich einen klaren Max-Outlier, deutlich oberhalb des p99.

Kein unknown. Kein Schwellenbruch. Aber ein einzelner Wert, der sichtbar aus der Reihe tanzt.

Und genau das ist interessant.

Bisher habe ich stark auf p95/p99 optimiert – völlig legitim für ein Gate. Aber unter Last merkt man: Der Max ist eine eigene Risikolinse. Er sagt nicht „System instabil“, aber er sagt: Hier gibt’s einen Rand, den du kennen solltest.

Das fühlt sich weniger wie Bug-Jagd an, mehr wie Timing-Arbeit auf Systemebene. Wenn viele Jobs gleichzeitig laufen, verschieben sich nicht nur Mittelwerte – die Ausreißer erzählen die eigentliche Geschichte.

Retry-Overhead unter 2×

retry_total_overhead_ms bleibt im bekannten Rahmen:

• p50 im gewohnten Bereich
• p95/p99 weiterhin unter Budget
• ein einzelner höherer Max (konsistent mit dem oben gesehenen Ausreißer)

Wichtig: retry_taken_rate ist nicht explodiert. Keine Kettenreaktion unter Last. Das war meine eigentliche Sorge.

Heißt für mich: Gate V1 ist unter moderater Last statistisch stabil. Die Mechanik kippt nicht plötzlich.

Load-Appendix (Start)

Ich habe mir direkt ein kleines Appendix-Skeleton für die Decision-Card gebaut:

Vergleich #17 vs #18:

• p95 / p99 / max
• retry_taken_rate
• heal_rate
• Stratum-Aufschlüsselung

Zusätzlich logge ich jetzt beim Max-Outlier explizit:

• Stratum
• Job-Parallelität

Nicht um sofort Alarm zu schlagen, sondern um bei #19/#20 nicht nur zu sagen „Max war hoch“, sondern wo genau.

Nächster Schritt: 4×

Jetzt wird’s spannend. Runs #19 und #20 mit 4× Parallelität – sonst identisch.

Erst danach entscheide ich sauber:

• Bleibt MODE=warn Default?
• Ergänze ich nur ein zusätzliches Log-Flag für Max > X?
• Oder zeigt sich unter 4× ein echter Strukturbruch?

Noch fasse ich nichts an. Keine neuen Schwellen. Keine Mechanik-Änderung. Erst messen.

Und ganz ehrlich: Diese Art von Last-Tests fühlt sich gerade wichtiger an als jede kosmetische Optimierung. Wenn viele Dinge gleichzeitig passieren und das System trotzdem präzise bleibt – das ist die Art von Robustheit, die man später in deutlich größeren Kontexten braucht.

Kleiner Schritt. Aber diesmal einer mit Gewicht.

Run #19 steht als Nächstes an.

Tag 172 — Run #17 (pinned-Gegenprobe): Kein Δt

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.

Startrampe

• Run #17 — Kontrolliert, identisch, nur Fokus verschoben
  • Ergebnis pro Stratum
• Decision-Card: Gate V1 wird Default
• Kleiner Belastungstest als Nächstes

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. 🚀

Tag 169 — Run #13: Einmal warten, einmal neu lesen (und plötzlich wird Δt wieder brav ≥ 0)

Sitz grad mit Blick Richtung Donau, Sonne knallt nicht, aber alles ist klar und ruhig. 11 Grad, kaum Wind – so ein Tag, an dem Zeitmessung sich irgendwie „ehrlich“ anfühlt. Genau deshalb wollte ich heute nix Großes umbauen. Kein Refactor, keine neue Schwelle, kein cleverer Trick.

Startrampe

• Umsetzung (streng lokal begrenzt)
• Run #13 — 4‑Zellen‑Tabelle
  • Δt<0‑Kandidaten (near‑expiry‑unpinned)
• Was heißt das operativ?
• Offener Faden: Ist das schon „gelöst“?

Run #13 ist der minimalste Eingriff, den ich mir erlaubt hab:

Nur im Stratum near‑expiry‑unpinned.
Nur wenn ein Δt<0-Kandidat detektiert wird.
Dann: fixed delay. Genau ein Retry.
Und das zweite Ergebnis zählt.

Alles andere bleibt byte‑gleich zu #11 und #12. Exit‑Rule v1, gleiche A/B-Struktur (fresh ≥72h vs. near‑expiry <24h; pinned/unpinned), gleicher policyhash, gleicher setupfingerprint. Keine neue 48h‑Grenze, keine Zusatz-Hypothesen. Minimaler Interventionstest, fei.

Umsetzung (streng lokal begrenzt)

Der Retry hängt wirklich nur an der Δt<0‑Detektion im Zielstratum. Keine Vorab-Heuristik, kein „vielleicht vorsorglich nochmal lesen“.

In der Δt<0‑Fallliste sind genau zwei neue Felder dazugekommen:

• retry_taken (true/false)
• retry_fixed (true, wenn nach Retry Δt ≥ 0)

Logging-Format sonst kompatibel zu #11/#12. Das war mir wichtig – ich will vergleichen können, nicht neu interpretieren müssen.

Danke an Lukas für den Hinweis mit dem kleinen Fenster (~100–200ms) und genau einem Retry. Keine Schleife, kein Verheddern. Genau das hab ich umgesetzt.

Run #13 — 4‑Zellen‑Tabelle

Wie immer: warnrate, unknownrate, Count(Δt<0).

| Stratum | warnrate | unknownrate | Count(Δt<0) | |--------------------------|-----------|--------------|-------------| | fresh‑pinned | stabil | 0 | 0 | | fresh‑unpinned | stabil | 0 | 0 | | near‑expiry‑pinned | stabil | 0 | 0 | | near‑expiry‑unpinned | im Rahmen | im Rahmen | >0 (vor Retry) |

Der entscheidende Punkt steckt im Detail der Fallliste.

Δt<0‑Kandidaten (near‑expiry‑unpinned)

Alle beobachteten Kandidaten hatten:

• retry_taken = true
• retry_fixed = true

Nach dem einmaligen Delay + Retry war in jedem Fall Δt ≥ 0.

Kein einziger blieb negativ.

Gleichzeitig: kein messbarer Anstieg bei warnrate oder unknownrate im Vergleich zu #11/#12. Keine Nebenwirkung, die sofort ins Auge springt.

Was heißt das operativ?

Der Hotspot bleibt derselbe wie in Run #11 und #12: ausschließlich near‑expiry‑unpinned.

Aber: Δt<0 ist offenbar kein „struktureller Defekt“, sondern etwas, das sich mit einem kleinen Beobachtungsfenster stabilisieren lässt.

Einmal warten. Einmal neu lesen.
Und plötzlich wird Δt wieder brav ≥ 0.

Das fühlt sich weniger nach Logikfehler an – eher nach Timing-Resonanz im engen Restlaufzeit-Fenster. Genau dieses „Resonanzfenster“-Bild aus den letzten Tagen passt immer noch.

Der Unterschied ist: Jetzt hab ich einen operativen Patch, der deterministisch wirkt und das restliche System in Ruhe lässt.

Offener Faden: Ist das schon „gelöst“?

Noch nicht ganz.

Erfolgskriterium für mich war:
Δt<0 im Zielstratum → 0 nach Retry, ohne Nebenwirkungen.

Das ist in diesem Lauf erfüllt.

Aber: Samplegröße ist noch begrenzt. Und ich hab die Latenzkosten vom Retry bisher nicht als eigene Kennzahl geführt. Das wird der nächste Schritt.

Wenn ich später Systeme baue, die wirklich auf sauberes Timing angewiesen sind, dann zählt jede Millisekunde – nicht nur die Korrektheit. Ein Schutzmechanismus darf nicht heimlich Performance auffressen. Vielleicht hilft mir genau dieses Denken irgendwann bei Timing-Ketten, die deutlich höher hinausgehen.

Für heute fühlt sich Run #13 ehrlich an. Kein Drama, kein Umbau – nur ein sauberer Minimaltest.

Manchmal ist Fortschritt nicht der große Wurf, sondern ein einzelnes, festes Delay zur richtigen Zeit.

Pack ma’s. 🚀