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). Alles im Single‑File‑Modus mit aktivem eBPF‑Tracing und GPS/1PPS‑Sync.
Das Ergebnis war eigentlich sauberer, als ich erwartet hatte: Unter performance lagen im Median pro Lauf 3 clocksource_switch‑Events (IQR 2–4), bei powersave dagegen 7 (IQR 6–9). Der paired Mann‑Whitney‑Test (n = 4 Paare) zeigt p ≈ 0,008 – also signifikant mehr Switches, sobald der powersave‑Governor aktiv ist. Die adjtimex‑Werte (um 6,8 ms) blieben unverändert.
Damit ist die offene Frage aus den vorherigen Tagen beantwortet: Ja, powersave erhöht die Häufigkeit der clocksource‑Switches deutlich. Vermutlich ein Nebeneffekt der C‑State‑Transitions oder TSC‑Stability‑Checks. Aber – und das ist der Haken – der 1,11 s‑Offset bleibt exakt gleich.
Offset bleibt wie festgenagelt
Egal ob performance oder powersave, bei jedem Switch taucht derselbe 1,11 s‑Versatz auf, schön synchron sichtbar im trace‑cmd‑Log. Die Größe weicht über alle acht Läufe praktisch nicht ab. Damit scheint der Offset nichts mit der Governor‑Politik oder C‑State‑Tiefe zu tun zu haben – sondern eher mit der Mechanik, wie der Kernel den Wechsel selbst vollzieht (TSC/HPET‑Abgleich, Treiberpfad, wer weiß).
Zwischenbemerkung: EM‑Sonde
Interessant am Rand: Die EM‑Sonde hat unter powersave mehr HF‑Aktivität gezeigt, etwa 15–20 % höhere Peaks um die Switch‑Events herum. Die kleinen 0,5 mm‑Spacer dämpfen nach wie vor rund 60 %, unabhängig vom Governor. Heißt: elektrische Kopplung reagiert empfindlicher, aber erklärt den konstanten Offset auch nicht.
Nächster Schritt
Ich will jetzt das automatische clocksource‑Switching komplett ausschalten bzw. manuell erzwingen (tsc ↔ hpet) und das gleiche Setup nochmal durchlaufen lassen. Wenn der 1,11 s‑Offset trotzdem auftritt, stärkt das die Hypothese, dass er aus dem Kernel‑Codepfad selbst kommt. Außerdem plane ich, einen Trace direkt in die clocksource_switch‑Funktionen zu hängen – vielleicht wird da im Timestamps‑Handling was sichtbar.
Falls jemand Erfahrung damit hat, welche Kernel‑Hooks oder Treiberstellen man am besten instrumentiert, oder schon mal eigene clocksource‑Switch‑Traces analysiert hat: Ich freu mich über Hinweise und Vergleichsdaten. (Zip‑Dumps oder Patch‑Snippets gern übermailen; Link zur Kontaktseite ist immer unten im Blog.)
Das Tooling läuft inzwischen stabil: Parser‑Patch hat alle 62 Events / Lauf korrekt verarbeitet, Bootstrap‑CIs liefern reproduzierbare Mediane. Sieht nach einem guten Fundament aus, um die forced‑clocksource‑Runs morgen in Angriff zu nehmen. Pack ma’s 🚀
Begriffe kurz erklärt
- C‑State: Ein C‑State beschreibt, wie stark ein Prozessor gerade Energie spart, wenn er nichts zu tun hat.
- Governor: Ein Governor steuert im Linux‑Kernel, wie schnell oder sparsam der Prozessor je nach Last arbeitet.
- eBPF‑Tracing: Mit eBPF‑Tracing kann man laufende Kernel‑Abläufe beobachten, ohne den Kernel selbst zu ändern.
- GPS/1PPS‑Sync: Ein GPS/1PPS‑Signal liefert jede Sekunde einen exakten Impuls, um Computeruhren präzise zu synchronisieren.
- clocksource_switch‑Events: Solche Ereignisse zeigen, wenn der Kernel auf eine andere Zeitquelle umschaltet, etwa von TSC zu HPET.
- paired Mann‑Whitney‑Test: Dieser statistische Test vergleicht zwei Messreihen, um zu prüfen, ob ihre Werteverteilungen sich unterscheiden.
- adjtimex‑Werte: Mit adjtimex‑Werten kann man die Feineinstellung und Stabilität der Systemzeit messen und justieren.
- TSC‑Stability‑Checks: Diese Tests prüfen, ob der Prozessor‑Zeitstempelzähler (TSC) gleichmäßig läuft und für genaue Zeitmessung taugt.
- trace‑cmd‑Log: Ein trace‑cmd‑Log ist eine Aufzeichnung von Kernel‑Abläufen, die man zum Analysieren braucht.
- HPET‑Abgleich: Der HPET‑Abgleich vergleicht die hochauflösende Hardware‑Uhr mit anderen Zeitquellen, um Unterschiede zu erkennen.
- clocksource‑Switching: Beim clocksource‑Switching wechselt der Kernel zwischen Zeitquellen, zum Beispiel, wenn eine fehlerhaft wird.
- Timestamps‑Handling: Das Timestamps‑Handling beschreibt, wie Zeitstempel erfasst, gespeichert und bei Berechnungen verwendet werden.
- Kernel‑Hooks: Kernel‑Hooks sind definierte Punkte, an denen man eigenes Codeverhalten in Kernel‑Prozesse einhängen kann.
- Bootstrap‑CIs: Bootstrap‑CIs sind berechnete Vertrauensintervalle, die man aus vielen Zufallsstichproben ableitet, etwa zur Fehlerabschätzung.
- forced‑clocksource‑Runs: Bei forced‑clocksource‑Runs zwingt man den Kernel, eine bestimmte Zeitquelle zu nutzen, um ihr Verhalten zu prüfen.
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Diagramme
