@@ -85,14 +85,16 @@ For Ethernet benchmarks, the simplest setup is:
8585
8686``` sh
8787export ARENA_ETH_IP=192.168.10.104
88- pixi run bench -- --stream-path patterns/pat0004.pat --json-out bench_results.jsonl
88+ pixi run bench-full -- --json-out bench_results.jsonl
8989```
9090
9191Useful pre-defined tasks:
9292
9393- ` pixi run all-on ` : turn all LEDs on as a communication sanity check
9494- ` pixi run all-off ` : turn all LEDs off as a communication sanity check
95- - ` pixi run bench ` : default host benchmark suite
95+ - ` pixi run bench ` : default host-side suite (` command_rtt ` + ` spf_updates ` )
96+ - ` pixi run bench-full ` : default host-side suite plus ` stream_frames ` using ` patterns/pat0004.pat `
97+ - ` pixi run bench-smoke ` : shorter full run for quick confidence checks
9698- ` pixi run bench-persistent ` : force persistent TCP sockets for small-command RTT
9799- ` pixi run bench-new-connection ` : open a new TCP connection per command
98100- ` pixi run bench-no-quickack ` : disable Linux ` TCP_QUICKACK ` but keep ` TCP_NODELAY `
@@ -103,6 +105,70 @@ Useful pre-defined tasks:
103105Extra arguments after the task are forwarded to the CLI or script, so you can
104106still customize labels, durations, rates, and pattern paths.
105107
108+ Examples:
109+
110+ ``` sh
111+ pixi run bench -- --json-out host_only.jsonl
112+ pixi run bench-full -- --json-out host_plus_stream.jsonl
113+ pixi run bench-full -- --stream-rate 250 --stream-seconds 8 --json-out stream_250hz.jsonl
114+ ```
115+
116+ ## Benchmark progress, timeouts, and failure reporting
117+
118+ The benchmark command now prints phase start and finish lines as it runs, along
119+ with throttled in-phase progress for the long loops. That makes it much easier
120+ to tell whether a run is healthy, slow, or stuck.
121+
122+ By default, the benchmark suite applies a temporary per-operation I/O timeout of
123+ ` 5.0 ` seconds. This avoids the old behavior where a missing reply could block a
124+ run forever.
125+
126+ You can override that timeout from the CLI:
127+
128+ ``` sh
129+ pixi run bench -- --io-timeout 10
130+ pixi run bench-full -- --io-timeout 0
131+ ```
132+
133+ Use ` --io-timeout 0 ` to disable the temporary benchmark timeout and fall back to
134+ blocking I/O.
135+
136+ If a phase fails, the suite now:
137+
138+ - records ` status=error `
139+ - records the failed phase name and exception in the JSON result
140+ - attempts a best-effort ` ALL_OFF ` cleanup before returning
141+ - exits the CLI with a nonzero status
142+
143+ This makes it much easier to automate benchmarks in CI-like shell scripts or
144+ lab orchestration scripts.
145+
146+ ## Host-only benchmarks versus QS logs
147+
148+ The Python benchmark suite is enough to compare host-visible and end-to-end
149+ behavior across:
150+
151+ - operating systems
152+ - host machines
153+ - NICs, switches, and cables
154+ - socket-option policies such as ` TCP_NODELAY ` and ` TCP_QUICKACK `
155+
156+ The JSON output is therefore a good default artifact for broad comparisons
157+ across rigs.
158+
159+ QS logs are still important when you need firmware-internal detail, including:
160+
161+ - ` PERF_NET ` poll cadence and command processing cost
162+ - ` PERF_UPD ` receive / process / commit / applied / coalesced counts
163+ - display-transfer and SPI bottlenecks
164+ - confirmation that the rig applied what the host sent
165+
166+ A practical workflow is:
167+
168+ 1 . Run Python-only benchmarks everywhere for broad comparison.
169+ 2 . Capture QS logs on representative runs or anomalous runs.
170+ 3 . Use the QS logs to explain why two host-visible results differ.
171+
106172## Socket latency tuning
107173
108174The host code exposes both ` TCP_NODELAY ` and ` TCP_QUICKACK ` as explicit options.
0 commit comments