Timing system observations Page: 3 of 4
This report is part of the collection entitled: Office of Scientific & Technical Information Technical Reports and was provided to Digital Library by the UNT Libraries Government Documents Department.
The following text was automatically extracted from the image on this page using optical character recognition software:
4. Additional Observations
The EPICS Time
On the Dealing
It is NOT possible to get synchronized time stamps on multiple records that are on different (or
even the same) IOCs unless an event system is used to initiate the record processing. And those
records refer to the event system as the source for their time stamps. (Event system in this
context is not the same as the EPICS event records.)
It is determined that an event system is in place by performing an init-time symbol search for
the required support functions. The required support functions for an event system are
described in the document "Synchronized Time Stamp Support." Should the required functions
not be located by the symbol search, the IOC will be configured for 'soft' or 'async' operation.
The timing driver provides tsLocalTime() so that any legacy code will still operate
modification free. However, the AT-8 event system interface is incompatible for use as a time
source. It would require the addition of event registry functions described in "Synchronized
Time Stamp Support."
The EPICS time stamp format is described in "Synchronized Time Stamp Support." However,
it might do to mention it before proceeding to leapsecond handling. The timestamp is based on
how many seconds have passed since an epoch. The timestamp uses the standard formula for
leap years and assumes that all days have 60*60*24 seconds in them. This is not true for days
that include leapseconds. Therefore the actual count of seconds that have passed since the
epoch are calculated improperly. This, in itself, is not really a problem unless some IOCs,
somehow, account for the leapseconds and others do not.
There is no reasonable way to deal with leap seconds since the EPICS time stamp does not
account for them. Therefore, any leap seconds that occur after January 1 1994 will not be
accounted for (prior leapseconds have been hard-coded into the interpretation code -- same as
the previous time stamp driver.)
The results of this is that leap-second sensative time sources may appear to have a different
time than the IOC that is syncing to it (this will be the case for GPS based time sources.) The
problem with this situation is that if a master timing IOC (that uses this type of time source) is
rebooted after sustained operation across a leap second, the initial time stamp value it
calculates will contain a different number of seconds from the epoch than any other master
timing IOC will currently have, that sustained operation across the same leap second and has
not yet rebooted. This will result in inconsistant values for the time stamps on the different
The solution to this problem would be to require that all master timing IOCs that use leap-
second accurate timing be rebooted, if ANY of them get rebooted (after a leap second event.)
Or to only allow one single master timing IOC.
Timing System Observations 3
Timing System Observations
Here’s what’s next.
This report can be searched. Note: Results may vary based on the legibility of text within the document.
Tools / Downloads
Get a copy of this page or view the extracted text.
Citing and Sharing
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
Reference the current page of this Report.
Winans, J. Timing system observations, report, March 1, 1994; Illinois. (digital.library.unt.edu/ark:/67531/metadc672835/m1/3/: accessed October 17, 2018), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT Libraries Government Documents Department.