Regarding the questions in the talk, it is rather suboptimal that crowd-cast does not allow for discussion after the talk. I therefore missed some of them entirely but I looked them up afterwards and maybe the answers are still of use.
- Will sensor_msgs/Image be carried via ZeroCopy transport
No since sensor_msgs/Image contains a string they are not fixed (or bounded) size. We may support data types like this in some future iteration but it can never be as performant as using some fixed size type since any non-fixed size type will require a serialization operation (which a fixed-size type does not). The reason is that the data may reside in external memory in a format not suitable for shared memory transfer. I suggest using a specifically crafted fixed size message type instead.
- If one is currently using ROS 2’s intra-process communication to achieve zero-copy transfer, is there a benefit in switching to this method?
Intra-process communication is more restricted, as it works only in the same process. Therefore this does not compete with shared memory usage which is used used for inter-process communication within the same machine (intra-machine).
I do not know the implementation but since under the hood intra-process communication can be as simple as exchanging a pointer I think it would be faster than communication via iceoryx. But as soon as we communicate between processes for sufficiently large/frequent messages there are definitely performance benefits in using iceoryx.
- Is ZeroCopy transportation can applicable to the docker container? For example, communication between host-container or data transportation over multiple containers.
No, each docker container essentially acts as a separate machine, so shared memory communication does not work across docker containers. The reason is POSIX shared memory resources are only visible in the container itself, not in other containers. Furthermore the middleware dameon has to run within the machine which uses shared memory and running it in one container it is not able to manage applications/memory in another.
- How do these SharedMemory settings interact with the standard ROS quality of service?
The default ROS QoS settings are Reliable, KeepLast, Volatile. These settings are supported with iceoryx (up to some limit for KeepLast). For an application there is virtually no difference in the reception of messages but potentially a performance gain.
- Is iceoryx a version of cyclone dds?
iceoryx is an independent project but is used in Cyclone DDS. There is a project to use iceoryx without cyclonedds in ROS 2 GitHub - ros2/rmw_iceoryx: rmw implementation for iceoryx You can also use iceoryx without ROS 2 as an inter-process communication mechanism.
- Is 64Kb the message fragmentation limit for cyclone dds ?
This cannot be fully explained as of now, the 64kB boundary requires further investigation and more benchmark data. At the moment we have no conclusive data as to why we see this increasing gap between network and Shared Memory transfer above 64kB message size. The current explanation is that a UDP datagram has at most this size. We also have to consider that sending a message always incurs some basic cost (waitset, semaphores, executor etc.), regardless of its size. There should be a point where this effort gets negligible compared to serialization and deserialization in the network case, but the exact point depends on many factors.
Furthermore I believe throughput already benefits from shared memory at much smaller (but frequent) messages, but the benchmark does not cover this. There is definitely some optimization potential but there is no doubt that in the case where it is supported shared memory support leads to performance gains.
I am interested in this framework.
