Static DDS discovery versus Multicast discovery for low‑traffic ROS 2 workloads

For a ROS 2 node publishing at 0.1 Hz, the discovery-traffic overhead from multicast DDS can dominate the available bandwidth if payload sizes are small. Multicast discovery typically emits 1-5 KB/s of RTPS Heartbeat and Participant Discovery packets regardless of application traffic. If each published message carries 100 bytes, the payload rate is 10 B/s, making the discovery overhead 100-500x larger than the actual data. In this regime, static DDS discovery becomes preferable when the goal is to eliminate that background noise, provided the participant list remains stable across all nodes.

Likely explanation: Multicast discovery's constant background traffic is independent of message rate. For low-frequency workloads, the ratio of discovery bytes to payload bytes rises sharply as payload shrinks. Static discovery removes the discovery stream entirely, but requires every node to know every peer's address.

• Multicast discovery creates fixed 1-5 KB/s overhead on LANs.
• Static discovery eliminates this overhead but shifts complexity to manual list synchronization.
• CPU savings from disabling multicast are measurable on low-power MCUs (5-15% reduction in wake-ups) but negligible on modern embedded Linux/SBCs.
• Behavior varies by DDS vendor (Fast DDS, Cyclone DDS) in how static participant lists are parsed and loaded.

On typical embedded hardware (e.g., ARM Cortex-M or Raspberry Pi-class boards), turning off multicast can shave a few percent of CPU cycles spent on packet processing and interrupt handling. On a Cortex-M4 running ROS 2 Humble with Fast DDS, anecdotal reports show about 8% lower CPU utilization at idle when static discovery is used, but results depend on the exact network stack and configuration.

To detect a static-list mismatch before it causes missed messages in low-traffic scenarios, a lightweight technique is to run a watchdog publisher at a modest rate (e.g., 1 Hz) that is only reachable by the intended static peers. If any peer is missing from the configured list, its packets will not be received, and a simple subscriber monitor can flag the gap. Alternatively, capture RTPS traffic with tshark or fastrtps' rtpsmon during an idle period; the absence of expected Heartbeat packets from a configured peer signals a configuration drift.

Missing detail for refined recommendation: If you can share the typical ROS 2 message payload size and whether participant addresses are static IP/DNS or dynamically assigned (DHCP), I can narrow the bandwidth threshold and CPU-savings estimate.