1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 2<html> 3<head> 4<meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> 5<meta name="generator" content="HTML Tidy, see www.w3.org"> 6<title>External Clock Discipline and the Local Clock Driver</title> 7<link href="scripts/style.css" type="text/css" rel="stylesheet"> 8</head> 9<body> 10<h3>External Clock Discipline and the Local Clock Driver</h3> 11<p>Last update: 12 <!-- #BeginDate format:En2m -->9-May-2014 04:46<!-- #EndDate --> 13 UTC</p> 14<hr> 15<p>The NTPv4 implementation includes provisions for an external clock, where 16 the system clock is implemented by some external hardware device. 17 One implementation might take the form of a bus peripheral with a high resolution 18 counter disciplined by a GPS receiver, for example. Another implementation 19 might involve another synchronization protocol, such as the Digital Time Synchronization 20 Service (DTSS), where the system time is disciplined to this protocol and 21 NTP clients of the server obtain synchronization indirectly via the server. 22 A third implementation might be a completely separate clock discipline algorithm 23 and synchronization protocol, such as the <tt>Lockclock</tt> algorithm used 24 with NIST Automated Computer Time Service (ACTS) modem synchronized time.</p> 25<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> 26<p>Control and monitoring functions for the external clock and driver are implemented using the <a href="drivers/driver1.html">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> 27<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> 28<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> 29<p><tt>ntp_enable</tt>. set/reset by the <tt>enable</tt> command. enables ntpd 30 clock discipline</p> 31<p><tt>ntp_contro</tt>l. set during initial configuration if kernel support is available</p> 32<p><tt>kern_enable</tt> Set/reset by the <tt>enable</tt> command</p> 33<p>If the <tt>kern_enable</tt> switch is set, the daemon computes the offset, 34 frequency, maximum error, estimated error, time constant and status bits, 35 then provides them to the kernel via <tt>ntp_adjtime()</tt>. If this switch 36 is not set, these values are not passed to the kernel; however, the daemon 37 retrieves their present values and uses them in place of the values computed 38 by the daemon.</p> 39<p>The <tt>pps_update</tt> bit set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.</p> 40<p>The <tt>PPS control</tt> Updated to the current time by kernel support if 41 the PPS signal is enabled and working correctly. Set to zero in the adjust 42 routine if the interval since the last update exceeds 120 s.</p> 43<p>The <tt>ntp_enable</tt> and <tt>kern_enable</tt> 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 <tt>pps_update</tt> switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The <tt>ntp_control</tt> switch is set during configuration by interrogating the kernel. If both the <tt>kern_enable</tt> and <tt>ntp_control</tt> switches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.</p> 44<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 <tt>ntp_adjtime()</tt> 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> 45<hr> 46<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> 47</body> 48</html> 49