ADTF  3.15.1
Clock Concept

ADTF Stream Time

ADTF defines a so called Stream Time that is used as a common base for processing in all components within an ADTF Session. All Samples and Triggers are tagged with a timestamp that is within the time domain of said Stream Time. All Timers will use the Stream Time as base for their processing.

A Streaming Source can use multiple methods (adtf::services::ant::IReferenceClock::ISync2RefChannel) to synchronize external timestamps (obtained from hardware devices) with the ADTF Stream Time such that they can tag their output data correctly and in sync with other external sources.

The clock implementation that provides this Stream Time is called ADTF Stream Clock and can be exchanged depending on the use-case (see adtf::services::ant::IReferenceClock).

During Online Mode (Live) the "system" clock will be used by default and provide timestamps based on UTC.

During Offline Mode (Playback/Re-Simulation) an artifical time is used that allows full deterministic processing. In most cases this will be a discrete clock (which can also be distributed among multiple sessions/hosts), that collects timing requirements from all active components and advances its time in discrete steps. Either trying to mimic real-time or at any custom speed.

ADTF Reference Clock

ADTF delivers a Reference Clock Service that provides a distinct method for getting timestamps within ADTF Stream Time, no matter if the ADTF System is running in Online Mode (Live) or Offline Mode (Playback/Re-Simulation). It allows the registration of many different time sources, that can either be used as time source for the ADTF Stream Time or be recorded for a simulation during playback. The user can configure which time source is used at a single place, without the need for recompilation of any ADTF components. The Service also extends the ADTF System with a mechanism to register and use synchronization algorithms for hardware timestamp conversions, that take clock drift and offset into account, in order to offer the best possible timestamps in the time domain of ADTF Stream Time. This prevents the use of hardcoded solutions and allows changes during configuration. For more information have a look at Clock Synchronization Service and adtf::services::ant::IReferenceClock::ISync2RefChannel.

Time Barrier Architecture

Time Barriers allow ADTF Components to pass timing constraints to the current ADTF Stream Clock.

A Time Barrier is composed of two instants in time, one that can be waited for to start a task and one that marks a time point that should not be crossed before the task has been completed.

Depending on the clock implementation used as ADTF Stream Clock, these barriers are handled in one of the two following ways/scenarios:

  • Online Mode (Live) : In this scenario, waiting for the beginning of a Time Barrier pauses the calling thread until the instant in time has been reached. The end time point of the barrier can be checked to not have passed after the task has completed.
  • Offline Mode (Playback/Re-Simulation) : The ADTF Stream Time will jump in discrete steps from one Time Barrier to the next. Whenever the beginning of a Time Barrier is reached, the thread waiting for it will be woken up to start its task. The time will not advance past the end of any barrier until the barrier is released. If the beginnings of multiple barriers are reached before the next end of a barrier, the corresponding tasks will be executed in parallel.

Each component within an ADTF Session is allowed to create such Time Barriers via adtf::services::penguin::IReferenceClock::GetTimeGuard(). Most likely Filter, Streaming Service and System Service implementions have no need to do so, as they can rely on the Timer Runner or the adtf::system::kernel_timer implementations.

The following ADTF Components use Time Barriers to express their timing requirements: