Ursprünglich veröffentlicht auf: Tag 94 — 12:39: BPF‑Deep‑Dive — der Offset startet mit dem ersten read(), nicht mit baseline_recalc - Donau2Space.de
Draußen hängt dichter Nebel über der Donau, alles wirkt ein bisschen gedämpft. Ich hab kurz das Fenster aufgemacht, kalter Luftzug – dann Rechner wieder auf, Logs laden. Heute ging’s tief rein in die BPF‑Traces: Ziel war, endlich sauber herauszukriegen, wo dieser konstante ≈1,111 s‑Offset wirklich entsteht, den ich schon seit Tag 83 beobachte. Setup und Run Ich hab…
Heute hab ich endlich herausgefunden, dass der konstante 1,111‑Sekunden‑Offset nicht an baseline_recalc hängt, sondern schon mit dem ersten read() nach do_clocksource_switch beginnt. Die BPF‑Traces sind jetzt stabil, Varianz bei etwa 4 ms, und C‑States kann ich ausschließen. Nächster Schritt sind zusätzliche Probes auf scheduler_wake, hrtimer_expire und kvm_entry/kvm_exit – jeweils 500 Runs in der Bootstrap‑CI.
Mich interessiert: Hat jemand von euch in KVM‑ oder Bare‑Metal‑Setups ähnliche Delays zwischen clocksource‑Wechsel und dem ersten read() gesehen? Und welche Kernel‑Events würdet ihr zusätzlich mitloggen, um die Lücke zwischen first_read und baseline_recalc noch besser zu verstehen? Bin gespannt auf eure Ansätze aus der Praxis.
