How clocks are used by Connext DDS

Clock Types

RTI Connext DDS uses two different clocks: 

• Internal clock: Used to measure time and handle timing inside the middleware. 
• External clock: Used to generate source and reception timestamps. 

Both clocks can be configured to use different implementations:

• Realtime (system): Adjustable by the user or time synchronization protocols, generally tracks the number of seconds since 1 January 1970 
• Monotonic:  Non-adjustable, generally tracks the number of seconds since system startup.

By default, both internal and external clocks are realtime. The monotonic clock implementation is not available on all platforms. For a list of supported platforms, see the Core Libraries Platform Notes. Setting a monotonic clock on an unsupported platform will trigger an error at DomainParticipant creation. For more information on clock selection, see Section 16.3.15 Clock selection in the User’s Manual.

Synchronization and Jumps in Time

With default settings, Connext DDS will function normally even if the internal or external clocks are not synchronized across Domain Participants. However, if DestinationOrderQoS is set to DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS, synchronization of external clocks is required. See Section 47.8 Destination_Order QosPolicy in the User’s Manual for more information.

Jumps in time can be caused by network time synchronization or manual adjustments. This affects Connext DDS in different ways, depending on the clock.

• Internal clock: Problems can appear with liveliness, deadline, and reliability (heartbeat, acknacks), as all internal DDS timings will be affected.
• External clock: If DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS is used, samples can be lost if their timestamps are outside source_timestamp_tolerance.

Time zones and daylight saving time changes do not count as jumps in time and they do not affect Connext DDS. See this KB article for more information:

https://community.rti.com/kb/do-i-need-worry-about-daylight-saving-time-or-time-zones-when-using-rti-connext

To make your application robust to jumps in time, it is recommended to use a monotonic clock for the internal clock. 

A monotonic internal clock and realtime external clock setup may cause a slight performance degradation, as the middleware will need to get times from both clocks. Changing the external clock to monotonic will solve the issue. However, with a monotonic external clock, the application will no longer be able to rely on source timestamps for DestinationOrderQoS, as comparing timestamps generated from monotonic clocks on different machines is not possible.