109 lines
5.3 KiB
HTML
109 lines
5.3 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<title>External Clock Discipline and the Local Clock Driver</title>
|
|
</head>
|
|
<body>
|
|
<h3>External Clock Discipline and the Local Clock Driver</h3>
|
|
|
|
<hr>
|
|
<p>The NTPv4 implementation includes provisions for an external
|
|
clock, where the system clock is implemented by some external
|
|
hardware device. One implementation might take the form of a bus
|
|
peripheral with a high resolution counter disciplined by a GPS
|
|
receiver, for example. Another implementation might involve another
|
|
synchronization protocol, such as the Digital Time Synchronization
|
|
Service (DTSS), where the system time is disciplined to this
|
|
protocol and NTP clients of the server obtain synchronization
|
|
indirectly via the server. A third implementation might be a
|
|
completely separate clock discipline algorithm and synchronization
|
|
protocol, such as the Lockclock algorithm used with NIST Automated
|
|
Computer Time Service (ACTS) modem synchronized time.</p>
|
|
|
|
<p>When external clocks are used in conjunction with NTP service,
|
|
some way needs to be provided for the external clock driver and NTP
|
|
daemon <tt>ntpd</tt> to communicate and determine which discipline
|
|
is in control. This is necessary in order to provide backup, for
|
|
instance if the external clock or protocol were to fail and
|
|
synchronization service fall back to other means, such as a local
|
|
reference clock or another NTP server. In addition, when the
|
|
external clock and driver are in control, some means needs to be
|
|
provided for the clock driver to pass on status information and
|
|
error statistics to the NTP daemon.</p>
|
|
|
|
<p>Control and monitoring functions for the external clock and
|
|
driver are implemented using the <a href="driver1.htm">Local Clock
|
|
(type 1) driver</a> and the <tt>ntp_adjtime()</tt> system call.
|
|
This system call is implemented by special kernel provisions
|
|
included in the kernel of several operating systems, including
|
|
Solaris, Tru64, FreeBSD and Linux, and possibly others. When the
|
|
external clock is disabled or not implemented, the system call is
|
|
used to pass time and frequency information, as well as error
|
|
statistics, to the kernel. Besides disciplining the system time,
|
|
the same interface can be used by other applications to determine
|
|
the operating parameters of the discipline.</p>
|
|
|
|
<p>When the external clock is enabled, <tt>ntpd</tt> does not
|
|
discipline the system clock, nor does it maintain the error
|
|
statistics. In this case, the external clock and driver do this
|
|
using mechanisms unknown to <tt>ntpd</tt>; however, in this case
|
|
the kernel state variables are retrieved at 64-s intervals by the
|
|
Local Clock driver and used by the clock selection and mitigation
|
|
algorithms to determine the system variables presented to other NTP
|
|
clients and peers. In this way, downstream clients and servers in
|
|
the NTP subnet can make an intelligent choice when more than one
|
|
server is available.</p>
|
|
|
|
<p>In order to implement a reliable mitigation between ordinary NTP
|
|
sources and the external clock source, a protocol is necessary
|
|
between the local clock driver and the external clock driver. This
|
|
is implemented using Boolean variables and certain bits in the
|
|
kernel clock status word. The Boolean variables include the
|
|
following:</p>
|
|
|
|
<p>ntp__enable. set/reset by enable command. enables ntp clock
|
|
discipline</p>
|
|
|
|
<p>ntp_control. set during initial configuration if kernel support
|
|
is available kern_enable Set/reset by enable commandexit If this
|
|
switch is set, the daemon computes the offset, frequency, maximum
|
|
error, estimated error, time constand and status bits, then
|
|
provides them to the kernel via ntp_adjtime(). If this switch is
|
|
set, these values are not passed to the kernel; however, the daemon
|
|
retrieves their present values and uses them in place of the values
|
|
computed by the daemon. pps_update set in the protocol routine if
|
|
the prefer peer has survived and has offset less than 128 ms;
|
|
otherwise set to zero. pps_control Updated to the current time by
|
|
kernel support if the PPS signal is enabled and working correctly.
|
|
Set to zero in the adjust routine if the interval since the last
|
|
update exceeds 120 s.</p>
|
|
|
|
<p>The ntp_enable and kern_enable are set by the configuration
|
|
module. Normally, both switches default on, so the daemon can
|
|
control the time and the kernel discipline can be used, if
|
|
available. The pps_update switch is set by the protocol module when
|
|
it believes the PPS provider source is legitimate and operating
|
|
within nominals. The ntp_control switch is set during configuration
|
|
by interrogating the kernel. If both the kern_enable and
|
|
ntp_control siwitches are set, the daemon disciplines the clock via
|
|
the kernel and the internal daemon discipline is disabled.</p>
|
|
|
|
<p>The external clock driver controls the system time and clock
|
|
selection in the following way. Normally, the driver adjusts the
|
|
kernel time using the ntp_adjtime() system call in the same way as
|
|
the daemon. In the case where the kernel discipline is to be used
|
|
intact, the clock offset is provided in this call and the loop
|
|
operates as specified. In the case where the driver steers only the
|
|
frequency, the offset is specified as zero.</p>
|
|
|
|
<hr>
|
|
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
|
|
"gif"></a>
|
|
|
|
<address><a href="mailto:mills@udel.edu">David L. Mills
|
|
<mills@udel.edu></a></address>
|
|
</body>
|
|
</html>
|
|
|