Why do I see incorrect RTI Connext behavior while using an SNTP server on Windows for time synchronization?

Note: Applies to RTI Connext 4.x and above.
RTI Data Distribution Service 4.4 and later include support for non-monotonic support. Please refer to the 4.4 User's Manual for details and the list of supported platforms.

RTI Data Distribution Service 4.3 and earlier requires a monotonic increasing clock to operate correctly. RTI’s middleware uses this time source for many of its operations, including determining timestamps for data and determining timeouts. If that time source makes unexpected leaps, the RTI middleware will not operate correctly. For example, if the time suddenly changes to an earlier time, RTI Connext will detect that the new data samples have "older" timestamps than the previous data samples. Event timers will also fire incorrectly. If the time suddenly changes to a later time, the internal event timers may trigger prematurely, since the expected future time arrives more quickly than it should. This can cause incorrect loss of liveliness. 

Using Simple Network Time Protocol (SNTP) for time synchronization might cause the problems described above on most platforms (including Windows) because SNTP can make a non-continuous change to the system time. For example, the Windows SNTP client will discontinuously change the time in a number of circumstances (quoted from http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03mngd/26_s3wts.mspx):

When the local clock offset has been determined, the following adjustments are made to the time:

  • If the local clock time of the client is behind the current time received from the server, Windows Time Service will change the local clock time immediately.
  • If the local clock time of the client is more than three minutes ahead of the time on the server, the service will change the local clock time immediately.
  • If the local clock time of the client is less than three minutes ahead of the time on the server, the service will quarter or halve the clock frequency for long enough to synchronize the clocks. 

The first and second of these items are discontinuous time changes that would cause problems. 

The Nework Time Protocol (NTP) is better than SNTP at controlling clock changes. NTP is designed to frequently make small changes in the clock by changing the clock frequency. In contrast, SNTP runs much more rarely and will make large, sometimes discontinuous changes. But even NTP will make discontinuous changes if the time difference becomes large enough. The exact behavior will vary depending on the specific NTP client used.

Platform:
Keywords:

Comments

Should modify this posting to add information about setting the Internal clock to use the "monotonic clock" as a solution to the system clock change problem...


            <participant_qos>

                <property>
                    <value>
                        <element>
                            <name> dds.clock.internal_clock </name>
                            <value> monotonic </value>
                        </element>
                    </value>
                </property>

            </participant_qos>