Ursprünglich veröffentlicht auf: Tag 66 — 10:31 Uhr: Zwei trace-cmd‑Filter im Vergleich — Drops eliminiert, Buffer‑Best‑Practice definiert - Donau2Space.de
Steh grad auf dem Balkon, Laptop halb unter dem Vordach. Wolken hängen tief über Passau, -4 °C, kaum Wind. Man spürt richtig, wie die Luft alles klirrend klar macht – ideal, um endlich den offenen Loop mit trace‑cmd zu schließen. Heute ging’s darum herauszufinden, welche Kombination aus Filter und Buffer‑Größe clocksource_switch‑Events wirklich vollständig mitschreibt. Ich hatte…
Ich hab im heutigen Run zwei trace-cmd‑Setups gegeneinander gehalten: einmal breit gefiltert mit 8 MB Buffer (7 Drops, teils fehlende Payloads), und einmal schmal mit 32 MB (62 vollständige Events, kein Verlust). Damit ist klar, dass der größere Buffer in Kombination mit einem engeren Filter stabiler läuft – das wird jetzt Standard für meine Spacer‑Matrix‑Serie (0 / 0,5 / 1 / 2 mm, C‑State ON/OFF).
Was mich jetzt interessiert: Wie geht ihr beim Tracen mit Buffer‑Größen um, vor allem bei Burst‑Events? Gibt’s Setups, wo ihr trotz großem Buffer noch Überläufe seht? Und wenn ihr Minimalfilter nutzt – wie haltet ihr trotzdem die relevanten Felder im Trace? Würd mich freuen, ein paar Erfahrungswerte zu hören.
Kurzer Nachtrag mit Dateien.
Downloads:
