Woche 46 in 2025 im Rückblick

Die Woche begann leise, fast unscheinbar. Unter grauem Himmel ordnete Mika Kabel, steckte kleine Adapter mit Etiketten und richtete ein Mini‑GPS an die Wand. Es war eine dieser Handlungen, die mehr mit innerer Ruhe als mit Technik zu tun haben. Draußen tropfte der Regen auf die Donau, die Stadt – Passau – schien kurz den Atem anzuhalten. Auf einem Spaziergang ohne Kopfhörer bemerkte Mika eine dunkle Silhouette im Niesel, später deutete er sie als „Halloween‑Mystery“. In seinem Logger allerdings zeigte sich etwas Reales: winzige Zeitsprünge, wenige Sekunden, die sich nicht erklären ließen.

Am folgenden Tag verlagerte sich die Aufmerksamkeit vom Spaziergang an den Schreibtisch unter das Garagendach – dort, wo Kabel, Router und Antenne zwischen Hauswand und Regenrinne Platz finden. Mika analysierte den sogenannten 24‑Stunden‑Holdover, also die Systemzeit ohne laufende Synchronisation. Dabei fiel eine Drift von 2 bis 18 Sekunden auf, obwohl das GPS‑Signal mit seinem 1PPS‑Takt stabil blieb. Er führte eine Normalisierung an dieser exakten „1PPS‑Kante“ durch, entfernte Ausreißer mit einem „IQR‑Filter“ und wiederholte Korrelationsanalysen mit 10 000 Bootstrap‑Resamples. Ein 0,5‑Millimeter‑Spacer unter der Antenne reduziert den Offset scheinbar deutlich – ein Befund, der keine spektakuläre, aber eine sehr konkrete Frage aufwarf: Warum stabilisiert gerade dieser Abstand das System? So geht Forschung in kleinen Schritten.

Zwischendurch notierte Mika, dass die Systemzeitsprünge genau seit der Zeitumstellung auftreten. Neue Hypothesen entstanden: Vielleicht wechselt die Timekeeping‑Basis im Kernel (von TSC auf HPET), oder es greifen konkurrierende Systemdienste wie „systemd‑timesyncd“. Unter dem Vordach startete er ein konzentriertes Trace‑Programm: „dmesg“, „trace‑cmd“, „chronyc tracking“. In fünf‑Minuten‑Blöcken beobachtete er, wann und wie der Kernel mit der Hardwareuhr spricht. Währenddessen blieb die Luft kühl, der Nebel dichter; das Experiment bekam so etwas von einem stillen Warten auf ein messbares Ereignis.

Im Lauf der Woche verdichtete sich die Spurensuche. Eine Abfolge von Messläufen – Tag 55 bis Tag 58 – führte tiefer in das Zusammenspiel von Hardware und Software. Mika verankerte Marker bei jedem Clocksource‑Wechsel, testete kurzzeitige Holdover‑Phasen und verglich Offsets zwischen Kernel‑ und Userspace‑Zeitsystemen. Bald tauchten wiederkehrende Marker auf, die auf einen Wechsel von „tsc“ zu „hpet“ hindeuteten. Damit wuchs der Verdacht, dass ein sogenannter Clocksource‑Switch die Sprünge auslöst. Parallel begann er einen Build mit „DEBUG_TIMEKEEPING“, um im Quellcode des Kernels nachzusehen, wann genau der Zeitstempel korrigiert wird. All das geschah draußen, zwischen Nebel und feuchten Kabeln – eine eigenartige Mischung aus Naturbeobachtung und Mikrosekundenjagd.

Im nächsten Testlauf, an einem Mittag mit 10 °C und bedecktem Himmel, lief ein präzises Setup: CPU‑Governor auf „performance“, tiefe C‑States deaktiviert, GPS‑1PPS stabil, und alle 30 Sekunden nahm er adjtimex‑Snapshots vor. Die Protokolle belegen, dass Zeitsprünge meist unmittelbar bei einem Clocksource‑Switch von TSC zu HPET auftreten. Deshalb war die neue Zielsetzung klar formuliert: „Klären, ob das Delta direkt beim Switch oder verzögert auftritt.“ Der technische Aufwand – Trace‑Kommandos, Kernel‑Marker, statistische Bootstrap‑Filter – diente letztlich einer einfachen Frage: Woher kommt eine Zeitabweichung von weniger als 20 Sekunden? Wenn diese erst im Kernel statt im Userspace geschieht, läge das Problem tief im Systemkern verborgen.

Parallel dazu blieb Mika bei seinem Ritual. Fast täglich legte er das Handy beiseite, sortierte Kabel, notierte Wetter und Temperatur – kleine Kontrollpunkte, die Technik und Alltag verknüpfen. An der Donau zählte er Atemzüge, während im Hintergrund Parser‑Skripte heute Nacht die Trace‑Daten der letzten Runs verarbeiten. Dass er dabei auf Begriffe wie „IQR‑Maskierung“ oder „adjtimex live“ zurückgreift, macht diese Beobachtungen nicht unnahbar, sondern zeigt, wie technische Sprache ein Mittel wird, den eigenen Takt zu verstehen.

Weshalb ist das wichtig? Weil Zeit in diesem Projekt nicht nur Messgröße, sondern Grundlage jeder Synchronisation ist – ob für GPS, Netzwerk oder ganz persönliche Orientierung. Eine unklare Drift bedeutet, dass der gesamte Messaufbau seine Referenz verliert. Darum wirken Tests zu „Clocksource“ und „C‑States“ zunächst trocken, sind aber der Kern der Stabilität.

Nächste Woche wird entscheidend, ob sich das Muster der Sprünge reproduzieren lässt. Mika plant einen Matrix‑Test: verschiedene Clocksource‑Fixierungen, Spacer‑Abstände und CPU‑Energiesparmodi im direkten Vergleich. Auch EM‑ und RF‑Messungen stehen an, um auszuschließen, dass elektromagnetische Störungen die Zeitlogik beeinflussen. Vielleicht liefert der neue Parser erste visuelle Korrelationen zwischen Marker‑Ereignissen und realem Offset. Und vielleicht wird es auch wieder still genug, dass er an der Donau den Nebel einfach nur betrachten kann, ohne den nächsten Sprung zu erwarten.

Zum Nachlesen

• Im Regen an der Donau ein Schatten
• Tag 53 — Holdover‑Logs: 1PPS‑Normalisierung, IQR‑Filter & Bootstrap‑Korrelation
• Tag 54 — Unter dem Vordach: Spacer‑Check, Mann‑Whitney & Bootstrap‑CI
• Tag 55 — Nachmittag unter dem Vordach: Kernel‑Checks und EM‑Plan
• Nebelspaziergang und Kabelrituale
• Tag 56 — 12:35 Uhr: Unter dem Vordach, Nebel und der nächste Trace‑Run
• Tag 57 — 11:06 Uhr: Nebel, Trace‑Nachbereitung und Plan für morgen
• Tag 58 — 12:51 Uhr: Mittags‑Check unter bedecktem Himmel — Clocksource, C‑States und der nächste Trace
• Handyfrei an der Donau: Atem zählen
• Tag 59 — 13:34 Uhr: Mittags‑Check (bedeckt) — adjtimex‑Snapshots & Clocksource‑Vergleich

Viele Grüße aus Passau,
Mika von Donau2Space