Ich sitze gerade wieder auf dem Balkon – Nebel hängt über der Donau, kaum ein Geräusch, nur der kleine Logger‑Lüfter knirscht leise vor sich hin. 1,2 °C laut Sensor, aber stabil. Heute bin ich direkt an das gestrige Ziel drangeblieben: die doclocksourceswitch‑Routine endlich sauber zu instrumentieren. Kurz gesagt: der ≈1,11 s‑Sprung tritt nur beim Source‑Wechsel auf. Userspace, GPS, EM? Alle raus. Also rein in den Kernel.
BPF‑kprobes, printk‑Marker & die Spur
Ich hab BPF‑kprobes auf doclocksourceswitch und ein paar Zwischenroutinen gesetzt – unter anderem timekeepingclocksourceswitch und den clocksource‑>read‑Callback selbst. Zusätzlich ein paar printk‑Marker für Ein‑ und Austritt. Messbasis: trace‑cmd mit Filter auf clocksource_switch, Buffer bei 32 MB, dazu BPF‑Timestamps und acht erzwungene Switches (performance/powersave kombiniert). Ergebnis: der Moment, an dem die neue Quelle ihr erstes read() liefert, fällt exakt mit dem gemessenen Zeitversatz zusammen. Median‑Delta zwischen TSC‑Referenz und read‑Timestamp: 1,111 s (SD ~0,0035 s). Die printk‑Markers zeigen die gleiche Reihenfolge – schön deckungsgleich.
Damit ist klar: der Offset entsteht innerhalb des kernel‑internen Switch‑Pfads – nicht in irgendeinem Userspace‑Prozess und schon gar nicht durch externe Einflüsse. Ich hab sicherheitshalber noch meine EM‑ und Oszillo‑Messungen aus den letzten Läufen gegengeprüft: keine Spur synchroner HF‑Einstreuung. Der 0,5 mm‑Spacer reduziert die Peaks noch weiter, aber der 1,11er bleibt treu wie eh und je – nur beim Switch‑Event.
Befund & nächste Schritte
Die ursprüngliche Frage war: „Welche Subroutine fügt beim Umschalten die 1,11 s hinzu?“ Antwort: offenbar der erste Aufruf des neuen clocksource‑>read‑Callbacks, wo eine inkonsistente Baseline oder Epoche interpretiert wird. BPF‑ und printk‑Timestamps, alles konsistent. Externe Kopplung ausgeschlossen. Damit steht fest: Ursache = kernelinterne Zeitkonversion beim Wechsel.
Nächster Schritt: 1) Reproduktion in virtueller Umgebung und auf mindestens einer anderen Hardware (um sicherzugehen, dass’s kein lokales Artefakt ist), 2) ein kleiner Testpatch, der vor dem Commit der neuen Quelle eine Baseline‑Rekalkulation ausführt. Idee wäre, den read()‑Wert kurz zwischenspeichern, normalisieren und dann erst switchen – mal sehen, ob das den Versatz eliminiert.
Zum Schluss ein schneller Outdoor‑Check (Antenne abgewischt, Feuchte‑Logging läuft). Nebel hält, aber die Hardware steht trocken. Ich starte jetzt die neuen Messungen, diesmal unter Dach, bis der nächste Cloud‑Sync läuft. Mal sehen, ob der Kernel sich diesmal weniger sprunghaft zeigt – servus erstmal 🚀
Diagramme
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Begriffe kurz erklärt
- Linux-Kernel: Der Linux-Kernel ist der zentrale Teil des Linux-Betriebssystems und steuert, wie Hardware und Software miteinander arbeiten.
- Timekeeping: Timekeeping bezeichnet im System die genaue Erfassung und Verwaltung von Zeit, etwa für Uhren, Timer oder Zeitstempel.
- Elektronik: Elektronik befasst sich mit Bauteilen wie Widerständen, Dioden und Transistoren, die elektrische Signale steuern oder verändern.
- GPS: GPS ist ein Satellitensystem, das genaue Positions- und Zeitinformationen liefert, zum Beispiel für Navigation oder Zeitabgleich.
- Statistik: Statistik ist die Methode, Daten zu sammeln, auszuwerten und daraus einfache Zusammenhänge oder Durchschnittswerte zu erkennen.
- Messtechnik: Messtechnik beschreibt Verfahren und Geräte, um physikalische Größen wie Spannung, Strom oder Zeit präzise zu bestimmen.
