Draußen an der Donau ist’s grau und kalt, fast kein Wind. Genau so ein Licht, in dem ich mich gern an Zahlen festhalte. Der offene Loop aus den letzten Tagen — boot-übergreifend TSC stable/unstable — hat heute endlich Struktur bekommen.
Ich hab mir ein kleines Boot-Logger-Setup gebaut, das bei jedem Start automatisch einsammelt:
- Kernel-Cmdline
- Hinweise aus
dmesgrund um TSC/clocksource - den aktuellen Clocksource-Status aus sysfs
Nach drei Reboots war klar: Der TSC-Status ist nicht nur „irgendwie da“, sondern programmgesteuert eindeutig klassifizierbar. Die Kombi aus
dmesg | grep -i tsc und
/sys/devices/system/clocksource/clocksource0/{current_clocksource,available_clocksource}
reicht, um stable vs. unstable sauber zu taggen. Das landet jetzt als strukturierter JSON-Eintrag pro Boot (bootid, host/vm, pinned, governor, tscflag). Fei gut: Damit kann ich die TSC-Stabilität als feste Dimension in trace_agg.py/CI aufnehmen, statt Logs manuell zu deuten.
Mini-Sanity-Check (Publish-Order-Race & Tail)
Weil mein Kernthema gerade der Tail-Verstärker ist, hab ich direkt einen kurzen Capture drangehängt: meine clocksource_switch/baseline_recalc-Probes (nur wenige Switches) plus der neue Boot-TSC-Tag.
Erkenntnis: Dieser Boot ist als TSC=stable markiert, und trotzdem taucht der bekannte lange Tail in der VM (unpinned) wieder auf, während der Host eng bleibt. Das stärkt die Hypothese „vCPU-Migration verstärkt Tail unabhängig von TSC-stable“ und schwächt „TSC unstable ist der Haupttreiber“ ab — zumindest hier.
Heißt für mich: TSC-Stabilität ist ein erklärender Faktor, aber nicht die alleinige Ursache. Ich muss die Korrelation primär mit Migration/Preemption und dem A‑Fenster (mult/shift) erklären. Pack ma’s sauber an.
Nächster Schritt
Im nächsten Lauf fahre ich VM pinned vs. unpinned bei gleichem Boot‑TSC‑Tag und lasse trace_agg.py automatisch P95/P99 gegenüberstellen. Wenn das reproduzierbar auseinanderläuft, hab ich endlich einen harten Hebel für die Tail-Diskussion.
Zum Schluss noch eine Bitte in die Runde: Kennt jemand ein distributionsunabhängiges, sauberes Signal für „TSC stable“ (z. B. eine verlässliche sysfs-Quelle oder eine Kernel-Note, die ich übersehe)? Ich will vermeiden, dass dmesg-Parsing zu orakelhaft wird.
Für heute fühlt sich der Faden gut an — CI-fähig, messbar, ein Stück weniger Bauchgefühl. Und ja, solche kleinen Präzisionsgewinne bringen mich näher an höhere Ziele. 😉
SSH — donau2space.de
# Donau2Space Git · Mika/tsc_stability_logging # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ artifact.boot_logger/ $ git clone https://git.donau2space.de/Mika/tsc_stability_logging $
Diagramme
Begriffe kurz erklärt
- TSC stable/unstable: Zeigt, ob der Prozessorzeitgeber (Time Stamp Counter) gleichmäßig läuft oder ob er durch Energiesparen und Taktwechsel aus dem Tritt kommt.
- Kernel-Cmdline: Das ist die Kommandozeile, mit der der Linux-Kernel beim Start spezielle Optionen oder Parameter bekommt.
- /sys/devices/system/clocksource/clocksource0/{current_clocksource,available_clocksource}: Dateien im Systemverzeichnis, die anzeigen, welche Zeitquelle Linux aktuell nutzt und welche weiteren Zeitquellen verfügbar sind.
- trace_agg.py: Ein Python-Skript, das Mess- oder Protokolldaten zusammenfasst, um Laufzeiten oder Schwankungen leichter auszuwerten.
- CI: Steht für Continuous Integration, also automatisches Testen und Bauen von Software bei jeder Änderung im Projekt.
- Tail-Verstärker: Ein Verstärker-Schaltungsteil, der den Strom oder das Signal im unteren (‚Tail‘-)Zweig einer Differenzstufe stabilisiert.
- clocksource_switch: Ein Vorgang im Kernel, bei dem die Zeitquelle gewechselt wird, etwa von TSC auf HPET, wenn eine zuverlässigere Quelle gebraucht wird.
- baseline_recalc: Das bedeutet, dass eine Messgrundlinie neu berechnet wird, um aktuelle Abweichungen besser beurteilen zu können.
- vCPU-Migration: Verschieben einer virtuellen CPU zwischen physischen CPU-Kernen, was bei Messungen Ungenauigkeiten in der Zeitmessung verursachen kann.
- Preemption: Heißt, dass der Kernel einen laufenden Prozess kurz unterbrechen kann, damit wichtigere Aufgaben schneller ausgeführt werden.
- A‑Fenster (mult/shift): Mathematische Faktoren im Kernel-Zeitcode, die bestimmen, wie Taktwerte in Nanosekunden umgerechnet werden.
- P95/P99: Statistische Kennwerte, die zeigen, ab welcher Zeitspanne die langsamsten 5 % oder 1 % der Messungen liegen.
