Benchmarks
Benchmarks are measurement-oriented Librux scenarios.
Complete the guided Developer Guide path first. Benchmark pages assume you already understand the normal communication surfaces.
For the public installed-user flow, benchmark pages assume.
- Librux runtime and SDK are already installed under
/opt/librux - benchmark runners are available under
/opt/librux/benchmarks - the Python SDK wheel has been installed into your active Python environment
- you run benchmark scenarios one at a time on a host
The benchmark runners can start the installed local control backend automatically when they do not detect one already running.
Clone the SDK source repo only for editable SDK work, source-level tests, or
advanced benchmark matrix tooling under tools/qa.
Public Benchmark Tracks
| Track | Description |
|---|---|
transport |
Event and Control latency/throughput harnesses |
timing |
Timed Exchange, Procedure, and Operation scheduling scenarios |
ros2-comparison |
Small ROS 2/DDS comparison track for calibrating Librux communication numbers |
Use benchmarks when you want performance numbers or scheduling behavior, not first-contact walkthroughs.
Cross-host one-way latency rows are accepted only when the matching time-sync track is also accepted; otherwise they are diagnostic transport data.
Acceptance Boundaries
Keep benchmark reports separated by intent.
- release/deployment smoke checks belong in Deployment Checks
- official Event fanout comparison stops at N=256 subscribers
- N=512 and N=1024 are stress runs for capacity, scheduler sensitivity, and local fanout-dispatch behavior
- ROS 2 comparison tables should include only runs whose scope and acceptance gates are explicitly labeled
Do not mix readiness-only, VM-led, software-timestamp, or stress rows into production timing tables without marking them as diagnostic evidence.