Performance / Latency / CPU
The pain
Beyond outright failures, DDS in ROS 2 has performance sharp edges (19 reports): large messages blocking unrelated work, latency that gets worse at low publish rates, and CPU/bandwidth spent on traffic that shouldn’t exist.
- Publishing a large message blocks all callback groups — one big sample stalls the whole executor.
- Latency increases for low-frequency data (warm-path assumptions).
- Even alternative middlewares show high latency / lost messages at high publish rates, so this is not unique to one vendor.
- Stacks send unnecessary packets through the network, burning bandwidth and CPU.
Most recent example
rmw_cyclonedds#559 — “Publishing large message blocks all callback groups” (2026-03-03). A single large publish blocks every callback group — a head-of-line stall that couples unrelated parts of the application through the middleware.
Reference list (most recent)
| Date | Source | Problem |
|---|---|---|
| 2026-03-03 | rmw_cyclonedds#559 | Large publish blocks all callback groups |
| 2025-04-12 | cyclonedds#2256 | Latency increases for low-frequency data |
| 2024-06-07 | rmw_zenoh#198 | High latency / lost messages at high pub rate (even on Zenoh) |
| 2024-04-19 | rmw_cyclonedds#489 | Sends unnecessary packets through the network |
How ZeroDDS solves it
Low, consistent latency from an event-driven core; large data on its own path so it doesn’t stall everything else.
- Measured low latency. Round-trip latency on loopback is p50 = 40 µs /
p99 = 83 µs (256 B, 200 samples, 0 lost). The number is reproducible from
the open
latency_ping/latency_pongexamples — not a slide. - Event-driven, no busy-poll. Receive and wait paths use listeners/condvars/wakers, never spin loops, so there is no “latency gets worse when idle / low-frequency” warm-path artifact and no core burned waiting.
- Large data on a dedicated fragmentation path. Big samples go through the DATA_FRAG / NACK_FRAG path with explicit caps; they don’t monopolize the small-message fast path, which is the mechanism behind “one large publish blocks everything.”
- No gratuitous traffic. Multicast-free unicast means packets go to the peers that asked for them — no broadcast discovery chatter consuming bandwidth and CPU on every node.
- Efficient by construction. Pure Rust,
no_std + alloccore (~1.6 MB on Cortex-M4F) — the same code path from MCU to server, without a garbage collector or a heavyweight runtime.
Honest status: the loopback latency, WiFi throughput (10.8 MiB/s) and scaling numbers are verified. Head-to-head latency/throughput comparison tables against each vendor on identical hardware are still being produced — that is exactly the kind of measurement we want open-source validators to run and publish.
Why it no longer has to be a pain
The performance cluster is coupling (large data stalling small data), warm-path assumptions (idle latency), and gratuitous traffic. ZeroDDS keeps paths decoupled, stays event-driven, and only sends unicast to real peers — so performance is predictable rather than full of sharp edges.
Reproduce it yourself
# Loopback RTT distribution (p50/p90/p99), 256 B, 200 samples:
crates/dcps/examples/latency_ping # + latency_pong→ Back to overview · Next: Migration
Performance / Latenz / CPU
Der Schmerz
Jenseits von Totalausfällen hat DDS in ROS 2 scharfe Performance-Kanten (19 Reports): große Nachrichten, die unverwandte Arbeit blockieren, Latenz, die bei niedrigen Publish-Raten schlechter wird, und CPU/Bandbreite, die für Traffic verbraucht werden, der nicht existieren sollte.
- Das Publizieren einer großen Nachricht blockiert alle Callback-Groups — ein großes Sample stallt den ganzen Executor.
- Latenz steigt für niederfrequente Daten (Warm-Path-Annahmen).
- Selbst alternative Middlewares zeigen hohe Latenz / verlorene Nachrichten bei hohen Publish-Raten, das ist also nicht auf einen Vendor beschränkt.
- Stacks senden unnötige Pakete durchs Netz und verbrennen Bandbreite und CPU.
Jüngstes Beispiel
rmw_cyclonedds#559 — „Publishing large message blocks all callback groups” (2026-03-03). Ein einziges großes Publish blockiert jede Callback-Group — ein Head-of-Line-Stall, der unverwandte Teile der Anwendung durch die Middleware koppelt.
Referenzliste (jüngste zuerst)
| Datum | Quelle | Problem |
|---|---|---|
| 2026-03-03 | rmw_cyclonedds#559 | Großes Publish blockiert alle Callback-Groups |
| 2025-04-12 | cyclonedds#2256 | Latenz steigt für niederfrequente Daten |
| 2024-06-07 | rmw_zenoh#198 | Hohe Latenz / verlorene Nachrichten bei hoher Pub-Rate (sogar auf Zenoh) |
| 2024-04-19 | rmw_cyclonedds#489 | Sendet unnötige Pakete durchs Netz |
Wie ZeroDDS es löst
Niedrige, konsistente Latenz aus einem event-getriebenen Kern; Large-Data auf eigenem Pfad, sodass es nicht alles andere stallt.
- Gemessene niedrige Latenz. Roundtrip-Latenz auf Loopback ist p50 = 40 µs / p99 = 83 µs (256 B, 200 Samples, 0 verloren). Die Zahl ist aus den offenen
latency_ping- /latency_pong-Examples reproduzierbar — kein Slide. - Event-getrieben, kein Busy-Poll. Empfangs- und Warte-Pfade nutzen Listener/Condvars/Waker, nie Spinloops, sodass es kein „Latenz wird schlechter im Idle / niederfrequent”-Warm-Path-Artefakt und keinen verbrannten Kern beim Warten gibt.
- Large-Data auf einem dedizierten Fragmentierungs-Pfad. Große Samples gehen durch den DATA_FRAG- / NACK_FRAG-Pfad mit expliziten Caps; sie monopolisieren nicht den Small-Message-Fast-Path, was der Mechanismus hinter „ein großes Publish blockiert alles” ist.
- Kein gratuiter Traffic. Multicast-frei Unicast bedeutet, dass Pakete an die Peers gehen, die sie angefragt haben — kein Broadcast-Discovery-Chatter, der Bandbreite und CPU auf jedem Node verbraucht.
- Effizient by construction. Pure-Rust,
no_std + alloc-Kern (~1,6 MB auf Cortex-M4F) — derselbe Code-Pfad vom MCU bis zum Server, ohne Garbage-Collector oder schwergewichtige Runtime.
Ehrlicher Status: die Loopback-Latenz, der WiFi-Durchsatz (10,8 MiB/s) und die Scaling-Zahlen sind verifiziert. Head-to-head-Latenz-/Durchsatz-Vergleichstabellen gegen jeden Vendor auf identischer Hardware werden noch produziert — genau die Art Messung, die wir Open-Source-Validatoren fahren und publizieren sehen wollen.
Warum es kein Schmerz mehr sein muss
Der Performance-Cluster ist Kopplung (Large-Data stallt Small-Data), Warm-Path-Annahmen (Idle-Latenz) und gratuiter Traffic. ZeroDDS hält Pfade entkoppelt, bleibt event-getrieben und sendet nur Unicast an echte Peers — sodass Performance vorhersehbar ist statt voller scharfer Kanten.
Selbst reproduzieren
# Loopback-RTT-Verteilung (p50/p90/p99), 256 B, 200 Samples:
crates/dcps/examples/latency_ping # + latency_pong→ Zurück zur Übersicht · Weiter: Migration