-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update DDS-tuning.rst with hints to try Cyclone #4522
base: jazzy
Are you sure you want to change the base?
Conversation
It may not be clear that the default FastDDS does not work well in all situations by default, and that one easy workaround could be to try CycloneDDS. Signed-off-by: Mitchell Pleune <[email protected]>
**Issue:** Sending messages larger than 0.5MB is very laggy, particularly to rclpy subscribers. | ||
|
||
**Workaround:** Switch to another DDS backend, such as Cyclone DDS. Or, if that is for some reason not an option, [increase the shared memory segment allocation through the XML configuration](https://github.com/ros2/ros2/issues/1289#issuecomment-2154807669). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have two suggestions here:
- The default DDS vendor can and will change between releases. I think we might want to mention this as the generic way to change the underlying RMW.
- In the case of FastDDS, a lot of users have found success using the FastDDS Discovery server. We might want to mention this.
**Note:** If you are seeing issues with the default FastDDS middleware, the easiest thing too try may be to switch to another, such as CycloneDDS. Try this by exporting ``export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp``. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really do not think changing rmw implementation is easy thing to do once it comes to production. btw, what do you mean by issues
here? if you want to mention that user can configure the rmw implementation with environmental variable, we already have https://docs.ros.org/en/rolling/How-To-Guides/Working-with-multiple-RMW-implementations.html?
@@ -92,6 +94,10 @@ Instead, define ``FooArray`` as: | |||
Fast RTPS tuning | |||
---------------- | |||
|
|||
**Issue:** Sending messages larger than 0.5MB is very laggy, particularly to rclpy subscribers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now i see the specific issue for large data.
We have https://github.com/ros2/rmw_fastrtps?tab=readme-ov-file#large-data-transfer-over-lossy-network, but that kind of tuning information is not well described in ros2 documentation. I do agree that we can add more suggested configuration for use case basis, that would be useful for users to save time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we discussed this with the ROS 2 team.
The most basic problem is that depending on your application, different RMW implementation work differently, and in some cases, better. Also, as @kscottz pointed out, the default may change between distributions.
Thus, the advice here should be generic, that switching to a different RMW backend may help. Thus I think the advice should be something like the following:
.. note::
If you are having issues with the default RMW implementation, sometimes switching to another one may help. You can find out what your current RMW implementation is by running ``ros2 doctor -r``. If you want to switch to a different DDS vendor, please see :doc:`<./Working-with-multiple-RMW-implementations>`.
@Pleune Friendly ping here. |
@@ -15,6 +15,8 @@ You may need to increase or decrease values while debugging relative to factors | |||
It is important to recognize that tuning parameters can come at a cost to resources, and may affect parts of your system beyond the scope of the desired improvements. | |||
The benefits of improving reliability should be weighed against any detriments for each individual case. | |||
|
|||
**Note:** If you are seeing issues with the default FastDDS middleware, the easiest thing too try may be to switch to another, such as CycloneDDS. Try this by exporting ``export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
**Note:** If you are seeing issues with the default FastDDS middleware, the easiest thing too try may be to switch to another, such as CycloneDDS. Try this by exporting ``export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp``. | |
**Note:** If you are seeing issues with the default FastDDS middleware, the easiest thing to try may be to switch to another, such as CycloneDDS. Try this by exporting ``export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp``. |
It may not be clear that the default FastDDS does not work well in all situations by default, and that one easy workaround could be to try CycloneDDS.
See some discussion at ros2/ros2#1289
And some more information about my particular issue at ros2/rmw_fastrtps#739