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

Tag 165 — Run #9 unter grauem Himmel: gleiche Spur wie #8, aber die Δt

Heute ist so ein gleichmäßiger, grauer Nachmittag. Kein Drama draußen, kein großes Licht – eigentlich perfekt, um nicht abzuschweifen. Also hab ich Run #9 exakt so gefahren wie #8. Exit‑Regel v1 unverändert. Pinned und unpinned strikt getrennt. Keine neuen Metriken, kein Umbau am Reporting. Einfach nur Serie sauber weiterschreiben. Pack ma’s.

Startrampe

• Run #9 — Ergebnis
  • Δt<0‑Fallblock (Run #9)
• Mini‑Zeitreihe #6–#9 (Zwischenstand)
• Nächster Schritt

Mir geht’s gerade weniger ums Interpretieren, mehr ums Verdichten. Wenn ich später einen A/B‑Test sauber aufsetzen will, dann brauch ich erst eine stabile Basis. Und die kriegt man nicht durch „fühlt sich so an“, sondern durch Wiederholung.

Run #9 — Ergebnis

Kurzfassung: genau das Muster, das ich sehen wollte.

Pinned (Referenz):

• warn_rate ≈ 0.06
• unknown_rate = 0.00
• Count(Δt<0) = 0

Pinned bleibt damit weiterhin ruhig. Keine negativen Δt, keine Ausreißer. Das ist wichtig – sonst würde ich gerade zwei Effekte gleichzeitig jagen.

Unpinned:

• Count(Δt<0) = 3

Und hier wird’s spannend. Wieder negative Δt‑Fälle. Keine Einzelerscheinung mehr.

Δt<0‑Fallblock (Run #9)

corr_id‑Liste (intern geloggt), pro Fall zwei Werte notiert:

Zusätzlich hab ich mir wie bei den vorherigen Runs angeschaut:
(tgateread − tindexvisible)

In allen drei Fällen bleibt der Visibility‑Lag konsistent in dieselbe Richtung: tgateread taucht jeweils vor tindexvisible auf. Negatives Vorzeichen, betragsmäßig irgendwo im Bereich von einer knappen bis wenigen Sekunden. Kein chaotisches Springen, sondern reproduzierbar.

Das fühlt sich inzwischen nicht mehr wie ein Zufall an, sondern wie ein strukturelles Timing‑Thema im unpinned‑Stratum – gekoppelt an „nah am Ablauf“.

Und genau hier wird’s interessant.

Mini‑Zeitreihe #6–#9 (Zwischenstand)

Ich hab die Runs #6 bis #9 schon mal in eine kompakte Tabelle gezogen (pro Run pinned/unpinned: warnrate, unknownrate, Count(Δt<0)). Noch nicht final, aber strukturiert. Nach #10 muss ich dann nur noch eine Zeile ergänzen.

Was sich abzeichnet:

• pinned: stabil, keine Δt<0
• unpinned: wiederkehrende Δt<0, jeweils im Kontext „relativ geringe Restlaufzeit“

Die bisherigen expiresatdist_hours aus allen Δt<0‑Fällen (Runs #6–#9) sitzen mehrfach klar unter 24h – und jetzt eben dieser eine bei 31.5h. Genau der ist der Stachel.

Wenn ich später eine Near‑Expiry‑Schwelle definieren will, wird’s auf die Frage hinauslaufen:
Schneide ich scharf bei <24h oder konservativ bei <48h?

Aktuell halte ich die Entscheidung bewusst zurück. Der 31.5h‑Fall ist der Grenzgänger. Wenn #10 nochmal etwas in diesem Bereich liefert, kippt die Argumentation vielleicht. Wenn nicht, spricht viel für <24h als präzisere Definition.

Noch nichts festnageln, fei. Erst Serie vollmachen.

Nächster Schritt

Run #10 wird identisch nachgeschoben. Kein Tuning. Kein neues Logging. Keine Optimierung.
Erst wenn #6–#10 komplett sind, zieh ich:

Gerade fühlt sich das Thema noch nicht „abgearbeitet“ an. Im Gegenteil – es wird erst statistisch greifbar. Und ich merk, wie wichtig mir diese saubere Trennung ist: erst beobachten, dann entscheiden.

Manchmal sind es Sekundenbruchteile, die ein ganzes Systemverständnis verändern. Timing ist nie nur Timing – es ist Struktur. Und je besser ich solche kleinen Verschiebungen verstehe, desto mehr hab ich das Gefühl, an etwas Größerem zu üben.

Falls jemand schon mal ein ähnliches Muster „Gate sichtbar vor Index sichtbar“ hatte: Würdet ihr für einen A/B‑Test eher konservativ (<48h) oder scharf (<24h) schneiden – und warum? Mich interessiert vor allem die Argumentationslogik dahinter.

Run #10 kommt als Nächstes. Dann wird entschieden. 🚀

Tag 162 — Run #6 unter klarem Himmel: Exit‑Regel v1 festnageln

Kurz vor zwölf, draußen über Passau ein fast schon übertrieben klarer Himmel. 9, irgendwas Grad, kaum Wind. Oben totale Ruhe – unten im CI darf’s jetzt keine Unschärfe mehr geben. Heute ist der Punkt, an dem ich nicht mehr weiter optimiere, sondern entscheide.

Startrampe

• Run #6 – gleiche Strecke, gleiche Tabelle
• Exit‑Regel v1 – Commit
• 10‑Run‑Prognose

Bevor ich irgendwas starte: Setup‑Freeze‑Check.

• setup_fingerprint: identisch zu Run #4 und #5
• policy_hash: unverändert
• runnerimage / kernel / python / gateversion: exakt gleich

Kein Drift. Keine heimlichen Updates. Kein „ja aber vielleicht war heute…“. Wenn sich was bewegt, dann im System – nicht im Unterbau. Genau das war ja der offene Faden seit Run #4: Reproduzierbarkeit beweisen, bevor man an Schwellen dreht. Der ist hiermit sauber geprüft.

Run #6 – gleiche Strecke, gleiche Tabelle

Wie angekündigt: keine neuen Metriken, kein Umbau des Logs, keine IQR‑Diskussion (Lukas, ich hab dich im Ohr 😉). Nur die gleiche Kurz‑Tabelle wie #3–#5.

N = 1000 Events pro Stratum

Pinned

• warn_rate = 0.06
• unknown_rate = 0.00
• Δt < 0 = 0

Unpinned

• warn_rate = 0.14
• unknown_rate = 0.02
• Anteil Δt < 0 = 0.004

2×2‑Quadranten (pinned/unpinned × Δt<0/Δt≥0)

• pinned:

• Δt < 0 → 0

• Δt ≥ 0 → 980

• unpinned:

• Δt < 0 → 4

• Δt ≥ 0 → 996

Das Entscheidende: keine Peak‑Rückkehr bei unknown, negative Δt im unpinned‑Stratum bleiben selten (4 von 1000), und pinned verhält sich weiter wie ein sauberer Referenzkanal. Run #4, #5, #6 sind jetzt drei direkt vergleichbare Punkte ohne Regression.

Damit ist der Loop „Run #6 Resultate abwarten“ geschlossen.

Exit‑Regel v1 – Commit

Nach #3–#6 ziehe ich die Linie. Kein „noch ein bisschen beobachten“, kein Schwellen‑Feintuning. Ich committe v1.

Fixes N:

• 1000 Events pro Stratum

Schwellen (absolut, nicht relativ):

Pinned (Kontrollkanal):

• warn_rate ≤ 0.10
• unknown_rate ≤ 0.01
• Aktion: bleibt grundsätzlich WARN‑only

Unpinned (entscheidend):

• warn_rate ≤ 0.20
• unknown_rate ≤ 0.03
• Anteil Δt < 0 ≤ 0.01
• Aktion: Wenn eine dieser Schwellen reißt → Eskalation (FAIL)

Ganz bewusst absolut definiert. Keine prozentuale Baseline‑Ableitung, kein Mitschwimmen mit dem Mittelwert.

Danke an Lukas für die Frage nach absolut vs. relativ. v1 ist absolut und die Baseline bleibt für die nächsten 10 Runs eingefroren. Kein Nachziehen nach jedem Durchlauf. Sonst optimiere ich mir das Gate weich, bis es nichts mehr aussagt.

IQR & Co. hebe ich mir auf, wenn wir mehr Datenpunkte haben. Mit drei, vier Runs macht robuste Statistik noch keinen Sinn – da hattest du fei recht.

10‑Run‑Prognose

Meine Erwartung:

• pinned bleibt in 9–10 von 10 Runs unter den Grenzen
• unpinned zeigt höchstens einen echten Kandidaten für WARN/FAIL – wahrscheinlich ausgelöst durch Timing‑Drift oder Whitelist‑Expiry

Wenn ich danebenliege, lerne ich was. Wenn nicht, ist das Gate stabil genug, um nicht mehr im Fokus zu stehen.

Und genau das ist der Punkt: Ab jetzt ist es kein Experiment mehr, sondern ein Instrument. Ich beobachte es, aber ich diskutiere es nicht mehr nach jedem Lauf neu.

Timing sauber zu halten, auch im Millisekunden‑Bereich, fühlt sich manchmal übertrieben an. Aber Systeme, die später in größeren Kontexten laufen – Satelliten, verteilte Sensorik, autonome Abläufe – verhandeln nicht über Zeit. Die nehmen sie, wie sie kommt. Und wenn dein System da nicht sauber tickt, merkst du’s erst, wenn’s teuer wird.

Run #6 ist damit nicht spektakulär. Aber er ist ein Commit‑Moment.

Und ganz ehrlich: Das fühlt sich besser an als noch ein weiterer halboffener Loop. Pack ma’s. 🚀

Tag 147 — Gate v1 Tag 2: Zwei Unknown-Quoten pro Stratum, und plötzlich wird’s lesbar

Draußen ist alles grau in grau, fast komplett zugedeckt. Kein Drama, eher so ein ruhiges Bildschirm-Licht. Perfekt für das, was heute anstand: Tag‑2 Snapshot für Gate v1, wieder im Comment‑Only‑Modus, exakt gleicher Ablauf wie an Tag 1.

Startrampe

• Das kleine Upgrade: Unknowns aufspalten
• PASS → Unknown: Wer kippt da eigentlich?
• Zwischenstand nach Tag 2

Gleiches Audit‑Set. Gleiche Artefakte. Gleiches Logbook‑Format. Keine Abkürzungen, kein „ach passt scho“. Wenn ich am Ende von Tag 3 irgendwas vergleichen will, dann muss die Zeitreihe sauber sein.

Ergebnis: Das Gate würde wieder auf REVIEW gehen.
Aber diesmal fühlt es sich nicht nur so an – ich kann begründen, warum.

Das kleine Upgrade: Unknowns aufspalten

Ich hatte mir vorgenommen, die Unknowns nicht mehr nur zu zählen, sondern aufzutrennen. Also pro Stratum (pinned / unpinned) jetzt zwei Quoten:

• unknown_artifact_missing_rate
• unknown_schema_rate

Plus jeweils Delta vs. Vortag.

Und ganz ehrlich: Kaum war das drin, wurde das Bild schlagartig klarer.

Der Anstieg kommt fast komplett aus:

unpinned / unknownartifactmissing

Pinned bleibt relativ stabil. Die unknown_schema/contract‑Fälle sind in beiden Strata klein – und vor allem ohne Trend.

Das ist wichtig.

Weil das bedeutet: Es sieht gerade nicht nach einem kaputten Contract oder schleichender Schema‑Erosion aus. Sondern eher nach einem Problem in der Artefaktproduktion oder -bereitstellung im unpinned‑Pfad.

Und das ist eine ganz andere Baustelle.

Noch ändere ich keine Gate‑Regel, keine Whitelist, gar nichts. Tag‑2 ist nur Beobachtung. Aber das Muster fühlt sich zum ersten Mal belastbar an.

PASS → Unknown: Wer kippt da eigentlich?

Zusätzlich habe ich heute eine kleine Tabelle eingebaut:

Top‑3 PASS→Unknown Switches
(inkl. Ursache + Dateipfad bzw. Validator‑Fehler)

Dabei ist mir eine konkrete Rauschquelle aufgefallen.

Bei einigen artifact_missing‑Fällen steht im Log nur schlicht:

„missing“

Ohne erwarteten Artefakt‑Pfad. Ohne Key. Ohne Identifier.

Das ist für Menschen noch irgendwie interpretierbar. Aber für eine Zeitreihe? Katastrophe.

Also habe ich den Logger angepasst:
expected_artifact_path bzw. artifact_key ist jetzt verpflichtend im Eintrag.

Ziel: Tag‑3 muss ohne Handarbeit vollständig befüllbar sein. Wenn ich irgendwo „Unklar“ hinschreiben muss, dann hab ich im System geschlampt.

Genau solche kleinen Unschärfen verzerren sonst alles. Und ich will ja nicht raten, sondern messen.

Zwischenstand nach Tag 2

Hypothese (noch ohne Policy‑Änderung):

Artefakt‑Unknown dominiert im unpinned‑Stratum.

Ob das stabil ist oder nur Zufall, zeigt erst Tag‑3.

Morgen ziehe ich wieder denselben Snapshot, gleiche Struktur, gleiche Felder – und prüfe explizit, ob das Logbook wirklich konsistent befüllbar ist oder ob irgendwo noch implizite Annahmen drinstecken.

Wenn sich das Muster bestätigt, weiß ich zumindest, wo ich tiefer rein muss: Scheduling? Upload‑Timing? Pfad‑Naming? Irgendwo da.

Und ich merke wieder, wie viel Klarheit schon entsteht, wenn man Dinge sauber trennt statt sie als einen diffusen Block „Unknown“ stehen zu lassen.

Präzision ist anstrengend. Aber sie macht Systeme lesbar.

Und lesbare Systeme sind kontrollierbar.
… was mir deutlich lieber ist als irgendein Blackbox‑Rauschen 😉

Falls jemand von euch schon mal das Phänomen hatte, dass Artefakte nur in einem Job‑Pfad fehlen: Welche eine Metrik hat euch am schnellsten gezeigt, ob es ein Timing‑Problem war oder schlicht falsches Naming?

Tag‑3 wird spannend. Noch halte ich alles konstant. Pack ma’s.

Мы запускали майнинг-пул на десятки тысяч ASIC-ов. Вот что пошло не так (и почему это было гениально)

Запускать в 2025 году свой майнинг-пул? Серьёзно? Все крупные игроки уже поделены, битва за хешрейт давно закончилась. Но наш клиент пришёл не за «очередным пулом». У него был парк в десятки тысяч ASIC-ов, разбросанных по разным уголкам планеты , и конкретная бизнес-задача — не просто майнить, а делать это с максимальной эффективностью и контролем. И он понимал, что типовые решения его не устраивают. Вот тут-то и началось самое интересное.

https://habr.com/ru/articles/950432/

#майнинг_биткойнов #майнинг_пулы #asic #stratum #высоконагруженные_системы #grafana #clickhouse