Fastrtps udp packets are larger than CycloneDDS packets
Bug report
Required Info:
- Operating System:
- Ubuntu
- Installation type:
- from source
-
Version or commit hash:
- DDS implementation:
- Fast-RTPS and CycloneDDS
- Client library (if applicable):
- N/A
Steps to reproduce issue
Start the publisher on one host and the subscriber on another, then capture packets using tcpdump.
publisher: ros2 topic pub -r 100 test std_msgs/String "{data: asdf}"
subscriber: ros2 topic hz test
Expected behavior
The packet sizes are about the same.
Actual behavior
FastRTPS packets are about 50 bytes larger than CycloneDDS packets.
FastRTPS:
CycloneDDS:
@rty813
In order to help you better, we'd need more information here.
You say that you are building from sources, but you are not indicating which version you are building (rolling? jazzy?) It would be best if you point to the commit hash of the main repo (i.e. https://github.com/ros2/ros2). You should also indicate whether you are using any build flags different from the ones indicated in the documentation.
I tried reproducing with the Jazzy docker image, and I only see INFO_TS and DATA sub-messages, but no HEARTBEATs, since the default configuration is BEST_EFFORT. So I suppose you either built the stack with different default values, or you are providing some custom configuration via environment variables or something.
@MiguelCompany The compiled version is Foxy, which is no longer maintained.
I tried it in the humble docker image and found that the data volume of fastrtps is still a little higher than that of cyclonedds, and it has a higher outbound traffic.
Subscriber's network traffic
test command: ros2 topic pub -r100 testt std_msgs/String "{data: hellowaslkdjflaksdjfklasdforld}"
cyclonedds:
fastrtps:
@rty813 Again, please provide full instructions on how to reproduce, including the commands to measure the bandwidth and, if possible, packet captures that we can analyze.
I would also check on Jazzy, just to check whether there have been improvements on the latest LTS release
@rty813 Some things that could be considered:
- There are several timing configurations that could affect the generated bandwidth. In particular, heartbeat period and participant announcement period come to mind.
- Fast DDS adds INFO_DST submessage when the packets are sent to a single participant.
- Fast DDS add custom statistics submessage. This can be avoided disabling the statistics when building Fast DDS by setting
-DFASTDDS_STATISTICS=OFFcmake option
Closing since enough information was provided