Copyright Notice
- [Dolly the sheep] "Clone me," says Dolly sheepishly
+ [sheepb.jpg] "Clone me," says Dolly sheepishly
_________________________________________________________________
The following copyright notice applies to all files collectively
called the Network Time Protocol Version 4 Distribution. Unless
specifically declared otherwise in an individual file, this notice
applies as if the text was explicitly included in the file.
-
-/***********************************************************************
- * *
- * Copyright (c) David L. Mills 1992-2000 *
- * *
- * Permission to use, copy, modify, and distribute this software and *
- * its documentation for any purpose and without fee is hereby *
- * granted, provided that the above copyright notice appears in all *
- * copies and that both the copyright notice and this permission *
- * notice appear in supporting documentation, and that the name *
- * University of Delaware not be used in advertising or publicity *
- * pertaining to distribution of the software without specific, *
- * written prior permission. The University of Delaware makes no *
- * representations about the suitability this software for any *
- * purpose. It is provided "as is" without express or implied *
- * warranty. *
- * *
- ***********************************************************************
- */
+***********************************************************************
+* *
+* Copyright (c) David L. Mills 1992-2001 *
+* *
+* Permission to use, copy, modify, and distribute this software and *
+* its documentation for any purpose and without fee is hereby *
+* granted, provided that the above copyright notice appears in all *
+* copies and that both the copyright notice and this permission *
+* notice appear in supporting documentation, and that the name *
+* University of Delaware not be used in advertising or publicity *
+* pertaining to distribution of the software without specific, *
+* written prior permission. The University of Delaware makes no *
+* representations about the suitability this software for any *
+* purpose. It is provided "as is" without express or implied *
+* warranty. *
+* *
+***********************************************************************
The following individuals contributed in part to the Network Time
Protocol Distribution Version 4 and are acknowledged as authors of
validated HTML documents according to the HTML DTD
_________________________________________________________________
- [50]Home
+ [50][home.gif]
[51]David L. Mills <mills@udel.edu>
47. mailto:tsuruoka@nc.fukuoka-u.ac.jp
48. mailto:vixie@vix.com
49. mailto:Ulrich.Windl@rz.uni-regensburg.de
- 50. file://localhost/backroom/ntp4+/html/index.htm
+ 50. file://localhost/backroom/ntp4/html/index.htm
51. mailto:mills@udel.edu
+2001-01-01 Harlan Stenn <stenn@whimsy.udel.edu>
+
+ * html/pic/wingdorothy.gif:
+ * html/pic/bustardfly.gif:
+ * html/pic/boom3a.gif:
+ * html/pic/tonea.gif:
+ * html/pic/stack1a.jpg:
+ * html/pic/pogoa.gif:
+ * html/pic/pogo8.gif:
+ * html/pic/pogo6.gif:
+ * html/pic/pogo5.gif:
+ * html/pic/pogo4.gif:
+ * html/pic/pogo3.gif:
+ * html/pic/pogo1.gif:
+ * html/pic/oz2.gif:
+ * html/pic/flatheads.gif:
+ * html/pic/boom4.gif:
+ * html/pic/boom3.gif:
+ * html/pic/appletree.gif:
+ * html/pic/alice51.gif:
+ * html/pic/alice44.gif:
+ * html/pic/alice35.gif:
+ * html/pic/alice31.gif:
+ * html/pic/alice15b.gif:
+ * html/pic/alice13.gif:
+ * html/pic/alice11.gif:
+ * html/release.htm:
+ * html/rdebug.htm:
+ * html/prefer.htm:
+ * html/porting.htm:
+ * html/ntptrace.htm:
+ * html/ntpq.htm:
+ * html/ntpdate.htm:
+ * html/monopt.htm:
+ * html/kernpps.htm:
+ * html/index.htm:
+ * html/hints.htm:
+ * html/gadget.htm:
+ * html/driver7.htm:
+ * html/copyright.htm:
+ * html/config.htm:
+ * html/build.htm:
+ * html/authopt.htm:
+ * html/assoc.htm:
+ * html/accopt.htm:
+ Cleanup from Dave Mills.
+
2000-12-30 Harlan Stenn <stenn@whimsy.udel.edu>
+ * configure.in: 4.0.99k13
+
* ntpd/refclock_wwv.c (wwv_start): Call audio_init with DEVICE_AUDIO.
* ntpd/refclock_irig.c (irig_start): Call audio_init with DEVICE_AUDIO.
* ntpd/refclock_chu.c: Documentation cleanup.
# Define the identity of the package.
PACKAGE=ntp
-VERSION=4.0.99k12
+VERSION=4.0.99k13
cat >>confdefs.h <<EOF
#define PACKAGE "$PACKAGE"
AC_DEFINE_UNQUOTED(STR_SYSTEM, "$target")
AM_CONFIG_HEADER(config.h)
AC_ARG_PROGRAM
-AM_INIT_AUTOMAKE(ntp, 4.0.99k12)
+AM_INIT_AUTOMAKE(ntp, 4.0.99k13)
AC_PREREQ(2.49)
ac_cv_var_oncore_ok=no
#! /bin/sh
BUILD_ARGS="$@"
+PARSE="--enable-parse-clocks"
+#PARSE=
# * baldwin sparc-sun-solaris2.7
# bridgeport sparc-sun-solaris2.6
for i in $LIST
do
echo $i
- ssh $i "cd $c_d ; ./build $SIG --enable-parse-clocks $BUILD_ARGS" &
- ssh $i "cd $c_d ; ./build $SIG --enable-parse-clocks --with-crypto=autokey $BUILD_ARGS" &
- ssh $i "cd $c_d ; ./build $SIG --enable-parse-clocks --without-crypto $BUILD_ARGS" &
+ ssh $i "cd $c_d ; ./build $SIG $PARSE $BUILD_ARGS" &
+ ssh $i "cd $c_d ; ./build $SIG $PARSE --with-crypto=autokey $BUILD_ARGS" &
+ ssh $i "cd $c_d ; ./build $SIG $PARSE --without-crypto $BUILD_ARGS" &
done
Access Control Options
</TITLE></HEAD><BODY><H3>
Access Control Options
-</H3><HR>
+</H3>
+
+<img align=left src=pic/pogo6.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>The skunk watches for intruders and sprays.
+<br clear=left><hr>
<H4>Access Control Support</H4>
Association Management
</title></head><body><h3>
Association Management
-</h3><hr>
+</h3>
+
+<img align=left src=pic/alice51.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Make sure who your friends are.
+<br clear=left><hr>
<h4>Association Modes</h4>
-<p>NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the <a href=confopt.htm>Configuration Options</a> and <a href=authopt.htm>Authentication Options</a> pages and in the papers, reports, memoranda and briefings at www.ntp.org.
+<p>NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the <a href=confopt.htm>Configuration Options</a> and <a href=authopt.htm>Authentication Options</a> pages and in the papers, reports, memoranda and briefings at <a href=http://www.ntp.org>www.ntp.org</a>.
<p>There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message.
Reference Clock Audio Drivers
</title></head><body><h3>
Reference Clock Audio Drivers
-</h3><hr>
+</h3>
+
+<img align=left src=pic/radio2.jpg>
+
+<p>Make a little noise here.
+<br clear=left><hr>
<p>There are some applications in which the computer time can be
disciplined to an audio signal, rather than a serial timecode and
Authentication Options
</title></head><body><h3>
Authentication Options
-</h3><hr>
+</h3>
+
+<img align=left src=pic/alice44.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Our resident cryptographer; now you see him, now you don't.
+<br clear=left><hr>
<h4>Authentication Support</h4>
</title></head><body><h3>
Protocol Conformance Statement
</h3>
-<BR><IMG align=left SRC="pic/flatheads.gif">From <i>The
-Wizard of Oz</i>, L. Frank Baum
+
+<img align=left src=pic/flatheads.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>From <i>The
+Wizard of Oz</i>, L. Frank Baum</a>
<p>Say it three times and it must be right.
<br clear=left>
<p>The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC), as provided by a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks.
-<p>Information on the NTP architecture, protocol and algorithms can be found in the following articles and reports, which are available online. General issues of the concepts and facilities assumed by NTP are discussed in tHe <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page, while issues related to the NTP timescale and pending century are discussed in the <a href=y2k.htm> Network Time Protocol Year 2000 Conformance Statement</a> page, both of which are included in this software distribution.
-
-<p>Note that network timekeeping technology continues to advance and may obsolete some of the following documents. For a current list of all papers, reports, briefings and other documents relevant to the NTP community, see the <a href=http://www.eecis.udel.edu/~mills>David L. Mills</a> web page. A historical perspective is available in
+<p>Information on the NTP architecture, protocol and algorithms can be found in the following articles and reports, which are available online. General issues of the concepts and facilities assumed by NTP are discussed in the <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page, while issues related to the NTP timescale and pending century are discussed in the <a href=y2k.htm> Network Time Protocol Year 2000 Conformance Statement</a> page, both of which are included in this software distribution. Network timekeeping technology continues to advance and may obsolete some of the following documents. For a current list of all papers, reports, briefings and other documents relevant to the NTP community, see the <a href=http://www.eecis.udel.edu/~mills>David L. Mills</a> web page. A historical perspective is available in
<ul>
</ul>
-<p>The NTP specification and implementation has evolved over the last two decades to the current Version 4 of the protocol. This version includes significant enhancements in accuracy and reliability, as determined by experience in an estimated total of well over 100,000 clients and servers in the Internet, while retaining backward compatibility with previous versions.
-
-<p>This software distribution contains an implementation of the NTP Version 4 architecture, protocol and algorithms. While a formal specification of this version is not yet available, this version is fully compliant with the previous NTP Version 3 specification and implementation defined in
+<p>The NTP specification and implementation has evolved over the last two decades to the current Version 4 of the protocol. This version includes significant enhancements in accuracy and reliability, as determined by experience in an estimated total of well over 100,000 clients and servers in the Internet, while retaining backward compatibility with previous versions. This software distribution contains an implementation of the NTP Version 4 architecture, protocol and algorithms. While a formal specification of this version is not yet available, this version is fully compliant with the previous NTP Version 3 specification and implementation defined in
<ul>
<p><li>Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992, 113 pp. Abstract: <a
-<HTML><HEAD><TITLE>
+<html><head><title>
Building and Installing the Distribution
-</TITLE></HEAD><BODY><H3>
+</title></head><body><h3>
Building and Installing the Distribution
-</H3>
+</h3>
-<img align=left src=pic/beaver.gif>From <i>pogo</i>, Walt Kelly
+<img align=left src=pic/beaver.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
<p>For putting out compiler fires.
<br clear=left><hr>
Reference Clock Options
</title></head><body><h3>
Reference Clock Options
-</h3><hr>
+</h3>
+
+<img align=left src=pic/boom4.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>See the radios, all in a row.
+<br clear=left><hr>
<h4>Reference Clock Support</h4>
-<HTML><HEAD><TITLE>
+<html><head><title>
Configuration Options
-</TITLE></HEAD><BODY><H3>
+</title></head><body><h3>
Configuration Options
-</H3>
+</h3>
-<IMG align=left SRC="pic/pogo3a.gif">From <i>pogo</i>, Walt Kelly
-<BR clear=left><HR>
+<img align=left src=pic/pogo3a.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>Gnu autoconfigure tools are in the backpack.
+<br clear=left><hr>
<H4>Basic Configuration Options - the <TT>configure</TT> utility</H4>
Configuration Options
</title></head><body><h3>
Configuration Options
-</h3><hr>
+</h3>
+
+<img align=left src=pic/boom3a.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>The chicken is getting configuration advice.
+<br clear=left><hr>
<h4>Configuration Support</h4>
-<html><head>
-<title>Copyright Notice</title>
-</head>
-<body>
+<html><head><title>
+Copyright Notice
+</title></head><body><h3>
+Copyright Notice
+</h3>
-<h3>Copyright Notice</h3>
-
-<IMG align=left HEIGHT=264 WIDTH=206 SRC="pic/sheepb.jpg" ALT="[Dolly the sheep]">"Clone
-me," says Dolly sheepishly
+<img align=left src=pic/sheepb.jpg>"Clone me," says Dolly sheepishly
<br clear=left><hr>
-<P>The following copyright notice applies to all files collectively
-called the Network Time Protocol Version 4 Distribution. Unless
-specifically declared otherwise in an individual file, this notice
-applies as if the text was explicitly included in the file.
+<P>The following copyright notice applies to all files collectively called the Network Time Protocol Version 4 Distribution. Unless specifically declared otherwise in an individual file, this notice applies as if the text was explicitly included in the file.
<br>
-<PRE>
-/***********************************************************************
- * *
- * Copyright (c) David L. Mills 1992-2000 *
- * *
- * Permission to use, copy, modify, and distribute this software and *
- * its documentation for any purpose and without fee is hereby *
- * granted, provided that the above copyright notice appears in all *
- * copies and that both the copyright notice and this permission *
- * notice appear in supporting documentation, and that the name *
- * University of Delaware not be used in advertising or publicity *
- * pertaining to distribution of the software without specific, *
- * written prior permission. The University of Delaware makes no *
- * representations about the suitability this software for any *
- * purpose. It is provided "as is" without express or implied *
- * warranty. *
- * *
- ***********************************************************************
- */
-</PRE>
-
-The following individuals contributed in part to the Network Time
-Protocol Distribution Version 4 and are acknowledged as authors of this
-work.
-
-<OL>
-
-<LI><A HREF="mailto: marka@syd.dms.csiro.au">Mark Andrews
-<marka@syd.dms.csiro.au></a> Leitch atomic clock controller</LI>
-
-<LI><A HREF="mailto: vbais@mailman1.intel.co">Viraj Bais
-<vbais@mailman1.intel.com></a> and <A HREF="mailto:
+<pre>
+***********************************************************************
+* *
+* Copyright (c) David L. Mills 1992-2001 *
+* *
+* Permission to use, copy, modify, and distribute this software and *
+* its documentation for any purpose and without fee is hereby *
+* granted, provided that the above copyright notice appears in all *
+* copies and that both the copyright notice and this permission *
+* notice appear in supporting documentation, and that the name *
+* University of Delaware not be used in advertising or publicity *
+* pertaining to distribution of the software without specific, *
+* written prior permission. The University of Delaware makes no *
+* representations about the suitability this software for any *
+* purpose. It is provided "as is" without express or implied *
+* warranty. *
+* *
+***********************************************************************
+</pre>
+
+The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.
+
+<ol>
+
+<li><A HREF="mailto: marka@syd.dms.csiro.au">Mark Andrews <marka@syd.dms.csiro.au></a> Leitch atomic clock controller</li>
+
+<li><A HREF="mailto: vbais@mailman1.intel.co">Viraj Bais <vbais@mailman1.intel.com></a> and <A HREF="mailto:
kirkwood@striderfm.intel.com">Clayton Kirkwood
-<kirkwood@striderfm.intel.com></a> port to WindowsNT 3.5</LI>
+<kirkwood@striderfm.intel.com></a> port to WindowsNT 3.5</li>
-<LI><A HREF="mailto: michael.barone@lmco.com">Michael Barone
-<michael,barone@lmco.com></a> GPSVME fixes</LI>
+<li><A HREF="mailto: michael.barone@lmco.com">Michael Barone <michael,barone@lmco.com></a> GPSVME fixes</li>
-<LI><A HREF="mailto: karl@owl.HQ.ileaf.com">Karl Berry
-<karl@owl.HQ.ileaf.com></a> syslog to file option</LI>
+<li><A HREF="mailto: karl@owl.HQ.ileaf.com">Karl Berry <karl@owl.HQ.ileaf.com></a> syslog to file option</li>
-<LI><A HREF="mailto: greg.brackley@bigfoot.com">Greg Brackley
-<greg.brackley@bigfoot.com></a> Major rework of WINNT port. Clean
-up recvbuf and iosignal code into separate modules.</LI>
+<li><A HREF="mailto: greg.brackley@bigfoot.com">Greg Brackley <greg.brackley@bigfoot.com></a> Major rework of WINNT port. Clean up recvbuf and iosignal code into separate modules.</li>
-<LI><A HREF="mailto: Marc.Brett@westgeo.com">Marc Brett
-<Marc.Brett@westgeo.com></a> Magnavox GPS clock driver</LI>
+<li><A HREF="mailto: Marc.Brett@westgeo.com">Marc Brett <Marc.Brett@westgeo.com></a> Magnavox GPS clock driver</li>
-<LI><A HREF="mailto: Piete.Brooks@cl.cam.ac.uk">Piete Brooks
-<Piete.Brooks@cl.cam.ac.uk></a> MSF clock driver, Trimble PARSE
-support</LI>
+<li><A HREF="mailto: Piete.Brooks@cl.cam.ac.uk">Piete Brooks <Piete.Brooks@cl.cam.ac.uk></a> MSF clock driver, Trimble PARSE support</li>
-<LI><A HREF="mailto: clift@ml.csiro.au">Steve Clift
-<clift@ml.csiro.au></a> OMEGA clock driver</LI>
+<li><A HREF="mailto: clift@ml.csiro.au">Steve Clift <clift@ml.csiro.au></a> OMEGA clock driver</li>
-<LI><A HREF="mailto:casey@csc.co.za">Casey Crellin
-<casey@csc.co.za></a> vxWorks (Tornado) port and help with target
-configuration</LI>
+<li><A HREF="mailto:casey@csc.co.za">Casey Crellin <casey@csc.co.za></a> vxWorks (Tornado) port and help with target configuration</li>
-<LI><A HREF="mailto: Sven_Dietrich@trimble.COM">Sven Dietrich
-<sven_dietrich@trimble.com></a> Palisade reference clock driver,
-NT adj. residuals, integrated Greg's Winnt port.</LI>
+<li><A HREF="mailto: Sven_Dietrich@trimble.COM">Sven Dietrich <sven_dietrich@trimble.com></a> Palisade reference clock driver, NT adj. residuals, integrated Greg's Winnt port.</li>
-<LI><A HREF="mailto: dundas@salt.jpl.nasa.gov">John A. Dundas III
-<dundas@salt.jpl.nasa.gov></a> Apple A/UX port</LI>
+<li><A HREF="mailto: dundas@salt.jpl.nasa.gov">John A. Dundas III <dundas@salt.jpl.nasa.gov></a> Apple A/UX port</li>
-<LI><A HREF="mailto: duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe
-<duwe@immd4.informatik.uni-erlangen.de></a> Linux port</LI>
+<li><A HREF="mailto: duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe <duwe@immd4.informatik.uni-erlangen.de></a> Linux port</li>
-<LI><A HREF="mailto: dennis@mrbill.canet.ca">Dennis Ferguson
-<dennis@mrbill.canet.ca></a> foundation code for NTP Version 2 as
-specified in RFC-1119</LI>
+<li><A HREF="mailto: dennis@mrbill.canet.ca">Dennis Ferguson
+<dennis@mrbill.canet.ca></a> foundation code for NTP Version 2 as specified in RFC-1119</li>
-<LI><A HREF="mailto: glenn@herald.usask.ca">Glenn Hollinger
-<glenn@herald.usask.ca></a> GOES clock driver</LI>
+<li><A HREF="mailto: glenn@herald.usask.ca">Glenn Hollinger <glenn@herald.usask.ca></a> GOES clock driver</li>
-<LI><A HREF="mailto: iglesias@uci.edu">Mike Iglesias
-<iglesias@uci.edu></a> DEC Alpha port</LI>
+<li><A HREF="mailto: iglesias@uci.edu">Mike Iglesias <iglesias@uci.edu></a> DEC Alpha port</li>
-<LI><A HREF="mailto: jagubox.gsfc.nasa.gov">Jim Jagielski
-<jim@jagubox.gsfc.nasa.gov></a> A/UX port</LI>
+<li><A HREF="mailto: jagubox.gsfc.nasa.gov">Jim Jagielski <jim@jagubox.gsfc.nasa.gov></a> A/UX port</li>
-<LI><A HREF="mailto: jbj@chatham.usdesign.com">Jeff Johnson
-<jbj@chatham.usdesign.com></a> massive prototyping overhaul</LI>
+<li><A HREF="mailto: jbj@chatham.usdesign.com">Jeff Johnson <jbj@chatham.usdesign.com></a> massive prototyping overhaul</li>
-<LI><A HREF="mailto: jones@hermes.chpc.utexas.edu">William L. Jones
-<jones@hermes.chpc.utexas.edu></a> RS/6000 AIX modifications, HPUX
-modifications</LI>
+<li><A HREF="mailto: jones@hermes.chpc.utexas.edu">William L. Jones <jones@hermes.chpc.utexas.edu></a> RS/6000 AIX modifications, HPUX modifications</li>
-<LI><A HREF="mailto:Hans.Lambermont@nl.origin-it.com">Hans Lambermont
-<Hans.Lambermont@nl.origin-it.com></A> or <A
-HREF="mailto:H.Lambermont@chello.nl"><H.Lambermont@chello.nl></A>
-ntpsweep</LI>
+<li><A HREF="mailto:Hans.Lambermont@nl.origin-it.com">Hans Lambermont <Hans.Lambermont@nl.origin-it.com></A> or <A
+HREF="mailto:H.Lambermont@chello.nl"><H.Lambermont@chello.nl></A> ntpsweep</li>
-<LI><A HREF="http://www4.informatik.uni-erlangen.de/~kardel">Frank
-Kardel</A> <A HREF="mailto: Frank.Kardel@informatik.uni-erlangen.de">
-<Frank.Kardel@informatik.uni-erlangen.de></a> PARSE
-<GENERIC> driver (14 reference clocks), STREAMS modules for PARSE,
-support scripts, syslog cleanup</LI>
+<li><A HREF="http://www4.informatik.uni-erlangen.de/~kardel">Frank Kardel</A> <A HREF="mailto: Frank.Kardel@informatik.uni-erlangen.de"> <Frank.Kardel@informatik.uni-erlangen.de></a> PARSE <GENERIC> driver (14 reference clocks), STREAMS modules for PARSE, support scripts, syslog cleanup</li>
-<LI><A HREF="mailto: dkatz@cisco.com">Dave Katz
-<dkatz@cisco.com></a> RS/6000 AIX port</LI>
+<li><A HREF="mailto: dkatz@cisco.com">Dave Katz <dkatz@cisco.com></a> RS/6000 AIX port</li>
-<LI><A HREF="mailto: leres@ee.lbl.gov">Craig Leres
-<leres@ee.lbl.gov></a> 4.4BSD port, ppsclock, Magnavox GPS clock
-driver</LI>
+<li><A HREF="mailto: leres@ee.lbl.gov">Craig Leres
+<leres@ee.lbl.gov></a> 4.4BSD port, ppsclock, Magnavox GPS clock driver</li>
-<LI><A HREF="mailto: lindholm@ucs.ubc.ca">George Lindholm
-<lindholm@ucs.ubc.ca></a> SunOS 5.1 port</LI>
+<li><A HREF="mailto: lindholm@ucs.ubc.ca">George Lindholm <lindholm@ucs.ubc.ca></a> SunOS 5.1 port</li>
-<LI><A HREF="mailto: louie@ni.umd.edu">Louis A. Mamakos
-<louie@ni.umd.edu></a> MD5-based authentication</LI>
+<li><A HREF="mailto: louie@ni.umd.edu">Louis A. Mamakos <louie@ni.umd.edu></a> MD5-based authentication</li>
-<LI><A HREF="mailto: thorinn@diku.dk">Lars H. Mathiesen
-<thorinn@diku.dk></a> adaptation of foundation code for Version 3
-as specified in RFC-1305</LI>
+<li><A HREF="mailto: thorinn@diku.dk">Lars H. Mathiesen <thorinn@diku.dk></a> adaptation of foundation code for Version 3 as specified in RFC-1305</li>
-<LI><A HREF="mailto: mills@udel.edu">David L. Mills
-<mills@udel.edu></a> Version 4 foundation: clock discipline,
-authentication, precision kernel; clock drivers: Spectracom, Austron,
-Arbiter, Heath, ATOM, ACTS, KSI/Odetics; audio clock drivers: CHU,
-WWV/H, IRIG</LI>
+<li><A HREF="mailto: mills@udel.edu">David L. Mills <mills@udel.edu></a> Version 4 foundation: clock discipline, authentication, precision kernel; clock drivers: Spectracom, Austron, Arbiter, Heath, ATOM, ACTS, KSI/Odetics; audio clock drivers: CHU, WWV/H, IRIG</li>
-<LI><A HREF="mailto: moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller
-<moeller@gwdgv1.dnet.gwdg.de></a> VMS port</LI>
+<li><A HREF="mailto: moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller <moeller@gwdgv1.dnet.gwdg.de></a> VMS port</li>
-<LI><A HREF="mailto: mogul@pa.dec.com">Jeffrey Mogul
-<mogul@pa.dec.com></a> ntptrace utility</LI>
+<li><A HREF="mailto: mogul@pa.dec.com">Jeffrey Mogul <mogul@pa.dec.com></a> ntptrace utility</li>
-<LI><A HREF="mailto: tmoore@fievel.daytonoh.ncr.com">Tom Moore
-<tmoore@fievel.daytonoh.ncr.com></a> i386 svr4 port</LI>
+<li><A HREF="mailto: tmoore@fievel.daytonoh.ncr.com">Tom Moore <tmoore@fievel.daytonoh.ncr.com></a> i386 svr4 port</li>
-<LI><A HREF="mailto: kamal@whence.com">Kamal A Mostafa
-<kamal@whence.com></a> SCO OpenServer port</LI>
+<li><A HREF="mailto: kamal@whence.com">Kamal A Mostafa <kamal@whence.com></a> SCO OpenServer port</li>
-<LI><A HREF="mailto: derek@toybox.demon.co.uk">Derek Mulcahy
-<derek@toybox.demon.co.uk></a> and <A HREF="mailto:
-d@hd.org">Damon Hart-Davis <d@hd.org></a> ARCRON MSF clock
-driver</LI>
+<li><A HREF="mailto: derek@toybox.demon.co.uk">Derek Mulcahy <derek@toybox.demon.co.uk></a> and <A HREF="mailto: d@hd.org">Damon Hart-Davis <d@hd.org></a> ARCRON MSF clock driver</li>
-<LI><A HREF="mailto: Rainer.Pruy@informatik.uni-erlangen.de">Rainer Pruy
-<Rainer.Pruy@informatik.uni-erlangen.de></a> monitoring/trap
-scripts, statistics file handling</LI>
+<li><A HREF="mailto: Rainer.Pruy@informatik.uni-erlangen.de">Rainer Pruy <Rainer.Pruy@informatik.uni-erlangen.de></a> monitoring/trap scripts, statistics file handling</li>
-<LI><A HREF="mailto: dirce@zk3.dec.com">Dirce Richards
-<dirce@zk3.dec.com></a> Digital UNIX V4.0 port</LI>
+<li><A HREF="mailto: dirce@zk3.dec.com">Dirce Richards <dirce@zk3.dec.com></a> Digital UNIX V4.0 port</li>
-<LI><A HREF="mailto: wsanchez@apple.com">Wilfredo Sánchez
-<wsanchez@apple.com></A> added support for NetInfo</LI>
+<li><A HREF="mailto: wsanchez@apple.com">Wilfredo Sánchez <wsanchez@apple.com></A> added support for NetInfo</li>
-<LI><A HREF="mailto: mrapple@quack.kfu.com">Nick Sayer
-<mrapple@quack.kfu.com></a> SunOS streams modules</LI>
+<li><A HREF="mailto: mrapple@quack.kfu.com">Nick Sayer <mrapple@quack.kfu.com></a> SunOS streams modules</li>
-<LI><A HREF="mailto: jack@innovativeinternet.com">Jack Sasportas
-<jack@innovativeinternet.com></A> Saved a Lot of space on the
-stuff in the html/pic/ subdirectory</LI>
+<li><A HREF="mailto: jack@innovativeinternet.com">Jack Sasportas <jack@innovativeinternet.com></A> Saved a Lot of space on the stuff in the html/pic/ subdirectory</li>
-<LI><A HREF="mailto: schnitz@unipress.com">Ray Schnitzler
-<schnitz@unipress.com></a> Unixware1 port</LI>
+<li><A HREF="mailto: schnitz@unipress.com">Ray Schnitzler <schnitz@unipress.com></a> Unixware1 port</li>
-<LI><A HREF="mailto: shields@tembel.org">Michael Shields
-<shields@tembel.org></a> USNO clock driver</LI>
+<li><A HREF="mailto: shields@tembel.org">Michael Shields <shields@tembel.org></a> USNO clock driver</li>
-<LI><A HREF="mailto: pebbles.jpl.nasa.gov">Jeff Steinman
-<jss@pebbles.jpl.nasa.gov></a> Datum PTS clock driver</LI>
+<li><A HREF="mailto: pebbles.jpl.nasa.gov">Jeff Steinman <jss@pebbles.jpl.nasa.gov></a> Datum PTS clock driver</li>
-<LI><A HREF="mailto: harlan@pfcs.com">Harlan Stenn
-<harlan@pfcs.com></a> GNU automake/autoconfigure makeover, various
-other bits (see the ChangeLog)</LI>
+<li><A HREF="mailto: harlan@pfcs.com">Harlan Stenn <harlan@pfcs.com></a> GNU automake/autoconfigure makeover, various other bits (see the ChangeLog)</li>
-<LI><A HREF="mailto: ken@sdd.hp.com">Kenneth Stone
-<ken@sdd.hp.com></a> HP-UX port</LI>
+<li><A HREF="mailto: ken@sdd.hp.com">Kenneth Stone <ken@sdd.hp.com></a> HP-UX port</li>
-<LI><A HREF="mailto: ajit@ee.udel.edu">Ajit Thyagarajan
-<ajit@ee.udel.edu></a>IP multicast/anycast support</LI>
+<li><A HREF="mailto: ajit@ee.udel.edu">Ajit Thyagarajan <ajit@ee.udel.edu></a>IP multicast/anycast support</li>
-<LI><A HREF="mailto: tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA
-<tsuruoka@nc.fukuoka-u.ac.jp></a>TRAK clock driver</LI>
+<li><A HREF="mailto: tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp></a>TRAK clock driver</li>
-<LI><A HREF="mailto: vixie@vix.com">Paul A Vixie
-<vixie@vix.com></a> TrueTime GPS driver, generic TrueTime clock
-driver</LI>
+<li><A HREF="mailto: vixie@vix.com">Paul A Vixie <vixie@vix.com></a> TrueTime GPS driver, generic TrueTime clock driver</li>
-<LI><A HREF="mailto: Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl
-<Ulrich.Windl@rz.uni-regensburg.de></a> corrected and validated
-HTML documents according to the HTML DTD</LI>
+<li><A HREF="mailto: Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de></a> corrected and validated HTML documents according to the HTML DTD</li>
-</OL>
+</ol>
-<hr>
-<a href=index.htm><img align=left src="pic/home.gif"
-WIDTH=36 HEIGHT=24 ALT="Home"></a>
-<address>
-<a href="mailto:mills@udel.edu">David L. Mills <mills@udel.edu></a>
-</address>
-</body>
-</html>
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
-<HTML><HEAD><TITLE>
+<html><head><title>
NTP Debugging Techniques
-</TITLE></HEAD><BODY><H3>
+</title></head><body><h3>
NTP Debugging Techniques
-</H3>
+</h3>
-<IMG align=left SRC="pic/pogo.gif"><I>Pogo Possum</I>, with toolkit
-and bug, Walt Kelly
+<img align=left src=pic/pogo.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>We make house calls and bring our own bugs.
<br clear=left><hr>
-<p>Once the NTP software distribution has been compiled and installed
-and the configuration file constructed, the next step is to verify
-correct operation and fix any bugs that may result. Usually, the command
-line that starts the daemon is included in the system startup file, so
-it is executed only at system boot time; however, the daemon can be
-stopped and restarted from root at any time. Usually, no command-line
-arguments are required, unless special actions described in the
-<tt><A HREF="ntpd.htm">ntpd</A></tt> page are required. Once started,
-the daemon will begin sending and receiving messages, as specified in
-the configuration file.
+<p>Once the NTP software distribution has been compiled and installed and the configuration file constructed, the next step is to verify correct operation and fix any bugs that may result. Usually, the command line that starts the daemon is included in the system startup file, so it is executed only at system boot time; however, the daemon can be stopped and restarted from root at any time. Usually, no command-line arguments are required, unless special actions described in the <tt><A HREF="ntpd.htm">ntpd</A></tt> page are required. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.
<h4>Initial Startup</h4>
-<p>The best way to verify correct operation is using the <tt><A
-HREF="ntpq.htm">ntpq</A></tt> and <tt><A HREF="ntpdc.htm">ntpdc</A></tt>
-utility programs, either on the server itself or from another machine
-elsewhere in the network. The <tt>ntpq</tt> program implements the
-management functions specified in Appendix A of the NTP specification <A
-HREF=
-"http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps">
-RFC-1305, Appendix A</A>. The <tt>ntpdc</tt> program implements
-additional functions not provided in the standard. Both programs can be
-used to inspect the state variables defined in the specification and, in
-the case of <tt>ntpdc</tt>, additional ones of interest. In addition,
-the <tt>ntpdc</tt> program can be used to selectively reconfigure and
-enable or disable some functions while the daemon is running.
-
-<p>In extreme cases with elusive bugs, the daemon can operate in two
-modes, depending on the presence of the <tt>-d</tt> command-line debug
-switch. If not present, the daemon detaches from the controlling
-terminal and proceeds autonomously. If one or more <tt>-d</tt> switches
-are present, the daemon does not detach and generates special output
-useful for debugging. In general, interpretation of this output requires
-reference to the sources. However, a single <tt>-d</tt> does produce
-only mildly cryptic output and can be very useful in finding problems
-with configuration and network troubles. With a little experience, the
-volume of output can be reduced by piping the output to <tt>grep
-</tt>and specifying the keyword of the trace you want to see.
-
-<p>Some problems are immediately apparent when the daemon first starts
-running. The most common of these are the lack of a UDP port for NTP
-(123) in the Unix <tt>/etc/services</tt> file. Note that NTP does not
-use TCP in any form. Other problems are apparent in the system log file.
-The log file should show the startup banner, some cryptic initialization
-data and the computed precision value. The next most common problem is
-incorrect DNS names. Check that each DNS name used in the configuration
-file responds to the Unix <tt>ping</tt> command.
-
-<p>When first started, the daemon normally polls the servers listed in
-the configuration file at 64-s intervals. In order to allow a sufficient
-number of samples for the NTP algorithms to reliably discriminate
-between correctly operating servers and possible intruders, at least
-four valid messages from the majority of servers and peers listed in the
-configuration file is required before the daemon can set the local
-clock. However, if the current system time is greater than 1000 s in
-error from the server times, the daemon will not set the local clock;
-instead, it will plant a message in the system log and shut down. It is
-necessary to set the local clock to within 1000 s first, either by a
-time-of-year hardware clock, by first using the <A
-HREF="ntpdate.htm"><tt>ntpdate</tt></A> program or manually be eyeball
-and wristwatch.
-
-<p>If the initial time error is less than 1000 s but greater than 125
-ms, the daemon will perform a step adjustment; otherwise, it will
-gradually slew the clock to the nominal time. However, if a step
-adjustment, the clock discipline algorithm will start all over again,
-requiring another round of at least four messages as before. This is
-necessary so that all servers and peers operate on the same set of time
-values.
-
-<p>If, as discussed later in this page, for some reason the hardware
-clock oscillator frequency error is relatively large, the time errors
-upon first startup of the daemon may increase over time until exceeding
-125 ms, which requires another step correction. However, due to
-provisions that reduce vulnerability to noise spikes, the second
-correction will not be done until 900 s have elapsed since the last
-adjustment. When the frequency error is very large, it may take a number
-of cycles like this until converging on the nominal frequency
-correction. After this, the correction is written to the
-<tt>ntp.drift</tt> file, which is read upon subsequent restarts, so the
-herky-jerky cycles should not recur.
+<p>The best way to verify correct operation is using the <tt><A HREF="ntpq.htm">ntpq</A></tt> and <tt><A HREF="ntpdc.htm">ntpdc</A></tt> utility programs, either on the server itself or from another machine elsewhere in the network. The <tt>ntpq</tt> program implements the management functions specified in the NTP specification <A HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps">
+RFC-1305, Appendix A</A>. The <tt>ntpdc</tt> program implements additional functions not provided in the standard. Both programs can be used to inspect the state variables defined in the specification and, in the case of <tt>ntpdc</tt>, additional ones of interest. In addition, the <tt>ntpdc</tt> program can be used to selectively reconfigure and enable or disable some functions while the daemon is running.
+
+<p>In extreme cases with elusive bugs, the daemon can operate in two modes, depending on the presence of the <tt>-d</tt> command-line debug switch. If not present, the daemon detaches from the controlling
+terminal and proceeds autonomously. If one or more <tt>-d</tt> switches are present, the daemon does not detach and generates special output useful for debugging. In general, interpretation of this output requires reference to the sources. However, a single <tt>-d</tt> does produce only mildly cryptic output and can be very useful in finding problems with configuration and network troubles. With a little experience, the volume of output can be reduced by piping the output to <tt>grep </tt>and specifying the keyword of the trace you want to see.
+
+<p>Some problems are immediately apparent when the daemon first starts running. The most common of these are the lack of a UDP port for NTP (123) in the Unix <tt>/etc/services</tt> file. Note that NTP does not use TCP in any form. Other problems are apparent in the system log file. The log file should show the startup banner, some cryptic initialization data and the computed precision value. The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file responds to the Unix <tt>ping</tt> command.
+
+<p>When first started, the daemon normally polls the servers listed in the configuration file at 64-s intervals. In order to allow a sufficient number of samples for the NTP algorithms to reliably discriminate between correctly operating servers and possible intruders, at least four valid messages from the majority of servers and peers listed in the configuration file is required before the daemon can set the local clock. However, if the current system time is greater than 1000 s in error from the server times, the daemon will not set the local clock; instead, it will plant a message in the system log and shut down. It is necessary to set the local clock to within 1000 s first, either by a time-of-year hardware clock, by first using the <A HREF="ntpdate.htm"><tt>ntpdate</tt></A> program or manually be eyeball and wristwatch.
+
+<p>If the initial time error is less than 1000 s but greater than 125 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. However, if a step adjustment, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values.
+
+<p>If, as discussed later in this page, for some reason the hardware clock oscillator frequency error is relatively large, the time errors upon first startup of the daemon may increase over time until exceeding 125 ms, which requires another step correction. However, due to provisions that reduce vulnerability to noise spikes, the second correction will not be done until 900 s have elapsed since the last adjustment. When the frequency error is very large, it may take a number of cycles like this until converging on the nominal frequency correction. After this, the correction is written to the <tt>ntp.drift</tt> file, which is read upon subsequent restarts, so the herky-jerky cycles should not recur.
<h4>Verifying Correct Operation</h4>
-<p>After starting the daemon, run the <tt>ntpq</tt> program using the
-<tt>-n</tt> switch, which will avoid possible distractions due to name
-resolution problems. Use the <tt>pe</tt> command to display a billboard
-showing the status of configured peers and possibly other clients poking
-the daemon. After operating for a few minutes, the display should be
-something like:
+<p>After starting the daemon, run the <tt>ntpq</tt> program using the <tt>-n</tt> switch, which will avoid possible distractions due to name resolution problems. Use the <tt>pe</tt> command to display a billboard showing the status of configured peers and possibly other clients poking the daemon. After operating for a few minutes, the display should be something like:
-<pre>ntpq> pe
+<p><pre>ntpq> pe
remote refid st t when poll reach delay offset jitter
=====================================================================
-isipc6.cairn.ne .GPS1. 1 u 18 64 377 65.592 -5.891 0.044
*pogo.udel.edu .GPS1. 1 u 95 128 377 0.607 0.123 0.027
</pre>
-<p>The host names or addresses shown in the <tt>remote</tt> column
-correspond to the server and peer entries listed in the configuration
-file; however, the DNS names might not agree if the names listed are not
-the canonical DNS names. The <tt>refid</tt> column shows the current
-source of synchronization, while the <tt>st</tt> column reveals the
-stratum, <tt>t</tt> the type (<tt>u</tt> = unicast, <tt>m</tt> =
-multicast, <tt>l</tt> = local, <tt>-</tt> = don't know), and
-<tt>poll</tt> the poll interval in seconds. The <tt>when</tt> column
-shows the time since the peer was last heard in seconds, while the
-<tt>reach</tt> column shows the status of the reachability register (see
-RFC-1305) in octal. The remaining entries show the latest delay, offset
-and jitter in milliseconds. Note that in NTP Version 4 what used to be
-the <tt>dispersion</tt> column has been replaced by the <tt>jitter</tt>
-column.
-
-<p>The tattletale symbol at the left margin displays the synchronization
-status of each peer. The currently selected peer is marked <tt>*</tt>,
-while additional peers designated acceptable for synchronization, but
-not currently selected, are marked <tt>+</tt>. Peers marked <tt>*</tt>
-and <tt>+</tt> are included in the weighted average computation to set
-the local clock; the data produced by peers marked with other symbols
-are discarded. See the <tt>ntpq</tt> page for the meaning of these
-symbols.
-
-<p>Additional details for each peer separately can be determined by the
-following procedure. First, use the <tt>as</tt> command to display an
-index of association identifiers, such as
+<p>The host names or addresses shown in the <tt>remote</tt> column correspond to the server and peer entries listed in the configuration file; however, the DNS names might not agree if the names listed are not the canonical DNS names. The <tt>refid</tt> column shows the current source of synchronization, while the <tt>st</tt> column reveals the stratum, <tt>t</tt> the type (<tt>u</tt> = unicast, <tt>m</tt> = multicast, <tt>l</tt> = local, <tt>-</tt> = don't know), and <tt>poll</tt> the poll interval in seconds. The <tt>when</tt> column shows the time since the peer was last heard in seconds, while the <tt>reach</tt> column shows the status of the reachability register (see RFC-1305) in octal. The remaining entries show the latest delay, offset and jitter in milliseconds. Note that in NTP Version 4 what used to be the <tt>dispersion</tt> column has been replaced by the <tt>jitter</tt> column.
+
+<p>The tattletale symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked <tt>*</tt>, while additional peers designated acceptable for synchronization, but not currently selected, are marked <tt>+</tt>. Peers marked <tt>*</tt> and <tt>+</tt> are included in the weighted average computation to set the local clock; the data produced by peers marked with other symbols are discarded. See the <tt>ntpq</tt> page for the meaning of these symbols.
+
+<p>Additional details for each peer separately can be determined by the following procedure. First, use the <tt>as</tt> command to display an index of association identifiers, such as
<p><pre>ntpq> as
ind assID status conf reach auth condition last_event cnt
4 50255 f614 yes yes ok sys.peer reachable 1
</pre>
-<p>Each line in this billboard is associated with the corresponding line
-in the <tt>pe</tt> billboard above. The <tt>assID</tt> shows the unique
-identifier for each mobilized association, while the <tt>status</tt>
-column shows the peer status word in hex, as defined in the NTP
-specification. Next, use the <tt>rv</tt> command and the respective
-<tt>assID</tt> identifier to display a detailed synopsis for the
-selected peer, such as
+<p>Each line in this billboard is associated with the corresponding line in the <tt>pe</tt> billboard above. The <tt>assID</tt> shows the unique identifier for each mobilized association, while the <tt>status</tt> column shows the peer status word in hex, as defined in the NTP specification. Next, use the <tt>rv</tt> command and the respective <tt>assID</tt> identifier to display a detailed synopsis for the selected peer, such as
<p><pre>ntpq> rv 50253
status=f414 reach, conf, auth, sel_candidat, 1 event, event_reach,
timestamp=3172053041
</pre>
-<p>A detailed explanation of the fields in this billboard are beyond the
-scope of this discussion; however, most variables defined in the NTP
-Version 3 specification RFC-1305 are available along with others defined
-for NTP Version 4. This particular example was chosen to illustrate
-probably the most complex configuration involving symmetric modes and
-public-key cryptography. As the result of debugging experience, the
-names and values of these variables may change from time to time. An
-explanation of the current set is on the <tt>ntpq</tt> page.
-
-<p>A useful indicator of miscellaneous problems is the <tt>flash</tt>
-value, which reveals the state of the various sanity tests on incoming
-packets. There are currently eleven bits, one for each test, numbered
-from the right, which is for test 1. If the test fails, the
-corresponding bit is set to one and zero otherwise. If any bit is set
-following each processing step, the packet is discarded. The meaning of
-each test is described on the <tt>ntpq</tt> page.
-
-<p>The three lines identified as <tt>filtdelay</tt>, <tt>filtoffset</tt>
-and <tt>filtdisp</tt> reveal the roundtrip delay, clock offset and
-dispersion for each of the last eight measurement rounds, all in
-milliseconds. Note that the dispersion, which is an estimate of the
-error, increases as the age of the sample increases. From these data, it
-is usually possible to determine the incidence of severe packet loss,
-network congestion, and unstable local clock oscillators. There are no
-hard and fast rules here, since every case is unique; however, if one or
-more of the rounds show large values or change radically from one round
-to another, the network is probably congested or lossy.
-
-<p>Once the daemon has set the local clock, it will continuously track
-the discrepancy between local time and NTP time and adjust the local
-clock accordingly. There are two components of this adjustment, time and
-frequency. These adjustments are automatically determined by the clock
-discipline algorithm, which functions as a hybrid phase/frequency
-feedback loop. The behavior of this algorithm is carefully controlled to
-minimize residual errors due to network jitter and frequency variations
-of the local clock hardware oscillator that normally occur in practice.
-However, when started for the first time, the algorithm may take some
-time to converge on the intrinsic frequency error of the host machine.
-
-<p>The frequency tolerance of computer clock oscillators can vary
-widely, which can put a strain on the daemon's ability to compensate for
-the intrinsic frequency error. While the daemon can handle frequency
-errors up to 500 parts-per-million (PPM), or 43 seconds per day, values
-much above 100 PPM reduce the headroom and increase the time to learn
-the particular value and record it in the <tt>ntp.drift</tt> file. In
-extreme cases before the particular oscillator frequency error has been
-determined, the residual system time offsets can sweep from one extreme
-to the other of the 128-ms tracking window only for the behavior to
-repeat at 900-s intervals until the measurements have converged.
-
-<p>In order to determine if excessive frequency error is a problem,
-observe the nominal <tt>filtoffset</tt> values for a number of rounds
-and divide by the poll interval. If the result is something approaching
-500 PPM, there is a good chance that NTP will not work properly until
-the frequency error is reduced by some means. A common cause is the
-hardware time-of-year (TOY) clock chip, which must be disabled when NTP
-disciplines the software clock. For some systems this can be done using
-the <tt><A HREF="tickadj.htm">tickadj</A></tt> utility and the <tt>-
-s</tt> command line argument. For other systems this can be done using a
-command in the system startup file.
-
-<p>If the TOY chip is not the cause, the problem may be that the
-hardware clock frequency may simply be too slow or two fast. In some
-systems this might require tweaking a trimmer capacitor on the
-motherboard. For other systems the clock frequency can be adjusted in
-increments of 100 PPM using the <tt>tickadj</tt> utility and the <tt>-
-t</tt> command line argument. Note that the <tt>tickadj</tt> alters
-certain kernel variables and, while the utility attempts to figure out
-an acceptable way to do this, there are many cases where
+<p>A detailed explanation of the fields in this billboard are beyond the scope of this discussion; however, most variables defined in the NTP Version 3 specification RFC-1305 are available along with others defined for NTP Version 4. This particular example was chosen to illustrate probably the most complex configuration involving symmetric modes and public-key cryptography. As the result of debugging experience, the names and values of these variables may change from time to time. An explanation of the current set is on the <tt>ntpq</tt> page.
+
+<p>A useful indicator of miscellaneous problems is the <tt>flash</tt> value, which reveals the state of the various sanity tests on incoming packets. There are currently eleven bits, one for each test, numbered from the right, which is for test 1. If the test fails, the corresponding bit is set to one and zero otherwise. If any bit is set following each processing step, the packet is discarded. The meaning of each test is described on the <tt>ntpq</tt> page.
+
+<p>The three lines identified as <tt>filtdelay</tt>, <tt>filtoffset</tt> and <tt>filtdisp</tt> reveal the roundtrip delay, clock offset and dispersion for each of the last eight measurement rounds, all in milliseconds. Note that the dispersion, which is an estimate of the error, increases as the age of the sample increases. From these data, it is usually possible to determine the incidence of severe packet loss, network congestion, and unstable local clock oscillators. There are no hard and fast rules here, since every case is unique; however, if one or more of the rounds show large values or change radically from one round to another, the network is probably congested or lossy.
+
+<p>Once the daemon has set the local clock, it will continuously track the discrepancy between local time and NTP time and adjust the local clock accordingly. There are two components of this adjustment, time and frequency. These adjustments are automatically determined by the clock discipline algorithm, which functions as a hybrid phase/frequency feedback loop. The behavior of this algorithm is carefully controlled to minimize residual errors due to network jitter and frequency variations of the local clock hardware oscillator that normally occur in practice. However, when started for the first time, the algorithm may take some time to converge on the intrinsic frequency error of the host machine.
+
+<p>The frequency tolerance of computer clock oscillators can vary widely, which can put a strain on the daemon's ability to compensate for the intrinsic frequency error. While the daemon can handle frequency errors up to 500 parts-per-million (PPM), or 43 seconds per day, values much above 100 PPM reduce the headroom and increase the time to learn the particular value and record it in the <tt>ntp.drift</tt> file. In extreme cases before the particular oscillator frequency error has been determined, the residual system time offsets can sweep from one extreme to the other of the 128-ms tracking window only for the behavior to repeat at 900-s intervals until the measurements have converged.
+
+<p>In order to determine if excessive frequency error is a problem, observe the nominal <tt>filtoffset</tt> values for a number of rounds and divide by the poll interval. If the result is something approaching 500 PPM, there is a good chance that NTP will not work properly until the frequency error is reduced by some means. A common cause is the hardware time-of-year (TOY) clock chip, which must be disabled when NTP disciplines the software clock. For some systems this can be done using the <tt><A HREF="tickadj.htm">tickadj</A></tt> utility and the <tt>-s</tt> command line argument. For other systems this can be done using a command in the system startup file.
+
+<p>If the TOY chip is not the cause, the problem may be that the hardware clock frequency may simply be too slow or two fast. In some systems this might require tweaking a trimmer capacitor on the motherboard. For other systems the clock frequency can be adjusted in increments of 100 PPM using the <tt>tickadj</tt> utility and the <tt>-t</tt> command line argument. Note that the <tt>tickadj</tt> alters certain kernel variables and, while the utility attempts to figure out an acceptable way to do this, there are many cases where
<tt>tickadj</tt> is incompatible with a running kernel.
-<p>The state of the local clock itself can be determined using the
-<tt>rv</tt> command (without the argument), such as
+<p>The state of the local clock itself can be determined using the <tt>rv</tt> command (without the argument), such as
<p><pre>ntpq> rv
status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
refresh=3172016539
</pre>
-<p>An explanation about most of these variables is in the RFC-1305
-specification. The most useful ones include <tt>clock</tt>, which shows
-when the clock was last adjusted, and <tt>reftime</tt>, which shows when
-the server clock of <tt>refid</tt> was last adjusted. The
-<tt>version</tt>, <tt>processor</tt> and <tt>system</tt> values are very
-helpful when included in bug reports. The mean millisecond time offset
-(<tt>phase</tt>) and deviation (<tt>jitter</tt>) monitor the clock
-quality, while the mean PPM frequency offset (<tt>frequency</tt>) and
-deviation (<tt>stability</tt>) monitor the clock stability and serve as
-a useful diagnostic tool. It has been the experience of NTP operators
-over the years that these data represent useful environment and hardware
-alarms. If the motherboard fan freezes up or some hardware bit sticks,
-the system clock is usually the first to notice it.
-
-<p>Among the new variables added for NTP Version 4 are the
-<tt>hostname</tt>, <tt>publickey</tt>, <tt>params</tt> and
-<tt>refresh</tt>, which are used for the Autokey public-key cryptography
-described on the <a href=authopt.htm>Authentication Options</a> page.
-The values show the filestamps, in NTP seconds, that the associated
-values were created. These are useful in diagnosing problems with
-cryptographic key consistency and ordering principles.
-
-<p>When nothing seems to happen in the <tt>pe</tt> billboard after some
-minutes, there may be a network problem. One common network problem
-is an access controlled router on the path to the selected peer or an
-access controlled server using methods described on the <a
-href=accopt.htm>Access Control Options</a> page. Another common problem
-is that the server is down or running in unsynchronized mode due to a
-local problem. Use the <tt>ntpq</tt> program to spy on the server
-variables in the same way you can spy on your own.
-
-<p>Normally, the daemon will adjust the local clock in small steps in
-such a way that system and user programs are unaware of its operation.
-The adjustment process operates continuously as long as the apparent
-clock error exceeds 128 milliseconds, which for most Internet paths is a
-quite rare event. If the event is simply an outlyer due to an occasional
-network delay spike, the correction is simply discarded; however, if the
-apparent time error persists for an interval of about 20 minutes, the
-local clock is stepped to the new value (as an option, the daemon can be
-compiled to slew at an accelerated rate to the new value, rather than be
-stepped). This behavior is designed to resist errors due to severely
-congested network paths, as well as errors due to confused radio clocks
-upon the epoch of a leap second.
+<p>An explanation about most of these variables is in the RFC-1305 specification. The most useful ones include <tt>clock</tt>, which shows when the clock was last adjusted, and <tt>reftime</tt>, which shows when the server clock of <tt>refid</tt> was last adjusted. The <tt>version</tt>, <tt>processor</tt> and <tt>system</tt> values are very helpful when included in bug reports. The mean millisecond time offset (<tt>phase</tt>) and deviation (<tt>jitter</tt>) monitor the clock quality, while the mean PPM frequency offset (<tt>frequency</tt>) and deviation (<tt>stability</tt>) monitor the clock stability and serve as a useful diagnostic tool. It has been the experience of NTP operators over the years that these data represent useful environment and hardware alarms. If the motherboard fan freezes up or some hardware bit sticks, the system clock is usually the first to notice it.
+
+<p>Among the new variables added for NTP Version 4 are the <tt>hostname</tt>, <tt>publickey</tt>, <tt>params</tt> and <tt>refresh</tt>, which are used for the Autokey public-key cryptography described on the <a href=authopt.htm>Authentication Options</a> page. The values show the filestamps, in NTP seconds, that the associated values were created. These are useful in diagnosing problems with cryptographic key consistency and ordering principles.
+
+<p>When nothing seems to happen in the <tt>pe</tt> billboard after some minutes, there may be a network problem. One common network problem is an access controlled router on the path to the selected peer or an access controlled server using methods described on the <a href=accopt.htm>Access Control Options</a> page. Another common problem is that the server is down or running in unsynchronized mode due to a local problem. Use the <tt>ntpq</tt> program to spy on the server variables in the same way you can spy on your own.
+
+<p>Normally, the daemon will adjust the local clock in small steps in such a way that system and user programs are unaware of its operation. The adjustment process operates continuously as long as the apparent clock error exceeds 128 milliseconds, which for most Internet paths is a quite rare event. If the event is simply an outlyer due to an occasional network delay spike, the correction is simply discarded; however, if the apparent time error persists for an interval of about 20 minutes, the local clock is stepped to the new value (as an option, the daemon can be compiled to slew at an accelerated rate to the new value, rather than be stepped). This behavior is designed to resist errors due to severely congested network paths, as well as errors due to confused radio clocks upon the epoch of a leap second.
<H4>Debugging Checklist</H4>
-If the <tt>ntpq</tt> or <tt>ntpdc</tt> programs do not show that
-messages are being received by the daemon or that received messages do
-not result in correct synchronization, verify the following:
+If the <tt>ntpq</tt> or <tt>ntpdc</tt> programs do not show that messages are being received by the daemon or that received messages do not result in correct synchronization, verify the following:
<OL>
-<p><li>Verify the <tt>/etc/services</tt> file host machine is configured
-to accept UDP packets on the NTP port 123. NTP is specifically designed
-to use UDP and does not respond to TCP.</li>
-
-<p><li>Check the system log for <tt>ntpd</tt> messages about
-configuration errors, name-lookup failures or initialization
-problems.</li>
-
-<p><li>Verify using <tt>ping</tt> or other utility that packets actually
-do make the round trip between the client and server. Verify using
-<tt>nslookup</tt> or other utility that the DNS server names do exist
-and resolve to valid Internet addresses.
-
-<p><li>Using the <tt>ntpdc</tt> program, verify that the packets
-received and packets sent counters are incrementing. If the sent counter
-does not increment and the configuration file includes configured
-servers, something may be wrong in the host network or interface
-configuration. If this counter does increment, but the received counter
-does not increment, something may be wrong in the network or the server
-NTP daemon may not be running or the server itself may be down or not
-responding.</li>
-
-<p><li>If both the sent and received counters do increment, but the
-<tt>reach</tt> values in the <tt>pe</tt> billboard with <tt>ntpq</tt>
-continues to show zero, received packets are probably being discarded
-for some reason. If this is the case, the cause should be evident from
-the <tt>flash</tt> variable as discussed above and on the <tt>ntpq</tt>
-page.</li>
-
-<p><li>If the <tt>reach</tt> values in the <tt>pe</tt> billboard show
-the servers are alive and responding, note the tattletale symbols at the
-left margin, which indicate the status of each server resulting from the
-various grooming and mitigation algorithms. The interpretation of these
-symbols is discussed on the <tt>ntpq</tt> page. After a few minutes of
-operation, one or another of the reachable server candidates should show
-a * tattletale symbol. If this doesn't happen, the intersection
-algorithm, which classifies the servers as truechimers or falsetickers,
-may be unable to find a majority of truechimers among the server
+<p><li>Verify the <tt>/etc/services</tt> file host machine is configured to accept UDP packets on the NTP port 123. NTP is specifically designed to use UDP and does not respond to TCP.</li>
+
+<p><li>Check the system log for <tt>ntpd</tt> messages about configuration errors, name-lookup failures or initialization problems.</li>
+
+<p><li>Verify using <tt>ping</tt> or other utility that packets actually do make the round trip between the client and server. Verify using <tt>nslookup</tt> or other utility that the DNS server names do exist and resolve to valid Internet addresses.
+
+<p><li>Using the <tt>ntpdc</tt> program, verify that the packets received and packets sent counters are incrementing. If the sent counter does not increment and the configuration file includes configured servers, something may be wrong in the host network or interface configuration. If this counter does increment, but the received counter does not increment, something may be wrong in the network or the server NTP daemon may not be running or the server itself may be down or not responding.</li>
+
+<p><li>If both the sent and received counters do increment, but the <tt>reach</tt> values in the <tt>pe</tt> billboard with <tt>ntpq</tt> continues to show zero, received packets are probably being discarded for some reason. If this is the case, the cause should be evident from the <tt>flash</tt> variable as discussed above and on the <tt>ntpq</tt> page.</li>
+
+<p><li>If the <tt>reach</tt> values in the <tt>pe</tt> billboard show the servers are alive and responding, note the tattletale symbols at the left margin, which indicate the status of each server resulting from the various grooming and mitigation algorithms. The interpretation of these symbols is discussed on the <tt>ntpq</tt> page. After a few minutes of operation, one or another of the reachable server candidates should show a * tattletale symbol. If this doesn't happen, the intersection algorithm, which classifies the servers as truechimers or falsetickers, may be unable to find a majority of truechimers among the server
population.</li>
-<p><li>If all else fails, see the FAQ and/or the discussion and
-briefings at <a href=http://www.eecis.udel.edu/~mills/ntp.htm>Network
-Time Synchronization Project<a>.</li>
+<p><li>If all else fails, see the FAQ and/or the discussion and briefings at <a href=http://www.eecis.udel.edu/~mills/ntp.htm>Network Time Synchronization Project<a>.</li>
</OL>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
<br>Driver ID: <tt>CHU</tt>
<br>Modem Port: <tt>/dev/chu<I>u</I></tt>; 300 baud, 8-bits, no parity
<br>Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no parity
-<br>Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
+<br>Audio Device: <tt>/dev/chu_audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
-This driver synchronizes the computer time using data encoded in radio
-transmissions from Canadian time/frequency station CHU in Ottawa,
-Ontario. Transmissions are made continuously on 3330 kHz, 7335 kHz and
-14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave
-receiver can be tuned manually to one of these frequencies or, in the
-case of ICOM receivers, the receiver can be tuned automatically as
-propagation conditions change throughout the day and night. The
-performance of this driver when tracking the station is ordinarily
-better than 1 ms in time with frequency drift less than 0.5 PPM when not
-tracking the station.
-
-<p>While there are currently no known commercial CHU receivers, a simple
-but effective receiver/demodulator can be constructed from an ordinary
-shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip,
-as described in the <a href=pps.htm>Pulse-per-second (PPS) Signal
-Interfacing</a> page. The driver can be compiled to use a modem to
-receive the radio signal and demodulate the data. Alternatively, the
-driver can be compiled to use the audio codec of the Sun workstation or
-another with compatible audio interface. In the latter case, the driver
-implements the modem using DSP routines, so the radio can be connected
-directly to either the microphone on line input port.
-
-<p>The driver replaces an earlier one built by Dennis Ferguson in 1988.
-The earlier driver required a special line discipline which preprocessed
-the signal in order to improve accuracy and avoid errors. The new driver
-includes more powerful algorithms implemented directly in the driver and
-requires no line discipline. It decodes the data using a
-maximum-likelihood technique which exploits the considerable degree of
-redundancy available to maximize accuracy and minimize errors.
-
-<p>This driver incorporates several features in common with other audio
-drivers such as described in the <a href=driver36.htm>Radio WWV/H Audio
-Demodulator/Decoder</a> and the <a href=driver6.htm>IRIG Audio
-Decoder</a> pages. They include automatic gain control (AGC), selectable
-audio codec port and signal monitoring capabilities. For a discussion of
-these common features, as well as a guide to hookup, debugging and
-monitoring, see the <a href=audio.htm>Reference Clock Audio Drivers</a>
-page.
-
-<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h),
-although this can be changed with configuration commands. As long as the
-clock is set or verified at least once during this interval, the NTP
-algorithms will consider the source reachable and selectable to
-discipline the system clock. However, if this does not happen for eight
-poll intervals, the algorithms will consider the source unreachable and
-some other source will be chosen (if available) to discipline the system
-clock.
-
-<p>The decoding algorithms take advantage of all the redundancy
-available in each broadcast message or burst. In each burst described in
-the next section, every character is sent twice and, in the case of
-format A bursts, the burst is sent eight times every minute. In the case
-of format B bursts, which are sent once each minute, the burst is
-considered correct only if every character matches its repetition in the
-burst. In the case of format A messages, a majority decoder requires at
-least six repetitions for each digit in the timecode and more than
-half of the repetitions decode to the same digit. Every character in
-every burst provides an independent timestamp upon arrival with a
-potential total of over 60 timestamps for each minute.
-
-<p>A timecode in the format described below is assembled when all bursts
-have been received in the minute. The timecode is considered valid and
-the clock set when at least one valid format B burst has been decoded
-and the above requirements are met. The <tt>yyyy</tt> year field in the
-timecode indicates whether a valid format B burst has been received.
-Upon startup, this field is initialized at zero; when a valid format B
-burst is received, it will be set to the correct Gregorian year. The
-<tt>q</tt> quality character field in the timecode indicates whether a
-valid timecode has been determined. If any of the high order three bits
-of this character are set, the timecode is invalid.
-
-<p>Once the clock has been set for the first time, it will appear
-reachable and selectable to discipline the system clock, even if the
-broadcast signal is lost. Since the signals are almost always available
-during some period of the day and the NTP clock discipline algorithms
-are designed to work well even in this case, it is unlikely that the
-system clock could drift more than a few tens of milliseconds during
-periods of signal loss. To protect against this most unlikely situation,
-if after four days with no signals, the clock is considered unset and
-resumes the synchronization procedure from the beginning.
-
-<p>The last three fields in the timecode are useful in assessing the
-quality of the radio channel during the most recent minute bursts were
-received. The <tt>bcnt</tt> field shows the number of format A bursts in
-the range 1-8. The <tt>dist</tt> field shows the majority decoder
-distance, or the minimum number of sample repetitions for each digit of
-the timecode in the range 0-16. The <tt>tsmp</tt> field shows the number
-of timestamps determined in the range 0-60. For a valid timecode,
-<tt>bcnt</tt> must be at least 3, <tt>dist</tt> must be greater than
-<tt>bcnt</tt> and <tt>tsmp</tt> must be at least 20.
+This driver synchronizes the computer time using data encoded in radio transmissions from Canadian time/frequency station CHU in Ottawa, Ontario. Transmissions are made continuously on 3330 kHz, 7335 kHz and 14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically as propagation conditions change throughout the day and night. The performance of this driver when tracking the station is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking the station.
+
+<p>While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described in the <a href=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</a> page. The driver can be compiled to use a modem to receive the radio signal and demodulate the data. Alternatively, the driver can be compiled to use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone on line input port. Ordinarily, the driver is compiled for the audio codec only for SunOS and Solaris machines and for the serial port for other machines.
+
+<p>The driver replaces an earlier one built by Dennis Ferguson in 1988. The earlier driver required a special line discipline which preprocessed the signal in order to improve accuracy and avoid errors. The new driver includes more powerful algorithms implemented directly in the driver and requires no line discipline. It decodes the data using a maximum-likelihood technique which exploits the considerable degree of redundancy available to maximize accuracy and minimize errors.
+
+<p>This driver incorporates several features in common with other audio drivers such as described in the <a href=driver36.htm>Radio WWV/H Audio Demodulator/Decoder</a> and the <a href=driver6.htm>IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href=audio.htm>Reference Clock Audio Drivers</a> page.
+
+<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h), although this can be changed with configuration commands. As long as the clock is set or verified at least once during this interval, the NTP algorithms will consider the source reachable and selectable to discipline the system clock. However, if this does not happen for eight poll intervals, the algorithms will consider the source unreachable and some other source will be chosen (if available) to discipline the system clock.
+
+<p>The decoding algorithms take advantage of all the redundancy available in each broadcast message or burst. In each burst described in the next section, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. In the case of format B bursts, which are sent once each minute, the burst is considered correct only if every character matches its repetition in the burst. In the case of format A messages, a majority decoder requires at least six repetitions for each digit in the timecode and more than half of the repetitions decode to the same digit. Every character in every burst provides an independent timestamp upon arrival with a potential total of over 60 timestamps for each minute.
+
+<p>A timecode in the format described below is assembled when all bursts have been received in the minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the above requirements are met. The <tt>yyyy</tt> year field in the timecode indicates whether a valid format B burst has been received. Upon startup, this field is initialized at zero; when a valid format B burst is received, it will be set to the correct Gregorian year. The <tt>q</tt> quality character field in the timecode indicates whether a valid timecode has been determined. If any of the high order three bits of this character are set, the timecode is invalid.
+
+<p>Once the clock has been set for the first time, it will appear reachable and selectable to discipline the system clock, even if the broadcast signal is lost. Since the signals are almost always available during some period of the day and the NTP clock discipline algorithms are designed to work well even in this case, it is unlikely that the system clock could drift more than a few tens of milliseconds during periods of signal loss. To protect against this most unlikely situation, if after four days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.
+
+<p>The last three fields in the timecode are useful in assessing the quality of the radio channel during the most recent minute bursts were received. The <tt>bcnt</tt> field shows the number of format A bursts in the range 1-8. The <tt>dist</tt> field shows the majority decoder distance, or the minimum number of sample repetitions for each digit of the timecode in the range 0-16. The <tt>tsmp</tt> field shows the number of timestamps determined in the range 0-60. For a valid timecode, <tt>bcnt</tt> must be at least 3, <tt>dist</tt> must be greater than <tt>bcnt</tt> and <tt>tsmp</tt> must be at least 20.
<h4>Program Operation</h4>
-<p>The program consists of four major parts: the DSP modem, maximum
-likelihood UART, burst assembler and majority decoder. The DSP modem
-demodulates Bell 103 modem answer-frequency signals; that is, frequency-
-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz (space). This is
-done using a 4th-order IIR filter and limiter/discriminator with 500-Hz
-bandpass centered on 2125 Hz and followed by a FIR raised-cosine lowpass
-filter optimized for the 300-b/s data rate. Alternately, the driver can
-be compiled to delete the modem and input 300 b/s data directly from an
-external modem via a serial port.
-
-<p>The maximum likelihood UART is implemented using a set of eight
-11-stage shift registers, one for each of eight phases of the 300-b/s
-bit clock. At each phase a new baseband signal value from the DSP modem
-is shifted into the corresponding register and the maximum and minimum
-over all 11 samples computed. This establishes a slice level midway
-between the maximum and minimum over all stages. For each stage, a
-signal level above this level is a mark (1) and below is a space (0). A
-quality metric is calculated for each register with respect to the slice
-level and the a-priori signal consisting of a mark bit (previous stop
-bit), space (start) bit, eight arbitrary information bits and the first
-of the two mark (stop) bits.
-<p>The shift registers are processed in round-robin order as each modem
-value arrives until one of them shows a valid framing pattern consisting
-of a mark bit, space bit, eight arbitrary data bits and a mark bit. When
-found, the data bits from the register with the best metric is chosen as
-the maximum likelihood character and the UART begins to process the next
-character.
-
-<p>The burst assembler processes characters either from the maximum
-likelihood UART or directly from the serial port as configured. A burst
-begins when a character is received and is processed after a timeout
-interval when no characters are received. If the interval between
-characters is greater than two characters, but less than the timeout
-interval, the burst is rejected as a runt and a new burst begun. As each
-character is received, a timestamp is captured and saved for later
-processing.
-
-<p>A valid burst consists of ten characters in two replicated
-five-character blocks. A format B block contains the year and other
-information in ten hexadecimal digits. A format A block contains the
-timecode in ten decimal digits, the first of which is a framing code
-(6). The burst assembler must deal with cases where the first character
-of a format A burst is lost or is noise. This is done using the framing
-code to correct the phase, either one character early or one character
-late.
-
-<p>The burst distance is incremented by one for each bit in the first
-block that matches the corresponding bit in the second block and
-decremented by one otherwise. In a format B burst the second block is
-bit-inverted relative to the first, so a perfect burst of five 8-bit
-characters has distance -40. In a format A block the two blocks are
-identical, so a perfect burst has distance +40. Format B bursts must be
-perfect to be acceptable; however, format A bursts, which are further
-processed by the majority decoder, are acceptable if the distance is at
-least 28.
-
-<p>Each minute of transmission includes eight format A bursts containing
-two timecodes for each second from 31 through 39. The majority decoder
-uses a decoding matrix of ten rows, one for each digit position in the
-timecode, and 16 columns, one for each 4-bit code combination that might
-be decoded at that position. In order to use the character timestamps,
-it is necessary to reliably determine the second number of each burst.
-In a valid burst, the last digit of the two timecodes in the block must
-match and the value must be in the range 2-9 and greater than in the
-previous burst.
-
-<p>As each hex digit of a valid burst is processed, the value at the row
-corresponding to the digit position in the timecode and column
-corresponding to the code found at that position is incremented. At the
-end of each minute of transmission, each row of the decoding matrix
-encodes the number of occurrences of each code found at the
-corresponding position of the timecode. However, the first digit
-(framing code) is always 6, the ninth (second tens) is always 3 and the
-last (second units) changes for each burst, so are not used.
-
-<p>The maximum over all occurrences at each timecode digit position is
-the distance for that position and the corresponding code is the maximum
-likelihood candidate. If the distance is zero, the decoder assumes a
-miss; if the distance is not more than half the total number of
-occurrences, the decoder assumes a soft error; if two different codes
-with the same distance are found, the decoder assumes a hard error. In
-all these cases the decoder encodes a non-decimal character which will
-later cause a format error when the timecode is reformatted. The
-decoding distance is defined as the minimum distance over the first nine
-digits; the tenth digit varies over the seconds and is uncounted.
-
-<p>The result of the majority decoder is a nine-digit timecode
-representing the maximum likelihood candidate for the transmitted
-timecode in that minute. Note that the second and fraction within the
-minute are always zero and that the actual reference point to calculate
-timestamp offsets is backdated to the first second of the minute. At
-this point the timecode block is reformatted and the year, days, hours
-and minutes extracted along with other information from the format B
-burst, including DST state, DUT1 correction and leap warning. The
-reformatting operation checks the timecode for invalid code combinations
-that might have been left by the majority decoder and rejects the entire
-timecode if found.
-
-<p>If the timecode is valid, it is passed to the reference clock
-interface along with the backdated timestamp offsets accumulated over
-the minute. A perfect set of nine bursts could generate as many as 90
-timestamps, but the maximum the interface can handle is 60. These are
-processed by the interface using a median filter and trimmed-mean
-average, so the resulting system clock correction is usually much better
-than would otherwise be the case with radio noise, UART jitter and
-occasional burst errors.
+<p>The program consists of four major parts: the DSP modem, maximum likelihood UART, burst assembler and majority decoder. The DSP modem demodulates Bell 103 modem answer-frequency signals; that is, frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz (space). This is done using a 4th-order IIR filter and limiter/discriminator with 500-Hz bandpass centered on 2125 Hz and followed by a FIR raised-cosine lowpass filter optimized for the 300-b/s data rate. Alternately, the driver can be compiled to delete the modem and input 300 b/s data directly from an external modem via a serial port.
+
+<p>The maximum likelihood UART is implemented using a set of eight 11-stage shift registers, one for each of eight phases of the 300-b/s bit clock. At each phase a new baseband signal value from the DSP modem is shifted into the corresponding register and the maximum and minimum over all 11 samples computed. This establishes a slice level midway between the maximum and minimum over all stages. For each stage, a signal level above this level is a mark (1) and below is a space (0). A quality metric is calculated for each register with respect to the slice level and the a-priori signal consisting of a mark bit (previous stop bit), space (start) bit, eight arbitrary information bits and the first of the two mark (stop) bits.
+
+<p>The shift registers are processed in round-robin order as each modem value arrives until one of them shows a valid framing pattern consisting of a mark bit, space bit, eight arbitrary data bits and a mark bit. When found, the data bits from the register with the best metric is chosen as the maximum likelihood character and the UART begins to process the next character.
+
+<p>The burst assembler processes characters either from the maximum likelihood UART or directly from the serial port as configured. A burst begins when a character is received and is processed after a timeout interval when no characters are received. If the interval between characters is greater than two characters, but less than the timeout interval, the burst is rejected as a runt and a new burst begun. As each character is received, a timestamp is captured and saved for later processing.
+
+<p>A valid burst consists of ten characters in two replicated five-character blocks. A format B block contains the year and other information in ten hexadecimal digits. A format A block contains the timecode in ten decimal digits, the first of which is a framing code (6). The burst assembler must deal with cases where the first character of a format A burst is lost or is noise. This is done using the framing code to correct the phase, either one character early or one character late.
+
+<p>The burst distance is incremented by one for each bit in the first block that matches the corresponding bit in the second block and decremented by one otherwise. In a format B burst the second block is bit-inverted relative to the first, so a perfect burst of five 8-bit characters has distance -40. In a format A block the two blocks are identical, so a perfect burst has distance +40. Format B bursts must be perfect to be acceptable; however, format A bursts, which are further processed by the majority decoder, are acceptable if the distance is at least 28.
+
+<p>Each minute of transmission includes eight format A bursts containing two timecodes for each second from 31 through 39. The majority decoder uses a decoding matrix of ten rows, one for each digit position in the timecode, and 16 columns, one for each 4-bit code combination that might be decoded at that position. In order to use the character timestamps, it is necessary to reliably determine the second number of each burst. In a valid burst, the last digit of the two timecodes in the block must match and the value must be in the range 2-9 and greater than in the previous burst.
+
+<p>As each hex digit of a valid burst is processed, the value at the row corresponding to the digit position in the timecode and column corresponding to the code found at that position is incremented. At the end of each minute of transmission, each row of the decoding matrix encodes the number of occurrences of each code found at the corresponding position of the timecode. However, the first digit (framing code) is always 6, the ninth (second tens) is always 3 and the last (second units) changes for each burst, so are not used.
+
+<p>The maximum over all occurrences at each timecode digit position is the distance for that position and the corresponding code is the maximum likelihood candidate. If the distance is zero, the decoder assumes a miss; if the distance is not more than half the total number of occurrences, the decoder assumes a soft error; if two different codes with the same distance are found, the decoder assumes a hard error. In all these cases the decoder encodes a non-decimal character which will later cause a format error when the timecode is reformatted. The decoding distance is defined as the minimum distance over the first nine digits; the tenth digit varies over the seconds and is uncounted.
+
+<p>The result of the majority decoder is a nine-digit timecode representing the maximum likelihood candidate for the transmitted timecode in that minute. Note that the second and fraction within the minute are always zero and that the actual reference point to calculate timestamp offsets is backdated to the first second of the minute. At this point the timecode block is reformatted and the year, days, hours and minutes extracted along with other information from the format B burst, including DST state, DUT1 correction and leap warning. The reformatting operation checks the timecode for invalid code combinations that might have been left by the majority decoder and rejects the entire timecode if found.
+
+<p>If the timecode is valid, it is passed to the reference clock interface along with the backdated timestamp offsets accumulated over the minute. A perfect set of nine bursts could generate as many as 90 timestamps, but the maximum the interface can handle is 60. These are processed by the interface using a median filter and trimmed-mean average, so the resulting system clock correction is usually much better than would otherwise be the case with radio noise, UART jitter and occasional burst errors.
<h4>Autotune</h4>
-<p>The driver includes provisions to automatically tune the radio in
-response to changing radio propagation conditions throughout the day and
-night. The radio interface is compatible with the ICOM CI-V standard,
-which is a bidirectional serial bus operating at TTL levels. The bus can
-be connected to a standard serial port using a level converter such as
-the CT-17. The serial port speed is presently compiled in the program,
-but can be changed in the <tt>icom.h</tt> header file.
-
-<p>Each ICOM radio is assigned a unique 8-bit ID select code, usually
-expressed in hex format. To activate the CI-V interface, the
-<tt>mode</tt> keyword of the <tt>server</tt> configuration command
-specifies a nonzero select code in decimal format. A table of ID select
-codes for the known ICOM radios is given below. Since all ICOM select
-codes are less than 128, the high order bit of the code is used by the
-driver to specify the baud rate. If this bit is not set, the rate is
-9600 bps for the newer radios; if set, the rate is 1200 bps for the
-older radios. A missing <tt>mode</tt> keyword or a zero argument leaves
-the interface disabled.
-
-<p>If specified, the driver will attempt to open the device
-<tt>/dev/icom</tt> and, if successful will tune the radio to 3.330 MHz.
-If after five minutes at this frequency not more than two format A
-bursts have been received for any minute, the driver will tune to 7.335
-MHz, then to 14.670 MHz, then return to 3.330 MHz and continue in this
-cycle. However, the driver is liberal in what it assumes of the
-configuration. If the <tt>/dev/icom</tt> link is not present or the open
-fails or the CI-V bus or radio is inoperative, the driver quietly gives
-up with no harm done.
+<p>The driver includes provisions to automatically tune the radio in response to changing radio propagation conditions throughout the day and night. The radio interface is compatible with the ICOM CI-V standard, which is a bidirectional serial bus operating at TTL levels. The bus can be connected to a standard serial port using a level converter such as the CT-17. The serial port speed is presently compiled in the program, but can be changed in the <tt>icom.h</tt> header file.
+
+<p>Each ICOM radio is assigned a unique 8-bit ID select code, usually expressed in hex format. To activate the CI-V interface, the <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies a nonzero select code in decimal format. A table of ID select codes for the known ICOM radios is given below. Since all ICOM select codes are less than 128, the high order bit of the code is used by the driver to specify the baud rate. If this bit is not set, the rate is 9600 bps for the newer radios; if set, the rate is 1200 bps for the older radios. A missing <tt>mode</tt> keyword or a zero argument leaves the interface disabled.
+
+<p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will tune the radio to 3.330 MHz. If after five minutes at this frequency not more than two format A bursts have been received for any minute, the driver will tune to 7.335 MHz, then to 14.670 MHz, then return to 3.330 MHz and continue in this cycle. However, the driver is liberal in what it assumes of the configuration. If the <tt>/dev/icom</tt> link is not present or the open fails or the CI-V bus or radio is inoperative, the driver quietly gives up with no harm done.
<h4>Radio Broadcast Format</h4>
-<p>The CHU time broadcast includes an audio signal compatible with the
-Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It consist of
-nine, ten-character bursts transmitted at 300 b/s and beginning each
-second from second 31 to second 39 of the minute. Each character
-consists of eight data bits plus one start bit and two stop bits to
-encode two hex digits. The burst data consist of five characters (ten
-hex digits) followed by a repeat of these characters. In format A, the
-characters are repeated in the same polarity; in format B, the
-characters are repeated in the opposite polarity.
+<p>The CHU time broadcast includes an audio signal compatible with the Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It consist of nine, ten-character bursts transmitted at 300 b/s and beginning each second from second 31 to second 39 of the minute. Each character consists of eight data bits plus one start bit and two stop bits to encode two hex digits. The burst data consist of five characters (ten hex digits) followed by a repeat of these characters. In format A, the characters are repeated in the same polarity; in format B, the characters are repeated in the opposite polarity.
-<p>Format A bursts are sent at seconds 32 through 39 of the minute in
-hex digits
+<p>Format A bursts are sent at seconds 32 through 39 of the minute in hex digits
<p><tt>6dddhhmmss6dddhhmmss</tt>
-<p>The first ten digits encode a frame marker (<tt>6</tt>) followed by
-the day (<tt>ddd</tt>), hour (<tt>hh</tt>), minute (<tt>mm</tt>) and
-second (<tt>ss</tt>). Since format A bursts are sent during the
-third decade of seconds the tens digit of <tt>ss</tt> is always 3. The
-driver uses this to determine correct burst synchronization. These
-digits are then repeated with the same polarity.
+
+<p>The first ten digits encode a frame marker (<tt>6</tt>) followed by the day (<tt>ddd</tt>), hour (<tt>hh</tt>), minute (<tt>mm</tt>) and second (<tt>ss</tt>). Since format A bursts are sent during the third decade of seconds the tens digit of <tt>ss</tt> is always 3. The driver uses this to determine correct burst synchronization. These digits are then repeated with the same polarity.
+
<p>Format B bursts are sent at second 31 of the minute in hex digits
<p><tt>xdyyyyttaaxdyyyyttaa</tt>
-<p>The first ten digits encode a code (<tt>x</tt> described below)
-followed by the DUT1 (<tt>d</tt> in deciseconds), Gregorian year
-(<tt>yyyy</tt>), difference TAI - UTC (<tt>tt</tt>) and daylight time
-indicator (<tt>aa</tt>) peculiar to Canada. These digits are then
-repeated with inverted polarity.
+<p>The first ten digits encode a code (<tt>x</tt> described below) followed by the DUT1 (<tt>d</tt> in deciseconds), Gregorian year (<tt>yyyy</tt>), difference TAI - UTC (<tt>tt</tt>) and daylight time indicator (<tt>aa</tt>) peculiar to Canada. These digits are then repeated with inverted polarity.
<p>The <tt>x</tt> is coded
<dd>Leap second warning. One second will be added.</dd>
<dt><tt>4</tt>
-<dd>Leap second warning. One second will be subtracted. This is not
-likely to happen in our universe.</dd>
+<dd>Leap second warning. One second will be subtracted. This is not likely to happen in our universe.</dd>
<dt><tt>8</tt>
<dd>Even parity bit for this nibble.</dd>
</dl>
-<p>By design, the last stop bit of the last character in the burst
-coincides with 0.5 second. Since characters have 11 bits and are
-transmitted at 300 b/s, the last stop bit of the first character
-coincides with 0.5 - 10 * 11/300 = 0.133 second. Depending on the UART,
-character interrupts can vary somewhere between the beginning of bit 9
-and end of bit 11. These eccentricities can be corrected along with the
-radio propagation delay using the <tt>fudge time1</tt> variable.
+<p>By design, the last stop bit of the last character in the burst coincides with 0.5 second. Since characters have 11 bits and are transmitted at 300 b/s, the last stop bit of the first character coincides with 0.5 - 10 * 11/300 = 0.133 second. Depending on the UART, character interrupts can vary somewhere between the beginning of bit 9 and end of bit 11. These eccentricities can be corrected along with the radio propagation delay using the <tt>fudge time1</tt> variable.
<h4>Debugging Aids</h4>
-<p>The most convenient way to track the program status is using the
-<tt>ntpq</tt> program and the <tt>clockvar</tt> command. This displays
-the last determined timecode and related status and error counters, even
-when the program is not discipline the system clock. If the debugging
-trace feature (<tt>-d</tt> on the <tt>ntpd</tt> command line)is enabled,
-the program produces detailed status messages as it operates. If the
-<tt>fudge flag 4</tt> is set, these messages are written to the
-<tt>clockstats</tt> file. All messages produced by this driver have the
-prefix <tt>chu</tt> for convenient filtering with the Unix <tt>grep</tt>
-command.
+<p>The most convenient way to track the program status is using the <tt>ntpq</tt> program and the <tt>clockvar</tt> command. This displays the last determined timecode and related status and error counters, even when the program is not discipline the system clock. If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt> command line)is enabled, the program produces detailed status messages as it operates. If the <tt>fudge flag 4</tt> is set, these messages are written to the <tt>clockstats</tt> file. All messages produced by this driver have the prefix <tt>chu</tt> for convenient filtering with the Unix <tt>grep</tt> command.
-<p>With debugging enabled the driver produces messages in the following
-formats:
+<p>With debugging enabled the driver produces messages in the following formats:
-<p>A format <tt>chuA</tt> message is produced for each format A burst
-received in seconds 32 through 39 of the minute:
+<p>A format <tt>chuA</tt> message is produced for each format A burst received in seconds 32 through 39 of the minute:
<p><tt>chuA n b s code</tt>
-<p>where <tt>n</tt> is the number of characters in the burst (0-11),
-<tt>b</tt> the burst distance (0-40), <tt>s</tt> the synchronization
-distance (0-40) and <tt>code</tt> the burst characters as received. Note
-that the hex digits in each character are reversed and the last ten
-digits inverted, so the burst
+<p>where <tt>n</tt> is the number of characters in the burst (0-11), <tt>b</tt> the burst distance (0-40), <tt>s</tt> the synchronization distance (0-40) and <tt>code</tt> the burst characters as received. Note that the hex digits in each character are reversed and the last ten digits inverted, so the burst
+
<p><tt>11 40 1091891300ef6e76ecff</tt>
-<p>is interpreted as containing 11 characters with burst distance 40.
-The nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI -
-UTC 31 seconds.
-<p>A format <tt>chuB</tt> message is produced for each format B burst
-received in second 31 of the minute:
+<p>is interpreted as containing 11 characters with burst distance 40. The nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI -UTC 31 seconds.
+
+<p>A format <tt>chuB</tt> message is produced for each format B burst received in second 31 of the minute:
<p><tt>chuB n b f s m code</tt>
-<p>where <tt>n</tt> is the number of characters in the burst (0-11),
-<tt>b</tt> the burst distance (0-40), <tt>f</tt> the field alignment (-
-1, 0, 1), <tt>s</tt>the synchronization distance (0-16), <tt>m</tt>the
-burst number (2-9) and <tt>code</tt> the burst characters as received.
-Note that the hex digits in each character are reversed, so the burst
+<p>where <tt>n</tt> is the number of characters in the burst (0-11), <tt>b</tt> the burst distance (0-40), <tt>f</tt> the field alignment (-1, 0, 1), <tt>s</tt>the synchronization distance (0-16), <tt>m</tt>the burst number (2-9) and <tt>code</tt> the burst characters as received. Note that the hex digits in each character are reversed, so the burst
<p><tt>10 38 0 16 9 06851292930685129293</tt>
-<p>is interpreted as containing 11 characters with burst distance 38,
-field alignment 0, synchronization distance 16 and burst number 9. The
-nibble-swapped timecode shows day 58, hour 21, minute 29 and second 39.
+<p>is interpreted as containing 11 characters with burst distance 38, field alignment 0, synchronization distance 16 and burst number 9. The nibble-swapped timecode shows day 58, hour 21, minute 29 and second 39.
-<p>If the CI-V interface for ICOM radios is active, a debug level
-greater than 1 will produce a trace of the CI-V command and response
-messages. Interpretation of these messages requires knowledge of the
-CI-V protocol, which is beyond the scope of this document.
+<p>If the CI-V interface for ICOM radios is active, a debug level greater than 1 will produce a trace of the CI-V command and response messages. Interpretation of these messages requires knowledge of the CI-V protocol, which is beyond the scope of this document.
<h4>Monitor Data</h4>
-When enabled by the <tt>filegen</tt> facility, every received timecode
-is written to the <tt>clockstats</tt> file in the following format:
+When enabled by the <tt>filegen</tt> facility, every received timecode is written to the <tt>clockstats</tt> file in the following format:
<pre>
sq yy ddd hh:mm:ss.fff ld dut lset agc rfrq bcnt dist tsmp
tsmp timestamps captured
</pre>
-The fields beginning with <tt>year</tt> and extending through
-<tt>dut</tt> are decoded from the received data and are in fixed-length
-format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the
-following driver-dependent fields, are in variable-length format.
+The fields beginning with <tt>year</tt> and extending through <tt>dut</tt> are decoded from the received data and are in fixed-length format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the following driver-dependent fields, are in variable-length format.
<dl>
<dt><tt>s</tt>
-<dd>The sync indicator is initially <tt>?</tt> before the clock is set,
-but turns to space when the clock is correctly set.</dd>
+<dd>The sync indicator is initially <tt>?</tt> before the clock is set, but turns to space when the clock is correctly set.</dd>
<dt><tt>q</tt>
-<dd>The quality character is a four-bit hexadecimal code showing which
-alarms have been raised during the most recent minute. Each bit is
-associated with a specific alarm condition according to the following:
+<dd>The quality character is a four-bit hexadecimal code showing which alarms have been raised during the most recent minute. Each bit is associated with a specific alarm condition according to the following:
<dl>
<dt><tt>8</tt>
-<dd>Decoder alarm. A majority of repetitions for at least one digit of
-the timecode fails to agree.
+<dd>Decoder alarm. A majority of repetitions for at least one digit of the timecode fails to agree.
</dd>
<dt><tt>4</tt>
<dd>Timestamp alarm. Fewer than 20 timestamps have been determined.</dd>
<dt><tt>2</tt>
-<dd>Format alarm. The majority timecode contains invalid bit
-combinations.</dd>
+<dd>Format alarm. The majority timecode contains invalid bit combinations.</dd>
<dt><tt>1</tt>
-<dd>Frame alarm. A framing or format error occurred on at least one
-burst during the minute.</dd>
+<dd>Frame alarm. A framing or format error occurred on at least one burst during the minute.</dd>
</dl>
-It is important to note that one or more of the above alarms does not
-necessarily indicate a clock error, but only that the decoder has
-detected a condition that may in future result in an error.
+It is important to note that one or more of the above alarms does not necessarily indicate a clock error, but only that the decoder has detected a condition that may in future result in an error.
<dt><tt>yyyy ddd hh:mm:ss.fff</tt></tt>
-<dd>The timecode format itself is self explanatory. Note that the
-Gregorian year is decoded directly from the transmitted timecode.</dd>
+<dd>The timecode format itself is self explanatory. Note that the Gregorian year is decoded directly from the transmitted timecode.</dd>
+
<dt><tt>l</tt>
-<dd>The leap second warning is normally space, but changes to <tt>L</tt>
-if a leap second is to occur at the end of the month of June or
-December.</dd>
+<dd>The leap second warning is normally space, but changes to <tt>L</tt> if a leap second is to occur at the end of the month of June or December.</dd>
<dt><tt>d</tt>
<dd>The DST code for Canada encodes the state for all provinces.</dd>
<dt><tt>dut</tt>
-<dd>The DUT sign and magnitude shows the current UT1 offset relative to
-the displayed UTC time, in deciseconds.</dd>
+<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds.</dd>
<dt><tt>lset</tt>
-<dd>Before the clock is set, the interval since last set is the number
-of minutes since the program was started; after the clock is set, this
+<dd>Before the clock is set, the interval since last set is the number of minutes since the program was started; after the clock is set, this
is number of minutes since the time was last verified relative to the
broadcast signal.</dd>
if not.</dd>
<dt><tt>bcnt</tt>
-<dd>The number of format A bursts received during the most recent minute
-bursts were received.</dd>
+<dd>The number of format A bursts received during the most recent minute bursts were received.</dd>
<dt><tt>dist</tt>
-<dd>The minimum decoding distance determined during the most recent
-minute bursts were received.</dd>
+<dd>The minimum decoding distance determined during the most recent minute bursts were received.</dd>
<dt><tt>tsmp</tt>
-<dd>The number of timestamps determined during the most recent
-minute bursts were received.</dd>
+<dd>The number of timestamps determined during the most recent minute bursts were received.</dd>
</dl>
<h4>Modes</h4>
-<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration
-command specifies the ICOM ID select code. A missing or zero argument
-disables the CI-V interface. Following are the ID select codes for the
-known radios.
+<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies the ICOM ID select code. A missing or zero argument disables the CI-V interface. Following are the ID select codes for the known radios.
<p><table cols=6 width=100%>
<dl>
<dt><tt>time1 <I>time</I></tt></dt>
-<dd>Specifies the propagation delay for CHU (45:18N 75:45N), in seconds
-and fraction, with default 0.0.</dd>
+<dd>Specifies the propagation delay for CHU (45:18N 75:45N), in seconds and fraction, with default 0.0.</dd>
<dt><tt>time2 <I>time</I></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <I>number</I></tt></dt>
-<dd>Specifies the driver stratum, in decimal from 0 to 15, with default
-0.</dd>
+<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd>
<dt><tt>refid <I>string</I></tt></dt>
-<dd>Specifies the driver reference identifier, an ASCII string from one
-to four characters, with default <tt>CHU</tt>.</dd>
+<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>CHU</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
-<dd>When the audio driver is compiled, this flag selects the audio input
-port, where 0 is the mike port (default) and 1 is the line-in port. It
-does not seem useful to select the compact disc player port.</dd>
+<dd>When the audio driver is compiled, this flag selects the audio input port, where 0 is the mike port (default) and 1 is the line-in port. It does not seem useful to select the compact disc player port.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
-<dd>When the audio driver is compiled, this flag enables audio
-monitoring of the input signal. For this purpose, the speaker volume
-must be set before the driver is started.</dd>
+<dd>When the audio driver is compiled, this flag enables audio monitoring of the input signal. For this purpose, the speaker volume must be set before the driver is started.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<h4>Additional Information</h4>
+
<A HREF="refclock.htm">Reference Clock Drivers</A>
<br><A HREF="audio.htm">Reference Clock Audio Drivers</A>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
Executive Summary - Computer Network Time Synchronization
</h3>
-<img align=left src=pic/alice12.gif><a href=pictures.htm>
+<img align=left src=pic/alice12.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The executive is the one on the left.
<br clear=left><hr>
-<p><h4>Introduction</h4>
-
-<p>Many radio clocks used as a primary reference source for NTP servers
-produce a pulse-per-second (PPS) signal that can be used to improve
-accuracy to a high degree. However, the signals produced are usually
-incompatible with the modem interface signals on the serial ports used
-to connect the signal to the host. The gadget box consists of a handful
-of electronic components assembled in a small aluminum box. It includes
-level converters and a optional radio modem designed to decode the radio
-timecode signals transmitted by the Canadian time and frequency station
-CHU. A complete set of schematics, PCB artwork, drill templates can be
-obrtained via the web as the distribution <a href=
-"http://www.eecis.udel.edu/~mills/ntp/ntp">gadget.tar.Z</a>, or by
-anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
-
-<p>The gadget box is assembled in a 5"x3"x2" aluminum
-minibox containing the level converter and modem circuitry. It includes
-two subcircuits. One of these converts a TTL positive edge into a fixed-
-width pulse at EIA levels and is for use with a timecode receiver or
-oscillator including a TTL PPS output. The other converts the timecode
-modulation broadcast by Canadian time/frequency standard station CHU
-into a 300-bps serial character stream at EIA levels and is for use with
-the <code>tty_clk</code> and <code>chu_tty</code> line disciplines in
-the ntp3 distribution.
-
-<p>This archive contains complete construction details for the gadget
-box, including schematic, parts list and artwork for a two-sided,
-printed-circuit board. All files are in PostScript, with the exception
-of this file and an information file, which are in ASCII. The artwork is
-in the 1:1 scale and is suitable for direct printing on photographic
-resist for each side of the board. While a plated-through-holes process
-is most convenient, it is possible to bridge the two sides using
-soldered wires where necessary.
-
-<p><h4>Circuit Description</h4>
-
-<p>Following is a brief functional description of the device. See the
-schematic diagram gadget.s01 for reference. The audio output of a
-shortwave radio tuned to CHU at 3330, 7335 or 14670 kHz is connected to
-J2. A level of at least 30 mV peak-peak is required, such as provided by
-the recorder output on many receivers. The input level is adjusted by
-potentiometer R8 so that the timecode modulation broadcast at 31-39
-seconds past the minute reliably lights green LED1, but the signals
-broadcast during other seconds of the minute do not.
-
-<p>Opamp U4A provides low-impedance drive for the bridged-tee bandpass
-filter U4B. The filter has a bandpass of about 600 Hz at the 6-dB points
-and a center frequency of about 2150 Hz. It is designed to avoid
-aliasing effects with receivers of relatively wide bandpass
-characteristics. The modem itself is implemented by U2 and its
-associated circuitry. Resistors R4 and R1 are a 40-dB pad which matches
-the filter output to the modem input. U2 is a TTL/EIA level converter
-with integral power supply for bipolar signals. The modem output is
-available at pin 3 (receive data) of DB25 connector J1.
-
-<p>The TTL PPS signal is connected via J3 to a retriggerable one-shot
-U3A, which generates a TTL pulse of width determined by potentiometer
-R7. The pulse width is determined by the bit rate of the attached serial
-port. In the common case the width is one bit-time, such as 26 us for
-38.4 kbps, for example. This appears to the port as a single start bit
-of zero followed by eight bits of ones and a stop bit of one. The second
-one-shot U3B generates a 200-ms pulse suitable for driving the amber
-LED3 as a visual monitor. The output of U3A is converted to EIA levels
-by U1 and appears at pin 12 (secondary receive data) of J1.
-
-<p>If only the PPS circuit is required, U2 and U4 can be deleted and the
-gadget box powered from the EIA modem-control signal at pin 20 (terminal
-ready) of J1, assuming this signal is placed in the on (positive
-voltage) condition by the computer program. J1 is wired to keep most
-finicky UARTs and terminal-driver programs happy. If the CHU circuit is
-required, an external 12-volt AC transformer or 9-12-volt DC supply
-connected to J4 is required. Red LED2 indicates power is supplied to the
-box.
+<h4>Introduction</h4>
+
+<p>Many radio clocks used as a primary reference source for NTP servers produce a pulse-per-second (PPS) signal that can be used to improve accuracy to a high degree. However, the signals produced are usually incompatible with the modem interface signals on the serial ports used to connect the signal to the host. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional radio modem designed to decode the radio timecode signals transmitted by the Canadian time and frequency station CHU. A complete set of schematics, PCB artwork, drill templates can be obrtained via the web as the distribution <a href= "http://www.eecis.udel.edu/~mills/ntp/ntp">gadget.tar.Z</a>, or by anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
+
+<p>The gadget box is assembled in a 5"x3"x2" aluminum minibox containing the level converter and modem circuitry. It includes two subcircuits. One of these converts a TTL positive edge into a fixed-width pulse at EIA levels and is for use with a timecode receiver or oscillator including a TTL PPS output. The other converts the timecode modulation broadcast by Canadian time/frequency standard station CHU into a 300-bps serial character stream at EIA levels and is for use with the <a href=driver7.htm>Radio CHU Audio Demodulator/Decoder</a> driver.
+
+<p>This archive contains complete construction details for the gadget box, including schematic, parts list and artwork for a two-sided, printed-circuit board. All files are in PostScript, with the exception of this file and an information file, which are in ASCII. The artwork is in the 1:1 scale and is suitable for direct printing on photographic resist for each side of the board. While a plated-through-holes process is most convenient, it is possible to bridge the two sides using soldered wires where necessary.
+
+<h4>Circuit Description</h4>
+
+<p>Following is a brief functional description of the device. See the schematic diagram gadget.s01 for reference. The audio output of a shortwave radio tuned to CHU at 3330, 7335 or 14670 kHz is connected to J2. A level of at least 30 mV peak-peak is required, such as provided by the recorder output on many receivers. The input level is adjusted by potentiometer R8 so that the timecode modulation broadcast at 31-39 seconds past the minute reliably lights green LED1, but the signals broadcast during other seconds of the minute do not.
+
+<p>Opamp U4A provides low-impedance drive for the bridged-tee bandpass filter U4B. The filter has a bandpass of about 600 Hz at the 6-dB points and a center frequency of about 2150 Hz. It is designed to avoid aliasing effects with receivers of relatively wide bandpass characteristics. The modem itself is implemented by U2 and its associated circuitry. Resistors R4 and R1 are a 40-dB pad which matches the filter output to the modem input. U2 is a TTL/EIA level converter with integral power supply for bipolar signals. The modem output is available at pin 3 (receive data) of DB25 connector J1.
+
+<p>The TTL PPS signal is connected via J3 to a retriggerable one-shot U3A, which generates a TTL pulse of width determined by potentiometer R7. The pulse width is determined by the bit rate of the attached serial port. In the common case the width is one bit-time, such as 26 us for 38.4 kbps, for example. This appears to the port as a single start bit of zero followed by eight bits of ones and a stop bit of one. The second one-shot U3B generates a 200-ms pulse suitable for driving the amber LED3 as a visual monitor. The output of U3A is converted to EIA levels by U1 and appears at pin 12 (secondary receive data) of J1.
+
+<p>If only the PPS circuit is required, U2 and U4 can be deleted and the gadget box powered from the EIA modem-control signal at pin 20 (terminal ready) of J1, assuming this signal is placed in the on (positive voltage) condition by the computer program. J1 is wired to keep most finicky UARTs and terminal-driver programs happy. If the CHU circuit is required, an external 12-volt AC transformer or 9-12-volt DC supply
+connected to J4 is required. Red LED2 indicates power is supplied to the box.
<p>Files
-<p>Following is a list of files included in this archive. All files are
-in PostScript, except the <code>README</code> and
-<code>gadget.lst</code> files, which are in ASCII. The files
-<code>gadget.s01, gadget.s02</code> and <code>gadget.lst</code> were
-generated using the Schema schematic-capture program from Omation. The
-printed-circuit files <code>*.lpr</code> were generated using Schema-
-PCB, also from Omation.
+<p>Following is a list of files included in this archive. All files are in PostScript, except the <tt>README</tt> and <tt>gadget.lst</tt> files, which are in ASCII. The files <tt>gadget.s01, gadget.s02</tt> and <tt>gadget.lst</tt> were generated using the Schema schematic-capture program from Omation. The printed-circuit files <tt>*.lpr</tt> were generated using Schema-PCB, also from Omation.
<p>Files
-<p><code>README</code> - helpful information
-<br><code>gadget.s01</code> - circuit schematic
-<br><code>gadget.s02</code> - minibox assembly drawing
-<br><code>gadget.lst</code> - net list, pin list, parts list, etc.
-<br><code>gen0102.lpr</code> - pcb x-ray diagram
-<br><code>art01.lpr</code> - pcb artword side 1
-<br><code>art02.lpr</code> - pcb artwork side 2
-<br><code>adt0127.lpr</code> - pcb assembly drawing
-<br><code>dd0124.lpr</code> - pcb drill drawing
-<br><code>sm0228.lpr</code> - pcb solder mask (side 2)
-<br><code>sst0126.lpr</code> - pcb silkscreen mask (side 1)
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+<p><tt>README</tt> - helpful information
+<br><tt>gadget.s01</tt> - circuit schematic
+<br><tt>gadget.s02</tt> - minibox assembly drawing
+<br><tt>gadget.lst</tt> - net list, pin list, parts list, etc.
+<br><tt>gen0102.lpr</tt> - pcb x-ray diagram
+<br><tt>art01.lpr</tt> - pcb artword side 1
+<br><tt>art02.lpr</tt> - pcb artwork side 2
+<br><tt>adt0127.lpr</tt> - pcb assembly drawing
+<br><tt>dd0124.lpr</tt> - pcb drill drawing
+<br><tt>sm0228.lpr</tt> - pcb solder mask (side 2)
+<br><tt>sst0126.lpr</tt> - pcb silkscreen mask (side 1)
+
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
<tt>ntp_genkeys</tt> - generate public and private keys
</title></head><body><h3>
<tt>ntp_genkeys</tt> - generate public and private keys
-</h3><hr>
+</h3>
+
+<img align=left src=pic/alice23.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Alice holds the key.
+<br clear=left><hr>
<h4>Synopsis</h4>
Hints and Kinks
</title></head><body><h3>
Hints and Kinks
-</h3><hr>
+</h3>
+
+<img align=left src=pic/alice35.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Mother in law has all the answers.
+<br clear=left><hr>
<p>This is an index for a set of troubleshooting notes contained in
individual text files in the <tt>./hints</tt> directory. They were
operating system (specific version(s) where appropriate), problem
description, problem solution and submitter's name and electric address.
If the submitter is willing to continue debate on the problem, please so
-advise. Bash <a href=http:hints>here</a> for a directory listing.
+advise. See the <a href=http:hints>directory listing</a>.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
How to Write a Reference Clock Driver
</title></head><body><h3>
How to Write a Reference Clock Driver
-</h3><hr>
+</h3>
+
+<img align=left src=pic/pogo4.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>You need a little magic.
+<br clear=left><hr>
<h4>Description</h4>
The Network Time Protocol (NTP) Distribution
</h3>
-<IMG align=left SRC=pic/barnstable.gif>From <i>pogo</i>, Walt Kelly
+<img align=left src=pic/barnstable.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
<p>Pleased to meet you.
-<br clear=left><HR>
+<br clear=left><hr>
<h4>Introduction</h4>
Note: The software contained in this distribution is available without charge under the conditions set forth in the <a href=copyright.htm>Copyright Notice</a>.
-<p>The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides client accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to a primary server synchronized to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks.
+<p>The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks and some provide automatic server discovery using IP multicast.
-<p>Background information on computer network time synchronization can be found on the <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found in the <a href=biblio.htm>Protocol Conformance Statement</a> page. Discussion on year-2000 issues can be found in the <a href=y2k.htm>Year 2000 Conformance Statement page</a>. Background information, bibliography and briefing slides suitable for presentations can be found in the <a href=http://www.eecis.udel.edu/~mills/ntp.htm> Network Time Synchronization Project</a> page. Additional information can be found at the NTP web site <
tt>www.ntp.org</tt>. Please send bug reports to <a href=mailto:bugs@mail.ntp.org><bugs@mail.ntp.org></a>.
+<p>Background information on computer network time synchronization can be found on the <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found in the <a href=biblio.htm>Protocol Conformance Statement</a> page. Discussion on year-2000 issues can be found in the <a href=y2k.htm>Year 2000 Conformance Statement page</a>. Background information, bibliography and briefing slides suitable for presentations can be found in the <a href=http://www.eecis.udel.edu/~mills/ntp.htm> Network Time Synchronization Project</a> page. Additional information can be found at the NTP web site <
a href=http://www.ntp.org>www.ntp.org</a>. Please send bug reports to <a href=mailto:bugs@mail.ntp.org><bugs@mail.ntp.org></a>.
<h4>Building and Installing NTP</h4>
<p>NTP is by its very nature a complex distributed network application and can be configured and used for a great many widely divergent timekeeping scenarios. The documentation presented on these pages attempts to cover the entire suite of configuration, operation and maintenance facilities which this distribution supports. However, most applications will need only a few of these facilities. If this is the case, the <a href=quick.htm>Quick Start</a> page may be useful to get a simple workstation on the air with an existing server.
-<p>However, in order to participate in the existing NTP synchronization subnet and obtain accurate, reliable time, it is usually necessary to construct an appropriate configuration file, commonly called <tt>ntp.conf</tt>, which establishes the servers and/or external receivers or modems to be used by this particular machine. Directions for constructing this file are in the <a href=notes.htm>Notes on Configuring NTP and Setting up a NTP Subnet</a> page. However, in many common cases involving simple network topologies and workstations, the file data can be specified entirely on the command line.
+<p>However, in order to participate in the existing NTP synchronization subnet and obtain accurate, reliable time, it is usually necessary to construct an appropriate configuration file, commonly called <tt>ntp.conf</tt>, which establishes the servers and/or external receivers or modems to be used by this particular machine. Directions for constructing this file are in the <a href=notes.htm>Notes on Configuring NTP and Setting up a NTP Subnet</a> page. However, in many common cases involving simple network topologies and workstations, the cpnfiguration data can be specified entirely on the command line for the <a href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>.
-<p>The most important factor in providing accurate, reliable time is the selection of modes and servers to be used in the configuration file. NTP support for one or more computers is normally engineered as part of the existing NTP synchronization subnet. The existing NTP subnet consists of a multiply redundant hierarchy of servers and clients, with each level in the hierarchy identified by stratum number. Primary servers operate at stratum one and provide synchronization to secondary servers operating at stratum two and so on to higher strata. In this hierarchy, clients are simply servers that have no dependents.
+<p>The most important factor in providing accurate, reliable time is the selection of modes and servers to be used in the configuration file. A discussion on the available modes is on the <a href=assoc.htm>Association Management</a> page. NTP support for one or more computers is normally engineered as part of the existing NTP synchronization subnet. The existing NTP subnet consists of a multiply redundant hierarchy of servers and clients, with each level in the hierarchy identified by stratum number. Primary servers operate at stratum one and provide synchronization to secondary servers operating at stratum two and so on to higher strata. In this hierarchy, clients are simply servers that have no dependents.
-<p>The NTP subnet in late 2000 includes
103 public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe, including Antarctica. Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are 116 public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total in excess of 100,000 clients and servers in the Internet. The current lists are maintained in the <a href=http://www.eecis.udel.edu/~mills/ntp/index.htm>Information on Time and Frequency Services</a> page, which is updated frequently. There are numerous private primary and secondary servers not normally available to the public as well. You are strongly discouraged from using these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and your traffic can bring up expensive ISDN lines, causing much grief and frustration.
+<p>The NTP subnet in late 2000 includes
pver a hundred public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe, including Antarctica. Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are over a hundred public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total in excess of 100,000 clients and servers in the Internet. The current lists are maintained in the <a href=http://www.eecis.udel.edu/~mills/ntp/index.htm>Information on Time and Frequency Services</a> page, which is updated frequently. There are numerous private primary and secondary servers not normally available to the public as well. You are strongly discouraged from using these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and your traffic can bring up expensive ISDN lines, causing much grief and frustration.
<h4>Resolving Problems</h4>
<ul>
-<LI<a href=ntp.htm>NTP Reference Library</a></li>
+<li><a href=http://www.eecis.udel.edu/~mills/ntp.htm>NTP Reference Library</a></li>
<li><a href=copyright.htm>Copyright Notice</a></li>
<li><a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a></li>
<li><a href=biblio.htm>Protocol Conformance Statement</a></li>
<li><a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a></li>
<li><a href=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</a></li>
<li><a href=measure.htm>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</a></li>
-<li><a href=kern.htm>A Kernel Model for Precision Timekeeping</a></li>
-<li><a href=kernpps.htm>A Kernel Programming Interface for Precision Time Signals</a></li>
+<li><a href=kern.htm>Kernel Model for Precision Timekeeping</a></li>
+<li><a href=kernpps.htm>Kernel Programming Interface for Precision Time Signals</a></li>
+
</ul>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
+<hr><center><img src=pic/pogo1a.gif></center>
+
+<a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
<html><head><title>
-A Kernel Model for Precision Timekeeping
+Kernel Model for Precision Timekeeping
</title></head><body><h3>
-A Kernel Model for Precision Timekeeping
+Kernel Model for Precision Timekeeping
</h3><hr>
-<p>The technical memorandum: Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf>PDF</a> Major revision and update of: Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</a>, describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators using phase-lock loops (PLL) and frequency-lock loops (FLL) often found in the engineering literature. The model uses a hybrid PLL/FLL discipline algorithm implemented in the kernel. The hybrid loop provides automatic time and frequency steering with update intervals from a few seconds to over one day.
+<p>The technical report [2], which is a major revision and update of an earlier report [3], describes an engineering model for a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators using phase-lock loops (PLL) and frequency-lock loops (FLL) often found in the engineering literature. The model uses a hybrid PLL/FLL discipline algorithm implemented in the kernel. The hybrid loop provides automatic time and frequency steering with update intervals from a few seconds to over one day.
-<p>The hybrid PLL/FLL has been implemented in the Unix kernels for several operating systems, including FreeBSD and Linux and those made by Sun Microsystems, Digital/Compaq and Hewlett Packard. The modifications are currently included in the licensed kernels for Digital Unix 4.0 (aka Tru64) and Sun Solaris 2.8. Since the modifications involve proprietary kernel interface code, they cannot be provided for other licensed kernels directly. Inquiries should be directed to the manufacturer's representatives. The software and documentation, including a simulator with code segments almost identical to the implementations, but not involving licensed code, is available via the web at <a HREF="http://www.eecis.udel.edu/~mills/ntp/ntp">kernel.tar.Z</a> or by anonymous FTP from ftp.udel.edu in the <tt>pub/ntp</tt> directory.
+<p>The hybrid PLL/FLL has been implemented in the Unix kernels for several operating systems, including FreeBSD and Linux and those made by Sun Microsystems, Digital/Compaq and Hewlett Packard. The modifications are currently included in the licensed kernels for Digital Unix 4.0 (aka Tru64) and Sun Solaris 2.8. Since the modifications involve proprietary kernel interface code, they cannot be provided for other licensed kernels directly. Inquiries should be directed to the manufacturer's representatives. The software and documentation, including a simulator with code segments almost identical to the implementations, but not involving licensed code, is called <tt>nanokernel.tar.gz</tt> and available via the web at <a href=http://www.ntp.org>www.ntp.org</a> or by anonymous FTP from ftp.udel.edu in the <tt>pub/ntp/software</tt> directory.
-<p>Recently, the model has been re-implemented to support a nanosecond system clock. Implementations are available for Linux, FreeBSD, SunOS and Tru64; however, only the Linux and FreeBSD implementations, which are included in recent system versions, are directly available. The software and documentation, including a simulator with code segments almost identical to the implementations, but not involving licensed code, is available via the web at <a HREF="http://www.eecis.udel.edu/~mills/ntp/ntp">nanokernel.tar.gz</a> or by anonymous FTP from ftp.udel.edu in the <tt>pub/ntp/software</tt> directory.
+<p>Recently [1], the model has been re-implemented to support a nanosecond system clock. The <tt>/usr/include/sys/timex.h</tt> header file defines the applications programming interface (API) routines and data structures. Implementations are available for Linux, FreeBSD, SunOS and Tru64; however, only the Linux and FreeBSD implementations, which are included in recent system versions, are directly available. The software and documentation, including a simulator with code segments almost identical to the implementations, but not involving licensed code, is called <tt>nanokernel.tar.gz</tt> and available via the web at <a href=http://www.ntp.org>www.ntp.org</a> or by anonymous FTP from ftp.udel.edu in the <tt>pub/ntp/software</tt> directory.
-<p>The model changes the way the system clock is adjusted in time and frequency, as well as provides mechanisms to discipline its time and frequency to an external precision timing source, such as described in the <a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a> page. The model incorporates a generic system-call interface for use with the Network Time Protocol (NTP) or similar time synchronization protocol. The NTP software daemons for Version 3 <tt>xntpd</tt> and Version 4 <tt>ntpd</tt> operate with this model to provide synchronization limited in principle only by the accuracy and stability of the external timing source. There are two new system calls defined in the model, <tt>ntp_gettime()</tt>, which returns a structure including the current time, estimated error and maximum error, and <tt>ntp_adjtime()</tt>, which provides a means to adjust kernel variables, including the current time and frequency offsets. Further information on the calling sequences and variable definitions are in the <tt>/usr/include/sys/timex.h</tt> file.
+<p>The model changes the way the system clock is adjusted in time and frequency, as well as provides mechanisms to discipline its time and frequency to an external precision timing source, such as described in the <a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a> page. The model incorporates a generic system call interface for use with the NTP or similar time synchronization protocol. The NTP software daemons for Version 3 <tt>xntpd</tt> and Version 4 <tt>ntpd</tt> use this API to provide synchronization limited in principle only by the accuracy and stability of the external timing source. There are two new system calls defined in <tt>timex.h</tt>, <tt>ntp_gettime()</tt>, which returns a structure including the current time, estimated error and maximum error, and <tt>ntp_adjtime()</tt>, which provides a means to adjust kernel variables, including the current time and frequency offsets.
+
+<p>These kernel modifications are normally used in conjunction with a kernel hardware interface such as described in the <a href=kernpps.htm>Kernel Programming Interface for Precision Time Signals</a> page.
+
+<h4>References</h4>
+
+<ol>
+
+<p><li>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href=database/papers/nano/nano2.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf>PDF</a>, Slides: <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.pdf>PDF</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ppt>PowerPoint</a></li>
+
+<p><li>Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps>PostScript</a> | <a href=database/reports/kern/kerna.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf>PDF</a></li>
+
+<p><li>Mills, D.L. A kernel model for precision timekeeping. Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</a></li>
+
+</ol>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
<html><head><title>
-A Kernel Programming Interface for Precision Time Signals
+Kernel Programming Interface for Precision Time Signals
Network Performance Evaluation
</title></head><body><h3>
-A Kernel Programming Interface for Precision Time Signals
+Kernel Programming Interface for Precision Time Signals
</h3><hr>
-<p>The technical memorandum: <cite>A Kernel Programming Interface for
-Precision Time Signals</cite><a
-href="http://www.eecis.udel.edu/~mills/database/memos/memo96c.ps">
-(PostScript) </a> describes a proposed programming interface for
-external precision time signals, such as the pulse-per-second (PPS)
-signal generated by some radio clocks and cesium oscillators.
-
-<p>The memorandum argues for a generic capability in the ubiquitous Unix
-kernel, which could be used for a wide variety of measurement
-applications, including network time synchronization and experiments
-involving performance measurement and evaluation of computer networks
-and transmission systems. The hardware to do this requires only a serial
-port and a modem control lead, such as the data carrier detect (DCD)
-lead, which can be driven by an external source via a level
-converter/pulse generator.
+<p>The technical report [1] describes a proposed application programming interface (API) for external precision time signals, such as the pulse-per-second (PPS) signal generated by some radio clocks and cesium oscillators. The report argues for a generic capability in the ubiquitous Unix kernel, which could be used for a wide variety of measurement applications, including network time synchronization and experiments involving performance measurement and evaluation of computer networks and transmission systems. The hardware to do this requires only a serial port and a modem control lead, such as the data carrier detect (DCD) lead, which can be driven by an external source via a level converter/pulse generator.
+
+<p>Support for this API has been implemented in the NTP Version 4 software distribution. The <tt>/usr/include/sys/timepps.h</tt> header file defines the API interface routines and data structures. The API obsoletes previous APIs based on the <tt>tty_clock</tt> and <tt>ppsclock</tt> line disciplines and streams modules, which are no longer supported. The API used by the <a href=driver22.htm>PPS Clock Discipline</a> driver (type 22) to support PPS signals via either a serial port or parallel port, depending on the operating system. The API is supported in stock FreeBSD from 3.4 and with the addition of the <tt>PPSkit</tt> kernel software in Linux. Limited support for Solaris from 2.8 is available using the <tt>timepps.h.solaris</tt> header file included in this distribution. Copy this file to <tt>/usr/include/sys</tt> before configuring the distributution.
+
+<p>The API is normally used in conjunction with the precision time kernel modifications described in the <a href=kern.htm>Kernel Model for Precision Timekeeping</a> page.
+
+<h4>Reference</h4>
+
+<ol>
+
+<p><li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2783.txt>ASCII</a>
+
+</ol>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
Miscellaneous Options
</title></head><body><h3>
Miscellaneous Options
-</h3><hr>
+</h3>
+
+<img align=left src=pic/boom3.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>We have three, now looking for more.
+<br clear=left><hr>
<dl>
Monitoring Options
</title></head><body><h3>
Monitoring Options
-</h3><hr>
+</h3>
+
+<img align=left src=pic/pogo8.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>The pig watches the logs.
+<br clear=left><hr>
<h4>Monitoring Support</h4>
-<HTML><HEAD><TITLE>
-<TT>ntpd</TT> - Network Time Protocol (NTP) daemon
-</TITLE></HEAD><BODY><H3>
-<TT>ntpd</TT> - Network Time Protocol (NTP) daemon
-</H3><HR>
+<html><head><title>
+<tt>ntpd</tt> - Network Time Protocol (NTP) daemon
+</title></head><body><h3>
+<tt>ntpd</tt> - Network Time Protocol (NTP) daemon
+</h3>
-<H4>Synopsis</H4>
+<img align=left src=pic/alice47.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>The mushroom knows all the command line options.
+<br clear=left><hr>
+
+<h4>Synopsis</h4>
<TT>ntpd [ -aAbdm ] [ -c <I>conffile</I> ] [ -f <I>driftfile</I> ] [ -g
] [ -k <I>keyfile</I> ] [ -l <I>logfile</I> ] [ -N high ] [ -p
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <TITLE>ntpdate - set the date and time via NTP
-</TITLE>
-</HEAD>
-<BODY>
-
-<H3>
-<TT>ntpdate</TT> - set the date and time via NTP</H3>
+<html><head><title>
+<tt>ntpdate</tt> - set the date and time via NTP
+</title></head><body><h3>
+<tt>ntpdate</tt> - set the date and time via NTP
+</h3>
+
+<img align=left src=pic/rabbit.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>I told you it was eyeball and wristwatch.
+<br clear=left><hr>
-<HR>
<H4>
Synopsis</H4>
<TT>ntpdate [ -bBdoqsuv ] [ -a <I>key</I> ] [ -e <I>authdelay</I> ] [ -k
ntpdc - special NTP query program
</title></head><body><h3>
<tt>ntpdc</tt> - special NTP query program
-</h3><hr>
+</h3>
+
+<img align=left src=pic/alice31.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>This program is a big puppy.
+<br clear=left><hr>
<h4>Synopsis</h4>
ntpq - standard NTP query program
</title></head><body><h3>
<tt>ntpq</tt> - standard NTP query program
-</h3><HR>
+</h3>
+
+<img align=left src=pic/bustardfly.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>A typical NTP monitoring packet.
+<br clear=left><hr>
<h4>Synopsis</h4>
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <TITLE>ntptime - read kernel time variables
-</TITLE>
-</HEAD>
-<BODY>
-
-<H3>
-<TT>ntptime</TT> - read kernel time variables</H3>
-
-<HR>
-<H4>
-Synopsis</H4>
-<TT>ntptime [ -chr ] [ -e <I>est_error</I> ] [ -f <I>frequency</I> ] [
--m <I>max_error</I> ] [ -o <I>offset</I> ] [ -s <I>status</I> ] [ -t <I>time_constant</I>
-]</TT>
-<H4>
-Description</H4>
-This program is useful only with special kernels described in the <A HREF="kern.htm">A
-Kernel Model for Precision Timekeeping </A>page. It reads and displays
-time-related kernel variables using the <TT>ntp_gettime()</TT> system call.
-A similar display can be obtained using the <TT>ntpdc</TT> program and
-<TT>kerninfo</TT> command.
-<H4>
-Options</H4>
+<HTML><HEAD><TITLE>
+ntptime - read kernel time variables
+</TITLE></HEAD><BODY><H3>
+<TT>ntptime</TT> - read kernel time variables
+</H3>
-<DL>
-<DT>
-<TT>-c</TT></DT>
-<DD>
-Display the execution time of <TT>ntptime</TT> itself.</DD>
+<img align=left src=pic/pogo5.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+
+<p>The turtle is been swimming in the kernel.
+<br clear=left><hr>
-<DT>
-<TT>-e <I>est_error</I></TT></DT>
+<h4>Synopsis</H4>
-<DD>
-Specify estimated error, in microseconds.</DD>
+<TT>ntptime [ -chr ] [ -e <I>est_error</I> ] [ -f <I>frequency</I> ] [ -m <I>max_error</I> ] [ -o <I>offset</I> ] [ -s <I>status</I> ] [ -t <I>time_constant</I>]</TT>
-<DT>
-<TT>-f <I>frequency</I></TT></DT>
+<H4>Description</H4>
-<DD>
-Specify frequency offset, in parts per million.</DD>
+This program is useful only with special kernels described in the <A HREF="kern.htm">A Kernel Model for Precision Timekeeping </A>page. It reads and displays time-related kernel variables using the <TT>ntp_gettime()</TT> system call. A similar display can be obtained using the <TT>ntpdc</TT> program and <TT>kerninfo</TT> command.
-<DT>
-<TT>-h</TT></DT>
+<H4>Options</H4>
-<DD>
-Display help information.</DD>
+<DL>
-<DT>
-<TT>-m <I>max_error</I></TT></DT>
+<DT><TT>-c</TT></DT>
+<DD>Display the execution time of <TT>ntptime</TT> itself.</DD>
-<DD>
-Specify max possible errors, in microseconds.</DD>
+<DT><TT>-e <I>est_error</I></TT></DT>
+<DD>Specify estimated error, in microseconds.</DD>
-<DT>
-<TT>-o <I>offset</I></TT></DT>
+<DT><TT>-f <I>frequency</I></TT></DT>
+<DD>Specify frequency offset, in parts per million.</DD>
-<DD>
-Specify clock offset, in microseconds.</DD>
+<DT><TT>-h</TT></DT>
+<DD>Display help information.</DD>
-<DT>
-<TT>-r</TT></DT>
+<DT><TT>-m <I>max_error</I></TT></DT>
+<DD>Specify max possible errors, in microseconds.</DD>
-<DD>
-Display Unix and NTP times in raw format.</DD>
+<DT><TT>-o <I>offset</I></TT></DT>
+<DD>Specify clock offset, in microseconds.</DD>
-<DT>
-<TT>-s <I>status</I></TT></DT>
+<DT><TT>-r</TT></DT>
+<DD>Display Unix and NTP times in raw format.</DD>
-<DD>
-Specify clock status. Better know what you are doing.</DD>
+<DT><TT>-s <I>status</I></TT></DT>
+<DD>Specify clock status. Better know what you are doing.</DD>
-<DT>
-<TT>-t <I>time_constant</I></TT></DT>
+<DT><TT>-t <I>time_constant</I></TT></DT>
+<DD>Specify time constant, an integer in the range 0-10.</DD>
-<DD>
-Specify time constant, an integer in the range 0-10.</DD>
</DL>
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
-
-</BODY>
-</HTML>
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <TITLE>ntptrace - trace a chain of NTP servers back to the primary
-source
-</TITLE>
-</HEAD>
-<BODY>
-
-<H3>
-<TT>ntptrace</TT> - trace a chain of NTP servers back to the primary source</H3>
-
-<HR>
-<H4>
-Synopsis</H4>
-<TT>ntptrace [ -vdn ] [ -r <I>retries</I> ] [ -t <I>timeout</I> ] [ <I>server</I>
-]</TT>
-<H4>
-Description</H4>
-<TT>ntptrace</TT> determines where a given Network Time Protocol (NTP)
-server gets its time from, and follows the chain of NTP servers back to
-their master time source. If given no arguments, it starts with <TT>localhost</TT>.
-Here is an example of the output from <TT>ntptrace</TT>:
-<PRE>% ntptrace
+<html><head><title>
+<tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source
+</title></head><body><h3>
+<tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source
+</h3>
+
+<img align=left src=pic/alice13.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>The rabbit knows the way back.
+<br clear=left><hr>
+
+<h4>Synopsis</h4>
+
+<tt>ntptrace [ -vdn ] [ -r <I>retries</I> ] [ -t <I>timeout</I> ] [ <I>server</I>
+]</tt>
+
+<h4>Description</h4>
+
+<p><tt>ntptrace</tt> determines where a given Network Time Protocol (NTP) server gets its time from, and follows the chain of NTP servers back to their master time source. If given no arguments, it starts with <tt>localhost</tt>. Here is an example of the output from <tt>ntptrace</tt>:
+
+<p><pre>% ntptrace
localhost: stratum 4, offset 0.0019529, synch distance 0.144135
server2ozo.com: stratum 2, offset 0.0124263, synch distance 0.115784
usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid
-'WWVB'</PRE>
-On each line, the fields are (left to right): the host name, the host stratum,
-the time offset between that host and the local host (as measured by <TT>ntptrace</TT>;
-this is why it is not always zero for "<TT>localhost</TT>"), the host synchronization
-distance, and (only for stratum-1 servers) the reference clock ID. All
-times are given in seconds. Note that the stratum is the server hop count
-to the primary source, while the synchronization distance is the estimated
-error relative to the primary source. These terms are precisely defined
-in RFC-1305.
-<H4>
-Options</H4>
-
-<DL>
-<DT>
-<TT>-d</TT></DT>
-
-<DD>
-Turns on some debugging output.</DD>
-
-<DT>
-<TT>-n</TT></DT>
-
-<DD>
-Turns off the printing of host names; instead, host IP addresses are given.
-This may be useful if a nameserver is down.</DD>
-
-<DT>
-<TT>-r <I>retries</I></TT></DT>
-
-<DD>
-Sets the number of retransmission attempts for each host (default = 5).</DD>
-
-<DT>
-<TT>-t <I>timeout</I></TT></DT>
-
-<DD>
-Sets the retransmission timeout (in seconds) (default = 2).</DD>
-
-<DT>
-<TT>-v</TT></DT>
-
-<DD>
-Prints verbose information about the NTP servers.</DD>
-</DL>
-
-<H4>
-Bugs</H4>
-This program makes no attempt to improve accuracy by doing multiple samples.
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
-
-</BODY>
-</HTML>
+'WWVB'</pre>
+
+On each line, the fields are (left to right): the host name, the host stratum, the time offset between that host and the local host (as measured by <tt>ntptrace</tt>; this is why it is not always zero for "<tt>localhost</tt>"), the host synchronization distance, and (only for stratum-1 servers) the reference clock ID. All times are given in seconds. Note that the stratum is the server hop count to the primary source, while the synchronization distance is the estimated error relative to the primary source. These terms are precisely defined in RFC-1305.
+
+<h4>Options</h4>
+
+<dl>
+
+<dt><tt>-d</tt></dt>
+<dd>Turns on some debugging output.</dd>
+
+<dt><tt>-n</tt></dt>
+<dd>Turns off the printing of host names; instead, host IP addresses are given. This may be useful if a nameserver is down.</dd>
+
+<dt><tt>-r <I>retries</I></tt></dt>
+<dd>Sets the number of retransmission attempts for each host (default = 5).</dd>
+
+<dt><tt>-t <I>timeout</I></tt></dt>
+<dd>Sets the retransmission timeout (in seconds) (default = 2).</dd>
+
+<dt><tt>-v</tt></dt>
+<dd>Prints verbose information about the NTP servers.</dd>
+
+</dl>
+
+<h4>Bugs</h4>
+
+This program makes no attempt to improve accuracy by doing multiple samples.
+
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
Patching Procedures
</h3>
-<img align=left src=pic/rabbit.gif>From <i>pogo</i>, Walt Kelly
+<img align=left src=pic/alice38.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>The Mad Hatter needs patches.
<br clear=left><hr>
<p>A distribution so widely used as this one eventually develops numerous barnacles as the result of <a href=porting.htm>porting</a> to new systems, idiosyncratic new features and just plain bugs. In order to help keep order and make maintenance bearable, we ask that proposed changes to the distribution be submitted in the following form.
Porting Hints
</title></head><body><h3>
Porting Hints
-</h3><hr>
+</h3>
+
+<img align=left src=pic/wingdorothy.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>The
+Wizard of Oz</i>, L. Frank Baum</a>
+
+<p>Porting Dorothy in Oz.
+<br clear=left><hr>
<p>NOTE: The following procedures have been replaced by GNU automake and
autoconfigure. This page is to be updated in the next release.
Pulse-per-second (PPS) Signal Interfacing
</title></head><body><h3>
Pulse-per-second (PPS) Signal Interfacing
-</h3><hr>
+</h3>
+
+<img align=left src=pic/alice32.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Alice is trying to find the PPS signal connector.
+<br clear=left><hr>
<p>Some radio clocks and related timekeeping gear have a pulse-per-second (PPS) signal that can be used to discipline the local clock oscillator to a high degree of precision, typically to the order less than 10 <font face=Symbol>m</font>s in time and 0.01 parts-per-million (PPM) in frequency. The PPS signal can be connected in either of two ways: via the data carrier detector (DCD) pin of a serial port or via the acknowledge (ACK) pin of a parallel port, depending on the hardware and operating system. Connection via a serial port may require signal conversion and regeneration to RS232 levels, which can be done using a circuit such as described in the <A HREF=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</A> page. Note that NTP no longer supports connection via the data leads of a serial port.
<html><head><title>
Mitigation Rules and the <tt>prefer</tt> Keyword
</title></head><body><h3>
-Mitigation Rules and the <TT>prefer</TT> Keyword
-</h3><hr>
+Mitigation Rules and the <tt>prefer</tt> Keyword
+</h3>
+
+<img align=left src=pic/alice11.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Listen carefully to what I say; it is very complicated.
+<br clear=left><hr>
<h4>Introduction</h4>
-<HTML><HEAD><TITLE>
+<html><head><title>
Quick Start
-</TITLE></HEAD><BODY><H3>
+</title></head><body><h3>
Quick Start
-</H3>
+</h3>
<img align=left src=pic/panda.gif>FAX test image for SATNET (1979).
-<p>The baby panda was scanned at University College London and used
-as a FAX test image for a demonstration of the DARPA Atlantic
-SATNET Program and the first transatlantic Internet connection in 1978.
-The computing system used for that demonstration was called the <A
-HREF="http://www.eecis.udel.edu/~mills/database/papers/fuzz.ps">Fuzzball
-</A>. As it happened, this was also the first Internet multimedia
-presentation and the first to use NTP in regular operation. The image
-was widely copied and used for testing purpose throughout much of the
-1980s.
-<br clear=left>
+<p>The baby panda was scanned at University College London and used as a FAX test image for a demonstration of the DARPA Atlantic SATNET Program and the first transatlantic Internet connection in 1978. The computing system used for that demonstration was called the <A HREF=http://www.eecis.udel.edu/~mills/database/papers/fuzz.ps>Fuzzball </A>. As it happened, this was also the first Internet multimedia presentation and the first to use NTP in regular operation. The image was widely copied and used for testing purpose throughout much of the 1980s.
+<br clear=left><hr>
-<H4>Introduction</H4>
+<p>This page describes what to expect when the NTP daemon <tt>ntpd</tt> is started for the first time. The discussion presumes the programs in this distribution have been compiled and installed as described in the <a href=build.htm>Building and Installing the Distribution</a> page.
-<p>This page describes what to expect when the NTP daemon <tt>ntpd</tt>
-is started for the first time. The discussion presumes the programs in
-this distribution have been compiled and installed as described in the
-<a href=build.htm>Building and Installing the Distribution</a> page.
+<p>When the daemon is started, whether for the first or subsequent times, a number of roundtrip samples are required to accumulate reliable measurements of network path delay and clock offset relative to the server(s). Normally, this takes about four minutes, after which the local clock is synchronized to the server. The daemon behavior at startup depends on whether a drift file <tt>ntp.drift</tt> exists. This file contains the latest estimate of local clock frequency error. When the daemon is started for the first time, this file is created after about one hour of operation and updated once each hour after that. When the daemon is started and the file does not exist, the daemon enters a special mode designed to quickly adapt to the particular system clock oscillator time and frequency error. This takes approximately 15 minutes, after which the time and frequency are set to nominal values and the daemon enters normal mode, where the time and frequency are continuously tracked relative to the server.
-<p>When the daemon is started, whether for the first or subsequent
-times, a number of roundtrip samples are required to accumulate reliable
-measurements of network path delay and clock offset relative to the
-server. Normally, this takes about four minutes, after which the local
-clock is synchronized to the server. The daemon behavior at startup
-depends on whether a drift file <tt>ntp.drift</tt> exists. This file
-contains the latest estimate of local clock frequency error. When the
-daemon is started for the first time, it is created after about one hour
-of operation and updated once each hour after that. When the daemon is
-started and the file does not exist, the daemon enters a special mode
-designed to quickly adapt to the particular system clock oscillator time
-and frequency error. This takes approximately 15 minutes, after which
-the time and frequency are set to nominal values and the daemon enters
-normal mode, where the time and frequency are continuously tracked
-relative to the server.
+<p>As a practical matter, once the local clock has been set, it very rarely strays more than 128 ms relative to the server, even under extreme cases of network path congestion and jitter. Sometimes, in particular when the daemon is first started, the relative clock offset exceeds 128 ms. In such cases the normal behavior of the daemon is to set the clock directly, rather than rely on gradual corrections. This may cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the <tt>-x</tt> option is included on the command line that starts the daemon, the clock will never be stepped and only slew corrections will be used.
-<p>As a practical matter, once the local clock has been set, it very
-rarely strays more than 128 ms relative to the server, even under
-extreme cases of network path congestion and jitter. Sometimes, in
-particular when the daemon is first started, the relative clock offset
-exceeds 128 ms. In such cases the normal behavior of the daemon is to
-set the clock directly, rather than rely on gradual corrections. This
-may cause the clock to be set backwards, if the local clock time is more
-than 128 s in the future relative to the server. In some applications,
-this behavior may be unacceptable. If the <tt>-x</tt> option is included
-on the command line that starts the daemon, the clock will never be
-stepped and only slew corrections will be used.
+<p>The issues should be carefully explored before deciding to use the <tt>-x</tt> option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.
-<p>The issues should be carefully explored before deciding to use the
-<tt>-x</tt> option. The maximum slew rate possible is limited to 500
-parts-per-million (PPM) as a consequence of the correctness principles
-on which the NTP protocol and algorithm design are based. As a result,
-the local clock can take a long time to converge to an acceptable
-offset, about 2000 s for each second the clock is outside the acceptable
-range. During this interval the local clock will not be consistent with
-any other network clock and the system cannot be used for distributed
-applications that require correctly synchronized network time.
+<p>There may be an occasional outlyer, where an individual measurement exceeds 128 ms. When the frequency of occurrence of these outlyers is low, the measurement is discarded and operation continues with the next one. However, if the outlyers persist for an interval longer than about 15 minutes, the next value is believed and the clock stepped or slewed as determined by the <tt>-x</tt> option. The usual reason for this behavior is when a leap second has occurred, but the reference clock receiver has not synchronized to it. When leap second support is implemented in the kernel, the kernel implements it as directed by the NTP daemon. If this happens and the reference clock source resynchronizes correctly within 15 minutes, the transient misbehavior of the source is transparent.
-<p>There may be an occasional outlyer, where an individual measurement
-exceeds 128 ms. When the frequency of occurrence of these outlyers is
-low, the measurement is discarded and operation continues with the next
-one. However, if the outlyers persist for an interval longer than about
-15 minutes, the next value is believed and the clock stepped or slewed
-as determined by the <tt>-x</tt> option. The usual reason for this
-behavior is when a leap second has occurred, but the reference clock
-receiver has not synchronized to it. When leap second support is
-implemented in the kernel, the kernel implements it as directed by the
-NTP daemon. If this happens and the reference clock source
-resynchronizes correctly within 15 minutes, the transient misbehavior of
-the source is transparent.
+<p>It has been observed that, as the result of extreme network congestion, the roundtrip delays can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus the error budget terms, can become very large. When the synchronization distance exceeds one second, the offset measurement is discarded. If this condition persists for several poll intervals, the server may be declared unreachable. Sometimes the large jitter results in large frequency errors which result in straying outside the acceptable offset range and an eventual step or slew time correction. If following such a correction the frequency error is so large that the first sample is outside the acceptable range, the daemon enters the same state as when the <tt>ntp.drift</tt> file is not present. The intent of this behavior is to quickly correct the frequency and restore operation to the normal tracking mode. In the most extreme cases (<tt>time.ien.it</tt> comes to mind), there may be occasional step/slew corrections and subsequent frequency corrections. It helps in these cases to use burst mode when configuring the server.
-<p>It has been observed that, as the result of extreme network
-congestion, the roundtrip delays can exceed three seconds and the
-synchronization distance, which is equal to one-half the roundtrip delay
-plus the error budget terms, can become very large. When the
-synchronization distance exceeds one second, the offset measurement is
-discarded. If this condition persists for several poll intervals, the
-server may be declared unreachable. Sometimes the large jitter results
-in large frequency errors which result in straying outside the
-acceptable offset range and an eventual step or slew time correction. If
-following such a correction the frequency error is so large that the
-first sample is outside the acceptable range, the daemon enters the same
-state as when the <tt>ntp.drift</tt> file is not present. The intent of
-this behavior is to quickly correct the frequency and restore operation
-to the normal tracking mode. In the most extreme cases
-(<tt>time.ien.it</tt> comes to mind), there may be occasional step/slew
-corrections and subsequent frequency corrections. It helps in these
-cases to use burst mode when configuring the server.
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
Debugging Hints for Reference Clock Drivers
</title></head><body><h3>
Debugging Hints for Reference Clock Drivers
-</h3><hr>
+</h3>
+
+<img align=left src=pic/oz2.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>The
+Wizard of Oz</i>, L. Frank Baum</a>
+
+<p>Call the girls and the'll sweep your bugs.
+<br clear=left><hr>
<p>The <a href=ntpq.htm><tt>ntpq</tt></a> and <a href=ntpdc.htm><tt>ntpdc</tt></a> utility programs can be used to debug reference clocks, either on the server itself or from another machine elsewhere in the network. The server is compiled, installed and started using the configuration file described in the <a href=ntpd.htm><tt>ntpd</tt></a> page and its dependencies. If the clock appears in the <tt>ntpq</tt> utility and <tt>pe</tt> command, no errors have occured and the daemon has started, opened the devices specified and waiting for peers and radios to come up. If not, the first thing to look for are error messages on the system log. These are usually due to improper configuration, missing links or multiple instances of the daemon.
Reference Clock Drivers
</H3>
-<IMG ALIGN=LEFT SRC=pic/tardisa.gif>From top:
+<img align=left src=pic/stack1a.jpg>Master Time Facility at the <a href=http://www.eecis.udel.edu/~mills/lab.htm>UDel Internet Research Laboratory</a>:
-<ul>
-
-<li>Austron 2100A GPS Receiver with LORAN-C assist</li>
-<li>Austron 2000 LORAN-C Receiver></li>
-<li>Spectracom 8170 WWVB Receiver</li>
-<li>Hewlett Packard 5061A Cesium Beam Standard</li>
-
-</ul>
-
-<br clear=left>
-The Tardis
-<hr>
+<br clear=left><hr>
Support for most of the commonly available radio and modem reference clocks is included in the default configuration of the NTP daemon for Unix <tt>ntpd</tt>. Individual clocks can be activated by configuration file commands, specifically the <tt>server</tt> and <tt>fudge</tt> commands described in the <a href=ntpd.htm><tt>ntpd</tt> program manual page</a>. The following discussion presents Information on how to select and configure the device drivers in a running Unix system.
NTP Version 4 Release Notes
</h3>
-<img align=left src=pic/hornraba.gif> <i>Alice's Adventures in Wonderland</i>, by Lewis Carroll, illustrations by Sir John Tenniel
+<img align=left src=pic/hornraba.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>The rabbit toots to make sure you read thie.
<br clear=left><hr>
-<p>This document was last updated 14 December 2000
+<p>This document was last updated 31 December 2000
<h4>NTP Version 4 Release Notes</h4>
Network Time Protocol Year 2000 Conformance Statement
</h3>
-<img align=left src=pic/alice15.gif>
-from <i>Alice's Adventures in Wonderland</i>, by Lewis Carroll,
-illustrations by Sir John Tenniel
+<img align=left src=pic/alice15.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The Mad Hatter and the March Hare are discussing whether the Teapot
serial number should have two or four digits.
projects / thirdparty / ntp.git / commitdiff
