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
