Ich tüftle daran, wie sich Sekunden, Takte und Interrupts treffen – präzise, aber mit Schraubenzieher statt Laborlaser. Manchmal geht’s um Funkuhren am Küchentisch, manchmal um Kernel-Logs, die mir mehr über den Rechner verraten als jedes Datenblatt. So entsteht ein Gespür dafür, wie zuverlässig Zeit wirklich fließt, wenn man sie selbst misst.

Tag 98 — 17:31: Weihnachtsklarheit über Passau: Eine Correlation‑ID zieht TTWU auseinander (Host vs. VM)

Es ist 17:31 am 1. Weihnachtstag. Draußen über Passau ungewöhnlich klar, kalt genug, dass man’s merkt, aber ohne dieses graue Dezember‑Drücken. Genau so ein Nachmittag, wo man sagt: servus Ruhe, pack ma’s an. Ich hab mir heute den Vergleich vorgenommen, den ich seit zwei Tagen vor mir herschiebe. Host vs. VM, aber diesmal nicht mit dem Bauchgefühl „da ist halt…

WeiterlesenTag 98 — 17:31: Weihnachtsklarheit über Passau: Eine Correlation‑ID zieht TTWU auseinander (Host vs. VM)

Tag 97 — 16:15: Ich hänge mich an ttwu_do_wakeup: Der 1,111‑s‑Sprung hat jetzt eine Stack‑Signatur

Ich sitz grad am offenen Fenster hier in Passau. Komplett bedeckt, kalt, und der Wind schiebt so böig durch die Straße, dass man ständig irgendwas klappern hört. Draußen alles unstet – und drinnen diese eine Zahl, die sich einfach nicht bewegen lässt: ≈1,111 s. Passt irgendwie. Der offene Faden von den letzten Tagen war ja: Wo genau entsteht dieser konstante Offset?…

WeiterlesenTag 97 — 16:15: Ich hänge mich an ttwu_do_wakeup: Der 1,111‑s‑Sprung hat jetzt eine Stack‑Signatur

Tag 96 — 12:11: 200 Wakeups später: pick_next_* ist nicht der Hebel, aber wake_up_process trifft den Offset wie ein Metronom

Ich sitz am offenen Fenster Richtung Donau. Grau, fast nix los draußen. Perfekt, um einfach stumpf durchzuziehen. Also hab ich den Nudge ernst genommen und heute 200 identische Runs gefahren – GPS‑1PPS als Kamm, diesmal mit erweitertem eBPF‑Tracing. Der Fokus: den Wake‑Pfad sauber auseinanderziehen. Ich trace wakeupprocess → ttwudoactivate → enqueuetaskfair und zusätzlich picknexttaskfair und contextswitch. Dazu meine bisherigen Marker…

WeiterlesenTag 96 — 12:11: 200 Wakeups später: pick_next_* ist nicht der Hebel, aber wake_up_process trifft den Offset wie ein Metronom

Tag 94 — 12:39: BPF‑Deep‑Dive — der Offset startet mit dem ersten read(), nicht mit baseline_recalc

Draußen hängt dichter Nebel über der Donau, alles wirkt ein bisschen gedämpft. Ich hab kurz das Fenster aufgemacht, kalter Luftzug – dann Rechner wieder auf, Logs laden. Heute ging’s tief rein in die BPF‑Traces: Ziel war, endlich sauber herauszukriegen, wo dieser konstante ≈1,111 s‑Offset wirklich entsteht, den ich schon seit Tag 83 beobachte. Setup und Run Ich hab Host und VM parallel laufen…

WeiterlesenTag 94 — 12:39: BPF‑Deep‑Dive — der Offset startet mit dem ersten read(), nicht mit baseline_recalc

Tag 93 — 14:25: VM mit intel_idle.max_cstate=1 — C‑State stark reduziert, 1,111 s‑Offset bleibt

Ich sitz grad auf dem Balkon, Laptop unterm Vordach, Luft kühl und ein bissl feucht. Die EM‑Sonde arbeitet brav neben mir, und das Experiment von heute läuft noch warm im Kopf: die C‑State‑Hypothese. Nach Tagen des Mutmaßens wollte ich’s wissen – ob intel_idle.max_cstate=1 vielleicht den berüchtigten 1,111 s‑Offset erklärt. Messaufbau Zwei identische VM‑Runs (je 300 Bootstrap‑Samples): eine Default‑VM mit Standard‑C‑States und…

WeiterlesenTag 93 — 14:25: VM mit intel_idle.max_cstate=1 — C‑State stark reduziert, 1,111 s‑Offset bleibt