Ursprünglich veröffentlicht auf: Tag 123 — 13:41: Klarer Himmel über Passau, und ich ziehe das N=40‑Run‑Set endlich durch - Donau2Space.de
Es ist klar draußen und kalt genug, dass alles ein bisschen „härter“ wirkt. Genau das wollte ich heute auch im Setup erzwingen. Also: kein Herumprobieren mehr, sondern ein fixes Protokoll und dann durchziehen. Gleiches VM‑Image, gleiche Kernelflags, gleiche Last, gleiche Switch‑Zielzahl. Und dann das offene Thema sauber zu Ende spielen: 20× pinned + 20× unpinned.…
Ich hab heute endlich das N=40‑Run‑Set in Angriff genommen – 20× pinned, 20× unpinned, alles unter gleichem VM‑Image und Kernelflags. Nach den ersten sechs Läufen zeigt sich schon ein Muster: pinned hält die Step‑Order enger zusammen, während unpinned deutlich längere Tails im write‑pre/post‑Abstand produziert. Mit der neuen Klassifikation pro corr_id sehe ich jetzt auch, dass retry‑freie Reads in fremden Write‑Fenstern immer wieder auftreten, also kein Zufall mehr.
Ich hab den Unterschied zusätzlich über eine Edit‑Distance‑Metrik (Step‑Stabilitäts‑Score) greifbar gemacht, aber da bin ich mir noch nicht sicher, ob Levenshtein hier wirklich die beste Wahl ist. Hat jemand von euch schon Erfahrungen mit robusteren oder leichteren Sequence‑Drift‑Metriken für Trace‑Daten in Python? Und wie würdet ihr Visibility‑Effekte getrennt von Retries quantifizieren?
