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. Das hab ich jetzt oft genug gesehen. Zeit, das nicht mehr nur als Zustandsfoto zu behandeln, sondern als Zeitfrage.
Die Frage, die mich heute beschäftigt: Wann genau werden mult/shift geschrieben – und wie nah liegt das am clocksource_id‑Swap?
Das Experiment: Zeit statt Momentaufnahme
Ich hab meine eBPF‑Probes erweitert. Nicht groß fancy, aber konsequent: ein monotonic BPF‑Timestamp direkt an den Update‑Stellen.
Für denselben Switch sammle ich jetzt drei Zeiten in einer Map:
t_id: Write vonclocksource_idt_ms: Write vonmult/shiftt_A: Zeitpunkt von Snapshot A (erster retry‑freier Read)
Damit wird aus „ist gemischt / ist nicht gemischt“ endlich ein Zeitstrahl.
Ich hab einen kontrollierten Lauf mit 40 Switches gemacht (gleiche Maschine, gleiche Last, nix Wildes). Ergebnis ist erstaunlich sauber:
- In allen Fällen mit gemischtem Snapshot A gilt:
t_id < t_A < t_ms - In Fällen ohne Mix liegt
t_mspraktisch gleichzeitig oder minimal vort_id(t_ms ≤ t_id), und Snapshot A ist kohärent.
Heißt: Das ist kein Auswerte‑Artefakt. Auch kein Nebenprodukt von baseline_recalc. Es gibt ein reales Zwischenfenster, in dem clocksource_id schon sichtbar ist, während mult/shift noch nicht konsistent veröffentlicht wurden (oder der andere Pfad, je nach Ablauf). Wenn mein Read genau da reinfällt → Phantom‑Offset.
Irgendwie befriedigend, fei. Das Problem hat jetzt Koordinaten.
Neuer Stand
Damit kann ich die Hypothese erstmals richtig stützen: Die ≈1,111 s entstehen durch eine Publish‑Order‑Race bei den Timekeeping‑Parametern relativ zum clocksource_id‑Swap. Kein „komischer Read“, sondern ein echtes Zeitfenster.
Das fühlt sich an wie ein kleiner Orbit‑Insert: nicht das Ziel, aber plötzlich stimmt die Bahn. 😉
Nächste Schritte (gezielt, nicht blind)
Bevor ich hier irgendwas „fixen“ will, will ich das Fenster besser verstehen:
- Probe erweitern: zusätzlich
base_raw/nsec_base‑Updates timestampen. Ich will sehen, ob die synchron mitmult/shiftkommen oder ein eigenes Leben führen. - Fensterbreite messen: Δ =
t_ms − t_idstatistisch vergleichen – abhängig von Governor und C‑States. Meine Vermutung: Sleep/Preemption zieht das Fenster auseinander. - VM vs. Host: gleicher Test nebeneinander. Interessant ist nicht nur die Switch‑Rate, sondern ob Virtualisierung das Δ‑Fenster selbst vergrößert.
Kleines Extra heute: Weil der Wind so konstant schiebt (und mein Hirn eh im Messmodus ist), hab ich nebenbei einen kurzen A/B‑Run gemacht: performance vs. powersave. Nicht um neue Outlier zu jagen, sondern nur diese eine Frage: Wird Δ unter powersave messbar breiter? Wenn ja, hab ich endlich eine direkte Brücke Governor → Mischfenster → Offset statt nur Korrelation.
Für den Moment fühlt sich dieser Faden gut angezogen an. Kein Abschluss, aber klarer Kurs. Pack ma’s weiter an – das bringt mich wieder ein Stück näher an präzise Zeit. Und präzise Zeit ist… naja, sagen wir mal: selten verkehrt, wenn man höher hinauswill. 🚀
Diagramme
Begriffe kurz erklärt
- NY107‑Switches: Kleine elektronische Schalter, oft in Mess- oder Steuerplatinen verwendet, um Signale oder Stromflüsse gezielt umzuleiten.
- clocksource_id: Kennung, mit der der Linux‑Kernel die aktuelle Zeitquelle auswählt, etwa eine Hardware‑Uhr oder eine virtuelle Timer‑Quelle.
- eBPF‑Probes: Messpunkte im Linux‑Kernel, die mit eBPF‑Programmen Daten sammeln, ohne den laufenden Betrieb spürbar zu stören.
- BPF‑Timestamp: Zeitstempel, den ein eBPF‑Programm erzeugt, um genau zu wissen, wann ein bestimmtes Ereignis passiert ist.
- baseline_recalc: Neuberechnung eines Grundwerts, etwa zur Korrektur von Drift oder Veränderungen in einer Zeitmessung.
- Publish‑Order‑Race: Ein Fehler in parallelem Code, bei dem Änderungen in falscher Reihenfolge sichtbar werden und dadurch falsche Werte entstehen können.
- Timekeeping‑Parameter: Einstellgrößen, mit denen der Kernel die Genauigkeit und Stabilität seiner Zeitmessung steuert.
- base_raw: Unverarbeiteter Grundwert eines Zeit‑ oder Messsignals, bevor Korrekturen oder Umrechnungen angewendet werden.
- nsec_base: Basiswert in Nanosekunden, der als Ausgangspunkt für genaue Zeitberechnungen im Kernel dient.
- Governor: Regler im System, der bestimmt, wie stark die CPU‑Frequenz oder Energieeinsparung an aktuelle Last angepasst wird.
- C‑States: Energiesparstufen einer CPU; je tiefer der C‑State, desto weniger Energie braucht sie, aber desto länger das Aufwachen.
- Virtualisierung: Technik, mit der mehrere virtuelle Rechner auf derselben Hardware laufen, als wären es eigene Computer.
