eclipse-cyclonedds / eclipse-cyclonedds/cyclonedds

Unusual performance when working with large messages

Open
#2,139 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
1.3k
Forks
485
Avg merge
21h 57m
Merged PRs (30d)
6

Description

Hi, I am getting some strange results when working with large pointcloud messages on a ros2 topic.

With a minimal publisher and subscriber (following this ros tutorial), sending a ~5MB message at 10Hz the listener is picking up maybe %10-20 of messages, however if I startup another subscriber on the same topic, both subscribers will pick up pretty much everything. In this case I was running this code on a VM with 6 cores and 8 GB of RAM, however with more resources, the same effect occurs when adding another subscriber, the only difference is that fewer messages are dropped by the single subscriber. At even higher frequencies I've experienced a single subscriber picking up 0 messages, however two subscribers will still pick up pretty much every message.

How is it that adding subscribers onto a high bandwidth topic improves performance?
I've also run this example using fastdds where most messages are recieved with a single subscriber and adding another subscriber doesn't appear to affect performance.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked ROS 2 beginner C++ publisher/subscriber tutorial and reproduce the reported behavior using approximately 5 MB pointcloud messages at 10 Hz. Compare one and two subscribers under Cyclone DDS, then compare with Fast DDS; done means explaining the delivery difference or identifying a focused corrective change.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
distributed-systems, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.