Understanding by_source and source_timestamp_tolerance at the DataWriter side

3 posts / 0 new
Last post
gustavo@rti.com's picture
Last seen: 6 years 4 months ago
Joined: 03/06/2017
Posts: 1
Understanding by_source and source_timestamp_tolerance at the DataWriter side


I have a question regarding Destination Order QoS, by_source_timestamp and source_timestamp_tolerance at the DW side.

At the DR the behavior is clear for me, I have tests and validated all behaviors. My question is about to the DW side, and the source_timestamp_tolerance at the DW.

According to the docs, if I have a DataWriter with kind DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS:

“When writing a DDS sample, its timestamp must not be less than the timestamp of the previously written DDS sample. However, if it is less than the timestamp of the previously written DDS sample but the difference is less than this tolerance, the DDS sample will use the previously written DDS sample's timestamp as its timestamp. Otherwise, if the difference is
greater than this tolerance, the write will fail.”

Does this “previously written DDS sample” refer to which of the following behaviors?
Behavior 1 - Previously written samples at the same DW
Behavior 2 - Previously written samples at the instance. The DW somehow is aware of the instance’s latest timestamp on a DR on the same application.

According to my tests here, I observed Behavior 1. I.e. the DW is not aware of the instance’s latest timestamp on a DR in the same app. When I receive a sample on a DR (the sample is from a machine with clock ahead by some seconds) at the same application, and then try to write to a DW on the same app with a timestamp earlier than the received sample at the DR, the write is successful (I see the sample in Wireshark, although it’s not received by other DRs because the sample is in the past).

Does the Behavior 2 apply ? Because I'm concerned about the tolerance parameter at the DW.

If Behavior 1 is the actual behavior, what’s the purpose of source_timestamp_tolerance on the DW side? How an application could write samples to the same DW with unordered timestamps?
Last seen: 2 years 6 months ago
Joined: 08/09/2017
Posts: 25

My response will not directly address your question, but I will attempt to provide a scenario in which it makes sense to use the source_timestamp_tolerance setting, and hopefully that will provide some additional insight into what it means and how it is used.

Consider a case where a multi-threaded application provides its own timestamps by using the write_with_timestamp() API.  The following sequence could occur:

1) Thread A of app grabs a time stamp and gets ready to write, but gets swapped out.
2) Thread B of app grabs a time stamp and writes.
3) Thread A wakes back up and writes.
In this scenario, thread A could be writing with a stampstamp that is earlier than thread B's timestamp, and the write could fail.  But the app may not want it to fail because, from its perspective, both samples are valid and should be accepted.  In this case, the app could use the source_timestamp_tolerance setting to cause the sample from Thread A to be accepted and end up with the same time stamp as the sample from Thread B.
Gerardo Pardo's picture
Last seen: 1 month 1 week ago
Joined: 06/02/2010
Posts: 601

Hi Gustavo,

[Updated:  I typed my answer before seeing that Mike had beat me to it. Mike's explanation is right on]

It is Behavior 1 as your tests show. There is no way for DataWriter to be aware of the timestamps in the DataReader's cache.

So yes, the comparison of the source timestamp difference with the source_timestamp_tolerance (and potential correction) occuus within a single DataWriter.

This logic is needed for situations where multiple application threads are writing data to the same DataWriter. Moreover in situations where the source-timestamp is passed by the application. In this scenario it is possible that the order in which the two samples if finally "commited" to the DataWriter cache (which is serialized by the DataWriter mutex) is not exactly the same in which the two threads "read" their respective timestamps from the clock (bacause that "read" happened outside the DataWriter mutex).  The source_timestamp_tolerance is the used to "adjust" slightly the second source timestamp so that the second sample can be accepted without violating the monotonicity of the source timestamp.