generalTime

Contents

• What is generalTime?
• Download
• How to use it?
• Timekeeping mechanism
• Acknowledgements

What is generalTime?

generalTime is a timekeeping mechanism implemented as an EPICS device and driver support to provide and maintain clock time for an EPICS IOC. It is a replacement for drvTS in iocCore of previous EPICS versions (before 3.14.8). It is meant to provide reliable and consistent time across IOC's and combine different timekeeping methods on the same (EPICS) network. It implements a failover mechanism specially in case of hardware-assisted time providers which may fail for different reasons.

Download

The package includes drvGeneralTime, drvDevNTPTime, drvDevVWTime and drvDevEventTime:

• Latest, genTime_1_2.tar.gz (29kB).
  (a) EventTime relies only on generalTime for a reference time and has no direct contact to external time refrences such as NTP server.
  (b) For EventTime validation aoRecord type is used instead of bo to allow a desired tolerance in time diffrence.
  (c) NTPTime fixed to handle arbitrary system clock rates.
  (d) generalTime init routine is called at initHookAtBeginning
• Prev. , genTime_1_1.tar.gz (29kB).
  EventTime driver was added to the initial version of generalTime (including NTP and VxWorks Time).

How to use it?

Timekeeping mechanism

generalTime maintains a list of prioritized clocks or time providers. When a client (i.e. EPICS record) requests the time to update its timestamp, generalTime gives the time of the highest avaiable and correct time provider (see the following figure). The idea behind is as the following: The generalTime device support has a central role. Any time-provider acts as an independent driver, therefore they can be added to existing ones like a plug-in. When a record wants to get a timestmap (i.e. when it is processed) it always uses the same method by a call to generalTime. generalTime goes through the list of the registered time providers from the highest priority and returns the first correct time. Time providers are responsible to determine whether or not they are correct.

• NTP Time

  drvDevNTPTime maintains a clock (time provider) which relies on the NTP server of its subnet. It is a pure soft clock. The NTPTime has been given a higher priority than VWTime which is logical. Each IOC periodically syncs its time with the NTP server.

• VxWorks Time

  drvDevVWTime maintains a clock (time provider) which synchronizes itself with the highest available and correct time provider (which has been registered to generalTime, e.g. NTPTime). VWTime is the lowest priority clock and must always be avaiable. It uses on-board real-time clock of the CPU.

• Event Time

  drvDevEventTime maintains a clock using the event system (APS/SLS/Diamond) timing hardware. It uses a master-slave mechanism to achieve tightly synchronized clocks with high quality timetamps. The master IOC generates and distributes clock ticks (event) to slave IOC's via the event system. Therefore EventTime clocks in all IOC's (master and all slaves) tick exactly at the same rate which provides us with perfect time synchrony. The highest timestamp resolution supported at the moment is about 333 nanosecond corresponding to 3 MHz clock rate, however the event system hardware is capable to provide up to 125 MHz rates. The limitation of 3 MHz at the moment is only due to PLL algorithm in drvDevEventTime running on the event master IOC which regulates the clock rate to folllow global time (provided by generalTime via drvDevNTPTime); otherwise if the user can live without runnig PLL algorithm at the risk of drifing from global time, then one can go to higher clock rates as well.

Acknowledgements

I should like to thank Jim Kowalkowsky for initial development of drvTS, Dave Thompson and Sheng Peng for priority-based clock concept, Timo Korhonen for the fruitful discussions we've had during the EventTime dvelopment, Andrew Johnson for his valuable comments.