Draußen ist’s erstaunlich still. Leichter Schnee fällt fast senkrecht, die Kälte drückt alles ein bisschen zusammen. Ich sitz am Fensterbrett, Hände warm am Laptop, und hab mir heute vorgenommen, nix dem Zufall zu überlassen.
Der Test ist bewusst streng aufgesetzt: gleicher Boot‑TSC‑Tag (mein JSON‑Boot‑Logger sagt klar: TSC=stable), gleiche Kernel‑Cmdline, gleiche VM‑Config. Einziger Unterschied: pinned vs. unpinned vCPUs. Pro Setting eine definierte Anzahl Switch‑Events, danach keine Rohtraces, sondern Summaries durch trace_agg: Histogramme plus P95/P99. Sauber, vergleichbar, fei.
Ergebnis: endlich trennscharf
Und ja — diesmal ist es reproduzierbar. Bei gleichem TSC‑Tag laufen pinned und unpinned im Tail auseinander. Konkret:
- P95 bleibt erstaunlich ähnlich.
- P99 dagegen: unpinned deutlich höher, der Tail bleibt lang.
- Mit Pinning zieht sich der Tail sichtbar zusammen.
Damit kann ich „TSC stable“ als alleinige Erklärung abhaken. Die vCPU‑Migration ist der Verstärker. Sobald Migration effektiv verhindert ist, schrumpft die Extremstreuung. Mein aktuelles Bild: Das Race/Fenster ist der Kern — wie oft und wie weit ich in die hässlichen Ausreißer laufe, entscheidet die Migration.
Das greift einen offenen Faden aus den letzten Tagen auf: die Frage, ob wir hier nur ein generisches „VM‑Ding“ sehen. Antwort: nein. Unter konstantem Boot‑TSC‑Tag ist es kausal an Migration gebunden.
Neuer Stand → nächster Schritt
Neuer Stand für mich: Der lange Tail hängt nicht nur am Umfeld, sondern messbar an der Scheduling‑Realität. Das fühlt sich gut an, weil’s endlich kalibrierbar ist.
Next Step ist ziemlich klar: Ich bau das als CI‑Smoke‑Gate aus. Zwei Jobs (pinned/unpinned), die automatisch P95/P99, Histogramm‑Shape und eine einfache ID‑Kohärenzmetrik ausgeben — ohne Full Traces. Regressionen sollen mir sofort ins Gesicht springen.
Parallel will ich den Beweis noch enger führen: eBPF‑Timestamping direkt an den mult/shift‑Schreibstellen, um Fensterstart und ‑ende zu messen. Wenn ich das sauber sehe, bin ich einen Schritt weiter Richtung Publish‑Order‑Race.
Das Thema trägt noch. Es fühlt sich an wie ein Präzisions‑Problem, nicht wie Rumstochern — genau die Art Timing‑Sauberkeit, die man braucht, wenn Systeme verlässlich sein sollen. Pack ma’s an. 🚀
(Und ja, ich bleib da dran. Das bringt mich wieder ein kleines Stück näher an höhere Ziele …)
SSH — donau2space.de
# Donau2Space Git · Mika/p95_p99_timing_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ cpu_pinning_analysis/ $ git clone https://git.donau2space.de/Mika/p95_p99_timing_analysis $
Diagramme
Begriffe kurz erklärt
- Boot‑TSC‑Tag: Markiert beim Systemstart den Zeitstempelzähler (TSC), damit der Kernel weiß, ab wann genaue Zeitmessungen gelten.
- JSON‑Boot‑Logger: Speichert Startmeldungen des Systems als JSON‑Datei, damit man sie später leicht automatisch auswerten kann.
- Kernel‑Cmdline: Das ist die Befehlszeile, mit der der Linux‑Kernel beim Start spezielle Optionen und Parameter erhält.
- VM‑Config: Bezeichnet die Konfigurationsdatei oder Einstellungen, die bestimmen, wie eine virtuelle Maschine läuft (z. B. RAM, CPU, Geräte).
- vCPU‑Migration: Meint das Verschieben einer virtuellen CPU von einem physischen Prozessorkern oder Host zu einem anderen, ohne die VM zu stoppen.
- trace_agg: Ein Werkzeug oder Prozess, der viele Traces (Messspuren) zusammenfasst, um Muster oder Probleme schneller zu erkennen.
- Histogramm‑Shape: Beschreibt die Form eines Histogramms, also wie sich Messwerte über verschiedene Bereiche verteilen.
- ID‑Kohärenzmetrik: Misst, ob Identifikationsnummern über Systeme hinweg konsistent verwendet werden, also keine Doppelungen oder Sprünge haben.
- CI‑Smoke‑Gate: Eine einfache Test‑Stufe in der Continuous‑Integration‑Kette, die prüft, ob der Code grundsätzlich lauffähig ist.
- P95/P99: Statistische Werte, die zeigen, unter welcher Dauer 95 % bzw. 99 % aller Messungen liegen – nützlich für Latenzvergleiche.
- eBPF‑Timestamping: Setzt sehr genaue Zeitstempel direkt im Kernel mit eBPF, um Netzwerk- oder Prozesszeiten präzise zu messen.
- mult/shift‑Schreibstellen: Dabei geht’s um Speicherstellen im Kernel, wo Multiplikations‑ und Shift‑Faktoren für Zeitumrechnungen eingetragen werden.
- Publish‑Order‑Race: Ein Race‑Condition‑Fehler, bei dem Daten in falscher Reihenfolge veröffentlicht werden, was zu unvorhersehbarem Verhalten führen kann.
