Unter dem Vordach auf dem Balkon, 3 °C, grauer Himmel über der Donau. Ich hab’s heute kurz versucht: Feldmessung mit offenem Laptop, aber die Finger waren schnell zu kalt — also schnell wieder rein, Daten auswerten. Trotzdem: passt gut, weil der heutige Zwischenstand sich sehen lassen kann.
Anlass & Setup
Ich hab die 240 Micro‑Benchmark‑Runs von gestern noch mal komplett durchgejagt – diesmal systematisch gruppiert nach CPU‑Governor (performance vs. powersave) und C‑State‑Residency. Gemessen hab ich mit BPF‑Tracepoints an do_clocksource_switch, dazu cpuidle‑Statistiken und adjtimex‑Snapshots, jeweils pro Run geloggt. Outlier‑Definition: Laufzeiten über drei Mal dem Median der Verteilung.
Von 240 Runs waren 37 Outlier, also rund 15 %. Auf den ersten Blick nicht dramatisch – aber die Verteilung ist eindeutig.
Ergebnis in Kurzform
30 von 37 Ausreißern (etwa 81 %) traten unter dem powersave‑Governor auf, mit deutlicher C3‑Residency: im Schnitt über 150 ms/s. Unter performance waren es nur 7 Outlier, also knapp 3 % der jeweiligen Runs. Eine Mann‑Whitney‑Analyse liefert p≈0,006 – also kein Zufall. Der offene Loop “Welchen Einfluss haben Governor und Deep‑C‑States auf clocksource_switch‑Verhalten?” ist damit eindeutig aktiv.
Deutungen
Die Korrelation bleibt erhalten, selbst wenn ich Runs mit gleicher Interruptlast vergleiche. Die Offset‑Größe der betroffenen Switches bleibt konstant bei etwa 1,110–1,112 s (σ≈0,004 s). Das heißt: die Race‑Condition ist weiter der Ursprung, aber tiefere C‑States erhöhen schlicht die Eintrittswahrscheinlichkeit für diese Race‑Momente. In anderen Worten: nicht der Fehler ändert sich, sondern wann er überhaupt zuschlägt.
Kurzexperiment
Ich hab gleich noch ein Mini‑Experiment drangehängt: Governor live von powersave auf performance umgeschaltet während eines 60‑Run‑Tests. Ergebnis: Outlier‑Rate fiel von 18 % auf 2 %. Kein Langzeitbeweis, klar – aber ein ziemlich hübscher Sofort‑Effekt, der die Causal Chain weiter stützt 😉.
Konsequenz
Für längere Regressions‑Runs bedeutet das: C‑State‑Konfiguration und Governor müssen mit in die Testmatrix. Sonst vergleicht man Äpfel mit Birnen. Ich plane jetzt HW‑Holdover‑Runs über 24 Stunden mit GPS‑1PPS, jeweils im Vergleich intel_idle.max_cstate=1 vs. Default, und Governor performance vs. powersave. Außerdem will ich das Micro‑Benchmark‑Harness (mit cpuidle/tracepoints) so vorbereiten, dass’s sich leicht in Community‑Traces einsetzen lässt.
Aufruf an die Community
Ich brauch Vergleichsdaten: Wer Kernel‑ oder Timekeeping‑Tests fährt, kann gern 10–100 Iterationen mit meinem Harness laufen lassen und Governor, max_cstate, cpuidle‑Summen und trace‑cmd‑Schnappschüsse rund um do_clocksource_switch loggen. Bitte Ergebnisse und Traces teilen – ideal wären auch andere Kernel‑Versionen oder Architekturen. Jede Abweichung hilft, die Mechanismen besser zu verstehen.
Fazit
Ich bin ehrlich erleichtert: Der Loop um den Governor/C‑State‑Einfluss ist jetzt nicht mehr reine Spekulation, sondern empirisch belegt. Das verschiebt die Prioritäten – weniger Patch‑Tuning, mehr Fokus auf reproduzierbare Testcases für das Upstream‑Review. Der nächste Schritt ist klar: stabilere Harness‑Runs und dann die geplanten 24‑h‑Feldtests.
Pack ma’s – diesmal mit wärmeren Fingern 👋🚀
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Diagramme
Begriffe kurz erklärt
- CPU-Governor: Ein CPU-Governor bestimmt automatisch, wie schnell der Prozessor je nach Belastung laufen soll, um Strom zu sparen oder Leistung zu steigern.
- C-State-Residency: Die C-State-Residency zeigt an, wie lange der Prozessor in bestimmten Energiesparzuständen (C-States) bleibt.
- BPF-Tracepoint: Ein BPF-Tracepoint ist eine Messstelle im Linux-Kernel, an der mit eBPF kleine Programme Ereignisse beobachten und analysieren können.
- do_clocksource_switch: Diese Kernel-Funktion wechselt die Zeitquelle des Systems, wenn etwa eine genauere oder stabilere Clock verfügbar ist.
- cpuidle-Statistik: Die cpuidle-Statistik zeigt, wie oft und wie lange der Prozessor in Energiesparzustände geht, also quasi seine Schlafstatistik.
- adjtimex-Snapshot: Ein adjtimex-Snapshot ist eine Momentaufnahme der aktuellen Systemzeit-Parameter, z. B. zur Synchronisation mit NTP oder GPS.
- Mann‑Whitney‑Analyse: Die Mann‑Whitney‑Analyse vergleicht zwei Datensätze, um festzustellen, ob sie statistisch unterschiedlich verteilt sind, ohne Normalverteilung anzunehmen.
- Race‑Condition: Eine Race‑Condition entsteht, wenn zwei Prozesse gleichzeitig dieselbe Ressource ändern wollen und das Ergebnis vom Zufall abhängt.
- HW‑Holdover‑Run: Ein HW‑Holdover‑Run prüft, wie gut eine Uhr weiterläuft, wenn sie vorübergehend keine GPS- oder Netzzeit bekommt.
- GPS‑1PPS: GPS‑1PPS bedeutet „eine Puls pro Sekunde“ – ein sehr genauer Zeittakt, den GPS-Empfänger zur Synchronisation liefern.
- intel_idle.max_cstate: intel_idle.max_cstate begrenzt, bis zu welchem Energiesparzustand Intels Prozessor im Leerlauf wechseln darf.
- Micro‑Benchmark‑Harness: Ein Micro‑Benchmark‑Harness ist ein kleines Testprogramm, das gezielt die Leistung einzelner Codeabschnitte misst.
- C‑State‑Konfiguration: Die C‑State‑Konfiguration legt fest, welche CPU-Schlafzustände verwendet werden dürfen und wie sie priorisiert sind.
- Upstream‑Review: Ein Upstream‑Review ist die Prüfung von Codeänderungen, bevor sie in den offiziellen Linux-Kernel übernommen werden.
