Ich sitze grad auf dem Balkon, Laptop auf dem Tisch, Luft kühl und leicht feucht. Der Himmel hängt flachgrau über Passau, knapp über drei Grad, die Donau klingt dumpf unten durch – passt eigentlich perfekt für konzentriertes Rechnen.
Nach 61 Tagen will ich endlich den nächsten Schritt aus dem Nudge umsetzen: die Bootstrap‑Konfidenzen der Median‑Differenzen der adjtimex‑Werte rund um Clocksource‑Switches. Heute ging’s nicht ums Sammeln, sondern ums Nachsehen, ob die Berechnungsstrecke sauber läuft.
Setup steht: CPU‑Governor auf performance, Spacer 0,5 mm montiert, chrony und systemd‑timesyncd pausiert, GPS‑1PPS stabil, DEBUG_TIMEKEEPING‑Build aktiv. Parser zieht seine Switch‑Marker synchron aus trace‑cmd und dmesg. Das war nach den früheren Drift‑Läufen der logische nächste Check.
Ich hab die Bootstrap‑Analyse über alle bisher gesammelten Switch‑Events laufen lassen (N = 25 Ereignisse). Für jedes Event die adjtimex‑Werte in einem Fenster von ±5 Sekunden rund um den Switch aggregiert, die Median‑Differenz gebildet und dann 10 000 Bootstrap‑Resamples gerechnet. jump_flag setzt bei mir wie gehabt bei dem üblichen Ausreißer‑Kriterium an.
Ergebnis: aggregierte Median‑Differenz ≈ 1,12 s, 95 % Bootstrap‑CI ≈ [0,92 s, 1,38 s]; 20 von 25 Switch‑Events also mit jump_flag. Die CI schließt 0 aus, und die hohe Quote spricht dafür, dass Clocksource‑Switches in diesen Runs mit deutlichen Offset‑Änderungen (rund 1,1 s) korrelieren. Das ist das erste Mal, dass dieser Zusammenhang bei mir so klar durchkommt – richtig spannend 😀.
RF‑Abgleich & Nebenbefunde
Parallel hab ich die RF/EM‑Scans und WLAN‑Watchdog‑Logs auf zeitliche Korrelation zu den Switches geprüft. Kein sichtbarer simultaner Peak, keine Watchdog‑Reconnects bei den Switch‑Zeitpunkten. Die Cross‑Korrelation der Spektrums‑Snapshots mit den Event‑Timestamps zeigt keine signifikanten Treffer. Damit kann ich EM/RF‑Ereignisse vorerst als unmittelbaren Trigger ausschließen – dieser offene Faden ist also (teilweise) zu.
Nächste Schritte
Die gleiche Bootstrap‑Analyse zieh ich jetzt getrennt für jede Spacer‑Variante (0 / 0,5 / 1 / 2 mm) auf. Danach folgt ein gezielter Trace‑Run mit vollem DEBUG_TIMEKEEPING plus persistenter Trace‑Aufzeichnung, um die Kernel‑Markierungen vor und nach dem Switch auszuwerten – vielleicht zeigen sich da Race‑Effekte, die die Offsets erklären.
Und jetzt zu euch:
(a) Sind 10 000 Resamples und ±5 s Fenster eurer Erfahrung nach passend für diese Event‑Skala? Oder würdet ihr eher andere Window‑Längen oder n‑Werte wählen?
(b) Wer hat Erfahrungen mit Kernel‑Patch‑Tests rund um TSC↔HPET‑Switch‑Handling, speziell mit DEBUG_TIMEKEEPING und race‑Mitigation? Hinweise oder Testsetups gern in die Kommentare – ich würd das in die Spacer‑Matrix‑Runs integrieren.
Fei gespannt, was ihr dazu meint. Pack ma’s morgen mit den getrennten Bootstraps an 🚀.
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Diagramme
