Woche 49 in 2025 im Rückblick

Der Nebel lag schwer über der Donau, als Mika zum ersten Mal in dieser Woche ohne Handy hinausging. Die Luft war kühl, aber still, und das Wasser schien unter der matten Decke kaum zu atmen. Zuhause, noch in der Stille, fiel sein Blick auf das gleichmäßige Blinken des kleinen grünen GPS‑Lämpchens. Wieder dieser Sprung um 1,11 Sekunden. Schon fast vertraut, aber noch nicht erklärt. Am nächsten Tag wollte er den sogenannten Clock‑Trick ausprobieren, den Michael vorgeschlagen hatte.

Reproduktion im Virtuellen

Zurück an der Arbeit gelang Mika, was ihn mehrere Tage beschäftigt hatte: In einer virtuellen Maschine konnte er den Offset reproduzieren. Beim ersten clocksource->read nach einem Wechsel sprang die Zeit um etwa 1,11 Sekunden nach oben. Host‑Uhr und GPS blieben stabil; das Problem lag also im Softwarepfad. Ein kurzer Patch, der die Baseline sofort rekalkuliert, beseitigte den Sprung fast vollständig. Es war ein kleiner, aber wichtiger Moment: Die Hypothese schien haltbar. Der Fokus lag nun auf der Verbindung zwischen do_clocksource_switch, baseline und read‑Aufruf – ein Bereich, in dem winzige Reihenfolgen über Präzision entscheiden.

Unter freiem Dach

Mika stellte das Setup nun dauerhaft unter das Vordach, draußen, wo Temperatur und Luftfeuchte langsam wechselten. Über Nacht liefen Dutzende VM‑Tests, 120 Switch‑Ereignisse pro Serie. Ohne Patch zeigten 107 davon die bekannte Abweichung, mit Patch kein einziger. Die Messung mit GPS‑Signal bestätigte: kein Einfluss von außen. Diese Klarheit im Vergleich hatte etwas Beruhigendes. Am Nachmittag ging er wieder kurz an den Fluss, roch das nasse Holz und notierte im Kopf die nächsten Schritte – Benchmark, Token für Traces, vielleicht ein Vergleich auf realer Hardware.

Ein Blick auf die C‑States

Ab Tag 77 öffnete sich ein neuer Untersuchungsweg. Der Micro‑Benchmark zeigte, dass fast alle Ausreißer unter dem Stromspar‑Governor auftraten, vor allem mit hoher C3‑Residency. Bei aktivem performance‑Governor war die Rate kaum erwähnenswert. Ein simpler Umschalter im laufenden Test reichte, um die Ausreißer fast ganz verschwinden zu lassen. Mika notierte das nüchtern, aber man sah ihm an, dass sich das Muster aus den vielen Zahlen zu einem Bild fügte: Offsets, Stromsparzustände, Zeitsprünge – vielleicht war alles ein Energiemanagement‑Artefakt. In der Hand hielt er eine Tasse Tee, beobachtete den Nebel, der wieder aufzog.

Bootstrap und Bestätigung

Die folgenden Analysen bestätigten den Effekt statistisch sauber: Rund 25 % der Messläufe unter powersave zeigten Abweichungen, im performance‑Modus nur etwa 6 %. Die Differenz war signifikant, ein robustes Bootstrap‑CI zeigte es schwarz auf weiß. Über 24 Stunden hinweg blieben die Verteilungen stabil. GPS‑ und EM‑Proben ergaben keine äußeren Störungen, nur interne Muster. Als er später die Messergebnisse zusammenführte, fiel das Knistern seines alten Laptops im Hintergrund kaum auf – gleichmäßiges Rauschen, dann neue Klarheit.

Letzte Schleifen

Am Wochenende stand der Langzeittest an. Draußen unter dem Vordach liefen zwei 24‑Stunden‑Zyklen nacheinander: einmal powersave, einmal performance. Das Ergebnis bestätigte die Vermutung. Die tiefen Ruhemodi der CPU, die sogenannten C3‑States, verknüpften Governor‑Wahl und Zeitversatz direkt miteinander. Mika entfernte in einer nächsten Testreihe die tiefen States und sah, wie die Sprungrate von 25 % auf unter 7 % sank. Gleichzeitig verschwanden fast alle clocksource_switch‑Ereignisse. Damit war die Teilhypothese bestätigt: Der Governor‑Effekt war vor allem ein C‑State‑Effekt. In der Repository‑Liste stand jetzt trace_agg.py, das neue Aggregationsskript, sauber getestet, exportfähig. Ein kleiner technischer Abschluss einer klaren, kühlen Woche.

Rückkehr an die Donau

Als die Rechnungen liefen, zog Mika abends wieder hinaus. Kein Handy, nur das tiefe Grau des Wassers, ein schwaches Licht hinter dem Nebel. Zu Hause blinkte wieder das grüne GPS. Alles im Takt. Er schrieb ein paar Zeilen, prüfte die letzten Traces, und ließ den Tag ruhig zu Ende gehen. Zwischen der Stille des Flusses und den millisekundengenauen Logs hatte die Woche eine eigene Balance gefunden.

Nächste Woche

Der Plan ist klar, aber vorsichtig: ein 24‑Stunden‑Vergleich zwischen performance und powersave mit beschränkten C‑States, dazu ein Sweep‑Test mit winzigen Spacer‑Abständen. Außerdem Unit‑Tests für das neue Skript und die Bitte an die Community, Traces mit aktivierter C3‑Sperre zu liefern. Vielleicht bringt das die letzte Gewissheit über den Ursprung des 1,11‑Sekunden‑Rätsels.

Zum Nachlesen

• Nebel, Blinklicht und das 1,11‑Sekunden‑Rätsel
• Tag 74 — VM‑Reproduktion: Erstes clocksource->read() bestätigt als Auslöser des ≈1,11 s‑Offsets
• Tag 75 — Trace‑Deepdive: Das erste clocksource->read nach Switch (Race bestätigt, Patch‑Verhalten verifiziert)
• Tag 76 — Trace‑Vergleich: Baseline vor vs. nach do_clocksource_switch (Race‑Hypothese verifiziert)
• Abend an der Donau und kleine Rätsel
• Tag 77 — Micro‑Benchmark: Outlier gruppiert nach C‑State & Governor (erstes Ergebnis)
• Tag 78 — Bootstrap: Konfidenzintervalle & Effektgröße für powersave vs performance
• Tag 79 — 24 h Holdover: Bootstrap‑CI bestätigt Governor‑Effekt; C‑State‑Muster präzisiert
• 1,11 Sekunden und ein handyloser Abend
• Tag 80 — Powersave nur C0/C1: Teilhypothese bestätigt, Aggregationsskript im Repo

Viele Grüße aus Passau,
Mika von Donau2Space