diff options
Diffstat (limited to 'contrib/ntp/html/extern.htm')
| -rw-r--r-- | contrib/ntp/html/extern.htm | 108 |
1 files changed, 0 insertions, 108 deletions
diff --git a/contrib/ntp/html/extern.htm b/contrib/ntp/html/extern.htm deleted file mode 100644 index 01c0149..0000000 --- a/contrib/ntp/html/extern.htm +++ /dev/null @@ -1,108 +0,0 @@ -<!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> - |
