Sometime lost topic when enabling loop mode in replay

8 posts / 0 new
Last post
Offline
Last seen: 1 year 4 months ago
Joined: 07/06/2021
Posts: 5
Sometime lost topic when enabling loop mode in replay

Hi,

When I enable loop mode in the RTI_REPLAY_SERVICE.xml file. 

<!-- Specify playback behavior, including what local time to start -->
<playback>
          <enable_looping>true</enable_looping>
</playback>

I use rtiddsspy to check topics. Sometimes, I don't see some topics.

Thanks,

 

 

 

 

 

 

 
Howard's picture
Offline
Last seen: 17 hours 52 min ago
Joined: 11/29/2012
Posts: 442

Sorry, there's not enough information to comment.  Please describe your scenario more:

1) what OS?

2) how many topics were recorded?  length of time?  how often was the data published for each topic?

3) did you see all of the topics when it first played or never saw all of the topics?

4) how many topics were "missing"?  what do you mean by you couldn't "see" the topics in rtiddspy?  that rtiddspy didn't receive any data for the topics?

5) when you repeat the test, are the same topics missing?  or are random topics missing?

6) if you use Admin Console, do you see DataWriters for the missing topics in the Replay service?

Offline
Last seen: 1 year 4 months ago
Joined: 07/06/2021
Posts: 5

Thanks for your response.

This is my scenario:

1. Using ubuntu 18.04 64bit

2. five topics, length of time: 5s, 100ms

3. I can see all topics but sometimes, one topic missed

4. only one topic. I think that topic can't publish data (sometimes)

5. yes, the same topic.

6. when I use Admin Console and sometimes, that topic does not have data.

Thanks!!!

 
Howard's picture
Offline
Last seen: 17 hours 52 min ago
Joined: 11/29/2012
Posts: 442

I asked:

6) if you use Admin Console, do you see DataWriters for the missing topics in the Replay service?

you wrote:

6. when I use Admin Console and sometimes, that topic does not have data.

However, that's not the question I asked.  I am not asking if Admin Console can see the data for the missing topic.  I'm asking if Admin Console can see the DataWriter in the Replay Service?

Continuing questions:

7) If it's always the same topic that has the problem, what is that topic?  How big is it?  How often is that data sent?

8) With just one recorded file, does the missing topic data show up if you remove the <enable_looping>?

9) Using SQLite Studio, you can attach to the recorded file and look at the tables in the database that's recorded by Recording Service.  Is the missing Topic in the Database?

I am guessing that you have a problem that's independent of <enable_looping>.  If you are missing a topic, and the topic missing from the recording, then it will be missing if you only replay the recording once, or if you replay the recording in a loop.

 

Offline
Last seen: 1 year 4 months ago
Joined: 07/06/2021
Posts: 5

Hi Howard,

I can see data of that topic on Admin Console.

What API do we have to enable loopback mode in relay service instead of enabling in XML?

Thanks,

 
Offline
Last seen: 1 year 4 months ago
Joined: 07/06/2021
Posts: 5

Hi Howard,

When I run replay service in loopback mode one by one topic, all topics run well.

The issue only appears when I run all topics at the same time.

Thanks

 
Offline
Last seen: 1 year 4 months ago
Joined: 07/06/2021
Posts: 5

Hi Howard,

I fixed this issue when I add the fidelity tag

 

<fidelity>
    <sampling_period>
        <sec>0</sec>
        <nanosec>5000000</nanosec>
   </sampling_period>
</fidelity>

 

But I don't really understand this tag, Can you explain more to help me?

Thanks

 

 
Howard's picture
Offline
Last seen: 17 hours 52 min ago
Joined: 11/29/2012
Posts: 442

On this page, Table 4.12, is the documentation for the <fidelity> tag:

https://community.rti.com/static/documentation/connext-dds/6.1.0/doc/manuals/connext_dds_professional/services/recording_service/replay/replay_configuration.html?highlight=fidelity

As explained, this setting controls at what resolution (aka fidelity), the Replay Service will be able to replay the data.  Replay Service has a thread that must wake up and check if there is any data to be sent out.

How fast it is set to wake up is it's resolution...and controls the timing fidelity of the data that replayed.  While we could have designed Replay Service to spin and check over and over again if there is any data to be replayed at that time, that method would consume 100% of the CPU that a thread could consume.  That method could be quite disruptive to the host on which the Replay Service is run.

So, instead, the Replay Service periodically wakes up and then sends data.  The data that is sent is the data with the timestamps between the last time the Replay Service woke up and the current time. 

As the document explains, if you set the <fidelity> to 100 ms, the data is only republished at 100 ms intervals, and so the data being sent out for each interval could be in the range of 100 ms of each other when recorded.

By default, the <fidelity> is set to 1 ms....which is the finest resolution (wakeup period) that can be set for a default Linux application.

While I am glad that you were able to get the data by setting the resolution to 5 ms, I am puzzled as to why that was required.

If you can zip up the directory containing your recorded data that shows this problem (default fidelity, missing data....5 ms fidelity, get all data) and upload it, we can try to see what is going on and if there some sort of issue with the Replay Service.