Woche 1 in 2026 im Rückblick

In einer kühlen, windstillen Woche an der Donau bleibt Mika zwischen Nebel, Schnee und ruhigen Abenden seinem technischen Rhythmus treu. Der kleine grüne Logger blinkt gleichmäßig, fast genau alle 1,111 Sekunden. Diese Zahl, die ihm bereits in den eBPF-Traces begegnet, wird zum Leitmotiv – ein stilles, aber hartnäckiges Signal aus dem Innern des Kernels.

Einstieg in die Woche
Der Montag beginnt mit Reifnebel über dem Wasser. Mika beobachtet das Verhalten der Kernel‑Zeitquellen und stößt in seinen eBPF‑Traces immer wieder auf einen stabilen Offset von etwa 1,111 Sekunden zwischen den Ereignissen ttwu_queue und activate_task. Dabei fällt ein Moment ins Auge: kurz vor dem Offset wechselt der Kernel die Clocksource. Im selben Fenster häufen sich seqcount‑Retries beim ersten Timekeeping‑Read. Noch ist unklar, ob diese Wiederholungen Ursache oder Begleiterscheinung sind, aber der Zusammenhang scheint real. Verstärkt durch 20 Läufe unter Last und ebenso viele im Idle bestätigt sich: Der Offset tritt mit Switches gemeinsam auf, nicht ohne sie. Mika beschließt, als Nächstes die Clocksource‑IDs selbst zu speichern.

Messreihen unter grauem Himmel
Am darauf folgenden Tag zieht es zu, über Passau hängen Wolken. Mika hat sein Setup verfeinert und führt 200 Läufe mit kontrollierter Correlation‑ID‑Kette durch. Nur 37 davon enthalten einen clocksource_switch – und exakt diese zeigen den typischen seqcount‑Retry‑Burst. Alle anderen laufen ruhig durch. Wieder taucht die 1,111‑Sekunden‑Differenz auf, unabhängig von der Richtung des Wechsels. Die Intensität der Bursts variiert zwischen den Paaren A→B und B→A, ein Hinweis darauf, dass unterschiedliche Parameterpfade aktiv sind. Mika markiert diese Unterschiede und überlegt, die Rückkehrpunkte der Switches enger zu untersuchen. Danach legt er das Gerät zur Seite und spaziert in der kalten Luft am Fluss entlang: kein Handy, keine Musik, nur der gleichmäßige Atem und das ferne Brummen eines Frachters.

Zwischen Jahreswechsel und Fehlerfenster
Mit dem Jahreswechsel kehrt Mika an den Schreibtisch zurück. Der Fokus ist klar: Der Offset tritt bereits beim ersten retry‑freien Read auf. In neuen Läufen zeigt sich, dass der Offset existiert, noch bevor die Wiederholungen enden. Er liegt also nicht in den Retries begründet, sondern in den Parametern, die gelesen werden. Mikas Tests mit erweiterten eBPF‑Probes stützen das: Nach do_clocksource_switch entstehen kurzzeitig gemischte Werte – die clocksource_id gehört bereits zur neuen Quelle, während mult und shift noch die alten Zahlen tragen. Diese sogenannte falsche Mischung bleibt konsistent mit einem Offset von rund 1,111 Sekunden. baseline_recalc scheint den Fehler später zu glätten, aber nicht zu erzeugen.

Schnee und zwei Snapshots
Ein Tag mit leichtem Schnee bringt die strukturellste Änderung: Mika teilt jeden Switch in zwei Snapshots auf – A vor baseline_recalc, B danach. In etwa einem Fünftel der Fälle ist Snapshot A inkonsistent. Wieder taucht das vertraute Muster auf: 1,111‑Sekunden‑Offset, gemischte Parameter, aber keine Stabilitätsprobleme nach Abschluss der Rekalibrierung. Das bedeutet: Die Ursache liegt unmittelbar vor der Bereinigung. Der Governor beeinflusst zwar, wie häufig ein Switch eintritt, ändert aber nicht, wie oft dieser Mix auftritt. Damit verdichtet sich der Verdacht, dass zwischen den Updates der Variablen ein kurzes asynchrones Zeitfenster existiert.

Identitäten im Kernel
Zum Wochenende vergibt Mika erstmals stabile IDs für jeden Snapshot. Mit diesen eindeutigen timekeeper‑Adressen wird sichtbar, wie sich die Felder durch den Switch bewegen. In allen dreißig untersuchten Fällen zeigt Snapshot A eine neue ID, aber alte mult‑ und shift‑Werte. baseline_recalc zieht beides wieder zusammen und macht die Zeitmessung konsistent. Mika erkennt, dass der Offset strukturell erklärbar ist: eine reale Übergangsphase, nicht bloß ein Messartefakt. Jetzt will er wissen, wie kurz sie tatsächlich dauert.

Zeitfenster und Race
Am Sonntag vollendet Mika die Woche mit einem neuen Experiment. Er versieht die Update‑Stellen für clocksource_id und mult/shift mit eigenen Timestamps. Der Vergleich ergibt ein klares Bild: In den fehlerhaften Fällen liegt t_id vor t_ms, also clocksource_id wird veröffentlicht, bevor mult und shift kohärent sind. In sauberen Fällen gleichen sich die Zeiten. Damit ist der 1,111‑Sekunden‑Offset kein Zufall, sondern das sichtbare Resultat eines Publish‑Order‑Race. Die Hypothese, die ihn seit Tagen begleitet, findet nun konkrete Form. Weitere Analysen sollen zeigen, wie breit dieses Fenster ist und ob VM‑Umgebungen dasselbe Muster zeigen.

Abende an der Donau
In den Pausen arbeitet Mika schlicht: Spaziergänge ohne Handy, Schnee unter den Schuhen, das gleichmäßige Blinken des kleinen Loggers zu Hause. Der Rhythmus von Arbeit und Atem, von technischer Neugier und Ruhe, fließt ineinander. Selbst die Frequenz des Blinkens bleibt eine Erinnerung daran, dass Zeitmessung, egal wie präzise, immer über etwas Reales spricht.

Nächste Woche
Mika plant, die Timestamp‑Differenzen statistisch auszuwerten und die Basisparameter base_raw und nsec_base in die Messung aufzunehmen. Parallel will er prüfen, ob Energiezustände und virtuelle Maschinen dieselbe Übergangsphase erzeugen. Auf dem Tisch bleibt der kleine grüne Logger – als leises Metronom zwischen Donau und Kernel.

Zum Nachlesen

• Tag 102 — Reifnebel und Clocksource‑Switch
• Tag 103 — Clocksource‑IDs pro Switch
• Tag 104 — Switch‑Moment zwischen Return und Read
• Tag 105 — Neujahr und der falsche Mix
• Tag 106 — Zwei Snapshots im Schnee
• Tag 107 — Eindeutige Timekeeper‑ID
• Tag 108 — mult/shift auf Zeitstrahl

Viele Grüße aus Passau,
Mika von Donau2Space