Minimise latency for existing subscribers when late subscriber joins

2 posts / 0 new
Log in or register to post comments
Last post
Sun, 01/24/2016 - 18:26
#1
_Phil_
Offline
Last seen: 7 years 3 months ago
Joined: 01/21/2016
Posts: 1
Minimise latency for existing subscribers when late subscriber joins

Hi,

I have a single publisher publishing 1MB samples every second. Late subscribers need to receive the last 1000 samples, so I’ve set KEEP_LAST_HISTORY and TRANSIENT_LOCAL_DURABILITY with max_samples set to 1000.

When a late-subscriber joins, it takes approximately 35 seconds for the 1000 historical samples to be received. During this time, the publisher continues to publish one sample every second but existing subscribers do not receive updates until the late-subscriber has “caught up”. When the late-subscriber has caught up, the existing subscribers receive a burst of samples that were published over the last 35 seconds (with latencies of up to 35 seconds).

I’m running RTI Connext 5.2.0 on Linux using C++. My publisher and subscriber are generated from rtiddsgen. My Qos is based on BuiltinQosLibExp::Generic.KeepLastReliable.LargeData.FastFlow.

Is there a way to minimise data latency (i.e. keep it below 1 second) for existing subscribers when late subscribers join?

Thanks in advance.

Philip

Keywords:
Top
Thu, 02/18/2016 - 00:02
Gerardo Pardo
Gerardo Pardo's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 06/02/2010
Posts: 602

Hi,

I was not able to reproduce this exact situation. I.e. using the rtiddsgen example with that Qos.  Can post the exact Qos file you use so that I can reproduce it with an automatically-generated example?

However while playing with it I found that if you had a subscriber and then kill it (ungracefully), then the publisher would write a few more samples and "stop" publishing for a while until it detects that the old subscriber has gone away. This is independent of whether there is a new subscriber or not...

I figured out that the problem is that the BuiltinQosLibExp::Generic.KeepLastReliable.LargeData.FastFlow has very conservative settings for "forgetting" a DataReader that dissapers and that combined with a faily small "send-window" causes the DataWriter to block. I a still investigating why exactly that happens, but as a workaround you can increaase the send window size and the agressiviness of forgetting the DataReaders by modifying the DataWriter Qos to add the snippet of XML below.

 
<datawriter_qos>
    <rtps_reliable_writer>
        <max_send_window_size>40</max_send_window_size>
        <min_send_window_size>10</min_send_window_size>
        <heartbeats_per_max_samples>40</heartbeats_per_max_samples>
        <max_heartbeat_retries>5</max_heartbeat_retries>
     </rtps_reliable_writer>
 </datawriter_qos>

Can you check out if that does the trick? If not can you send and XML file with the configuration you use and the IDL data-type so I can try creating a reproducer using the an example generated with rtiddsgen? Gerardo

Top