source: trunk/third/xntp/html/extern.htm @ 17260

Revision 17260, 5.3 KB checked in by zacheiss, 23 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r17259, which included commits to RCS files with non-trunk default branches.
Line 
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
12clock, where the system clock is implemented by some external
13hardware device. One implementation might take the form of a bus
14peripheral with a high resolution counter disciplined by a GPS
15receiver, for example. Another implementation might involve another
16synchronization protocol, such as the Digital Time Synchronization
17Service (DTSS), where the system time is disciplined to this
18protocol and NTP clients of the server obtain synchronization
19indirectly via the server. A third implementation might be a
20completely separate clock discipline algorithm and synchronization
21protocol, such as the Lockclock algorithm used with NIST Automated
22Computer Time Service (ACTS) modem synchronized time.</p>
23
24<p>When external clocks are used in conjunction with NTP service,
25some way needs to be provided for the external clock driver and NTP
26daemon <tt>ntpd</tt> to communicate and determine which discipline
27is in control. This is necessary in order to provide backup, for
28instance if the external clock or protocol were to fail and
29synchronization service fall back to other means, such as a local
30reference clock or another NTP server. In addition, when the
31external clock and driver are in control, some means needs to be
32provided for the clock driver to pass on status information and
33error statistics to the NTP daemon.</p>
34
35<p>Control and monitoring functions for the external clock and
36driver are implemented using the <a href="driver1.htm">Local Clock
37(type 1) driver</a> and the <tt>ntp_adjtime()</tt> system call.
38This system call is implemented by special kernel provisions
39included in the kernel of several operating systems, including
40Solaris, Tru64, FreeBSD and Linux, and possibly others. When the
41external clock is disabled or not implemented, the system call is
42used to pass time and frequency information, as well as error
43statistics, to the kernel. Besides disciplining the system time,
44the same interface can be used by other applications to determine
45the operating parameters of the discipline.</p>
46
47<p>When the external clock is enabled, <tt>ntpd</tt> does not
48discipline the system clock, nor does it maintain the error
49statistics. In this case, the external clock and driver do this
50using mechanisms unknown to <tt>ntpd</tt>; however, in this case
51the kernel state variables are retrieved at 64-s intervals by the
52Local Clock driver and used by the clock selection and mitigation
53algorithms to determine the system variables presented to other NTP
54clients and peers. In this way, downstream clients and servers in
55the NTP subnet can make an intelligent choice when more than one
56server is available.</p>
57
58<p>In order to implement a reliable mitigation between ordinary NTP
59sources and the external clock source, a protocol is necessary
60between the local clock driver and the external clock driver. This
61is implemented using Boolean variables and certain bits in the
62kernel clock status word. The Boolean variables include the
63following:</p>
64
65<p>ntp__enable. set/reset by enable command. enables ntp clock
66discipline</p>
67
68<p>ntp_control. set during initial configuration if kernel support
69is available kern_enable Set/reset by enable commandexit If this
70switch is set, the daemon computes the offset, frequency, maximum
71error, estimated error, time constand and status bits, then
72provides them to the kernel via ntp_adjtime(). If this switch is
73set, these values are not passed to the kernel; however, the daemon
74retrieves their present values and uses them in place of the values
75computed by the daemon. pps_update set in the protocol routine if
76the prefer peer has survived and has offset less than 128 ms;
77otherwise set to zero. pps_control Updated to the current time by
78kernel support if the PPS signal is enabled and working correctly.
79Set to zero in the adjust routine if the interval since the last
80update exceeds 120 s.</p>
81
82<p>The ntp_enable and kern_enable are set by the configuration
83module. Normally, both switches default on, so the daemon can
84control the time and the kernel discipline can be used, if
85available. The pps_update switch is set by the protocol module when
86it believes the PPS provider source is legitimate and operating
87within nominals. The ntp_control switch is set during configuration
88by interrogating the kernel. If both the kern_enable and
89ntp_control siwitches are set, the daemon disciplines the clock via
90the kernel and the internal daemon discipline is disabled.</p>
91
92<p>The external clock driver controls the system time and clock
93selection in the following way. Normally, the driver adjusts the
94kernel time using the ntp_adjtime() system call in the same way as
95the daemon. In the case where the kernel discipline is to be used
96intact, the clock offset is provided in this call and the loop
97operates as specified. In the case where the driver steers only the
98frequency, 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
Note: See TracBrowser for help on using the repository browser.