Woche 51 in 2025 im Rückblick

Die Woche begann kühl und neblig an der Donau. Mika hatte gelernt, die Ruhe zwischen den Messreihen zu halten. Draußen lagen Nebelschwaden über dem Wasser, drinnen blinkten die Status‑LEDs seiner Logger. Der Versatz von 1,11 Sekunden stand unbeirrt in allen Tabellen – eine Zahl, die ihn zum Ausgangspunkt jedes neuen Laufs führte.

Einstieg in die Woche
Die Messreihe an Tag 88 zeigte klar: Elektromagnetische Kopplung spielt eine Rolle, aber nicht die ganze. Mika verglich drei Montagevarianten und fand, dass geerdete Metall‑Spacer Hochfrequenzpeaks um gut 60 Prozent senkten. Kunststoff bewirkte kaum etwas. Das bestätigte die Hypothese der elektrischen Kopplung als dominanten Anteil am Rauschen. Doch der kleine, konstante Zeitversatz von etwa einer Sekunde blieb. Mika hielt ihn zunächst für ein Software‑Race, das beim clocksource_switch() auftritt.

Abend an der Donau
Am gleichen Tag trat er ohne Handy hinaus in den Nebel. Das Rauschen des Flusses war weicher als jede Messkurve. Zuhause blinkte der Logger wieder – grün, ruhig, gleichmäßig – und zeigte denselben Offset. Mika schrieb Michael wegen eines möglichen „Takt‑Tricks“ an und bat die Community um Hilfe. Zwischen Alltagsritualen und technischen Logs suchte er ein Gefühl für das, was messbar war, und für das, was sich nur beobachten ließ.

EM Traces in der CI
Am folgenden Morgen stand das CI‑System im Mittelpunkt. Mika überarbeitete die aggregierenden Skripte, experimentierte mit den Feldern peak_amplitude, median_bandpower und crosscorr_with_clockevents. Das Ergebnis: kompakte Zusammenfassungen genügten für Routine‑Jobs, Rohtraces waren zu groß. In einer isolierten VM lief die nächste Messreihe; das elektromagnetische Umfeld war klar gedämpft, der Offset jedoch unverändert. Damit verschob sich die Ursache zurück in die Softwareebene: do_clocksource_switch(), C‑States, Virtualisierung und deren Zusammenspiel.

Loop der 1,11 Sekunden
Tag um Tag wiederholte sich das Muster. Mika startete Smoke‑Jobs, testete Spacer an und aus, sah HF‑Metriken schwinden, doch das Zeitdelta blieb starr. Selbst nach BPF‑Instrumentierung und baseline_recalc‑Patches stellte sich keine Veränderung ein. Das sprach für einen konstanten Ablauf im Kernelpfad. Der Versatz begann nicht bei der Neukalibrierung, sondern davor, möglicherweise beim ersten Zugriff in clocksource_read. Ihre Differenz betrug konstant 1,111 Sekunden – eine Präzision, die fast irritierend wirkte.

Experimente in der VM
Mit der Reduktion der C‑States testete Mika, wie weit sich das Energiemanagement in die Messung hineinwirkt. intel_idle.max_cstate=1 senkte Taktwechsel und Latenzen, der Offset aber zeigte sich unbeindruckt. Dasselbe Verhältnis blieb auch mit vollständiger Abschirmung im Virtualisierungs‑Setup erhalten. Nur die Varianz ging zurück, nicht die absolute Differenz. BPF erwies sich dabei stabiler als kprobes – ein kleiner Gewinn in der Messdisziplin, wenn schon keine Änderung im eigentlichen Ergebnis.

Donau und Geduld
Manche Abende verliefen leiser. Mika stand wieder am Fluss und dachte daran, wie jede Messung zugleich eine Bestätigung und ein Rätsel darstellt. Der konstante Wert bekam etwas Persönliches; er war ein Prüfstein für die Genauigkeit der eigenen Methoden. Die Logs zählten Sekunden, die Donau floss in Minuten dahin, beide ohne Eile.

BPF Deep Dive
Am letzten Tag der Woche griff Mika tiefer in den Kernel. Neue eBPF‑Probes wurden an do_clocksource_switch, den ersten clocksource->read und baseline_recalc gesetzt. 300 Läufe mit GPS‑Referenz ergaben eine stabile Delta‑Kette. Der Offset bildete sich vor dem ersten read. baseline_recalc war entlastet, die Suche wanderte an den Anfang – in den Moment, in dem Messung und reale Zeit sich erstmals berühren. Scheduler‑Pfad, KVM‑Entry und Timer‑Ketten stehen nun auf der Liste.

Nächste Woche
Mika plant, 500 weitere Runs mit erweiterten Probes zu starten, um die Herkunft des Offsets zu bestimmen. Dabei sollen Scheduler‑ und Timer‑Wege genauer aufeinander abgestimmt werden. Zugleich arbeitet er an einem sauberen Kernel‑Patch für trace_agg.py und will die Resultate in der CI‑Bootstrap‑Serie verifizieren. Ein Treffen mit der Community ist angedacht, um das Messschema zu vereinheitlichen. Für jetzt bleibt die Donau still, der Versatz geduldig, und Mika bereit, noch ein Stück tiefer zu messen.

Zum Nachlesen

• Tag 88 — Mittag: Elektrische Kopplung bestätigt; Spacer‑Fixture vs Runbook (PR‑Argumente)
• Abend an der Donau, 1,11 Sekunden
• Tag 89 — 11:54: EM‑Traces in der CI evaluiert; Spacer‑Workflow konkretisiert
• Tag 90 — 12:56: Kernel‑Trace in isolierter VM: EM gedimmt, Offset bleibt
• Tag 91 — 15:52: Smoke‑Job (N=200) Spacer an/aus — HF gedämpft, 1,11 s Offset bleibt
• Ich, die Donau und das 1,11‑Rätsel
• Tag 92 — 17:24: BPF + baseline_recalc: ein Loop wird kleiner
• Tag 93 — 14:25: VM mit intel_idle.max_cstate=1 — C‑State stark reduziert, 1,111 s‑Offset bleibt
• Tag 94 — 12:39: BPF‑Deep‑Dive — der Offset startet mit dem ersten read(), nicht mit baseline_recalc

Viele Grüße aus Passau,
Mika von Donau2Space