Master Time Facility at the UDel Internet Research Laboratory
Last update: 10-Mar-2014 05:20 UTC
NTP Version 4 supports almost four dozen satellite, radio and telephone modem reference clocks plus several audio devices for instrumentation signals. A general description of the reference clock support is on this page. Additional information about each reference clock driver can be found via links from this page. Additional information is on the Debugging Hints for Reference Clock Drivers and How To Write a Reference Clock Driver pages. Information on how to support pulse-per-second (PPS) signals produced by some devices is on the Pulse-per-second (PPS) Signal Interfacing page. All reference clock drivers require that the reference clock use only Coordinated Universal Time (UTC). Timezone and standard/daylight adjustments are performed by the operating system kernel.
A reference clock will generally (though not always) be a radio timecode receiver synchronized to standard time as provided by NIST and USNO in the US, NRC in Canada and their counterparts elsewhere in the world. A device driver specific to each reference clock must be compiled in the distribution; however, most common radio, satellite and telephone modem clocks are included by default and are activated by configuration commands.
Reference clocks are supported in the same way as ordinary NTP clients and use the same filter, select, cluster and combine algorithms. Drivers have addresses in the form
t is the driver type and
u is a unit number in the range 0-3 to distinguish multiple instances of the same driver. The connection to the computer is device-dependent, usually a serial port, parallel port or special bus peripheral, but some can work directly from an audio codec or sound card. The particular device is specified by adding a soft link from the name used by the driver to the particular device name.
server command is used to configure a reference clock. Only the
prefer options are supported for reference clocks, as described on the Reference Clock Commands page. The
prefer option is discussed on the Mitigation Rules and the
prefer Keyword page. Some of these options have meaning only for selected clock drivers.
fudge command can be used to provide additional information for individual drivers and normally follows immediately after the
server command. The reference clock stratum is by default 0, so that the server stratum appears to clients as 1. The
stratum option can be used to set the stratum to any value in the range 0 through 15. The
refid option can be used to change the reference identifier, as might in the case when the driver is disciplined by a pulse-per-second (PPS) source. The device-dependent
flag options can provide additional driver customization.
The Audio Drivers page describes three software drivers that process audio signals from an audio codec or sound card. One is for the NIST time and frequency stations WWV and WWVH, another for the Canadian time and frequency station CHU. These require an external shortwave radio and antenna. A third is for the generic IRIG signal produced by some timing devices. Currently, these are supported in FreeBSD, Solaris and SunOS and likely in other systems as well.
The Undisciplined Local Clock driver can simulate a reference clock when no external synchronization sources are available. If a server with this driver is connected directly or indirectly to the public Internet, there is some danger that it can destabilize other clients. It is not recommended that the local clock driver be used in this way, as the orphan mode described on the Association Management page provides a generic backup capability.
The local clock driver can also be used when an external synchronization source such as the IEEE 1588 Precision Time Protocol or NIST Lockclock directly synchronizes the computer time. Further information is on the External Clock Discipline and the Local Clock Driver page.
Several drivers make use of the pulse-per-second (PPS) signal discipline, which is part of the generic driver interface, so require no specific configuration. For those drivers that do not use this interface, the PPS Clock Discipline driver can provide this function. It normally works in conjunction with the reference clock that produces the timecode signal, but can work with another driver or remote server. When PPS kernel features are present, the driver can redirect the PPS signal to the kernel.
Some drivers depending on longwave or shortwave radio services need to know the radio propagation time from the transmitter to the receiver. This must be calculated for each specific receiver location and requires the geographic coordinates of both the transmitter and receiver. The transmitter coordinates for various radio services are given in the Time and Frequency Standard Station Information page. Receiver coordinates can be obtained locally or from Google Earth. The actual calculations are beyond the scope of this document.
Depending on interface type, port speed, etc., a reference clock can have a small residual offset relative to another. To reduce the effects of jitter when switching from one driver to another, it is useful to calibrate the drivers to a common ensemble offset. The
enable calibrate configuration command described on the Miscellaneous Options page activates a special feature which automatically calculates a correction factor for each driver relative to an association designated the prefer peer.
Following is a list showing the type and title of each driver currently implemented. The compile-time identifier for each is shown in parentheses. Click on a selected type for specific description and configuration documentation, including the clock address, reference ID, driver ID, device name and serial line speed. For those drivers without specific documentation, please contact the author listed in the Copyright Notice page.
Was this page helpful?
Glad to hear it!
Sorry to hear that.