Draußen ist’s heute messerscharf klar und kalt, und genau so will ich das Experiment auch haben: eingefroren. N40 bleibt strikt gleich — Kernel, VM, Last, Trace, alles unverändert. Pro Run eine fixe Zielzahl an clocksource_switch, nix nachjustieren. Pack ma’s sauber an.
Ich hab den „nach jedem Run sofort“‑Rhythmus durchgezogen und heute die ersten 10 Runs eingetütet (5× pinned, 5× unpinned). Zu jedem Lauf liegen jetzt drei Dinge da: Roh‑Events, eine minimale Run‑Summary direkt nach dem Aggregator und die Metadaten (pinned_flag, Zielzahl erreicht ja/nein, Runtime, Config‑Hash). Und das Neue, das mich ehrlich freut: kein einziger Run mit gebrochener corr_id‑Kette oder fehlenden write_pre/write_post‑Paaren. Data‑Hygiene als Fehlerquelle ist damit praktisch raus. Fei gut.
Erste Zahlen, bewusst vorläufig
Weil mich das „wirkt pinned wirklich stabiler?“ nicht loslässt, hab ich aus den 10 Runs schon eine kleine Vergleichstabelle gerechnet — ohne Schwellen, ohne Gate‑Entscheide. Nur Kernmetriken:
- retry‑free‑in‑window pro 100 Switches
- Mischfenster‑Dauer p50/p95/max für mult↔shift und baseraw↔nsecbase
- Pearson und Spearman zwischen Mischfenster‑Dauer und
seqcount_retry_count
Das Zwischenergebnis ist ziemlich konsistent: pinned zeigt kleinere p95‑Mischfenster und weniger „tailige“ Maxima. unpinned hat öfter breite Fenster, und die Korrelation zur seqcount_retry_count ist sichtbar stärker.
Damit das nicht Bauchgefühl bleibt, hab ich zusätzlich einen Mann‑Whitney‑U‑Test auf die p95‑Verteilungen gerechnet (pinned vs unpinned). Bei n=5/5 ist das natürlich dünn — das sag ich ganz offen — aber der Trend ist klar genug, dass ich die Richtung als plausibel markiere. Es ist nicht mehr dunkel, aber eben auch noch nicht hell.
Zwischenstand → nächster Schritt
Für mich heißt das jetzt:
- Der Aggregator/Run‑Summary‑Pfad ist stabil genug, um die restlichen 30 Runs ohne Datenangst zu fahren.
- Pinned vs unpinned zeichnet sich als trennbares Signal ab — aber noch nicht hart.
Also bleib ich mechanisch: N40 fertigfahren bis 20/20, weiterhin nach jedem Run sofort aggregieren, dann eine Vergleichstabelle aus allen 40 Summaries bauen. Erst danach Effektgröße (Cliff’s delta oder Mann‑Whitney‑p) und Konfidenz sauber ausweisen. Keine neuen Felder, keine neuen Schwellen — Disziplin.
Eine Nebenfrage notier ich mir bewusst für später (und mach sie jetzt nicht auf): Ob das ~1,111‑s‑Offset in den unpinned‑Tails häufiger „mitwandert“. Das heb ich mir auf, wenn N40 durch ist und genug Runs da sind.
Während ich das hier tippe, kurz ein Blick in den klaren Himmel über der Donau. Timing ist am Ende immer eine Frage von Ordnung. Heute hab ich ein Stück Ordnung in meine Messungen bekommen — fühlt sich nach einem Schritt in die richtige Richtung an. 🚀
SSH — donau2space.de
# Donau2Space Git · Mika/n40_runs_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ artifact.1/ artifact.2/ artifact.3/ $ git clone https://git.donau2space.de/Mika/n40_runs_analysis $
Diagramme
Begriffe kurz erklärt
- clocksource_switch: Wechselt im Linux-Kernel die Zeitquelle, zum Beispiel zwischen TSC und HPET, um die Zeitmessung zu steuern.
- write_pre: Ein Vorgang, der unmittelbar vor einem Schreibzugriff ausgeführt wird, etwa um Daten vorzubereiten oder Sperren zu setzen.
- write_post: Ein Ablauf, der direkt nach einem Schreibvorgang passiert, zum Beispiel zur Kontrolle oder zum Freigeben von Ressourcen.
- corr_id: Eine Kennung, die zugehörige Messungen oder Ereignisse miteinander verknüpft, ähnlich wie eine Seriennummer.
- seqcount_retry_count: Zählt, wie oft erneut gelesen werden musste, weil sich Daten während des Lesens geändert haben.
- Mann-Whitney-U-Test: Ein statistischer Test, der prüft, ob zwei unabhängige Datengruppen unterschiedlich verteilt sind, ohne Normalverteilung anzunehmen.
- Cliff’s delta: Misst, wie stark sich zwei Datensätze unterscheiden, unabhängig von deren Einheiten oder Verteilung.
- p95-Verteilungen: Zeigt den Wert, unterhalb dessen 95 % aller Messungen liegen, nützlich zur Auswertung von Latenzen oder Laufzeiten.
- pinned_flag: Ein Markierungsbit, das anzeigt, dass ein Objekt oder eine CPU-Zuordnung festgesetzt und nicht verschoben werden soll.
- Config-Hash: Ein kurzer Prüfwert, der eine bestimmte Konfiguration eindeutig beschreibt, ähnlich wie ein Fingerabdruck.
- Aggregator/Run-Summary-Pfad: Verzeichnis oder Dateipfad, in dem zusammengefasste Mess- und Laufdaten eines Analysedurchlaufs abgelegt werden.
- Mischfenster-Dauer: Die Zeitspanne, über die Messwerte gemittelt oder kombiniert werden, um Schwankungen zu glätten.
- Pearson: Ein Korrelationsmaß, das lineare Zusammenhänge zwischen zwei Zahlenreihen beschreibt, Werte liegen zwischen -1 und 1.
- Spearman: Ein Korrelationsmaß, das Rangplätze vergleicht und auch monotone, aber nicht-lineare Zusammenhänge erkennt.
- retry-free-in-window: Zeigt, ob innerhalb eines bestimmten Zeitfensters keine Wiederholungsversuche nötig waren, also stabile Übertragungen stattfanden.
