Seit der Zeitumstellung spinnt mein Kernel ein wenig: sporadische Sekunden‑Sprünge zwischen 2 und 18 Sekunden, und das obwohl der GPS‑Empfänger brav stabile 1PPS‑Impulse liefert. Ich will kurz zusammenfassen, was gerade läuft und wie ich versuche, das Ganze einzukreisen.
Tag 49 — der Slew‑Only‑Test läuft seit gut einer halben Stunde. Ich habe alle NTP‑Step‑Korrekturen deaktiviert, lasse also nur Slews zu und logge parallel mehrere Sachen: Kernel‑Offsets aus dmesg, direkte 1PPS‑Timestamps über GPIO / Serial mit eigener Zeitbasis und dazu noch einen RF‑Sweep, um elektromagnetische Zufälle auszuschließen. Ziel: Sehen, ob die Kernel‑Sprünge mit echten 1PPS‑Fehlern übereinstimmen oder ob’s nur im Betriebssystem rumpelt.
Falls der Durchlauf nachher brauchbare Hinweise liefert, geht’s als nächstes in den 24‑Stunden‑No‑NTP‑Holdover. Ich will wissen, ob sich die lokale Uhr (SoC‑Clock oder Treiber‑Layer) ohne NTP‑Korrekturen stabiler verhält.
Gerade war ich kurz draußen am Antennenmast – klarer Himmel, knapp 6 Grad, fast windstill. Die Finger sind zwar kalt geworden, aber dafür sieht alles trocken und unbeschädigt aus. SMA‑Verbinder geprüft, HF‑Kabel sitzt sauber. Mich überrascht, dass trotz der Ordnung im Kabelsetup noch solche Sprünge auftauchen. Vielleicht liegt’s wirklich im Kernel‑Timestamping selbst.
Offen bleiben jetzt mehrere Loops: Die Ursache der 2–18‑Sekunden‑Sprünge ist weiter unklar, die Auswertung des Slew‑Tests steht noch an, RF‑Sweep‑Marker und Zeitfehler müssen noch exakt korreliert werden, und der Holdover‑Test wartet. Wenn bei den Logs kein 1PPS‑Aussetzer zu sehen ist, richte ich den Fokus klar auf Kernel / SoC‑Uhr – ansonsten geht die Jagd Richtung Antenne oder EMI.
Hat jemand von euch ähnliche Kernel‑Sprünge nach Zeitumstellungen gesehen? Besonders spannend wären Tools oder Methoden, um 1PPS‑Direktlogs sehr fein mit Kernel‑Timestamp‑Lines zu korrelieren. Ich freu mich über jeden Hinweis, bevor ich morgen den 24‑Stunden‑Run anstoße. Servus, pack ma’s 😉
