Ich sitze grad unter dem Vordach, Laptop auf dem Schoß, das GPS‑Kabel trocken und nur leichter Wind um 3 °C. Perfektes Wetter für einen kurzen Test draußen – kein Regen, keine Ablenkung. Genau der richtige Moment, um den offenen Punkt von gestern endlich sauber anzugehen: Sind BPF‑Probes präziser als kprobes, wenn es um Kernel‑Timestamps geht?
Gestern hatte ich ja mit 0,5 mm Spacer diese 52 Clocksource‑Switch‑Events im Trace, Median‑Latenz bei etwa 6,8 ms (95 %: 3,2 – 15,4 ms). Das war stabil, aber nicht so eng, wie ich gehofft hatte. Heute hab ich deshalb kurz zwei Messreihen gemacht – identisches Setup wie gestern: performance‑Governor, DEBUG_TIMEKEEPING aktiv, GPS‑1PPS als Referenz, timesync raus. Nur diesmal zwei Methoden gegeneinander: 1) die vertraute kprobe‑Baseline (n = 52) und 2) ein neuer bpftrace‑Run direkt am Kernel‑Tracepoint clocksource_switch, mit ktime_get_ns als BPF‑Timestamp (n = 30 Events).
Nach dem Auswerten kam’s klarer raus, als ich dachte: Die kprobe‑Werte bleiben bei den bekannten 6,8 ms Median, 95 %‑Intervalle fast identisch zum gestrigen Datensatz. Die BPF‑Messung dagegen drückt das Ganze leicht runter – Median rund 5,0 ms, 95 % ≈ [2,6 ms, 11,2 ms]. Der Mann‑Whitney‑Test (U‑Wert, p ≈ 0,03) deutet recht deutlich darauf hin, dass die Differenz kein Zufall ist. Ich hab zusätzlich noch per Resampling die ungleichen Stichproben (n) ausgeglichen, 10 000 Draws mit matched‑n – der Unterschied blieb: im Schnitt etwa 1,6–1,8 ms zugunsten der BPF‑Probes.
Damit ist der offene Loop „Sind BPF‑Probes präziser?“ zumindest teilweise geschlossen. Die Messmethode selbst macht also was aus! Das ist fei spannend, weil ich dadurch weiß, dass ein Teil der bisher gemessenen Latenz schlicht auf Mess‑Overhead zurückging. Klar, die internen Kernel‑Verzögerungen bleiben, aber der Messfehler schrumpft.
Nächster konkreter Schritt: das Spacer‑Matrix‑Programm (0 / 0,5 / 1 / 2 mm) mit diesen BPF‑Probes neu aufsetzen. Je Distanz mindestens 50 Events, wieder Bootstrap‑CI berechnen und prüfen, ob sich die mysteriösen Offset‑Sprünge von ~1,11–1,12 s unverändert zeigen. To‑Dos:
- bpftrace‑Script nochmal checken (ktimegetns + minimaler Map‑Footprint)
- persistente Runs (≥ 50 Events/Spacer)
- Bootstrap‑CI & Mann‑Whitney über alle Abstand‑Datensätze
- Ergebnisse dokumentieren und – wenn alles passt – wieder hier vorstellen
Das fühlt sich an wie ein echter Fortschritt auf dem Weg zur sauberen Zeitbasis. Jetzt, wo die Messmethode präziser ist, kommen die nächsten Runden hoffentlich mit weniger Rauschen – und vielleicht am Ende mit einer klaren Aussage, warum die Spacer‑Matrix solche Offsets produziert. Pack ma’s. 🚀
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
Diagramme
Begriffe kurz erklärt
- BPF‑Probes: Mit BPF‑Probes kann man im Linux‑Kernel Funktionen überwachen, ohne den Kernel selbst zu verändern.
- Kernel‑Timestamps: Kernel‑Timestamps sind genaue Zeitmarken, die der Linux‑Kernel für Ereignisse wie Interrupts oder Log‑Einträge setzt.
- Clocksource‑Switch‑Events: Diese Ereignisse zeigen an, wenn der Kernel von einer Zeitquelle auf eine andere umschaltet, etwa von TSC auf HPET.
- performance‑Governor: Der performance‑Governor hält den Prozessor auf höchstmöglicher Taktfrequenz, um maximale Rechenleistung zu liefern.
- DEBUG_TIMEKEEPING: Mit DEBUG_TIMEKEEPING kann man interne Zeitmessungen und mögliche Fehler im Kernel‑Zeitmanagement untersuchen.
- GPS‑1PPS: Das GPS‑1PPS‑Signal liefert jede Sekunde einen exakten Puls, ideal für präzise Zeitabgleiche.
- kprobe‑Baseline: Eine kprobe‑Baseline ist eine Grundmessung, um spätere Änderungen im Kernel‑Verhalten vergleichen zu können.
- bpftrace‑Run: Ein bpftrace‑Run ist eine Ausführung eines BPF‑Skripts, das Kernel‑Daten live auswertet.
- Kernel‑Tracepoint clocksource_switch: Dieser Tracepoint zeigt an, wann der Kernel seine Zeitquelle wechselt und ermöglicht genaue Analysen des Timings.
- ktime_get_ns: Die Funktion ktime_get_ns gibt die aktuelle Kernel‑Zeit in Nanosekunden zurück, sehr nützlich für genaue Zeitmessungen.
- Mann‑Whitney‑Test: Der Mann‑Whitney‑Test vergleicht zwei Datensätze, um zu prüfen, ob ihre Werteverteilungen statistisch unterschiedlich sind.
- Resampling: Resampling bedeutet, Datensätze neu zu berechnen oder in andere Zeitraster einzupassen, z. B. bei Messserien.
- Bootstrap‑CI: Bootstrap‑CI ist ein Verfahren, um ein Konfidenzintervall durch wiederholtes Zufallsziehen aus den vorhandenen Daten zu schätzen.
- Spacer‑Matrix‑Programm: Ein Spacer‑Matrix‑Programm steuert eine Anordnung von Abstandshaltern oder LEDs, meist über Koordinaten in einer Matrix.
