We are using TAO DDS (version 0.11) to publish and subscribe to data. The publisher is event driven and the subscriber receives data using on_data_available. The behaviour we see is an apparent buffering of data somewhere between writing by the data writer and the listener receiving it.
When we write data at 10Hz we note that the subscriber receives the data at 5Hz with two packets received almost instantaneously. Similarly, if we write data at 20Hz the subscriber again receives the data at 5Hz with 4 packets coming in simultaneously. Is there some underlying buffering of data going on that we can disable?
The transport configuration (simpleTCP) and QoS settings remain as their defaults. It is critical that this data be received as close as possible to when it is actioned by the publisher.
This behavior indeed sounds very implementation dependent.
The DDS implementation I'm familiar with (OpenSplice DDS) utilizes the 'latency-budget' QoS policy that indicates how much time is available to the middleware to get the data delivered to the readers 'in-time' to potentially pack multiple updates so that they can be distributed more efficiently, but in case of default budget which is zero i.e. 'asap', there should be very little latency on the transport of each individually written sample (where the determinism/jitter on this latency would be controlled by the TRANSPORT_PRIORITY QoS-value that indirectly drives the selection of the most appropriate priority-lane that OPENSPLICE DDS allows to be dynamically configured