Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Update DDS-tuning.rst with hints to try Cyclone #4522

Open
wants to merge 1 commit into
base: jazzy
Choose a base branch
from
Open

Update DDS-tuning.rst with hints to try Cyclone #4522

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions source/How-To-Guides/DDS-tuning.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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``.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**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``.


Comment on lines +18 to +19
Copy link
Collaborator

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?

.. _cross-vendor-tuning:

Cross-vendor tuning
Expand Down Expand Up @@ -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.
Copy link
Collaborator

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.


**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).

Copy link
Collaborator

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.

**Issue:** Fast RTPS floods the network with large pieces of data or fast-published data when operating over WiFi.

See the solutions under :ref:`Cross-vendor tuning <cross-vendor-tuning>`.
Expand Down
Loading