Reference Clock Support
Last update: May 4, 2022 17:05 UTC (dbea9b7d4)
Master Time Facility at the UDel Internet Research Laboratory
Table of Contents
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.
List of Reference Clock Drivers
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.
- Type 1 Undisciplined Local Clock (
- Type 2 Deprecated: was Trak 8820 GPS Receiver
- Type 3 PSTI/Traconex 1020 WWV/WWVH Receiver (
- Type 4 Spectracom WWVB/GPS Receivers (
- Type 5 TrueTime GPS/GOES/OMEGA Receivers (
- Type 6 IRIG Audio Decoder (
- Type 7 Radio CHU Audio Demodulator/Decoder (
- Type 8 Generic Reference Driver (
- Type 9 Magnavox MX4200 GPS Receiver (
- Type 10 Austron 2200A/2201A GPS Receivers (
- Type 11 Arbiter 1088A/B GPS Receiver (
- Type 12 KSI/Odetics TPRO/S IRIG Interface (
- Type 13 Leitch CSD 5300 Master Clock Controller (
- Type 14 EES M201 MSF Receiver (
- Type 15 reserved
- Type 16 Bancomm GPS/IRIG Receiver (
- Type 17 Datum Precision Time System (
- Type 18 NIST/USNO/PTB Modem Time Services (
- Type 19 Heath WWV/WWVH Receiver (
- Type 20 Generic NMEA GPS Receiver (
- Type 21 TrueTime GPS-VME Interface (
- Type 22 PPS Clock Discipline (
- Type 23 reserved
- Type 24 reserved
- Type 25 reserved
- Type 26 Hewlett Packard 58503A GPS Receiver (
- Type 27 Arcron MSF Receiver (
- Type 28 Shared Memory Driver (
- Type 29 Trimble Navigation Palisade GPS (
- Type 30 Motorola UT Oncore GPS
- Type 31 Rockwell Jupiter GPS (
- Type 32 Chrono-log K-series WWVB receiver (
- Type 33 Dumb Clock (
- Type 34 Ultralink WWVB Receivers (
- Type 35 Conrad Parallel Port Radio Clock (
- Type 36 Radio WWV/H Audio Demodulator/Decoder (
- Type 37 Forum Graphic GPS Dating station (
- Type 38 hopf GPS/DCF77 6021/komp for Serial Line (
- Type 39 hopf GPS/DCF77 6039 for PCI-Bus (
- Type 40 JJY Receivers (
- Type 41 TrueTime 560 IRIG-B Decoder
- Type 42 Zyfer GPStarplus Receiver
- Type 43 RIPE NCC interface for Trimble Palisade
- Type 44 NeoClock4X - DCF77 / TDF serial line
- Type 45 Spectracom TSYNC PCI
- Type 46 GPSD NG client protocol