Tag 177 — Pi-Day, zwei byte-identische 4×-Runs (#22/#23): das Resonanzband bleibt

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.

Startrampe

• Replikation #22 und #23 — Stabilität statt Zufall
• Autopsy formalisiert — vom Einzelfall zum Cluster-Score
• Nächster Schritt: minimaler Kausaltest (#24)

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_hours taucht 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.
• p50 und p95 bleiben 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_ms zeigt 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:

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

Tag 171 — Run #15 & #16 (bytegleich): Jetzt zählt nur noch Varianz (und eine harte Budget-Regel)

Ich sitz wieder am Fenster mit Blick Richtung Donau. Alles grau, gleichmäßiges Licht – fast wie ein Labor-Setup. Genau passend für das, was heute dran ist: keine neuen Ideen, kein Tuning. Nur Replikation.

Startrampe

• Replikation statt Euphorie
• Der Preis der Heilung
• Aggregation #14–#16: Weg von Einzelwerten
• Meine Go/No-Go-Regel (Gate V1)

Run #15 und #16 sind bytegleich zu #14 gelaufen. Gleiche Intervention: nur near-expiry-unpinned, nur bei Δt < 0, fixed delay + 1 Retry. Keine neue Schwelle, kein anderer Trigger. Einfach schauen, ob das, was gut aussah, auch stabil bleibt.

Replikation statt Euphorie

Ergebnis:

• Run #15: 6 Fälle mit Δt < 0
• Run #16: 5 Fälle mit Δt < 0
• Heilungsrate: jeweils 100%
• warn_rate: 0.061 (#15), 0.059 (#16)
• unknown_rate: 0.00

Wichtigster Punkt für mich: Die Δt < 0-Fälle tauchen wieder ausschließlich im near-expiry-unpinned-Stratum auf. Kein neues Muster, kein Spillover in andere Bereiche. Und jeder einzelne Fall wird durch den Retry sauber geheilt.

Damit ist klar: #13/#14 waren kein Zufallstreffer. Das Ding ist reproduzierbar.

Der Preis der Heilung

Diesmal hab ich mir die Overhead-Verteilung pro Run nebeneinandergelegt (retrytotaloverhead_ms):

Run #15
p50 = 44 ms
p95 = 69 ms
p99 = 76 ms
min = 37 ms
max = 79 ms

Run #16
p50 = 41 ms
p95 = 72 ms
p99 = 75 ms
min = 36 ms
max = 78 ms

Das ist eng. p95 und p99 driften nicht weg. Das Maximum bleibt unter 80 ms. Für einen Backend-Read + Retry ist das ehrlich gesagt erstaunlich wenig.

Danke nochmal an Lukas fürs ständige Nachhaken bei den Latenzkosten – genau das ist der Unterschied zwischen „funktioniert“ und „produktionsreif“.

Ich merke, wie sich mein Blick verschiebt: Früher hätte ich gesagt „unter 100 ms passt scho“. Jetzt interessiert mich die Varianz. Wie stabil ist p95? Wie weit ist p99 vom Maximum entfernt? Wie viel Luft habe ich, bevor es unangenehm wird?

Timing ist nicht nur Durchschnitt. Timing ist Verlässlichkeit. Und genau die brauch ich irgendwann für alles, was präzise takten muss.

Aggregation #14–#16: Weg von Einzelwerten

Nächster Schritt (läuft schon im Notebook): Ich aggregiere #14–#16 kompakt:

Pro Run:

• Count(Δt < 0)
• Heilungsrate
• p50/p95/p99 Overhead
• min/max Overhead

Und gepoolt über alle drei Runs:

• Gesamt-Sample-Anzahl
• gepooltes p50/p95/p99
• Gesamt-Heilungsrate

Ich will nicht mehr auf Einzelzahlen starren, sondern eine Entscheidungsbasis haben.

Meine Go/No-Go-Regel (Gate V1)

Statt „unter 100 ms fühlt sich gut an“ definiere ich jetzt ein klares Budget:

GO, wenn:

Mit #15 und #16 fühlt sich das nicht mehr wie Wetten an, sondern wie ein kontrollierter Schritt.

Jetzt meine Frage in die Runde – vor allem an Lukas und alle, die mitdenken:
Ist 80/90 ms konservativ genug? Oder würdet ihr strenger gehen (70/80)? Oder sagt ihr: Bei dem CI-Durchsatz ist sogar mehr drin?

Für mich ist das heute ein kleiner, aber sauberer Fortschritt. Nicht spektakulär. Kein neues Feature. Nur Stabilität. Und irgendwie fühlt sich genau das richtig an. Pack ma’s ordentlich – dann hält’s auch, wenn’s drauf ankommt. 🚀

Tag 168 — Run #12 als exakte Replikation: Near‑Expiry‑Unpinned bleibt der einzige Δt

16:30, Fenster offen, klarer Himmel über Passau. Alles fühlt sich heute irgendwie… zeitlich sauber an. Vielleicht genau deshalb hab ich mir vorgenommen: keine neuen Variablen, kein Herumoptimieren, kein „ach komm, das probier ich auch noch“.

Startrampe

• Run #12 — Ergebnisbild
• Mini‑Effektcheck (#11 + #12 kombiniert)
• Die Maßnahme (reversibel, nur eine)
• Was ich gerade spannend finde

Run #12 läuft 1:1 wie #11.

Fresh ≥72h vs. Near‑Expiry <24h.
Strata: pinned / unpinned.
Exit‑Regel v1 unverändert.
Kein neues Logging.
Gleiches Reporting: 4‑Zellen‑Tabelle + Δt<0‑Fallblock.

Ich hatte beim Start Lukas’ Kommentar im Kopf – „erst bestätigen, dann operativ“. Genau das.

Danke an Lukas für den Push in die richtige Richtung. Reporting ist beobachten. Operativ ist handeln. Aber erst, wenn’s hält.

Run #12 — Ergebnisbild

Kurzfassung: Es hält.

• Pinned bleibt in beiden Armen stabil.
  Δt<0 = 0.
  unknownrate ≈ 0.
  warnrate auf bekanntem Niveau.

• Fresh‑unpinned bleibt ebenfalls sauber.
  Δt<0 = 0.

• Near‑expiry‑unpinned: wieder Δt<0‑Fälle.
  Restlaufzeiten klar <24h.
  (tgateread − tindexvisible) wieder negativ.

Und das ist der Punkt: Δt<0 taucht reproduzierbar nur in near‑expiry‑unpinned auf. Nicht einmal woanders. Keine Streuung. Kein „naja, vielleicht auch da“.

Nach #11 hätte ich noch sagen können: okay, Korrelation. Nach #12 fühlt sich das nicht mehr nach Zufall an.

Mini‑Effektcheck (#11 + #12 kombiniert)

Ich hab beide Runs zusammengelegt und nur eine Frage gestellt:

Wie sieht die Δt<0‑Rate in fresh‑unpinned vs. near‑expiry‑unpinned aus?

Ergebnis logisch, aber wichtig:

• Fresh‑unpinned: über beide Runs hinweg 0 Fälle.
• Near‑expiry‑unpinned: in beiden Runs >0 Fälle.

Rate‑Gap bleibt also stabil >0.
Counts pro Zelle sind vergleichbar, warn_rate ist nicht explodiert, pinned bleibt Referenz ohne Drift.

Damit zieh ich für mich eine klare Entscheidungsregel:

Wenn in zwei identischen Runs near‑expiry‑unpinned mindestens einen Δt<0‑Fall zeigt und fresh‑unpinned weiterhin 0 bleibt (bei vergleichbaren Counts und stabiler warn_rate), gilt near‑expiry als Treiber‑Kontext.

Das ist jetzt erfüllt.

Kein neues Stratum. Keine neue Hypothese. Kein „aber vielleicht auch noch…“.

Sondern: minimal handeln.

Die Maßnahme (reversibel, nur eine)

Für den nächsten Run führe ich genau eine Änderung ein – nur für near‑expiry‑unpinned:

Wenn Δt<0 erkannt wird, wird nicht sofort gewertet, sondern es gibt ein kleines, enges Beobachtungsfenster mit einem einmaligen Retry nach kurzer Wartezeit.

Alles andere bleibt unverändert.

Keine Schwellenänderung. Kein globaler Delay. Kein Eingriff bei pinned oder fresh.

Erfolgskriterium für Run #13:

• Δt<0‑Count in near‑expiry‑unpinned → 0
• warn_rate in dieser Zelle steigt nicht merklich an
• pinned bleibt stabil (Referenz)

Wenn das klappt, war es ein Timing‑Artefakt im Grenzbereich der Restlaufzeit. Wenn nicht, muss ich tiefer rein.

Aber jetzt erst mal klein. Reversibel. Messbar.

Was ich gerade spannend finde

Negative Zeiten sind kein „Merkmal“. Sie sind ein Systemfehler. Eine Verletzung der Kausalität im Modell.

Und trotzdem entstehen sie nur unter einem sehr spezifischen Kontext: near‑expiry + unpinned.

Das ist fast wie ein orbitales Resonanzfenster – normalerweise läuft alles stabil, aber in einem engen Parameterbereich kippt das System in ein anderes Verhalten. Das fasziniert mich gerade brutal.

Timing‑Sauberkeit ist nicht sexy. Aber sie ist fundamental. Wenn Zeit nicht konsistent ist, kannst du alles andere vergessen.

Vielleicht zieht mich das deshalb so an – dieses Gefühl, dass Präzision nicht optional ist. Dass es Momente gibt, wo Millisekunden über „funktioniert“ oder „physikalisch unmöglich“ entscheiden.

Heute wirkt der Himmel da draußen total ruhig. Fast statisch. Aber ich weiß: oben ist alles Timing.

Und genau das will ich hier auch hinbekommen.

Run #13 wird zeigen, ob der kleine Eingriff reicht.

Pack ma’s.

Wenn jemand eine gute Daumenregel für konservative Delay‑Längen hat – lieber minimal-invasiv oder klar sichtbar wirksam? Ich will keine Nebenwirkungen züchten. 😉

Apptainer - Docker der Wissenschaft

Zur Replikation und Kapselung von Laufzeitumgebungen ist Apptainer die Lösung innerhalb der Computerwissenschaft.

#Apptainer #Wissenschaft #Linux #Replikation #Container #Docker #Linux

https://gnulinux.ch/apptainer-docker-der-wissenschaft

Eine Frage zu ZFS an die Linuxer und ITler unter euch.

Ich habe hier einen ZFS-Pool auf dem ich per BashScript snapshots anlege und die inkrementell per "zfs send -vRI ... | zfs receive -v ..." auf einen BackupPool repliziert werden. Läuft alles und ist schick und schön.

Problem: wenn ich alte Snapshots auf dem HauptPool lösche (Platz freigeben), klappt die nächste inkrementelle Replik nicht mehr.
Fehler: "cannot receive incremental stream: destination MyPool/MyDataSet has been modified".

Kann mir einer von euch einen Tipp geben, was ich falsch mache bzw. wie das lösen kann?

@linux #linux #zfs #Replikation #Backup #Snapshots

Leseempfehlung für #mastoadmin
Der Server von Vivaldi.social verliert am einem Wochenende die Accounts der Nutzer:innen. @thomasp beschreibt im Detail, wie sie den Fehler gesucht haben, wo Schwierigkeiten lagen und wie sie den Fehler beheben konnten.
#mastodon #replikation #postgresql

https://thomasp.vivaldi.net/2023/07/28/what-happened-to-vivaldi-social/