RMW Fast DDS Publication Mode: Sync vs Async and how to change it

Next Generation ROS
1

NEW AND EASY WAY TO CHANGE PUBLICATION MODE USING EPROSIMA FAST DDS RMW IMPLEMENTATION

We are happy to announce the new and easy manner to change the publication mode when using the default RMW implementation. Setting the new environment variable RMW_FASTRTPS_PUBLICATION_MODE allows the user to easily configure the publication mode that best applies to its application requirements. More information about how to use this variable can be found in the README.

eProsima Fast DDS implements both possible publication modes for the middleware layer: SYNCHRONOUS and ASYNCHRONOUS publication mode. The main difference between them consist in how the write/publish operation is carried out. While the SYNCHRONOUS mode waits until all data has been sent, the ASYNCHRONOUS uses an internal thread to send the data.

There has been an open discussion about the default publication mode used within ROS 2 for some time (see this issue). Currently, following ROS 1 philosophy, the publication mode selected is ASYNCHRONOUS, and so it is a requirement for all RMW implementations to support it (see this issue as an example). Currently, eProsima Fast DDS is the only open source RMW implementation that, besides supporting the default ASYNCHRONOUS publication mode requirement, also allows the user to change to SYNCHRONOUS publication mode (more information here).

The main reason behind this requirement is preventing a blocking behavior in the write operation whenever possible. Nevertheless, the ASYNCHRONOUS publishing mode could also block if the History is filled and it is not possible to add a new change. To prevent this from happening, it is important to tune correctly the Quality of Service Policies related to the History management (Resource Limits, History, Reliability and Durability) and configure a flow controller to prevent flooding the network.

Although the default publication mode for ROS 2 is ASYNCHRONOUS, there may be use cases that benefit from using the SYNCHRONOUS publication mode. The main advantages of changing the publishing mode to SYNCHRONOUS are:

  1. The latency generally decreases with the SYNCHRONOUS publication mode.
  2. The blocking behavior due to the filling of the History is less frequent and only occurs when using RELIABLE Reliability QoS Policy.

Both eProsima Fast DDS RMW implementations (rmw_fastrtps_cpp and rmw_fastrtps_dynamic_cpp) can be configured to use either of the two publication modes. Both implementations provide an easy way to change between them by simply setting an environment variable RMW_FASTRTPS_PUBLICATION_MODE. Our new post on this explains the main differences between both publication modes and its advantages and caveats so you can choose wisely what publication mode is better for your application.

2 Likes
2

@Jaime_Martin_Losa

Nice work :+1:

it is really nice to give user this flexibility, since it depends on the use case. as you mentioned, async and sync both have pros/cons, being optional to allow user to choose this behavior is good i guess.

1 Like
3

I think this information might not be correct. Check this PR. This information is repeated in many places on the web and does not seem to be correct.

Why then did the default behavior changed from asynchronous to synchronous? I have found that with the asynchronous behavior the cpu load would spike after +1hour of activity and make the system unresponsive.

I am not sure of this finding though as switching back to default (synchronous) was the only thing that changed this behavior.

4

Hi @grizzi, good catch! It seems that that particular bit of documentation was overlooked when changing the default publication mode for Humble, the documentation on rmw_fastrtps itself was indeed updated (see here).

Regarding this CPU spike when using asynchronous, I’m afraid we’ll need more information in order to check whether it is indeed caused by the asynchronous mode and provide with a fix. I think the proper place for that discussion would be the rmw_fastrtps repository itself.

1 Like