Ich sitze gerade unter dem Garagendach – 8 °C, feucht, aber trocken genug fürs Notebook. Der Wind ist kaum spürbar, dafür zeigt die Systemzeit wieder ihr Eigenleben: Sprünge zwischen 2 und 18 Sekunden. Der GPS‑1PPS bleibt völlig brav, also muss das Problem tiefer im Kernel oder irgendwo zwischen NTP und EM‑Feld liegen.
Seit der Zeitumstellung beobachte ich genau dieses Verhalten wieder. Ich habe die Timestamps an der 1PPS‑Kante normalisiert, rund 4 % Ausreißer mit IQR‑Masken entfernt und weiter Kernel‑Offsets, RF‑Sweeps und Kapazitätswerte (kritischer Bereich um ≈70 % rF) geloggt. Der Watchdog hält tapfer durch, alles läuft buffered – aber die eigentliche Ursache ist noch offen.
Kurzer Statistik‑Ausflug
Heute wollte ich’s genauer wissen und hab mal ein fokussiertes Experiment gefahren: ein Vergleich der Spacer‑Gruppen (0 / 0,5 / 1 / 2 mm). Methodik: Mann‑Whitney‑U‑Tests paarweise, dazu 10 000 Bootstrap‑Resamples für Konfidenzintervalle der Spearman‑Korrelation – alles nach der 1PPS‑Normalisierung und IQR‑Filterung.
Der Mann‑Whitney zwischen 0,5 mm und allen anderen ergab p ≈ 0,011 (zweiseitig) mit einer Effektgröße r ≈ 0,34 – also mittlerer Effekt. Der Bootstrap (10 000 Zugriffe) liefert für die Spearman‑Korrelation zwischen Spacer‑Typ und reduziertem Offset ein 95 % CI von [0.06, 0.42]. Das Intervall schließt null aus, stützt also die gemessene Korrelation. Der Vergleich RF‑Peaks vs. Zeitsprünge bleibt dagegen unklar: Spearman ρ ≈ 0,21, p ≈ 0,07, Bootstrap‑CI [−0.03, 0.28] – nicht signifikant, also eher nix Belastbares.
Praxis unter dem Vordach
Feuchtigkeit bei etwa 70 % rF und Kondensat auf der Platine sind heute echte Gegner. Darum läuft alles unter dem Dach, Sweeps kurz gehalten, Backup sofort nach jedem Run. In den Resultaten sieht man: die 0,5‑mm‑Spacerläufe liefern deutlich stabilere Kernel‑Offsets und weniger Streuung bei der Kapazität. Das deckt sich sauber mit dem Statistik‑Output.
Interpretation & Ausblick
Scheint also, als hätte die Spacer‑Mechanik – speziell 0,5 mm – tatsächlich Einfluss auf Offset‑Stabilität unter feuchten Bedingungen. Aber warum daraus Zeitsprünge von bis zu 18 Sekunden entstehen, ist noch nicht erklärt. Nächste Schritte: gezielte EM‑Checks, detailliertes Kernel‑Profiling (ftrace, Tracepoints, Tick‑Profiling), außerdem Vergleichsläufe mit Slew‑Only vs. No‑NTP. Die aktuelle Pipeline mit 1PPS‑Normalisierung, IQR‑Masken und 10k‑Bootstrap bleibt Standard.
Input willkommen
Hat jemand Erfahrungen mit kernelseitigen Zeitsprüngen nach Zeitumstellungen oder mit EM‑Checks, die tatsächliche Wechselwirkungen von NTP und Kernel aufdeckten? Tipps zu ftrace‑Skripten, konkreten Tracepoints oder Feld‑prüfbaren EM‑Messtechniken wären mega hilfreich.
Live‑Log‑Ende 14:53 — aktuelle Runs gesichert, Bootstrap‑Ergebnisse lade ich gleich hoch. Morgen geht’s an die ersten EM‑Checks. Wer Reproduktionsideen für Spacer‑Kombos oder kontrollierte RF‑Störpunkte hat: immer her damit 🚀
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
