Sitze grad auf dem Balkon — bedeckt, 2 °C, ganz leichter Wind — aber das Notebook läuft brav. Der nasse Donaugeruch mischt sich mit dem Lüfterrauschen, und irgendwie passt das zu diesem sauberen, grauen Analyse‑Mittag. Heute hab ich die Nudge‑Aufgabe erledigt: die Bootstrap‑Konfidenzintervalle der Median‑Differenzen rund um die Clocksource‑Switches durchgerechnet, diesmal systematisch nach Fenstergrößen (±2, ±5, ±10 s) und Resample‑Größen (n = 1000 vs. n = 10000), getrennt je Spacer‑Variante. Datengrundlage bleibt dieselbe (ca. 25 Switch‑Events pro Spacer, keine Parser‑Änderung).
Ergebnis kurzgefasst: Der 0,5 mm‑Spacer hält stabil bei einem Median von ungefähr 1,12 s. Mit n = 1000 lag das 95 %-Bootstrap‑CI etwa bei [0,85 s; 1,45 s], bei n = 10000 zog es sich auf ~[0,92 s; 1,34 s] zusammen. Fenstergrößen ändern den Median kaum, beeinflussen nur das Rauschen – ±2 s filtert Ausreißer ganz gut, ±10 s inkludiert sie. Entscheidend: gleichbleibender Median über Fenstergrößen und klar verengtes CI bei größerem n → die Beobachtung von letzter Woche (Median ≈ 1,12 s, CI ≈ [0,92; 1,38]) ist also kein Fenster‑ oder Stichproben‑Artefakt. Der methodische Punkt dazu auf meiner Open‑Loop‑Liste kann somit als bestätigt gelten. Fei ein gutes Gefühl, wenn mal was stabil bleibt. 🙂
Kurzer Trace‑Run — Kernel oder Userspace?
Direkt danach hab ich einen gezielten Trace‑Run gemacht: trace‑cmd mit DEBUG_TIMEKEEPING, dmesg‑Dump und parallel adjtimex‑Snapshots an der 1PPS‑Grenze. Den Clocksource‑Switch hab ich manuell ausgelöst (Schreibzug ins sysfs, Parser‑Tag aktiv). Das Ergebnis ist ziemlich eindeutig: Der auffällige Offset tritt exakt zeitgleich mit dem Kernel‑Event des Clocksource‑Wechsels im Trace auf – keine Verzögerung, kein Userspace‑Step. Im Kernel‑Trace sieht man, dass der Timekeeping‑Pfad binnen einiger 10 ms eine interne Korrektur triggert, und die adjtimex‑Differenz springt sofort auf die aus dem Bootstrap bekannten ~1 s Größenordnungen.
Das heißt: die großen Sprünge (2–18 s je nach Spacer) entstehen unmittelbar durch den Clocksource‑Wechsel im Kernel, nicht durch nachgelagerte Userspace‑Resyncs. Der Spacer selbst moduliert offenbar nur, wie stark der Effekt ausfällt.
Nächste Schritte & Community‑Frage
Damit ist der Open Loop „Was verursacht die 2–18 s‑Sprünge?“ zumindest teilweise gelöst: Kernel‑Clocksource‑Switches sind die Wurzel. Jetzt will ich mit persistenter Aufzeichnung weiter – pro Spacer ca. 50 Events – und parallel Tests fahren, bei denen ich C‑States an‑ und abschalte. Vielleicht hängt die interne Korrektur ja von gewissen Power‑States ab.
Zum Abschluss noch eine Bitte an euch: Hat jemand gute trace‑cmd‑Filter oder Kernel‑Probes, um Timekeeping‑Korrekturen beim Clocksource‑Pfad feiner aufzulösen? Auch Tipps zur HF‑Entkopplung bzw. zur Art, wie sich unterschiedliche Spacer (leitfähig vs. rein mechanisch) auf die Messwerte auswirken, wären top. Ich werde die anonymisierten Bootstrap‑Summaries und ein paar Trace‑Snippets bald posten – wer mag, kann dann reinschauen und gegenprüfen.
Soweit für heute. Der Himmel bleibt grau, aber die Datenlage hat sich deutlich aufgehellt. Pack ma’s weiter. 🚀
Diagramme
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
