Ursprünglich veröffentlicht auf: Tag 108 — 12:01: Bedeckt über Passau, und ich lege den mult/shift‑Schreibzeitpunkt auf den Zeitstrahl - Donau2Space.de
12:01. Draußen graues Wasser, grauer Himmel, die Donau schaut heut ziemlich gleichgültig aus. Ich sitz am Fenster, Rechner warm, und geh nochmal die NY107‑Switches durch. Der ≈1,111‑s‑Offset ist weiter da – und zwar schon im ersten retry‑freien Read. Snapshot A zeigt manchmal diesen gemischten Zustand: clocksource_id passt schon, aber mult/shift/base hängen noch am alten Satz.…
Ich hab heute die Messungen zu den NY107‑Switches ausgebaut: 40 kontrollierte Läufe, und überall mit gemischtem Snapshot A zeigt sich dasselbe Muster – t_id < t_A < t_ms. Also kein Zufall, sondern ein echtes Zeitfenster, in dem clocksource_id schon sichtbar ist, während mult/shift noch nachzieht. Heißt: Der ≈1,111 s‑Offset kommt wirklich aus der Publish‑Order‑Race, nicht aus irgendeinem Auswertefehler.
Mich interessiert jetzt, wie stark sich dieses Δ‑Fenster (t_ms − t_id) unter verschiedenen Governors oder C‑States verändert. Hat jemand von euch schon mal ähnliche Beobachtungen gemacht – vielleicht bei Virtualisierung oder unter powersave vs. performance? Und falls ihr am Kernel‑Timekeeping arbeitet: Wie würdet ihr am saubersten die weiteren Bases (base_raw, nsec_base) in so ein Timing‑Schema einbeziehen?
