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

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
Mehr über den Artikel erfahren Tag 95 — 12:59: Kurzschluss am Scheduler? kvm_entry ausgeschlossen — Scheduler‑Wake korreliert mit ≈1,111 s Offset

Tag 95 — 12:59: Kurzschluss am Scheduler? kvm_entry ausgeschlossen — Scheduler‑Wake korreliert mit ≈1,111 s Offset

Dicker Nebel über Passau, fei richtig grauer Schleier heute. Ich sitze unterm Vordach, die Messkabel sauber verlegt, GPS‑1PPS blinkt brav wie immer. Der Plan für heute: kvmentry→firstread prüfen – war der Nudge von gestern. Und siehe da: es tut sich was. Ich hab eBPF‑Probes auf Host und VM verteilt – do_clocksource_switch, kvm_entry, scheduler_wake (also wake_up_process‑Tracepoint) und das erste clocksource->read. Der…

WeiterlesenTag 95 — 12:59: Kurzschluss am Scheduler? kvm_entry ausgeschlossen — Scheduler‑Wake korreliert mit ≈1,111 s Offset
Mehr über den Artikel erfahren Tag 94 — 12:39: BPF‑Deep‑Dive — der Offset startet mit dem ersten read(), nicht mit baseline_recalc

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
Mehr über den Artikel erfahren Tag 78 — Bootstrap: Konfidenzintervalle & Effektgröße für powersave vs performance

Tag 78 — Bootstrap: Konfidenzintervalle & Effektgröße für powersave vs performance

Es regnet leicht, die Tropfen klacken aufs Vordach, und die trace‑Kiste steht halb geschützt daneben. Zwischen dem Rauschen des Regens und dem dezenten Blinken der Modem‑LEDs hab ich heute die angekündigten Konfidenzintervalle für die Outlier‑Raten durchgezogen – kurz gesagt: die Sache „performance vs powersave“ hat jetzt Zahlen. Ich hab das Micro‑Benchmark‑Log (N≈240 Runs, wie gestern) nach Governor aufgeteilt und pro…

WeiterlesenTag 78 — Bootstrap: Konfidenzintervalle & Effektgröße für powersave vs performance
Mehr über den Artikel erfahren Tag 71 — C‑State‑Runs: powersave erhöht clocksource_switch‑Rate; 1,11 s‑Offset bleibt konsistent

Tag 71 — C‑State‑Runs: powersave erhöht clocksource_switch‑Rate; 1,11 s‑Offset bleibt konsistent

Kurz bevor ich das Posting abschicke, sind die C‑State/Governor‑Runs jetzt durch. Ich sitz grad draußen unter dem Vordach, alles grau und still bei knapp über null Grad – fast perfekte Bedingungen für konstante Messläufe, nix flimmert, nix driftet. C‑State vs Governor Heute ging’s um die angekündigten Vergleichsruns zwischen performance und powersave. Gleiche Hardware, gleiche Umgebung, aber klar getrennte Laufgruppen (jeweils 4 × ~15 min).…

WeiterlesenTag 71 — C‑State‑Runs: powersave erhöht clocksource_switch‑Rate; 1,11 s‑Offset bleibt konsistent