contrib/ntp/html/extern.htm

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <html>
   3 <head>
   4 <meta name="generator" content="HTML Tidy, see www.w3.org">
   5 <title>External Clock Discipline and the Local Clock Driver</title>
   6 </head>
   7 <body>
   8 <h3>External Clock Discipline and the Local Clock Driver</h3>
   9
  10 <hr>
  11 <p>The NTPv4 implementation includes provisions for an external
  12 clock, where the system clock is implemented by some external
  13 hardware device. One implementation might take the form of a bus
  14 peripheral with a high resolution counter disciplined by a GPS
  15 receiver, for example. Another implementation might involve another
  16 synchronization protocol, such as the Digital Time Synchronization
  17 Service (DTSS), where the system time is disciplined to this
  18 protocol and NTP clients of the server obtain synchronization
  19 indirectly via the server. A third implementation might be a
  20 completely separate clock discipline algorithm and synchronization
  21 protocol, such as the Lockclock algorithm used with NIST Automated
  22 Computer Time Service (ACTS) modem synchronized time.</p>
  23
  24 <p>When external clocks are used in conjunction with NTP service,
  25 some way needs to be provided for the external clock driver and NTP
  26 daemon <tt>ntpd</tt> to communicate and determine which discipline
  27 is in control. This is necessary in order to provide backup, for
  28 instance if the external clock or protocol were to fail and
  29 synchronization service fall back to other means, such as a local
  30 reference clock or another NTP server. In addition, when the
  31 external clock and driver are in control, some means needs to be
  32 provided for the clock driver to pass on status information and
  33 error statistics to the NTP daemon.</p>
  34
  35 <p>Control and monitoring functions for the external clock and
  36 driver are implemented using the <a href="driver1.htm">Local Clock
  37 (type 1) driver</a> and the <tt>ntp_adjtime()</tt> system call.
  38 This system call is implemented by special kernel provisions
  39 included in the kernel of several operating systems, including
  40 Solaris, Tru64, FreeBSD and Linux, and possibly others. When the
  41 external clock is disabled or not implemented, the system call is
  42 used to pass time and frequency information, as well as error
  43 statistics, to the kernel. Besides disciplining the system time,
  44 the same interface can be used by other applications to determine
  45 the operating parameters of the discipline.</p>
  46
  47 <p>When the external clock is enabled, <tt>ntpd</tt> does not
  48 discipline the system clock, nor does it maintain the error
  49 statistics. In this case, the external clock and driver do this
  50 using mechanisms unknown to <tt>ntpd</tt>; however, in this case
  51 the kernel state variables are retrieved at 64-s intervals by the
  52 Local Clock driver and used by the clock selection and mitigation
  53 algorithms to determine the system variables presented to other NTP
  54 clients and peers. In this way, downstream clients and servers in
  55 the NTP subnet can make an intelligent choice when more than one
  56 server is available.</p>
  57
  58 <p>In order to implement a reliable mitigation between ordinary NTP
  59 sources and the external clock source, a protocol is necessary
  60 between the local clock driver and the external clock driver. This
  61 is implemented using Boolean variables and certain bits in the
  62 kernel clock status word. The Boolean variables include the
  63 following:</p>
  64
  65 <p>ntp__enable. set/reset by enable command. enables ntp clock
  66 discipline</p>
  67
  68 <p>ntp_control. set during initial configuration if kernel support
  69 is available kern_enable Set/reset by enable commandexit If this
  70 switch is set, the daemon computes the offset, frequency, maximum
  71 error, estimated error, time constand and status bits, then
  72 provides them to the kernel via ntp_adjtime(). If this switch is
  73 set, these values are not passed to the kernel; however, the daemon
  74 retrieves their present values and uses them in place of the values
  75 computed by the daemon. pps_update set in the protocol routine if
  76 the prefer peer has survived and has offset less than 128 ms;
  77 otherwise set to zero. pps_control Updated to the current time by
  78 kernel support if the PPS signal is enabled and working correctly.
  79 Set to zero in the adjust routine if the interval since the last
  80 update exceeds 120 s.</p>
  81
  82 <p>The ntp_enable and kern_enable are set by the configuration
  83 module. Normally, both switches default on, so the daemon can
  84 control the time and the kernel discipline can be used, if
  85 available. The pps_update switch is set by the protocol module when
  86 it believes the PPS provider source is legitimate and operating
  87 within nominals. The ntp_control switch is set during configuration
  88 by interrogating the kernel. If both the kern_enable and
  89 ntp_control siwitches are set, the daemon disciplines the clock via
  90 the kernel and the internal daemon discipline is disabled.</p>
  91
  92 <p>The external clock driver controls the system time and clock
  93 selection in the following way. Normally, the driver adjusts the
  94 kernel time using the ntp_adjtime() system call in the same way as
  95 the daemon. In the case where the kernel discipline is to be used
  96 intact, the clock offset is provided in this call and the loop
  97 operates as specified. In the case where the driver steers only the
  98 frequency, the offset is specified as zero.</p>
  99
 100 <hr>
 101 <a href="index.htm"><img align="left" src="pic/home.gif" alt=
 102 "gif"></a>
 103
 104 <address><a href="mailto:mills@udel.edu">David L. Mills
 105 &lt;mills@udel.edu&gt;</a></address>
 106 </body>
 107 </html>
 108