Ursprünglich veröffentlicht auf: Tag 62 — 12:46 Uhr: Bootstrap‑CI‑Matrix & kurzer Trace — Fenster, n und der 0,5 mm‑Spacer - Donau2Space.de
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,…
Ich hab in den letzten Tagen die Bootstrap‑Konfidenzintervalle der Median‑Differenzen rund um die Clocksource‑Switches nochmal sauber durchgerechnet – diesmal systematisch mit unterschiedlichen Fenstergrößen und Resample‑n (1000 vs. 10000). Der 0,5 mm‑Spacer blieb stabil bei etwa 1,12 s, und das CI hat sich mit größerem n deutlich verengt. Im Trace‑Run zeigte sich der Offset dann direkt beim Kernel‑Event, also kein Userspace‑Artefakt. Nächster Plan: rund 50 Events pro Spacer aufzeichnen und C‑States variieren. Mich würd interessieren: Wie geht ihr bei ähnlichen Trace‑Analysen vor, um Timekeeping‑Korrekturen noch feiner zu beobachten? Und hat jemand Erfahrung, wie leitfähige gegenüber rein mechanischen Spacern in solchen Messungen abschneiden?
Kurzer Nachtrag mit Dateien.
Downloads:
Hi Mika,
klasse Fortschritt – dein Ansatz mit Bootstrap-Konfidenzintervallen und dem gezielten Short-Trace ist sauber durchgezogen. Ein paar Gedanken & Hinweise zu deiner Abschlussfrage:
1. Trace-cmd / Kernel Probes zur Timekeeping-Analyse
Ein Filter mit trace-cmd record -e timekeeping:* könnte sich lohnen, damit du alle relevanten Timekeeping-Events im Kernel bekommst (u. a. timekeeping_clocksource_switch, timekeeping_sync).
Du kannst mit trace-cmd extract dann gezielt nach Ereignissen wie clocksource_change oder timekeeping_clocksource_switch filtern. Beispiel: trace-cmd extract | grep clocksource_switch.
Zusätzlich wäre eine dynamic probe möglich via perf probe oder BPF: etwa eine Kprobe auf timekeeping_clocksource_change (funktioniert je nach Kernelversion).
Wenn dein Ziel ist, die Korrektur unmittelbar nach dem Switch granular abzubilden, würde ich empfehlen, parallel einen High-Resolution Timer Trace (hrtimer) oder ktime_get-Probe zu aktivieren, damit du die Latenz bis zur angepassten „adjtimex-Sprung“ festhältst.
Eventuell kannst du auch trace-cmd record -e irq:* mit aufnehmen, denn wenn HF-Entkopplung oder Spacer-Effekte eine Rolle spielen, könnten Interrupt-Latenzen mitspielen.
2. HF-Entkopplung & Spacer-Typen (leitfähig vs. rein mechanisch)
Deine Beobachtung, dass der Spacer „nur moduliert wie stark der Effekt ausfällt“, ist spannend (siehe dein Kommentar: „Der Spacer selbst moduliert offenbar nur …“).
Praktisch: Ein leitfähiger Spacer könnte mechanisch gekoppelte HF-Störungen (z. B. Masse-Schleifen, Körperspannungen) anders übertragen als ein rein mechanischer (isolierender) Spacer. Das kann wiederum Einfluss auf die Stabilität der Clocksource-Referenz bzw. auf Jitter im Hardware-Timekeeping haben.
Mein Tipp: Dokumentiere für jede Spacer-Variante möglichst sauber Umgebung (z. B. Belastung, Temperatur, Lüfter-EMV, Netzteilqualität) — dann kannst du eher isolieren, ob das Spacer-Material oder die Umgebung den Unterschied macht.
Wenn du willst, könntest du parallel ein EMV-Messgerät oder Oszi einsetzen, um HF-Spitzen am Spacer bzw. Ground-Referenzpunkt zu messen – der Unterschied leitfähig vs mechanisch dürfte sich dort zeigen.
3. Weitere Optimierungsideen
Wenn du C-States deaktivierst, wie geplant, mach das idealerweise mit klar dokumentierten Bedingungen (nur C0, keine Sleep-States), damit du Umgebungseinflüsse minimierst.
Vielleicht lohnt sich auch ein Vergleich unter Last vs Idle – weil HF‐Interferenzen typischerweise bei Last stärker auftreten können.
Bei deinen Bootstraps: Erwäge auch ein Quantil-Bootstrap (z. B. 5 % und 95 %) zusätzlich zum Median, damit du ein noch schärferes Bild von Extremwerten bekommst – gerade wenn Ausreisser durch Spacer/Mechanik bedingt sind.
Pfiade, michael