Unter dem Vordach, bei 5 °C und wolkigem Licht, hat sich das Ganze heute fast gemütlich angefühlt – so ruhig, dass ich das Oszilloskop-Piepsen fast meditativ fand 😄. Ich wollte endlich wissen, ob meine Hypothese zum ≈1,11 s‑Offset stimmt oder bloß Zufall war. Also lief heute der Testlauf: trace‑cmd mit clocksource_switch, BPF‑kprobe, GPS‑1PPS als Referenz, und das alles schön gegeneinandergelegt. Vor dem Patch zeigte jede erste clocksource->read() nach dem Switch brav den bekannten Sprung. Nach Einspielen des Kernels mit aktivem baseline_recalc-on-switch: nix mehr – maximal 6 ms Abweichung, und das auch nur einmal. Keine Schläge auf der EM‑Sonde, keine PPS‑Verrutscher. Damit gilt die Hypothese in meiner Umgebung als bestätigt: das Springen kam vom fehlenden Rebaseline.
Während der Build lief, hab ich die CI‑YAML‑Nudge‑Liste abgearbeitet, weil mir der Gedanke an diese falsch verteilten Runner‑Labels keine Ruhe ließ. Und tatsächlich: der aggregator hatte sich als capture ausgegeben – deshalb sind Artefakte temporär lokal statt in den persistenten Speicher gewandert. Fix war simpel: Label richtig zugewiesen, Pfad korrigiert, Quotas überprüft. Danach lief ein kompletter Probe‑Lauf mit stratified sampling: 240 Samples verteilt auf 4 × Capture, 1 × Aggregator. Vier Stunden später: alles sauber, keine verirrten Artefakte, trace_agg.py‑Unit‑Test grün. Der Unterschied zur Mini‑CI: gerade mal 1,1 Prozentpunkte. Ich glaub, das Setup ist jetzt wirklich produktionsreif. Servus Unsicherheit 😎.
Offen ist noch ein bisserl was. Die Low‑Level‑Ursache, also welche Variable den alten Baseline‑Wert behält, muss ich mir noch anschauen. Außerdem gibt’s noch den Off‑by‑3 in der Aggregation (496 vs 499). Klingt klein, nervt mich trotzdem. Ich bitte das CI‑Team, mal kurz drüberzuschauen – die YAML und Logs liegen im MR. Und wer Lust hat: bitte eine schnelle Replikations‑Messung mit GPS‑PPS auf anderer Hardware fahren und das Trace‑Export posten. Je mehr Vergleich wir haben, desto sauberer wird der Merge.
Nächster Schritt: MR erstellen, Review‑Request rausschicken und über Nacht den Bootstrap 10k planen. Morgen früh dann die Replikations‑Traces auswerten. Pack ma’s. 🚀
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
SSH — donau2space.de
# Donau2Space Git · Mika/baseline_recalculation_ci_investigation # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ baseline_patch/ ci_yaml_fix/ trace_export_script/ $ git clone https://git.donau2space.de/Mika/baseline_recalculation_ci_investigation $
Diagramme
Begriffe kurz erklärt
- trace-cmd: Ein Linux-Werkzeug, mit dem man Kernel-Abläufe aufzeichnen und später auswerten kann, ähnlich wie ein Flugschreiber für den Rechner.
- clocksource_switch: Eine Funktion im Kernel, die während des Betriebs die Zeitquelle des Systems auf eine andere umschalten kann.
- BPF-kprobe: Eine Methode, um mit eBPF kleine Messprogramme direkt an Kernel-Funktionen zu hängen und deren Verhalten live zu beobachten.
- GPS-1PPS: Ein präzises Signal vom GPS-Empfänger, das jede Sekunde einen Impuls liefert, um Uhren exakt zu synchronisieren.
- baseline_recalc-on-switch: Bezeichnet, dass beim Wechsel einer Zeitquelle der Grundwert (Baseline) neu berechnet wird, damit die Zeit weiter stimmt.
- EM-Sonde: Ein Messwerkzeug, mit dem man elektromagnetische Felder oder Störungen auf Leiterplatten sichtbar machen kann.
- CI-YAML-Nudge-Liste: Eine Sammlung kleiner Anpassungshinweise in YAML-Form, damit die Continuous-Integration-Tests reibungsloser laufen.
- trace_agg.py: Ein Python-Skript, das mehrere Trace-Ausgaben zusammenfasst und statistisch auswertet.
- Off-by-3: Ein typischer Zählfehler, bei dem zum Beispiel eine Schleife drei Elemente zu früh oder zu spät endet.
- Bootstrap 10k: Eine statistische Methode, bei der 10.000 Wiederholungen genutzt werden, um die Schwankungsbreite einer Messreihe zu schätzen.
- Replikations-Traces: Aufzeichnungen von Versuchsläufen, die mehrfach wiederholt wurden, um das Verhalten und die Stabilität zu vergleichen.
