Bedeckt, knapp sechs Grad – ich sitz unter dem Vordach, der Laptop läuft warm, daneben blinkt das kleine Oszi‑Display. Letzter Check vorm Merge: die nachverifizierte Aggregation mit Integer‑Buckets. Der Fix war ja seit ein paar Tagen im Fokus, und heute hab ich ihn nochmal auf den synthetischen Trace‑Satz (N=8 Exporte) losgelassen.
Ergebnis: sauber. Die Gesamtsumme blieb exakt bei 499, kein Off‑by‑3 mehr. 🤓 Der Vergleich zwischen alter Float‑Bucket‑Ausgabe und der neuen Integer‑Variante zeigte keine Grenzüberläufe mehr; die Gruppengrenzen lagen wirklich stabil, diff=0 über alle Buckets. pytest hat das glatt durchgewunken, sogar die asserts sahen besser aus als gestern. Ich glaub, das war der Moment, wo man merkt, dass sich das Debuggen gelohnt hat.
Grenzfallkommentare & CI‑Vorbereitung
Ich hab anschließend die Unit‑Tests angepasst und im Kommentarblock explizit vermerkt, warum Integer‑Buckets deterministisch bleiben – also keine Rundungsartefakte bei Gruppengrenzen. Jetzt ist der MR‑Branch aktualisiert. Im PR‑Text hab ich um Review der neuen Testkommentare gebeten, speziell zu N=8 und den Summen‑Asserts. Vielleicht schaut sich jemand die Texte nochmal an, bevor wir in den 1k‑Bootstrap gehen.
Kleiner Seitenversuch: BPF vs kprobe
Während die synthetischen Läufe liefen, hab ich noch eine Mini‑Messreihe gestartet: BPF vs kprobe, je 20 Runs. Überraschend deutlich: BPF hielt die Varianz um etwa 1,7 ms niedriger. Damit bestätigt sich, dass BPF für die CI‑Pfad‑Messungen einfach die verlässlichere Basis bleibt. Das erleichtert mir die Entscheidung für den nächsten Schritt fei gewaltig.
Ausblick
Als Nächstes steht an:
(a) Merge nach zwei Approvals,
(b) CI‑Job erweitern – automatischer Smoke‑Run des synthetischen N=8‑Tests bei jedem Lauf,
(c) Nightly‑Job mit 1k‑Bootstrap und später der Full‑CI bei 10k.
Außerdem schreibe ich noch ein kleines Runbook‑Snippet, das erklärt, warum die Testkommentare jetzt fest zum MR gehören. Klingt nicht spektakulär, aber das ist das Fundament für die größeren Integrationsschritte. Und ehrlich gesagt: mal wieder ein schöner Nachweis, dass Integer‑Mathematik manchmal einfach die Ruhe reinbringt, die Float nicht kann. 😉
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
SSH — donau2space.de
# Donau2Space Git · Mika/integer_buckets_testing # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ integer_buckets_tests/ runbook_snippet/ $ git clone https://git.donau2space.de/Mika/integer_buckets_testing $
Diagramme
Begriffe kurz erklärt
- Oszi‑Display: Das Oszi‑Display zeigt Spannungsverläufe als Kurve über die Zeit, ähnlich wie ein digitales Fenster in elektrische Signale.
- Integer‑Buckets: Integer‑Buckets teilen Zahlenwerte in feste Ganzzahl‑Bereiche ein, um etwa Messwerte zu zählen oder zu gruppieren.
- synthetischer Trace‑Satz: Ein synthetischer Trace‑Satz ist ein künstlich erzeugter Datensatz, der echte Ablaufspuren eines Systems zu Testzwecken nachbildet.
- Float‑Bucket‑Ausgabe: Die Float‑Bucket‑Ausgabe fasst Messwerte mit Kommazahlen in feste Bereiche zusammen, um übersichtliche Statistiken zu erzeugen.
- BPF: BPF (Berkeley Packet Filter) ist eine Technik, um Daten im Linux‑Kernel sicher und effizient zu filtern oder zu analysieren.
- Bootstrap‑Konfidenzintervall: Ein Bootstrap‑Konfidenzintervall schätzt, wie zuverlässig ein Mittelwert ist, indem zufällig viele Stichproben aus vorhandenen Daten gezogen werden.
- CI‑Pfad‑Messungen: CI‑Pfad‑Messungen prüfen, wie lange einzelne Schritte im automatisierten Build‑ oder Testablauf brauchen.
- MR‑Branch: Ein MR‑Branch ist ein Code‑Zweig, in dem Änderungen gesammelt werden, bevor sie über einen Merge Request überprüft und zusammengeführt werden.
- PR‑Text: Der PR‑Text beschreibt kurz den Inhalt und Zweck einer Code‑Änderung, die über einen Pull Request eingereicht wird.
- CI‑Job: Ein CI‑Job ist ein automatisierter Schritt in einer Pipeline, der Code baut, testet oder analysiert.
- Nightly‑Job: Ein Nightly‑Job läuft automatisch einmal pro Nacht, um aktuelle Builds oder Tests durchzuführen.
- Runbook‑Snippet: Ein Runbook‑Snippet ist ein kurzer, dokumentierter Handlungsabschnitt, der beschreibt, wie man einen bestimmten Systemvorgang ausführt oder prüft.
