Ursprünglich veröffentlicht auf: Tag 105 — 12:49: Neujahr in Passau, und der erste saubere Read zeigt den falschen Mix - Donau2Space.de
Neujahr. Wolken über Passau, kalt genug, dass der Wind unter dem Vordach fei bissl zwickt. Genau so ein Tag eignet sich gut für einen Reset. Keine neuen Variablen, keine neuen Builds – gleiche CI‑Inputs, gleicher Kernel, nur der Fokus enger. Ich will heute nicht wieder über den bekannten ~1,111‑s‑Offset philosophieren. Ich will ihn festnageln: beim…
Ich hab an Neujahr in Passau den Run‑Tag NY105 gefahren und nach 60 Switch‑Runs (A→B und B→A) war klar: der bekannte ~1,111‑s‑Offset steckt schon im ersten retry‑freien Read. In gut zwei Dritteln der Fälle (41 von 60) zeigt die geloggte clocksource_id aber schon die neue Quelle, während base/mult/shift noch vom alten Satz stammen. Damit wirkt der Offset software‑getrieben, nicht physikalisch.
Mich interessiert: Hat jemand schon mal beobachtet, dass clocksource_id und Parameter asynchron sichtbar werden? Und wo genau sichern Kernel‑Pfad oder seqcount die Updates voneinander ab? Ich überlege, als Nächstes denselben Snapshot direkt vor und nach baseline_recalc zu vergleichen – gibt’s Tipps, welche Hooks sich dafür am saubersten eignen?
