[ros-users] [Discourse.ros.org] [Next Generation ROS] What should be the correct behavier of a "reliable" transmission? (throughput problem)

EwingKang ros.discourse at gmail.com
Wed Nov 14 03:14:28 UTC 2018





@wjwwood, I really appreciate your detailed explanation of what's going on.

It makes a lot of sense if you compare the behavior to ROS1, that the publisher will not care if the receiver gets the data or not.



I fully agree that we should make it clear for the user. The tutorial page [About Quality of Service Settings](https://index.ros.org/doc/ros2/About-Quality-of-Service-Settings/) did caught me off guard for a while since it states `Reliable: guarantee that samples are delivered, may retry multiple times.` and that "delivered" did not means the delivering for the end-to-end ROS publisher/subscriber, but actually means the operation of underlying DDS. This would be a easy fix of wiki on that regards.



Indeed, in this `KEEP_LAST` style, no publisher will be affected by the broken subscriber and probably will make most scenarios easier (unless you're measuring throughput :slight_smile:). However, I did find the current system default history.length is set to 0 according the the [types.h](https://github.com/ros2/rmw/blob/f7801aa601a1e0215dfb45f56f2ad2dc519e268b/rmw/include/rmw/types.h). I couldn't find the meaning of setting this value to 0?



As far as the QoS configuring goes, I thought we can only consider `max_samples` since ROS2 rwm implementation is currently keyless (ans thus have only one instance) AFAIK. The definition I found (as quoted below) stated that `KEEP_ALL` will not take history length into consideration. According to my experiment, the memory access will kept expand very quickly until the computer dies. This match the behavior stated in the DDS manual that `max_samples` in both `durability_service` and `resource_limits` are set to  `LENGTH_UNLIMITED`. I propose we can expose the `resource_limits.max_samples` through RMW as well as provide limited value for any preset that involve `KEEP_ALL` history. And this behavior should also be properly documented so the user knows what they're doing when adjusting the configuration.



Again, thanks for your reply. Any other opinions are much welcome.





P.s. The definition I found in the OSPL DDS document



> KEEP_ALL_HISTORY_QOS - all samples are stored, provided, the resources are available. On the publishing side, the Data Distribution Service will attempt to keep all samples (representing each value written) of each instance of data (identified by its key) managed by the DataWriter until they can be delivered to all subscribers. On the subscribing side, the Data Distribution Service will attempt to keep all samples of each instance of data (identified by its key) managed by the DataReader.

> These samples are kept until the application takes them from the Data Distribution Service via the DataReader::take operation. The setting of depth has no effect. Its implied value is LENGTH_UNLIMITED. The resources that the Data Distribution Service can use to keep this history are limited by the settings of the ResourceLimitsQosPolicy. 

> If the limit is reached, the behaviour of the Data Distribution Service will depend on the ReliabilityQosPolicy. If the ReliabilityQosPolicy is BEST_EFFORT_RELIABILITY_QOS, the old values are discarded. If ReliabilityQosPolicy is RELIABLE_RELIABILITY_QOS, the Data Distribution Service will block the DataWriter until it can deliver the necessary old values to all subscribers.











---

[Visit Topic](https://discourse.ros.org/t/what-should-be-the-correct-behavier-of-a-reliable-transmission-throughput-problem/6826/3) or reply to this email to respond.









More information about the ros-users mailing list