freebsd/usr.sbin/xntpd/doc

                 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 <keyword> <value>, where <keyword> is one
of the flag names and <value> 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<cr><lf>

     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<cr> request,
     following which the radio sends a RQTX DONE<cr><lf> response. In
     the normal mode, other control and status requests are effective,
     including the leap-second status request RQLS<cr>. The radio
     responds with RQLS yy,mm,dd<cr><lf>, 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<cr> yy/dd/mm/ddd<cr> frdzycchhSSFTttttuuxx<cr>

     on-time = first <cr>
     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):

     <cr><lf>i  ddd hh:mm:ss  TZ=zz<cr><lf>

     on-time = first <cr>
     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):

     <cr><lf>iqyy ddd hh:mm:ss.fff ld

     on-time = <cr>
     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
     <cr> 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 <u> 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 <u> 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 <u>.

     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)

     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 <file

Type 19: Heath WWV/WWVH Receiver

     This driver supports the Heath GC-1000 Most Accurate Clock, with
     RS232C Output Accessory. This is a WWV/WWVH receiver somewhat less
     robust than other supported receivers. Its claimed accuracy is 100
     ms when actually synchronized to the broadcast signal, but this
     doesn't happen even most of the time, due to propagation
     conditions, ambient noise sources, etc. When not synchronized, the
     accuracy is at the whim of the internal clock oscillator, which can
     wander into the sunset without warning. Since the indicated
     precision is 100 ms, expect a host synchronized only to this thing
     to wander to and fro, occasionally being rudely stepped when the
     offset exceeds the default CLOCK_MAX of 128 ms.

     The internal DIPswitches should be set to operate at 1200 baud in
     MANUAL mode and the current year. The external DIPswitches should
     be set to GMT and 24-hour format. 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.

     In MANUAL mode the clock responds to a rising edge of the request
     to send (RTS) modem control line by sending the timecode.
     Therefore, it is necessary that the operating system implement the
     TIOCMBIC and TIOCMBIS ioctl system calls and TIOCM_RTS control bit.
     Present restrictions require the use of a POSIX-compatible
     programming interface, although other interfaces may work as well.

     The clock message consists of 23 ASCII printing characters in the
     following format:

     hh:mm:ss.f     dd/mm/yr<cr>

     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 <cr>, 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 <mills@udel.edu>
Electrical Engineering Department
University of Delaware
Newark, DE 19716
302 831 8247 fax 302 831 4316

3 July 1994