Timing system observations Page: 2 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:
3. Synchronous Timing
Soft Slave With
This is ONLY appropriate if the IOC contains a better time source than the UNIX NTP time
service can provide. This mode is enabled by the use of TSconfigure(. When employed, the
IOC will use the accurate local time source and respond to slave polls that are used to search
for a soft master timing IOC. The result will be that soft slaves will choose this IOC as a
timing choice over the use of the UNIX NTP service. Use of this service will result in time as
accurate as the local source.
This mode is entered only if a soft slave finds a soft master IOC on the network. It locates the
soft master by broadcasting for it periodically. If a soft master is found, a simple time sync
protocol (not NTP) is used where the soft slave periodically polls the master for the time. This
typically results in the slave being out of sync by no more than one clock tick.
3. Synchronous Timing
If an event system is located during initialization, the IOC will be configured as a synchronous
slave. Options for synchronous operation are:
" Synchronous Master
" Synchronous Slave
By default, the "Synchronous Slave" mode is used. "Synchronous Master" mode is enabled by
the use of the TsconfigureO command in the startup.cmd file.
This mode is entered when Tsconfigure() requests it at init time. In this mode the time
source of the IOC is defined by the presence of the ErGetTimeO function. If it is present, it is
used to get the initial time. Presumably, GPS drivers will supply ErGetTimeO. After the initial
time has been set, it uses the clock tick mechanism of the event system to maintain the time
(ie. ErGetTimeO is never called again.)
In this mode, the IOC will broadcast resync messages when resync events are detected on the
on the event system. This will maintain the exact same tick count value on all synchronous
slaves that is accurate to the propagation delay present in the event system.
This is the default mode of operation when an IOC boots with event receiver hardware present.
In this mode the IOC will get its time from the tick counter on the event receiver hardware.
And resync with the master by receiving the resync event code followed by the resync time
stamp from the synchronous master.
4. Additional Observations
DrvTS is actually part of the IocCore proper. It is not a regular driver because it is used
internally by IocCore. (This is the same as the old time stamp support.)
2 Timing System Observations Document Revision: 1
Timing System Observations
Document Revision: 1
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/2/: accessed November 18, 2017), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT Libraries Government Documents Department.