Batching samples with rtps_udp transport

[davidgyates]

I send a large number of small samples, all of which get sent as individual packets.

max_samples_per_packet has no effect for the following config:

[common]
DCPSGlobalTransportConfig=$file
DCPSDefaultDiscovery=DEFAULT_RTPS

[transport/the_rtps_transport]
transport_type=rtps_udp 
use_multicast=1
max_samples_per_packet=10

[mitza-oci]

max_samples_per_packet only defines the maximum, it doesn't enforce a minimum. Each transport type can handle this differently. In general, DataWriter::write() calls will turn in to network traffic 1:1 (even in the TCP transport). This is because OpenDDS is trying to not add any latency. There are cases where multiple samples will be combined into one network "message," especially with durability, but again this depends on the transport.

[davidgyates]

...ah, ok - I'd been looking at RTI DDS which has configurable batching which suits our application (if not our budget) which may dump thousands of small samples (near) simultaneously.

I saw this max_samples_per_packet setting, tried it, found it didn't work, but also couldn't see how you controlled the aggregation time so wondered if I was on a bit of a loser...

Thanks,

[jwillemsen]

Sounds an interesting feature to add when someone has time to implement it or there is sponsoring to add this

[mitza-oci]

The OpenDDS core already has support for a form of this in TransportSendStrategy. It would just need to be adapted to the rtps_udp transport.

With the current implementation, how long does it take to repair any lost samples from the burst? Have you tried adjusting the timing parameters?