Information on Reference Clock Drivers Revised 5 August 1994 Support for most of the commonly available radio clocks is included in the default configuration of xntpd. Individual clocks can be activated by configuration file commands, specifically the server and fudge commands described in the xntpd.8 man page. This file contains information useful in configuring and operating these clocks. Note that the man pages and documentation files mentioned in this note can be found in the ./doc directory of the xntp3 distribution. Radio clocks by convention have addresses in the form 127.127.t.u, where "t" is the clock type and "u" is a unit number in the range 0-3 used to distinguish multiple instances of clocks of the same type. Most of these clocks require support in the form of a serial port or special bus peripheral. The particular device is normally specified by adding a soft link /dev/device%d to the particular hardware device involved. The name "device" is compiled in the driver according to the table below. The table shows the type number, device name, short description used in some displays, and long description used in other displays. Type Device Name Description ------------------------------------------------------- 1 (none) LOCAL Undisciplined Local Clock 2 trak GPS_TRAK TRAK 8820 GPS Receiver 3 pst WWV_PST PSTI/Traconex WWV/WWVH Receiver 4 wwvb WWVB_SPEC Spectracom WWVB Receiver 5 goes GPS_GOES_TRUE TrueTime GPS/GOES Receivers 6 irig IRIG_AUDIO IRIG Audio Decoder 7 chu CHU Scratchbuilt CHU Receiver 8 refclock- GENERIC Generic Reference Clock Driver 9 gps GPS_MX4200 Magnavox MX4200 GPS Receiver 10 gps GPS_AS2201 Austron 2201A GPS Receiver 11 omega OMEGA_TRUE TrueTime OM-DC OMEGA Receiver 12 tpro IRIG_TPRO KSI/Odetics TPRO/S IRIG Interface 13 leitch ATOM_LEITCH Leitch CSD 5300 Master Clock Controller 14 ees MSF_EES EES M201 MSF Receiver 15 gpstm GPS_TRUE TrueTime GPS/TM-TMD Receiver 16 * GPS_BANC Bancomm GPS/IRIG Receiver 17 datum GPS_DATUM Datum Precision Time System 18 acts NIST_ACTS NIST Automated Computer Time Service 19 heath WWV_HEATH Heath WWV/WWVH Receiver 20 nmea GPS_NMEA Generic NMEA GPS Receiver 21 * GPS_MOTO Motorola Six Gun GPS Receiver 22 pps ATOM_PPS PPS Clock Discipline * Not yet available. A radio clock is specified in the configuration using the server command server 127.127.t.u [ prefer ] [ mode m ] where t is the type number above and u can be in the range 0-3, conventionally 1. Ordinarily, this is the only command necessary to configure a radio clock. The optional prefer keyword can be used to modify the clock selection algorithm as described in Appendix B. For those clock drivers that support multiple modes of operation, the optional mode parameter selects which one. This parameter affects the operation of each driver as described in Appendix A. In rare cases a fudge command is necessary to specify additional details. This command has the following syntax fudge 127.127.t.u [stratum s] [refid r] [time1 t1] [time2 t2] [flags] and must follow the corresponding server command in the configuration file. The optional fields following the clock address are interpreted as follows: stratum s The s, a decimal number in the range 0-15, overrides the default stratum assigned by the driver. refid r The r, a 4-character, null-terminated ASCII string, overrides the reference identifier assigned by the driver. time1 t1 The t1, a fixed-point decimal number in seconds, specifies a constant to be added to the time offset produced by the driver. This provides a way to correct a systematic error or bias on the part of the particular clock. time2 t2 The t2, a fixed-point decimal number, is interpreted in a driver-dependent way. See the descriptions of specific clock drivers in Appendix A. There are four optional flags named flag1, flag2, flag3 and flag4. A flag is specified in the form , where is one of the flag names and is either 0 or 1, as appropriate. Two of the flags are generic and are interpreted by all applicable drivers, and two are driver dependent. The generic ones are as follows: flag4 This flag is used to enable detailed status monitoring and event recording. The data collected are written to the clockstats file maintained by the filegen utility (See the xntpd.8 man page). This file is normally processed by a cron job run once per day to produce summary statistics and performance data. The ./scripts/stats directory contains a number of shell and awk scripts for this, as well as S- language programs that produce PostScript plots of performance data. flag3 This flag is used with Sun SPARCstation baseboard serial ports to assign the ppsclock streams driver for a 1-pps signal produced by some radio clocks and timekeeping devices. See the dscription of the PPS Clock Discipline Driver (type 22) in Appendix A for further information. Note that the fudge factors above can be changed at run time using the xntpdc program (see the xntpdc.8 man page). This program does not have to be run on the server machine itself, since it communicates with the xntpd daemon using cryptographically authenticated messages. The PPS Signal Some radio clocks and related timekeeping gear have a pulse-per-second (PPS) signal that can be used to discipline the local clock oscillator to a high degree of precision, typically to the order less than 50 us in time and 0.1 ppm in frequency. The PPS signal can be connected in either of two ways, either via the data leads of a serial port or via the modem control leads. Either way requires conversion of the PPS signal, usually at TTL levels, to RS232 levels, which can be done using a circuit such as described in the ./gadget directory of the xntp3 distribution. The data leads interface requires regenerating the PPS pulse and converting to RS232 signal levels, so that the pulse looks like a legitimate ASCII character. The tty_clk module in the ./kernel directory inserts a timestamp following this character in the input data stream. The driver uses this timestamp to determine the time of arrival of the PPS pulse to within 26 us at 38.4 kbps while eliminating error due to operating system queues and service times. In order to use the tty_clk module, the xntp3 distribution must be compiled with CLK defined. The modem control leads interface requires converting to RS232 levels and connecting to the carrier detect (CD) lead of a serial port. The ppsclock streams module in the ./ppsclock directory is used to capture a timestamp upon transition of the PPS signal. The driver reads the latest timestamp with a designated ioctl() system call to determine the time of arrival of the PPS pulse to within a few tens of microseconds. In order to use the ppsclock module, the xntp3 distribution must be compiled with PPS defined. Both of these mechanisms are supported by the ATOM_PPS reference clock driver described in Appendix A. This driver is ordinarily used in conjunction with another clock driver that supports the radio clock that produces the PPS pulse. This driver furnishes the coarse timecode used to disambiguate the seconds numbering of the PPS pulse itself. The NTP daemon mitigates between the radio clock driver and ATOM_PPS driver as described in Appendix B in order to provide the most accurate time, while respecting the various types of equipment failures that could happen. For the utmost time quality, a number of Unix system kernel modifications can be made as described in the README.magic and README.kernel files. Specifically, the ppsclock module can be used to interface the PPS signal directly to the kernel for use as discipline sources for both time and frequency. These sources can be separately enabled and monitored using the ntp_adjtime() system call described in README.kernel and the ./include/sys/timex.h header file in the xntp3 distribution. In order to use the kernel PPS signal, the xntp3 distribution must be compiled with KERNEL_PLL defined. In some configurations may have multiple radio clocks, each with PPS outputs, as well as a kernel modified to use the PPS signal. In order to provide the highest degree of redundancy and survivability, the kernel PPS discipline, tty_clk module and ppsclock module may all be in use at the same time, each backing up the other. The sometimes complicated mitigation rules are described in Appendix B. Debugging Hints The ntpq and xntpdc utility programs can be used to debug reference clocks, either on the server itself or from another machine elsewhere in the network. The server is compiled, installed and started using the command-line switches described in the xntpd.8 man page. The first thing to look for are error messages on the system log. If none occur, the daemon has started, opened the devices specified and waiting for peers and radios to come up. The next step is to be sure the RS232 messages, if used, are getting to and from the clock. The most reliable way to do this is with an RS232 tester and to look for data flashes as the driver polls the clock and/or as data arrive from the clock. Our experience is that the overwhelming fraction of problems occurring during installation are due to problems such as miswired connectors or improperly configured radio clocks at this stage. If RS232 messages are getting to and from the clock, the variables of interest can be inspected using the ntpq program and various commands described in the ntpq.8 man page. First, use the pe and as commands to display a pair of billboards showing the peer configuration and association IDs for all peers, including the radio clock peers. The assigned clock address should appear in the pe billboard and the association ID for it at the same relative line position in the as billboard. If things are operating correctly, after a minute or two samples should show up in the pe display line for the clock. Additional information is available with the rv and clockvar commands, which take as argument the association ID shown in the as billboard. The rv command with no argument shows the system variables, while the rv command with argument shows the peer variables for the clock, as well as any other peers of interest. The clockvar command with argument shows the peer variables specific to reference clock peers, including the clock status, device name, last received timecode (if relevant), and various event counters. In addition, a subset of the fudge parameters is included. The xntpdc utility program can be used for detailed inspection of the clock driver status. The most useful are the clockstat and clkbug commands described in the xntpdc.8 man page. While these commands permit getting quite personal with the particular driver involved, their use is seldom necessary, unless an implementation bug shows up. Most drivers write a message to the clockstats file as each timecode or surrogate is received from the radio clock. By convention, this is the last ASCII timecode (or ASCII gloss of a binary-coded one) received from the radio. This file is managed by the filegen facility described in the xntpd.8 man page and requires specific commands in the configuration file. This forms a highly useful record to discover anomalies during regular operation of the clock. The scripts included in the ./scripts/stats directory can be run from a cron job to collect and summarize these data on a daily or weekly basis. The summary files have proven invaluable to detect infrequent misbehavior due to clock implementation bugs in some radios. Appendix A. Individual Driver Descriptions Following are detailed descriptions of the clock drivers, together with configuration data useful for special circumstances. Type 1: Undisciplined Local Clock This is a hack to allow a machine to use its own system clock as a reference clock, i.e., to free-run using no outside clock discipline source. This is useful if you want to use NTP in an isolated environment with no radio clock or NIST modem available. Pick a machine that you figure has a good clock oscillator and configure it with this driver. Set the clock using the best means available, like eyeball-and-wristwatch. Then, point all the other machines at this one or use broadcast (not multicast) mode to distribute time. Another application for this driver is if you want to use a particular server's clock as the clock of last resort when all other normal synchronization sources have gone away. This is especially useful if that server has an ovenized oscillator. For this you would configure this driver at a higher stratum (say 3 or 4) to prevent the server's stratum from falling below that. A third application for this driver is when an external discipline source is available, such as the NIST "lockclock" program, which synchronizes the local clock via a telephone modem and the NIST Automated Computer Time Service (ACTS), or the Digital Time Synchronization Service (DTSS), which runs on DCE machines. In this case the stratum should be set at zero, indicating a bona fide stratum-1 source. Exercise some caution with this, since there is no easy way to telegraph via NTP that something might be wrong in the discipline source itself. In the case of DTSS, the local clock can have a rather large jitter, depending on the interval between corrections and the intrinsic frequency error of the clock oscillator. In extreme cases, this can cause clients to exceed the 128-ms slew window and drop off the NTP subnet. In the default mode the behavior of the clock selection algorithm is modified when this driver is in use. The algorithm is designed so that this driver will never be selected unless no other discipline source is available. This can be overridden with the prefer keyword of the server configuration command, in which case only this driver will be selected for synchronization and all other discipline sources will be ignored. This behavior is intended for use when an external discipline source controls the system clock. Fudge Factors The stratum for this driver LCLSTRATUM is set at 3 by default, but can be changed by the fudge command and/or the xntpdc utility. The reference ID is "LCL" by default, but can be changed using the same mechanisms. *NEVER* configure this driver to operate at a stratum which might possibly disrupt a client with access to a bona fide primary server, unless the local clock oscillator is reliably disciplined by another source. *NEVER NEVER* configure a server which might devolve to an undisciplined local clock to use multicast mode. This driver provides a mechanism to trim the local clock in both time and frequency, as well as a way to manipulate the leap bits. The fudge time1 parameter adjusts the time, in seconds, and the fudge time2 parameter adjusts the frequency, in ppm. Both parameters are additive; that is, they add increments in time or frequency to the present values. (Note: The frequency cannot be changed when the kernel modifications are in use - see the README.kern file). The fudge flag1 and fudge flag2 bits set the corresponding leap bits; for example, setting flag1 causes a leap second to be added at the end of the UTC day. These bits are not reset automatically when the leap takes place; they must be turned off manually after the leap event. Type 2: TRAK 8820 GPS Receiver This driver supports the TRAK 8820 GPS Station Clock. The claimed accuracy at the 1-pps output is 200-300 ns relative to the broadcast signal; however, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system. For best accuracy, this radio requires the LDISC_ACTS line discipline, which captures a timestamp at the '*' on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the \r ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines. Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning. No provisions are included in this preliminary version of the driver to read and record detailed internal radio status. In operation, this driver sends a RQTS\r request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second: *RQTS U,ddd:hh:mm:ss.0,q on-time = '*' ddd = day of year hh:mm:ss = hours, minutes, seconds q = quality indicator (phase error), 0-6: 0 > 20 us 6 > 10 us 5 > 1 us 4 > 100 ns 3 > 10 ns 2 < 10 ns The alarm condition is indicated by '0' at Q, which means the radio has a phase error than 20 usec relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarming. The continuous time mode is disabled using the RQTX request, following which the radio sends a RQTX DONE response. In the normal mode, other control and status requests are effective, including the leap-second status request RQLS. The radio responds with RQLS yy,mm,dd, where yy,mm,dd are the year, month and day. Presumably, this gives the epoch of the next leap second, RQLS 00,00,00 if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver. Fudge Factors There are no special fudge factors other than the generic. Type 3: PSTI/Traconex WWV/WWVH Receiver This driver supports the PSTI 1010 and Traconex 1020 WWV/WWVH Receivers. No specific claim of accuracy is made for these receiver, but actual experience suggests that 10 ms would be a conservative assumption. The DIPswitches should be set for 9600 bps line speed, 24-hour day- of-year format and UTC time zone. Automatic correction for DST should be disabled. It is very important that the year be set correctly in the DIPswitches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year. The propagation delay DIPswitches should be set according to the distance from the transmitter for both WWV and WWVH, as described in the instructions. While the delay can be set only to within 11 ms, the fudge time1 parameter can be used for vernier corrections. Using the poll sequence QTQDQM, the response timecode is in three sections totalling 50 ASCII printing characters, as concatenated by the driver, in the following format: ahh:mm:ss.fffs yy/dd/mm/ddd frdzycchhSSFTttttuuxx on-time = first hh:mm:ss.fff = hours, minutes, seconds, milliseconds a = AM/PM indicator (' ' for 24-hour mode) yy = year (from DIPswitches) dd/mm/ddd = day of month, month, day of year s = daylight-saving indicator (' ' for 24-hour mode) f = frequency enable (O = all frequencies enabled) r = baud rate (3 = 1200, 6 = 9600) d = features indicator (@ = month/day display enabled) z = time zone (0 = UTC) y = year (5 = 91) cc = WWV propagation delay (52 = 22 ms) hh = WWVH propagation delay (81 = 33 ms) SS = status (80 or 82 = operating correctly) F = current receive frequency (4 = 15 MHz) T = transmitter (C = WWV, H = WWVH) tttt = time since last update (0000 = minutes) uu = flush character (03 = ^c) xx = 94 (unknown) The alarm condition is indicated by other than '8' at A, which occurs during initial synchronization and when received signal is lost for an extended period; unlock condition is indicated by other than "0000" in the tttt subfield at Q. Fudge Factors There are no special fudge factors other than the generic. Type 4: Spectracom WWVB Receiver This driver supports the Spectracom Model 8170 and Netclock/2 WWVB Synchronized Clock. This clock has proven a reliable source of time, except in some cases of high ambient conductive RF interference. The claimed accuracy of the clock is 100 usec relative to the broadcast signal; however, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system. The DIPswitches on this clock should be set to 24-hour display, AUTO DST off, time zone 0 (UTC), data format 0 or 2 (see below) and baud rate 9600. If this clock is to used as the source for the IRIG Audio Decoder (refclock_irig.c in this distribution), set the DIPswitches for AM IRIG output and IRIG format 1 (IRIG B with signature control). There are two timecode formats used by these clocks. Format 0, which is available with both the Netclock/2 and 8170, and format 2, which is available only with the Netclock/2 and specially modified 8170. Format 0 (22 ASCII printing characters): i ddd hh:mm:ss TZ=zz on-time = first hh:mm:ss = hours, minutes, seconds i = synchronization flag (' ' = in synch, '?' = out synch) The alarm condition is indicated by other than ' ' at A, which occurs during initial synchronization and when received signal is lost for about ten hours. Format 2 (24 ASCII printing characters): iqyy ddd hh:mm:ss.fff ld on-time = i = synchronization flag (' ' = in synch, '?' = out synch) q = quality indicator (' ' = locked, 'A'...'D' = unlocked) yy = year (as broadcast) ddd = day of year hh:mm:ss.fff = hours, minutes, seconds, milliseconds The alarm condition is indicated by other than ' ' at A, which occurs during initial synchronization and when received signal is lost for about ten hours. The unlock condition is indicated by other than ' ' at Q. The Q is normally ' ' when the time error is less than 1 ms and a character in the set 'A'...'D' when the time error is less than 10, 100, 500 and greater than 500 ms respectively. The L is normally ' ', but is set to 'L' early in the month of an upcoming UTC leap second and reset to ' ' on the first day of the following month. The D is set to 'S' for standard time 'I' on the day preceding a switch to daylight time, 'D' for daylight time and 'O' on the day preceding a switch to standard time. The start bit of the first is synchronized to the indicated time as returned. This driver does not need to be told which format is in use - it figures out which one from the length of the message. A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself, which is a known problem with the older radios. Fudge Factors This driver can retrieve a table of quality data maintained internally by the Netclock/2 receiver. If flag4 of the fudge configuration command is set to 1, the driver will retrieve this table and write it to the clockstats file on when the first timecode message of a new day is received. Type 5: TrueTime GPS/GOES Receivers This driver supports at least two models of Kinemetrics/TrueTime Timing Receivers, the 468-DC MK III GOES Synchronized Clock and GPS-DC MK III GPS Synchronized Clock and very likely others in the same model family that use the same timecode formats. The clocks are connected via a serial port. Up to four units, with unit numbers in the range 0 through 3, can be configured. The driver assumes the serial port device name is /dev/goes%d (i.e., unit 1 at 127.127.5.1 opens the clock at /dev/goes1) and that the clock is configured for 9600-baud operation. Type 6: IRIG Audio Decoder This driver supports the Inter-Range Instrumentation Group standard time-distribution signal IRIG-B using the audio codec native to the Sun SPARCstation. This signal is generated by several radio clocks, including those made by Austron, TrueTime, Odetics and Spectracom, among others, although it is generally an add-on option. The signal is connected via an attenuator box and cable to the audio codec input on a Sun SPARCstation and requires a specially modified kernel audio driver. Details are in the README.irig file. Timing jitter using the decoder and a Sun IPC is in the order of a few microseconds, although the overall timing accuracy is limited by the wander of the CPU oscillator used for timing purposes to a few hundred microseconds. These figures are comparable with what can be achieved using the 1-pps discipline as describe elsewhere in this note. Fudge Factors There are no special fudge factors other than the generic. The flag3 and flag4 flags are not applicable to this driver. Type 7: Scratchbuilt CHU Receiver This driver supports a shortwave receiver and special modem circuitry described in the ./gadget directory of the xntp3 distribution. It requires the chu-clk line discipline or chu_clk STREAMS module described in the ./kernel directory of that distribution. It is connected via a serial port operating at 300 baud. Unlike the NIST time services, whose timecode requires quite specialized hardware to interpret, the CHU timecode can be received directly via a serial port after demodulation. While there are currently no known commercial CHU receivers, the hardware required to receive the CHU timecode is fairly simple to build. While it is possible to configure several CHU units simultaneously, this is in general not useful. Fudge Factors The time1 option can be used to set the CHU propagation delay, compensate for inherent latencies in the serial port hardware and operating system. The default value is 0.0025 seconds, which is about right for Toronto. Values for other locations can be calculated using the propdelay program in the util directory of the xntp3 distribution or equivalent means. The time2 option can be used to compensate for inherent latencies in the serial port hardware and operating system. The value, which defaults to zero, is in addition to the propagation delay provided by the time1 option. The default value is 0.0002 seconds, which is about right for typical telephone modem chips. The flag1 option can be used to modify the averaging algorithm used to smooth the clock indications. Ordinarily, the algorithm picks the median of a set of samples, which is appropriate under conditions of poor to fair radio propagation conditions. If the clock is located relatively close to the WWV or WWVH transmitters, setting this flag will cause the algorithm to average the set of samples, which can reduce the residual jitter and improve accuracy. Type 8: Generic Reference Clock Driver The timecode of these receivers is sampled via a STREAMS module in the kernel (The STREAMS module has been designed for use with SUN Systems under SunOS 4.1.x. It can be linked directly into the kernel or loaded via the loadable driver mechanism). This STREAMS module can be adapted to be able to convert different time code formats. If the daemon is compiled without the STREAM definition synchronization will work without the Sun streams module, though accuracy is significantly degraded. The actual receiver status is mapped into various synchronization states generally used by receivers. The STREAMS module is configured to interpret the time codes of DCF U/A 31, PZF535, GPS166, Trimble SV6 GPS, ELV DCF7000, Schmid and low cost receivers (see list below). The reference clock support in xntp contains the necessary configuration tables for those receivers. In addition to supporting up to 32 different clock types and 4 devices, the generation a a PPS signal is also provided as an configuration option. The PPS configuration option uses the receiver generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization. CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way xntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined. The use of the PPS option requires receivers with an accuracy of better than 1ms. Fudge factors Only two fudge factors are utilized. The time1 fudge factor defines the phase offset of the synchronization character to the actual time. On the availability of PPS information the time2 fudge factor defines the skew between the PPS time stamp and the receiver timestamp of the PPS signal. This parameter is usually zero, as usually the PPS signal is believed in time and OS delays should be corrected in the machine specific section of the kernel driver. time2 needs only be set when the actual PPS signal is delayed for some reason. The flag0 enables input filtering. This a median filter with continuous sampling. The flag1 selects averaging of the samples remaining after the filtering. Leap secondhandling is controlled with the flag2. When set a leap second will be deleted on receipt of a leap second indication from the receiver. Otherwise the leap second will be added, (which is the default). ntpq (8) timecode variable The ntpq program can read clock variables command list several variables. These hold the following information: refclock_time is the local time with the offset to UTC (format HHMM). The currently active receiver flags are listed in refclock_status. Additional feature flags of the receiver are optionally listed in parentheses. The actual time code is listed in timecode. A qualification of the decoded time code format is following in refclock_format. The last piece of information is the overall running time and the accumulated times for the clock event states in refclock_states. When PPS information is present additional variable are available. refclock_ppstime lists then the PPS timestamp and refclock_ppsskew lists the difference between RS232 derived timestamp and the PPS timestamp. Unit encoding The unit field encodes the device, clock type and the PPS generation option. There are 4 possible units, which are encoded in the lower two bits of the field. The devices are named /dev/refclock-0 through /dev/refclock-3. Bits 2 thru 6 encode the clock type. The fudge factors of the clock type are taken from a table clockinfo in refclock_parse.c. The generation of PPS information for disciplining the local NTP clock is encoded in bit 7 of . Currently, nine clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported. 127.127.8.0-3 16 Meinberg PZF535 receiver (FM demodulation/TCXO / 50us) 127.127.8.4-7 16 Meinberg PZF535 receiver (FM demodulation/OCXO / 50us) 127.127.8.8-11 16 Meinberg DCF U/A 31 receiver (AM demodulation / 4ms) 127.127.8.12-15 16 ELV DCF7000 (sloppy AM demodulation / 50ms) 127.127.8.16-19 16 Walter Schmid DCF receiver Kit (AM demodulation / 1ms) 127.127.8.20-23 16 RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms) 127.127.8.24-27 16 RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms) 127.127.8.28-31 16 Meinberg GPS166 receiver (GPS / <<1us) 127.127.8.32-35 16 Trimble SV6 GPS receiver (GPS / <<1us) 127.127.8.40-43 16 RAW DCF77 100/200ms pulses (Boeder DCF77 receiver / 5ms) The reference clock support carefully monitors the state transitions of the receiver. All state changes and exceptional events such as loss of time code transmission are logged via the syslog facility. Every hour a summary of the accumulated times for the clock states is listed via syslog. PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronizations, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus a function of clock type. This is one of the parameters in the clockinfo field of the reference clock implementation. This parameter cannot be configured by xntpdc. In addition to the PPS loopfilter control a true PPS hardware signal can be applied on Sun Sparc stations via the CPU serial ports on the CD pin. This signal is automatically detected and will be used for offset calculation. The input signal must be the time mark for the following time code. (The edge sensitivity can be selected - look into the appropriate kernel/parsestreams.c for details). Meinberg receivers can be connected by feeding the PPS pulse of the receiver via a 1488 level converter to Pin 8 (CD) of a Sun serial zs\-port. There exists a special firmware release for the PZF535 Meinberg receivers. This release (PZFUERL 4.6 (or higher - The UERL is important)) is absolutely recommended for XNTP use, as it provides LEAP warning, time code time zone information and alternate antenna indication. Please check with Meinberg for this firmware release. For the Meinberg GPS166 receiver is also a special firmware release available (Uni-Erlangen). This release must be used for proper operation. The raw DCF77 pulses can be fed via a level converter directly into Pin 3 (Rx) of the Sun. The telegrams will be decoded an used for synchronization. AM DCF77 receivers are running as low as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) to 10ms (cheap). Upon bad signal reception of DCF77 synchronizations will cease as no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. For transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available. Type 9: Magnavox MX4200 GPS Receiver This driver supports the Magnavox MX4200 Navigation Receiver adapted to precision timing applications. This requires an interface box described in the ./ppsclock directory of the xntp3 distribution. It is connected via a serial port and requires the ppsclock STREAMS module described in the same directory. Fudge Factors There are no special fudge factors other than the generic. Type 10: Austron 2201A GPS Receiver This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock and Timing Receiver connected via a serial port. It supports several special features of the clock, including the Input Buffer Module, Output Buffer Module, IRIG-B Interface Module and LORAN Assist Module. It requires the RS232 Serial Interface module for communication with the driver. This receiver is capable of a comprehensive and large volume of statistics and operational data. The specific data collection commands and attributes are embedded in the driver source code; however, the collection process can be enabled or disabled using the flag4 flag. If set, collection is enabled; if not, which is the default, it is disabled. A comprehensive suite of data reduction and summary scripts is in the ./scripts/stats directory of the xntp3 distribution. To achieve the high accuracy this device provides, it is necessary to use the ppsclock feature of the xntp3 program distribution or, alternatively, to install the kernel modifications described in the README.kern. The clock can be wired to provide time to a single CPU or bussed in parallel to several CPUs, with one CPU controlling the receiver and the others just listening. Fair accuracy can be achieved in the single-CPU configuration without use of the 1-pps signal, but in multiple CPU configurations accuracy is severely degraded without it. Fudge Factors There are no special fudge factors other than the generic. Type 11: TrueTime OM-DC OMEGA Receiver This driver supports the Kinemetrics/TrueTime OMEGA-DC OMEGA Synchronized Clock connected via a serial port. This clock is sufficiently different from other Kinemetrics/TrueTime models that a separate driver is required. Up to four units, with unit numbers in the range 0 through 3, can be configured. The driver assumes the serial port device name is /dev/omega%d (i.e., unit 1 at 127.127.11.1 opens the clock at /dev/omega1) and that the clock is configured for 9600-baud operation. Fudge Factors There are no special fudge factors other than the generic. Type 12: KSI/Odetics TPRO/S IRIG Interface This driver supports the KSI/Odetics TPRO and TPRO-SAT IRIG-B Decoder, which is a module connected directly to the SBus of a Sun workstation. The module works with the IRIG-B signal generated by several radio clocks, including those made by Austron, TrueTime, Odetics and Spectracom, among others, although it is generally an add-on option. In the case of the TPRO-SAT, the module is an integral part of a GPS receiver, which serves as the primary timing source. Using the TPRO interface as a NTP reference clock provides precision time only to xntpd and its clients. With suitable kernel modifications, it is possible to use the TPRO as the CPU system clock, avoiding errors introduced by the CPU clock oscillator wander. See the README.kernel and kern.c files for further details. Type 13: Leitch CSD 5300 Master Clock Controller Information not available. Type 14: EES M201 MSF Receiver This driver supports the EES M201 MSF receiver connected to a Sun SPARCstation running SunOS 4.x with the "ppsclock" STREAMS module. Fudge Factors If flag1 is set, then the system clock is assumed to be sloppy (e.g. Sun4 with 20ms clock), so samples are averaged. If flag2 is set, then leaphold is set. If flag3 is set, then the sample information is dumped. If flag4 is set, then the input data is smoothed, and all data points are used. Type 15: TrueTime GPS/TM-TMD Receiver Information not available. Type 16: Bancomm GPS/IRIG Receiver Information not available. Type 17: Datum Precision Time System Information not available. Type 18: NIST Automated Computer Time Service This driver supports the NIST Automated Computer Time Service (ACTS). It periodically dials a prespecified telephone number, receives the NIST timecode data and calculates the local clock correction. It designed primarily for use when neither a radio clock nor connectivity to Internet time servers is available. For the best accuracy, the individual telephone line/modem delay needs to be calibrated using outside sources. The ACTS is located at NIST Boulder, CO, telephone 303 494 4774. A toll call from Newark, DE, costs between three and four cents, although it is not clear what carrier and time of day discounts apply. The modem dial string will differ depending on local telephone configuration, etc., and is specified by the phone command in the configuration file. The argument to this command is an AT command for a Hayes compatible modem. The accuracy produced by this driver should be in the range of a millisecond or two, but may need correction due to the delay characteristics of the individual modem involved. For undetermined reasons, some modems work with the ACTS echo-delay measurement scheme and some don't. This driver tries to do the best it can with what it gets. Initial experiments with a Practical Peripherals 9600SA modem here in Delaware suggest an accuracy of a millisecond or two can be achieved without the scheme by using a fudge time1 value of 65.0 ms. In either case, the dispersion for a single call involving ten samples is about 1.3 ms. The driver can operate in either of three modes, as determined by the mode parameter in the server configuration command. In mode 0 (automatic) the driver operates continuously at intervals depending on the prediction error, as measured by the driver, usually in the order of several hours. In mode 1 (backup) the driver is enabled in automatic mode only when no other source of synchronization is available and when more than MAXOUTAGE (3600 s) have elapsed since last synchronized by other sources. In mode 2 (manual) the driver operates only when enabled using a fudge flags switch, as described below. For reliable call management, this driver requires a 1200-bps modem with a Hayes-compatible command set and control over the modem data terminal ready (DTR) control line. Present restrictions require the use of a POSIX-compatible programming interface, although other interfaces may work as well. The ACTS telephone number and modem setup string are hard-coded in the driver and may require changes for nonstandard modems or special circumstances. Fudge Factors Ordinarily, the propagation time correction is computed automatically by ACTS and the driver. When this is not possible or erratic due to individual modem characteristics, the fudge flag2 switch should be set to disable the ACTS echo-delay scheme. In any case, the fudge time1 parameter can be used to adjust the propagation delay as required. The ACTS call interval is determined in one of three ways. In manual mode a call is initiated by setting fudge flag1 using xntpdc, either manually or via a cron job. In automatic mode this flag is set by the peer timer, which is controlled by the sys_poll variable in response to measured errors. In backup mode the driver is ordinarily asleep, but awakes (in automatic mode) if all other synchronization sources are lost. In either automatic or backup modes, the call interval increases as long as the measured errors do not exceed the value of the fudge time2 parameter. When the fudge flag1 is set, the ACTS calling program is activated. This program dials each number listed in the phones command of the configuration file in turn. If a call attempt fails, the next number in the list is dialed. The fudge flag1 and counter are reset and the calling program terminated if (a) a valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs, or (d) fudge flag1 is reset manually using xntpdc. The NIST timecode message is transmitted at 1200 bps in the following format (see the driver source for more information): jjjjj yy-mm-dd hh:mm:ss tt l uuu mmmmm UTC(NIST) * jjjjj = modified Julian day yy-mm-dd = year, month, day hh:mm:ss = hours, minutes, seconds tt = DST indicator (see driver listing) l = leap-second warning (see driver listing) uuu = DUT1 correction (see driver listing) mmmmm = modem calibration (see driver listing) on-time = '*' The timecode message is transmitted continuously after a signon banner, which this driver ignores. The driver also ignores all but the yy-mm-dd, hh:mm:ss and on-time character '*' fields, although it checks the format of all fields of the message. A timestamp is captured at the '*' character, as required by the ACTS specification, and used as the reference time of the timecode. If a message with an on-time character of '#' is received, the driver updates the propagation delay. The driver disconnects when (a) ten valid messages have been received, (b) no message has been received for 15 s, (c) an on-time character of '#' is received. These messages are processed by a trimmed-mean filter to reduce timing noise and then by the usual NTP algorithms to develop the clock correction. The behavior of the clock selection algorithm is modified when this driver is in use. The algorithm is designed so that this driver will never be selected unless no other discipline source is available. This can be overridden with the prefer keyword of the server configuration command, in which case only this driver will be selected for synchronization and all other discipline sources will be ignored. Ordinarily, the prefer keyword would be used only in automatic mode ehen primary time is to be obtained via ACTS and backup NTP peers used only when ACTS fails. Call Management Since ACTS will be a toll call in most areas of the country, it is necessary to carefully manage the calling interval. The ACTS call program is initiated by setting fudge flag1. This flag can be set manually using xntpdc, by a cron job that calls xntpdc, or automatically by the driver itself. The fudge flag1 is reset when the program terminates after a time determination is comlete or when no more numbers remain in the alternate path list, a device fault or timeout has occured, or the fudge flag1 has been reset using xntpdc. In automatic and backup modes, the driver determines the call interval using a procedure depending on the measured prediction error and the fudge time2 parameter. If the error exceeds time2 for a number of times depending on the current interval, the interval is decreased, but not less than about 1000 s. If the error is less than time2 for some number of times, the interval is increased, but not more than about 18 h. With the default value of zero for fudge time2, the interval will increase from 1000 s to the 4000-8000-s range, in which the expected accuracy should be in the 1-2-ms range. Setting fudge time2 to a large value, like 0.1 s, may result in errors of that order, but increase the call interval to the maximum. The exact value for each configuration will depend on the modem and operating system involved, so some experimentation may be necessary. Manual call attempts can be made at any time by setting fudge flag1 using xntpdc. For example, the xntpdc command fudge 127.127.18.1 flags 1 will ask for a key identifier and password and, if authenticated by the server, will set flag1. There may be a short delay until the expiration of the current poll timeout. The flag1 can be set from a cron job in the following way. Construct a file with contents keyid 11 passwd dialup fudge 127.127.18.1 flags 1 quit Then, run the following program at specified times as required. /usr/local/bin/xntpdc hh:mm:ss.f = hours, minutes, seconds f = deciseconds ('?' when out of spec) dd/mm/yr = day, month, year The alarm condition is indicated by '?', rather than a digit, at A. Note that 0?:??:??.? is displayed before synchronization is first established and hh:mm:ss.? once synchronization is established and then lost again for about a day. Fudge Factors There are no special fudge factors other than the generic. A fudge time1 value of .07 s appears to center the clock offset residuals. Type 20: Generic NMEA GPS Receiver Information not available. Type 21: Motorola Six Gun GPS Receiver Information not available. Type 22: PPS Clock Discipline This driver furnishes an interface for pulse-per-second (PPS) signals produced by a cesium clock, timing receiver or related equipment. It can be used to remove accumulated jitter and retime a secondary server when synchronized to a primary server over a congested, wide-area network and before redistributing the time to local clients. Note that this driver does not control the system clock if the kernel modifications described in the README.kernel file have been installed, but it can be useful as a monitoring tool. In order for this driver to work, the local clock must be set to within +-500 ms by another means, such as a radio clock or NTP itself. The 1-pps signal is connected via a serial port and gadget box consisting of a one-shot and RS232 level converter. When operated at 38.4 kbps with a SPARCstation IPC, this arrangement has a worst-case jitter less than 26 us. There are three ways in which this driver can be used. The first way uses the LDISC_PPS line discipline and works only for the baseboard serial ports of the Sun SPARCstation. The PPS signal is connected via a gadget box to the carrier detect (CD) line of a serial port and flag3 of the driver configured for that port is set. This causes the ppsclock streams module to be configured for that port and capture a timestamp at the on-time transition of the PPS signal. This driver then reads the timestamp directly by a designated ioctl() system call. This provides the most accurate time and least jitter of any other scheme. There is no need to configure a dedicated device for this purpose, which ordinarily is the device used for the associated radio clock. The second way uses the LDISC_CLKPPS line discipline and works for any architecture supporting a serial port. If after a few seconds this driver finds no ppsclock module configured, it attempts to open a serial port device /dev/pps%d, where %d is the unit number, and assign the LDISC_CLKPPS line discipline to it. If the line discipline fails, no harm is done except the accuracy is reduced somewhat. The pulse generator in the gadget box is adjusted to produce a start bit of length 26 us at 38400 bps (or 104 us at 9600 bps). Used with the LDISC_CLKPPS line discipline, this produces an ASCII DEL character ('\377') followed by a timestamp at each seconds epoch. The third way involves an auxiliary radio clock driver which calls the PPS driver with a timestamp captured by that driver. This use is documented in the source code for the driver(s) involved. Fudge Factors There are no special fudge factors other than the generic and those explicitly defined above. The fudge time1 parameter can be used to compensate for miscellaneous UART and OS delays. Allow about 247 us for uart delays at 38400 bps and about 1 ms for SunOS streams nonsense. Appendix B. Mitigation Rules In order to provide robust backup sources, stratum-1 peers are usually operated in a diversity configuration, in which the local server operates with a number of remote peers in addition with one or more radio clocks operating also as local peers. In these configurations the suite of algorithms used in NTP to refine the data from each peer separately and to select and weight the data from a number of peers can be used with the entire ensemble of remote peers and local radios. However, Because of small but significant systematic time offsets between the peers, it is in general not possible to achieve the lowest jitter and highest stability in these configurations. In addition, there are a number of special configurations involving auxiliary radio clock outputs, telephone backup services and other special cases, so that a set of mitigation rules becomes necessary. The mitigation rules are based on a set of special characteristics of the various reference clock drivers configured on the server. For instance, it is possible to designate a peer as "preferred," in which case, all other things being equal, this peer will be selected for synchronization over all other eligible candidates in the clock selection procedures. The precise characterization of the prefer peer is described below. In addition, when a pulse-per-second (PPS) signal is connected via the PPS Clock Discipline Driver (type 22), the corresponding peer is called the PPS peer. The manner in which this peer operates is described below. When the Undisciplined Local Clock Driver (type 1) is configured in the server, this becomes the local-clock peer. When the Automated Computer Time Service Driver (type 18) is configured in the server, this becomes the ACTS peer. Both the local-clock and ACTS peers operates in the manner described in Appendix A. Finally, where support is available, the PPS signal may be processed directly by the kernel. In the following this will be called the kernel discipline. The mitigation rules apply in the clock selection procedures following the sanity checks, intersection algorithm and clustering algorithm. The survivors at this point represent the subset of all peers which can provide the most accurate, stable time. In the general case, with no designated prefer peer, PPS peer or local-clock peer, the mitigation rules require all survivors be averaged according to a weight depending on the reciprocal of the dispersion, as provided in the NTP specification. The mitigation rules establish the choice of system peer, which determine the stratum, reference identifier and several other system variables which are visible to clients of the local server. In addition, they establish which source or combination of sources control the local clock. In detail, these rules operate as follows: 1. If there is a prefer peer and it is the local-clock peer or the ACTS peer; or, if there is a prefer peer and the kernel discipline is active, choose the prefer peer as the system peer. 2. If the above is not the case and there is a PPS peer, then choose it as the system peer and its offset as the system clock offset. 3. If the above is not the case and there is a prefer peer (not the local-clock or ACTS peer in this case), then choose it as the system peer and its offset as the system clock offset. 4. If the above is not the case and the peer previously chosen as the system peer is in the surviving population, then choose it as the system peer and average its offset along with the other survivors to determine the system clock offset. This behavior is designed to avoid excess jitter due to "clockhopping," when switching the system peer would not materially improve the time accuracy. 5. If the above is not the case, then choose the first candidate in the list of survivors ranked in order of synchronization distance and average its offset along with the other survivors to determine the system clock offset. This is the default case and the only case considered in the current NTP specification. The specific interpretation of the prefer peer and PPS peer require some explanation, which is given in following sections. B.1. Using the prefer Keyword For the reasons stated previously, a scheme has been implemented in NTP to provide an intelligent mitigation between various classes of peers, one designed to provide the best quality time without compromising the normal operation of the NTP algorithms. This scheme in its present form is not an integral component of the NTP specification. but is likely to be included in future versions of the specification. The scheme is based on the "preferred peer," which is specified by including the prefer keyword with the associated server or peer command in the configuration file. This keyword can be used with any peer or server, but is most commonly used with a radio clock server. The prefer scheme works on the set of peers that have survived the sanity and intersection algorithms of the clock select procedures. Ordinarily, the members of this set can be considered truechimers and any one of them could in principle provide correct time; however, due to various error contributions, not all can provide the most stable time. The job of the clustering algorithm, which is invoked at this point, is to select the best subset of the survivors providing the least variance in the combined ensemble compared to the variance in each member of the subset. The detailed operation of the clustering algorithm, which are given in the specification, are not important here, other than to point out it operates in rounds, where a survivor, presumably the worst of the lot, is discarded in each round until one of several termination conditions is met. In the prefer scheme the clustering algorithm is modified so that the prefer peer is never discarded; on the contrary, its potential removal becomes a termination condition. If the original algorithm were about to toss out the prefer peer, the algorithm terminates right there. The prefer peer can still be discarded by the sanity and intersection algorithms, of course, but it will always survive the clustering algorithm. A preferred peer retains that designation as long as it survives the intersection algorithm. If for some reason the prefer peer fails to survive the intersection algorithm, either because it was declared a falseticker or became unreachable, it loses that designation and the clock selection remitigates as described above. Along with this behavior, the clock select procedures are modified so that the combining algorithm is not used when a prefer (or PPS) peer is present. Instead, the offset of the prefer (or PPS) peer is used exclusively as the synchronization source. In the usual case involving a radio clock and a flock of remote stratum-1 peers, and with the radio clock designated a prefer peer, the result is that the high quality radio time disciplines the server clock as long as the radio itself remains operational and with valid time, as determined from the remote peers, sanity algorithm and intersection algorithm. While the model does not forbid it, it does not seem useful to designate more than one peer as preferred, since the additional complexities to mitigate among them do not seem justified from on the air experience. Note that the prefer peer interacts with the PPS peer discussed in Appendix C. It also interacts with the Undisciplined Local Clock Driver (type 1), as described in Appendix A. See the main text for the mitigation rules applying to the general case. B.2. Using the Pulse-per-Second (PPS) Signal Most radio clocks are connected using a serial port operating at speeds of 9600 bps or lower. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character, like carriage-return , is limited to a millisecond at best and a few milliseconds in typical cases. However, some radios produce a precision pulse-per-second (PPS) signal which can be used to improve the accuracy in typical workstation servers to the order of a few tens of microseconds. The details of how this can be accomplished are discussed in the README.magic file; the following discusses how this signal is implemented and configured in a typical working server. First, it should be pointed out that the PPS signal is inherently ambiguous, in that it provides a precise seconds epoch, but does not provide a way to number the seconds. In principle and most commonly, another source of synchronization, either the timecode from an associated radio clock, or even a set of remote peers, is available to perform that function. In all cases a specific, configured peer or server must be designated as associated with the PPS signal. This is done by including the prefer keyword with the associated server or peer command in the configuration file. This PPS signal can be associated in this way any peer or server, but is most commonly used with the radio clock generating the PPS signal. The PPS signal is processed by a special PPS Clock Discipline Driver (type 22) described in Appendix A. That description specifies the hardware configurations in which this signal can be connected to the server. This driver replaces the former scheme based on conditional compilation and the PPS, CLK and PPSCLK compile-time switches. Regardless of method, the driver, like all other drivers, is mitigated in the manner described for the prefer peer in Appendix B. However, in the case of the PPS peer, the behavior is slightly more complex. First, in order for the PPS peer to be considered at all, its associated prefer peer must have survived the sanity and intersection algorithms and have been designated the prefer peer. This insures that the radio clock hardware is operating correctly and that, presumably, the PPS signal is operating correctly as well. Second, the absolute time offset from that peer must be less than CLOCK_MAX, the gradual-adjustment range, which is ordinarily set at 128 ms, or well within the +-0.5-s unambiguous range of the PPS signal itself. Finally, the time offsets generated by the PPS peer are propagated via the clock filter to the clock selection procedures just like any other peer. Should these pass the sanity and intersection algorithms, they will show up along with the offsets of the prefer peer itself. Note that, unlike the prefer peer, the PPS peer samples are not protected from discard by the clustering algorithm. These complicated procedures insure that the PPS offsets developed in this way are the most accurate, reliable available for synchronization. A PPS peer retains that designation as long as it survives the intersection algorithm; however, like any other clock driver, it runs a reachability algortihm on the PPS signal itself. If for some reason the signal fails or displays gross errors, the PPS peer will either become unreachable or stray out of the survivor population. In this case the clock selection remitigates as described above. Finally, the mitigation procedures described above for the prefer peer are modified so that, if the PPS peer survives the clustering algorithm, its offset is mitigated over the prefer peer offset; in other words in case of ties, the PPS offset wins. See the main text for the mitigation rules applying to the general case. B.3. Using the Kernel Discipline Code to implement the kernel discipline is a special feature that can be incorporated in the kernel of some workstations as described in the README.kernel file. The discipline provides for the control of the local clock oscillator time and/or frequency by means of an external PPS signal interfaced via a modem control lead. As the PPS signal is derived from external equipment, cables, etc., which sometimes fail, a good deal of error checking is done in the kernel to detect signal failure and excessive noise. In order to operate, the kernel discipline must be enabled and the signal must be present and within nominal jitter and wander error tolerances. In the NTP daemon the kernel is enabled only when the prefer peer is among the survivors of the clustering algorithm, as described above. Then, the PPS peer is designated the prefer peer as long as the PPS signal is present and operating within tolerances. Under these conditions the kernel disregards updates produced by the NTP daemon and uses its internal PPS source instead. The kernel maintains a watchdog timer for the PPS signal; if the signal has not been heard or is out of tolerance for more than some interval, currently two minutes, the kernel discipline is declared inoperable and operation continues as if it were not present. Appendix C. NTP Local Clock Discipline Implementation of the ACTS driver caused somewhat of a shakeup in the NTP local clock model and implementation. The model described in the specification RFC-1305 is based on a phase-lock loop (PLL) design, which is optimum or near optimum for the update intervals used for NTP peers and radio clocks, ordinarily in the range 64-1024 s. However, the ACTS driver must operate with update intervals in the range well above 1024 s, where the performance of the PLL model deteriorates. As suggested by Judah Levine of NIST and used in his "lockclock" algorithm, a hybrid frequency-lock loop (FLL) gives better performance at the longer update intervals up to a maximum depending on the acceptable error bound. In a series of experiments and simulations, it was verified that the PLL model provides better performance in the regime less than about 1000 s, while the FLL model provides better performance above that. The parameters of each model were optimized by simulation for the lowest time and frequency error using data collected on an undisciplined computer clock oscillator over a period of about two weeks. The PLL/FLL hybrid loop has been implemented in NTP, along with certain other refinements described below. While it was designed primarily with ACTS in mind, it can be used with any NTP peer or radio clock, should that prove useful. To take advantage of this feature for other than the ACTS driver, where it is automatic, note that the default minimum poll interval is 64 s and default maximum poll interval 1024 s (for the ACTS driver the default minimum is 1024 s and default maximum 16384 s). However, using the minpoll and/or maxpoll parameters of the server or peer commands in the configuration file, it is possible to set the minimum poll interval as low as 16 s and the maximum poll interval as high as 16384 s. Poll intervals less than 64 s are useful if an exceptionally quick lock is required, like in real-time or portable systems. Poll intervals above 1024 s, other than ACTS, may be useful to reduce traffic in some situations, such as when charges are made on a per-packet basis. Another modification to the stock NTP local clock discipline is to avoid errors due to old data. From a study of the stability characteristics of typical computer clock oscillators using both experiment and simulation, it was determined that data used to discipline the PLL are not generally useful if older than about 1000 s. This corresponds roughly to the knee in the Allan variance characteristic measured for a typical workstation oscillator. The NTP clock filter algorithm was modified to adjust the effective length of the shift register so that samples older than about 1000 s are not used to determine the filtered offset, delay and dispersion values. This design has the useful byproduct that the time to acquire lock when first coming up and to declare unreachability is independent of the poll interval. A problem which has recurred on every occasion a leap second has been inserted in the UTC timescale is that not all radio clocks detect and implement the leap event. As a result, some radios sail right through the leap, become confused for periods up to 15 minutes, then reacquire lock. In order to cope with this, as well as other occasions where atypically large offsets occur, the NTP clock discipline has been modified to disregard offsets over 128 ms, unless (a) first coming up, (b) first returning to service after a period when unsynchronized, or (c) an interval of about 15 minutes has elapsed since the last update less than 128 ms was received. In addition, the discipline has been modified so that, if the first offset received after coming up is less than 128 ms, the local clock is immediately reset to that offset without affecting the PLL variables. It has been the experience of some users that, when first installed in a system, the NTP clock discipline fails to reliably lock to other peers and servers as configured. The indications are that the daemon locks for some period of time, but is unable to stabilize the frequency estimate. As the result, the time offsets eventually climb above 128 ms and the discipline unlocks again. After the 15-minute timeout, the daemon locks again and the cycle repeats. The problem here is that the intrinsic frequency error of the local clock exceeds the design capture range of the PLL, 100 ppm. This particular limit was selected as a compromise between useful maximum error indications and the tolerances found in typical computer clock oscillators. In spite of the tolerance assumed in the NTP specification of 100 ppm, the NTP daemon for Unix can operate with an intrinsic frequency error of over 380 ppm, depending on the values of tick and tickadj selected by the tickadj program. However, with errors that large, the PLL will not reliably lock, and the behavior noted above can occur. Formerly, the only remedial in cases where this happens waas a somewhat painful manual process where the nominal oscillator frequency is measured by some other means, such as eyeball-and-wristwatch, and a specific drift file (ntp.drift) crafted. In order to avoid the above problem, the NTP clock discipline has been modified to measure the frequency during periods when not locked to another server or radio clock. Such periods occur when the time offset wanders through and beyond the 128-ms window as described above. When synchronization is reestablished, the working frequency used by NTP is initialized with the measured value. Since a precise frequency determination is not always possible under these chaotic conditions, it may take more than one cycle of this type to get the residual error below 100 ppm and reliable lock established. David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716 302 831 8247 fax 302 831 4316 3 July 1994