diff options
| author | roberto <roberto@FreeBSD.org> | 2000-01-28 14:55:50 +0000 |
|---|---|---|
| committer | roberto <roberto@FreeBSD.org> | 2000-01-28 14:55:50 +0000 |
| commit | b5b40f9e420899251189775800d9f74092925299 (patch) | |
| tree | 98efdf1b74d6ecb7828bb502a0350116eeb2fd3c /contrib/ntp/html | |
| parent | ef64b99e8412f2273dd2e8b3291c2f78ffc4667f (diff) | |
| download | FreeBSD-src-b5b40f9e420899251189775800d9f74092925299.zip FreeBSD-src-b5b40f9e420899251189775800d9f74092925299.tar.gz | |
Virgin import of ntpd 4.0.99b
Diffstat (limited to 'contrib/ntp/html')
| -rw-r--r-- | contrib/ntp/html/audio.htm | 153 | ||||
| -rw-r--r-- | contrib/ntp/html/build.htm | 24 | ||||
| -rw-r--r-- | contrib/ntp/html/copyright.htm | 217 | ||||
| -rw-r--r-- | contrib/ntp/html/driver30.htm | 82 | ||||
| -rw-r--r-- | contrib/ntp/html/driver35.htm | 82 | ||||
| -rw-r--r-- | contrib/ntp/html/driver36.htm | 839 | ||||
| -rw-r--r-- | contrib/ntp/html/driver37.htm | 75 | ||||
| -rw-r--r-- | contrib/ntp/html/driver6.htm | 431 | ||||
| -rw-r--r-- | contrib/ntp/html/driver7.htm | 792 | ||||
| -rw-r--r-- | contrib/ntp/html/driver8.htm | 26 | ||||
| -rw-r--r-- | contrib/ntp/html/hints/solaris-dosynctodr.html | 320 | ||||
| -rw-r--r-- | contrib/ntp/html/hints/solaris.html | 8 | ||||
| -rw-r--r-- | contrib/ntp/html/hints/solaris.xtra.S99ntpd | 1 | ||||
| -rw-r--r-- | contrib/ntp/html/hints/winnt.htm | 315 | ||||
| -rw-r--r-- | contrib/ntp/html/index.htm | 6 | ||||
| -rw-r--r-- | contrib/ntp/html/monopt.htm | 618 | ||||
| -rw-r--r-- | contrib/ntp/html/notes.htm | 27 | ||||
| -rw-r--r-- | contrib/ntp/html/ntpd.htm | 18 | ||||
| -rw-r--r-- | contrib/ntp/html/pps.htm | 25 | ||||
| -rw-r--r-- | contrib/ntp/html/qth.htm | 64 | ||||
| -rw-r--r-- | contrib/ntp/html/refclock.htm | 83 | ||||
| -rw-r--r-- | contrib/ntp/html/tickadj.htm | 4 |
22 files changed, 3215 insertions, 995 deletions
diff --git a/contrib/ntp/html/audio.htm b/contrib/ntp/html/audio.htm new file mode 100644 index 0000000..5df5570 --- /dev/null +++ b/contrib/ntp/html/audio.htm @@ -0,0 +1,153 @@ +<html><head><title> +Reference Clock Audio Drivers +</title></head><body><h3> +Reference Clock Audio Drivers +</h3><hr> + +<p>There are some applications in which the computer time can be +disciplined to an audio signal, rather than a serial timecode and +communications port or special purpose bus peripheral. This is useful in +such cases where the audio signal is sent over a telephone circuit, for +example, or received directly from a shortwave receiver. In such cases +the audio signal can be connected via an ordinary sound card or +baseboard audio codec. The suite of NTP reference clock drivers +currently includes three drivers suitable for these applications. They +include a driver for the Inter Range Instrumentation Group (IRIG) +signals produced by most radio clocks and timing devices, another for +the Canadian time/frequency radio station CHU and a third for the NIST +time/frequency radio stations WWV and WWVH. The radio drivers are +designed to work with ordinary inexpensive shortwave radios and may be +one of the least expensive ways to build a good primary time server. + +<p>All three drivers make ample use of sophisticated digital signal +processing algorithms designed to efficiently extract timing signals +from noise and interference. The radio station drivers in particular +implement optimum linear demodulation and decoding techniques, including +maximum likelihood and soft-decision methods. The documentation page for +each driver contains an in-depth discussion on the algorithms and +performance expectations. In some cases the algorithms are further +analyzed, modelled and evaluated in a technical report. + +<p>Currently, the audio drivers are compatible with Sun operating +systems, including Solaris and SunOS, and the native audio codec +interface supported by these systems. In fact, the interface is quite +generic and support for other systems, in particular the various Unix +generics, should not be difficult. Volunteers are solicited. + +<p>The audio drivers include a number of common features designed to +groom input signals, suppress spikes and normalize signal levels. An +automatic gain control (AGC) feature provides protection against +overdriven or underdriven input signals. It is designed to maintain +adequate demodulator signal amplitude while avoiding occasional noise +spikes. In order to assure reliable operation, the signal level must be +in the range where the audio gain control is effective. In general, this +means the input signal level must be such as to cause the AGC to set the +gain somewhere in the middle of the range from 0 to 255, as indicated in +the timecode displayed by the <tt>ntpq</tt> program. + +<p>The drivers operate by disciplining a logical clock based on the +codec sample clock to the audio signal as received. This is done by +stuffing or slipping samples as required to maintain exact frequency to +the order of 0.1 PPM. In order for the driver to reliably lock on the +audio signal, the sample clock frequency tolerance must be less than 250 +PPM (.025 percent) for the IRIG driver and half that for the radio +drivers. The largest error observed so far is about 60 PPM, but it is +possible some sound cards or codecs may exceed that value. + +<p>The drivers include provisions to select the input port and to +monitor the input signal. The <tt>fudge flag 2</tt> selects the +microphone port if set to zero or the line-in port if set to one. It +does not seem useful to specify the compact disc player port. The +<tt>fudge flag 3</tt> enables the input signal monitor using the +previously selected output port and output gain. Both of these flags can +be set in the configuration file or remotely using the <tt>ntpdc</tt> +utility program. + +<H4>Shortwave Radio Drivers</H4> + +<p>The WWV/H and CHU audio drivers require an external shortwave radio +with the radio output - speaker or headphone jack - connected to either +the microphone or line-in port on the computer. There is some degree of +art in setting up the radio and antenna and getting the setup to work. +While the drivers are highly sophisticated and efficient in extracting +timing signals from noise and interference, it always helps to have as +clear a signal as possible. + +<p>The most important factor affecting the radio signal is the antenna. +It need not be long - even 15 feet is enough if it is located outside of +a metal frame building, preferably on the roof, and away from metallic +objects. An ordinary CB whip mounted on a PVC pipe and wooden X-frame on +the roof should work well with most portable radios, as they are +optimized for small antennas. + +<p>The radio need not be located near the computer; in fact, it +generally works better if the radio is outside the near field of +computers and other electromagnetic noisemakers. It can be in the +elevator penthouse connected by house wiring, which can also be used to +power the radio. A couple of center-tapped audio transformers will +minimize noise pickup and provide phantom power to the radio with return +via the AC neutral wire. + +<p>The WWV/H and CHU transmitters operate on several frequencies +simultaneously, so that in most parts of North America at least one +frequency supports propagation to the receiver location at any given +hour. While both drivers support the ICOM CI-V radio interface and can tune the radio automatically, computer-tunable radios are expensive and probably not cost effective compared to a GPS receiver. So, the radio frequency must usually be fixed and chosen by compromise. + +<p>Shortwave (3-30 MHz) radio propagation phenomena are well known to +shortwave enthusiasts. The phenomena generally obey the following rules: + +<ul> + +<p><li>The optimum frequency is higher in daytime than nighttime, stays +high longer on summer days and low longer on winter nights. + +<p><li>Transitions between daytime and nightime conditions generally +occur somewhat after sunrise and sunset at the midpoint of the path from +transmitter to receiver. + +<p><li>Ambient noise (static) on the lower frequencies follows the +thunderstorm season, so is higher on summer afternoons and evenings. + +<p><li>The lower frequency bands are best for shorter distances, while +the higher bands are best for longer distances. + +<p><li>The optimum frequencies are higher at the peak of the 11-year +sunspot cycle and lower at the trough. The current sunspot cycle should +peak in the first couple of years beginning the century. + +</ul> + +The best way to choose a frequency is to listen at various times over +the day and determine the best highest (daytime) and lowest (nighttime) +frequencies. Then, assuming one is available, choose the highest +frequency between these frequencies. This strategy assumes that the high +frequency is more problematic than the low, that the low frequency +probably comes with severe multipath and static, and insures that +probably twice a day the chosen frequency will work. For instance, on +the east coast the best compromise CHU frequency is probably 7335 kHz +and the best WWV frequency is probably 15 MHz. + +<h4>Debugging Aids</h4> + +<p>The audio drivers include extensive debugging support to help hook up +the audio signals and monitor the driver operations. The documentation +page for each driver describes the various messages that can be produced +either in real-time or written to the <tt>clockstats</tt> file for +later analysis. Of particular help in verifying signal connections and +compatibility is a provision to monitor the signal via headphones or +speaker. + + +<p>The drivers write a synthesized timecode to the <tt>clockstats</tt> +file each time the clock is set or verified and at other times if verbose monitoring is enabled. The format includes several fixed-length fields defining the Gregorian time to the millisecond, together with additional variable-length fields specific to each driver. The data include the intervals since the clock was last set or verified, the audio gain and various state variables and counters specific to each driver. + +<H4>Additional Information</H4> + +<A HREF="refclock.htm">Reference Clock Drivers</A> +<br><A HREF="driver7.htm">Radio CHU Audio Demodulator/Decoder</A> +<br><A HREF="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</A> +<br><A HREF="driver6.htm">IRIG Audio Decoder</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> diff --git a/contrib/ntp/html/build.htm b/contrib/ntp/html/build.htm index c321bf3..44b0391 100644 --- a/contrib/ntp/html/build.htm +++ b/contrib/ntp/html/build.htm @@ -177,28 +177,8 @@ function.</DD> </DL> <H4>Building and Installing under Windows NT</H4> - -Under Windows NT, you will need <TT>Visual C++ 5.0</TT> or above, -<TT>InstallShield</TT> SDK, <TT>Perl5</TT> and some version of the -archiving program <TT>ZIP</TT>. Note that the version of -<TT>InstallShield</TT> that comes with VC++5.0 is not useable here, -since it does not include the command line tools. - -<P>See the <TT>./scripts/wininstall/readme.nt</TT> file for directions -to compile the sources, build the libraries and link the executables. -Initiate the build by running either <TT>bldrel.bat</TT> or -<TT>blddbg.bat</TT> to compile all of the source and create an -<TT>InstallShield</TT> based graphical installation package. - -<P>To install the executables, make sure that you are logged in as a -system account, or one with administrator privileges such as the -"administrator" account. As part of the build an <TT>InstallShield</TT> -based graphical installer was created. Run -<TT>\ntp\scripts\wininstall\intel\disk1\setup.exe</TT> to begin the -installation. This installer will prompt for basic defaults, -copy the binaries, install the service, and start it up. The other -option is to run <TT>\ntp\scripts\wininstall\distrib\install.bat</TT> -which will do the basic installation from the command line. +See <tt><a href="hints/winnt.htm">hints/winnt.htm</a> </tt>for directions +to compile the sources and install the executables. <hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href="mailto:mills@udel.edu"> David L. diff --git a/contrib/ntp/html/copyright.htm b/contrib/ntp/html/copyright.htm index d5d8243..527b5d0 100644 --- a/contrib/ntp/html/copyright.htm +++ b/contrib/ntp/html/copyright.htm @@ -1,123 +1,202 @@ -<HTML><HEAD><TITLE> +<html><head><title> Copyright Notice -</TITLE></HEAD><BODY><H3> +</title></head><body><h3> Copyright Notice -</H3> +</h3> <IMG align=left HEIGHT=264 WIDTH=206 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-1999 * - * * - * 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. +<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: 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> +<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> -<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: michael.barone@lmco.com">Michael Barone +<michael,barone@lmco.com></a> GPSVME fixes</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: karl@owl.HQ.ileaf.com">Karl Berry +<karl@owl.HQ.ileaf.com></a> syslog to file option</LI> -<LI><A HREF="mailto: clift@ml.csiro.au">Steve Clift <clift@ml.csiro.au></a> OMEGA clock driver</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:casey@csc.co.za">Casey Crellin <casey@csc.co.za></a> vxWorks (Tornado) port and help with target configuration</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: duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe <duwe@immd4.informatik.uni-erlangen.de></a> Linux port</LI> +<LI><A HREF="mailto: clift@ml.csiro.au">Steve Clift +<clift@ml.csiro.au></a> OMEGA clock driver</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:casey@csc.co.za">Casey Crellin +<casey@csc.co.za></a> vxWorks (Tornado) port and help with target +configuration</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: 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: glenn@herald.usask.ca">Glenn Hollinger <glenn@herald.usask.ca></a> GOES clock driver</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: iglesias@uci.edu">Mike Iglesias <iglesias@uci.edu></a> DEC Alpha 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: jagubox.gsfc.nasa.gov">Jim Jagielski <jim@jagubox.gsfc.nasa.gov></a> A/UX 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: jbj@chatham.usdesign.com">Jeff Johnson <jbj@chatham.usdesign.com></a> massive prototyping overhaul</LI> +<LI><A HREF="mailto: glenn@herald.usask.ca">Glenn Hollinger +<glenn@herald.usask.ca></a> GOES clock driver</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: iglesias@uci.edu">Mike Iglesias +<iglesias@uci.edu></a> DEC Alpha port</LI> -<LI><A HREF="mailto: dkatz@cisco.com">Dave Katz <dkatz@cisco.com></a> RS/6000 AIX 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: leres@ee.lbl.gov">Craig Leres <leres@ee.lbl.gov></a> 4.4BSD port, ppsclock, Maganavox GPS clock driver</LI> +<LI><A HREF="mailto: jbj@chatham.usdesign.com">Jeff Johnson +<jbj@chatham.usdesign.com></a> massive prototyping overhaul</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: 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: louie@ni.umd.edu">Louis A. Mamakos <louie@ni.umd.edu></a> -MD5-based authentication</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: 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="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: 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: dkatz@cisco.com">Dave Katz +<dkatz@cisco.com></a> RS/6000 AIX port</LI> -<LI><A HREF="mailto: mills@udel.edu">David L. Mills <mills@udel.edu></a> Version 4 foundation, Spectractom WWVB, Austron GPS, Arbiter GPS, CHU, Heath, ATOM, ACTS, KSI/Odetics, IRIG clock drivers; PPS support; precision kernel; NTPv4 changes</LI> +<LI><A HREF="mailto: leres@ee.lbl.gov">Craig Leres +<leres@ee.lbl.gov></a> 4.4BSD port, ppsclock, Maganavox GPS clock +driver</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: lindholm@ucs.ubc.ca">George Lindholm +<lindholm@ucs.ubc.ca></a> SunOS 5.1 port</LI> -<LI><A HREF="mailto: mogul@pa.dec.com">Jeffrey Mogul <mogul@pa.dec.com></a> ntptrace utility</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: tmoore@fievel.daytonoh.ncr.com">Tom Moore <tmoore@fievel.daytonoh.ncr.com></a> i386 svr4 port</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: 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: 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: dirce@zk3.dec.com">Dirce Richards <dirce@zk3.dec.com></a> Digital UNIX V4.0 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: mrapple@quack.kfu.com">Nick Sayer <mrapple@quack.kfu.com></a> SunOS streams modules</LI> +<LI><A HREF="mailto: mogul@pa.dec.com">Jeffrey Mogul +<mogul@pa.dec.com></a> ntptrace utility</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: tmoore@fievel.daytonoh.ncr.com">Tom Moore +<tmoore@fievel.daytonoh.ncr.com></a> i386 svr4 port</LI> -<LI><A HREF="mailto: schnitz@unipress.com">Ray Schnitzler <schnitz@unipress.com></a> Unixware1 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: shields@tembel.org">Michael Shields <shields@tembel.org></a> USNO 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: pebbles.jpl.nasa.gov">Jeff Steinman <jss@pebbles.jpl.nasa.gov></a> Datum PTS clock driver</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: harlan@pfcs.com">Harlan Stenn <harlan@pfcs.com></a> GNU automake/autoconfigure makeover</LI> +<LI><A HREF="mailto: wsanchez@apple.com">Wilfredo Sánchez +<wsanchez@apple.com></A> added support for NetInfo</LI> -<LI><A HREF="mailto: ken@sdd.hp.com">Kenneth Stone <ken@sdd.hp.com></a> HP-UX port</LI> +<LI><A HREF="mailto: mrapple@quack.kfu.com">Nick Sayer +<mrapple@quack.kfu.com></a> SunOS streams modules</LI> -<LI><A HREF="mailto: ajit@ee.udel.edu">Ajit Thyagarajan <ajit@ee.udel.edu></a>IP multicast support</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: tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp></a>TRAK clock driver</LI> +<LI><A HREF="mailto: schnitz@unipress.com">Ray Schnitzler +<schnitz@unipress.com></a> Unixware1 port</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: shields@tembel.org">Michael Shields +<shields@tembel.org></a> USNO 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: pebbles.jpl.nasa.gov">Jeff Steinman +<jss@pebbles.jpl.nasa.gov></a> Datum PTS clock driver</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: harlan@pfcs.com">Harlan Stenn +<harlan@pfcs.com></a> GNU automake/autoconfigure makeover, various +other bits (see the ChangeLog)</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: 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: 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: 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: wsanchez@apple.com">Wilfredo Sánchez <wsanchez@apple.com></A> added support for NetInfo</LI> </OL> -<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><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> +</address></a></body></html> diff --git a/contrib/ntp/html/driver30.htm b/contrib/ntp/html/driver30.htm index 8d547b1..fab604b 100644 --- a/contrib/ntp/html/driver30.htm +++ b/contrib/ntp/html/driver30.htm @@ -17,24 +17,32 @@ Motorola Oncore GPS receiver</H3> <H4> Synopsis</H4> -Address: 127.127.30.0 -<BR>Reference ID: <TT>GPS</TT> -<BR>Driver ID: ONCORE -<BR>Serial Port: <TT>/dev/cuaa0</TT>; 9600 baud, 8-bits, no parity -<BR>PPS Port: <TT>/dev/xpps0</TT>; <TT>PPS_CAPTUREASSERT</TT> -required, <TT>PPS_OFFSETASSERT</TT> supported. +Address: 127.127.30.0<BR> +Reference ID: <TT>GPS</TT><BR> +Driver ID: ONCORE<BR> +Serial Port: <TT>/dev/oncore.serial.0</TT>; 9600 baud, 8-bits, +no parity.<BR> +PPS Port: <TT>/dev/oncore.pps.0</TT>; <TT>PPS_CAPTUREASSERT</TT> +required, <TT>PPS_OFFSETASSERT</TT> supported. <H4> Description</H4> This driver supports various models of the <A HREF="http://www.mot.com/AECS/PNSB/products">Motorola Oncore GPS -receivers</A>. as long as they support the <I>Motorola Binary +receivers</A> as long as they support the <I>Motorola Binary Protocol</I>. -<P>The two most interesting version of the Oncore are the "UT+" -and the "Remote" which is a prepackaged "UT+". The evaluation kit +<P>The three most interesting versions of the Oncore are the "VP", +the "UT+", +and the "Remote" which is a prepackaged "UT+". +The "VP" is no longer available. + +<P>The evaluation kit can also be recommended, it interfaces to a PC straightaway, using the -parallel port for PPS input (supported under FreeBSD), and packs the +serial (DCD) or parallel port for PPS input and packs the receiver in a nice and sturdy box. +Two less expensive interface kits are available from +<A HREF="http://www.tapr.org">TAPR </A>. + <BR> <CENTER><TABLE NOSAVE > <TR NOSAVE> @@ -61,18 +69,22 @@ WIDTH=210></TD> </TR> </TABLE></CENTER> -<P>The driver requires a standard <TT>PPS</TT> interface for the pulse- -per-second output from the receiver. The serial data stream alone +<P>The driver requires a standard <TT>PPS</TT> interface for the +pulse-per-second output from the receiver. The serial data stream alone does not provide precision time stamps (0-50msec variance, according to the manual), whereas the PPS output is precise down to 50 nsec (1 sigma) -for the UT models. <P>The driver will use the "position hold" mode if -available, with either the receivers built-in site-survey or a similar -algorithm implemented in this driver. +for the VP/UT models. + +<P>The driver will use the "position hold" mode with +user provided coordinates, +the receivers built-in site-survey, +or a similar algorithm implemented in this driver. <H4> Monitor Data</H4> The driver is quite chatty on stdout if ntpd is run with debugging. A manual will be required though. +Additional information is written to the clockstats file, if configured. <H4> Fudge Factors</H4> @@ -114,7 +126,7 @@ Not used by this driver.</DD> <TT>flag2 0 | 1</TT></DT> <DD> -Assume GPS receiver is on a mobile platform if set.</DD> +Not used by this driver.</DD> <DT> <TT>flag3 0 | 1</TT></DT> @@ -128,26 +140,40 @@ Not used by this driver.</DD> <DD> Not used by this driver.</DD> </DL> -<B>Additional Information</B><B></B> -<P>The driver has been developed under FreeBSD, and may still be pretty -FreeBSD centric. Patches are most welcome. -<P><B>Performance</B><B></B> -<P>Really good. With the UT+, the generated PPS pulse is -referenced +<B>Additional Information</B> +<P>The driver has been tested on FreeBSD, Linux and SunOS. + +<P>There is a driver specific configuration file <TT>/etc/ntp.oncore</TT> +that contains information on the startup mode, the location of the GPS +receiver, an offset of the PPS signal from zero, and the cable delay. +The offset shifts the PPS signal to avoid interrupt pileups `on' the second, +and adjust the timestamp accordingly. +See the driver source for information on this file. +The default with no file is: no delay, no offset, and a site survey is done +to get the location of the gps receiver. + +<P>The <TT>/etc/ntp.conf</TT> file will need a line of the form<BR> + +<TT> pps /dev/oncore.pps.0 [ assert/clear ] hardpps</TT><BR> +if you want the oncore driver to control the kernel PLL. +For more information, see the <A HREF=clockopt.htm>Reference Clock +Options</A> page. + +<P><B>Performance</B> +<P>Really good. With the VP/UT+, the generated PPS pulse is referenced to UTC(GPS) with better than 50 nsec (1 sigma) accuracy. The limiting factor will be the timebase of the computer and the precision with which you can timestamp the rising flank of the PPS signal. Using FreeBSD, a FPGA based Timecounter/PPS interface -and -an ovenized quartz oscillator, that performance has been reproduced. - For -more details on this aspect: <A +and an ovenized quartz oscillator, that performance has been reproduced. + For more details on this aspect: <A HREF="http://phk.freebsd.dk/rover.html">Sub-Microsecond timekeeping under FreeBSD</A> <HR> <ADDRESS> -Poul-Henning Kamp (phk@FreeBSD.org)</ADDRESS> - +Poul-Henning Kamp (phk@FreeBSD.org), +Reg Clemens (reg@dwf.com) +</ADDRESS> </BODY> </HTML> diff --git a/contrib/ntp/html/driver35.htm b/contrib/ntp/html/driver35.htm new file mode 100644 index 0000000..d3b77e0 --- /dev/null +++ b/contrib/ntp/html/driver35.htm @@ -0,0 +1,82 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> +<html> +<head> +<title>Conrad parallel port radio clock</title> +</head> +<body> + +<h3>Conrad parallel port radio clock</h3> +<hr> + +<h4>Synopsis</h4> + +<p>Address: 127.127.35.<i>u</i><br> +Reference ID: <tt>PCF</tt><br> +Driver ID: <tt>PCF</tt><br> +Parallel Port: <tt>/dev/pcfclock<i>u</i></tt> +</p> + +<h4>Description</h4> + +<p>This driver supports the parallel port radio clocks sold by <a +href="http://www.conrad-electronic.com/">Conrad Electronic</a> under +order numbers 967602 and 642002. The battery-powered radio clock is +put between a parallel port and your printer. It receives the legal +German time, which is either CET or CEST, from the DCF77 transmitter +and uses it to set internal quartz clock. The DCF77 transmitter is +located near to Frankfurt/Main and covers a radius of more than 1500 +kilometers. + +<p>The driver requires that the pcfclock device driver be installed. +A device driver for Linux 2.2 is available at +<a href="http://home.pages.de/~voegele/pcf.html">the pcfclock driver +page</a>. +</p> + +<p>The driver uses C library functions to convert the received +timecode to UTC and therefore requires that the local timezone be +CET/CEST. If your server is not located in Central Europe, you have +to set the environment variable TZ to CET before <tt>ntpd</tt> is +started.</p> + +<h4>Monitor Data</h4> + +<p>Each timecode is written to the <tt>clockstats</tt> file in the format +<tt>YYYY MM DD HH MI SS</tt>.</p> + +<h4>Fudge Factors</h4> + +<dl> +<dt><tt>time1 <i>time</i></tt></dt> +<dd>Specifies the time offset calibration factor, 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> + +<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>PCF</tt>.</dd> + +<dt><tt>flag1 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> + +<dt><tt>flag2 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> + +<dt><tt>flag3 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> + +<dt><tt>flag4 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> +</dl> + +<hr> +<address>Andreas Voegele (andreas.voegele@gmx.de)</address> + +</body> +</html> diff --git a/contrib/ntp/html/driver36.htm b/contrib/ntp/html/driver36.htm new file mode 100644 index 0000000..6f70dcc --- /dev/null +++ b/contrib/ntp/html/driver36.htm @@ -0,0 +1,839 @@ +<html><head><title> +Radio WWV/H Audio Demodulator/Decoder +</title></head><body><h3> +Radio WWV/H Audio Demodulator/Decoder +</h3><hr> + +<h4>Synopsis</h4> + +Address: 127.127.36.<I>u</I> +<br>Reference ID: <tt>WWV</tt> or <tt>WWVH</tt> +<br>Driver ID: <tt>WWV_AUDIO</tt> +<br>Autotune Port: <tt>/dev/icom</tt>; 9600 baud, 8-bits, no parity +<br>Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt> + +<h4>Description</h4> + +This driver synchronizes the computer time using data encoded in +shortwave radio transmissions from NIST time/frequency stations WWV in +Ft. Collins, CO, and WWVH in Kauai, HI. Transmissions are made +continuously on 2.5, 5, 10, 15 and 20 MHz. 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 by the +driver as propagation conditions change throughout the day and night. +The performance of this driver when tracking one of the stations is +ordinarily better than 1 ms in time with frequency drift less than 0.5 +PPM when not tracking either station. + +<p>The demodulation and decoding algorithms used by this driver are +based on a machine language program developed for the TAPR DSP93 DSP +unit, which uses the TI 320C25 DSP chip. The analysis, design and +performance of the program running on this unit is described in: Mills, +D.L. A precision radio clock for WWV transmissions. Electrical +Engineering Report 97-8-1, University of Delaware, August 1997, 25 pp. +Available from <a href=http://www.eecis.udel.edu/~mills/reports.htm> +www.eecis.udel.edu/~mills/reports.htm</a>. For use in this driver, the +original program was rebuilt in the C language and adapted to the NTP +driver interface. The algorithms have been modified somewhat to improve +performance under weak signal conditions and to provide an automatic +station identification feature. + +<p>This driver incorporates several features in common with other audio +drivers such as described in the <a href=driver7.htm>Radio CHU 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>The WWV signal format is described in NIST Special Publication 432 +(Revised 1990). It consists of three elements, a 5-ms, 1000-Hz pulse, +which occurs at the beginning of each second, a 800-ms, 1000-Hz pulse, +which occurs at the beginning of each minute, and a pulse-width +modulated 100-Hz subcarrier for the data bits, one bit per second. The +WWVH format is identical, except that the 1000-Hz pulses are sent at +1200 Hz. Each minute encodes nine BCD digits for the time of century +plus seven bits for the daylight savings time (DST) indicator, leap +warning indicator and DUT1 correction. + +<h4>Program Architecture</h4> + +<p>As in the original program, the clock discipline is modelled as a +Markov process, with probabilistic state transitions corresponding to a +conventional clock and the probabilities of received decimal digits. The +result is a performance level which results in very high accuracy and +reliability, even under conditions when the minute beep of the signal, +normally its most prominent feature, can barely be detected by ear with +a shortwave receiver. + +<p>The analog audio signal from the shortwave radio is sampled at 8000 +Hz and converted to digital representation. The 1000/1200-Hz pulses and +100-Hz subcarrier are first separated using two IIR filters, a 600-Hz +bandpass filter centered on 1100 Hz and a 150-Hz lowpass filter. The +minute sync pulse is extracted using a 800-ms synchronous matched filter +and pulse grooming logic which discriminates between WWV and WWVH +signals and noise. The second sync pulse is extracted using a 5-ms FIR +matched filter and 8000-stage comb filter. + +<p>The phase of the 100-Hz subcarrier relative to the second sync pulse +is fixed at the transmitter; however, the audio highpass filter in most +radios affects the phase response at 100 Hz in unpredictable ways. The +driver adjusts for each radio using two 170-ms synchronous matched +filters. The I (in-phase) filter is used to demodulate the subcarrier +envelope, while the Q (quadrature-phase) filter is used in a tracking +loop to discipline the codec sample clock and thus the demodulator +phase. + +<p>The data bit probabilities are determined from the subcarrier +envelope using a threshold-corrected slicer. The averaged envelope +amplitude 30 ms from the beginning of the second establishes the minimum +(noise floor) value, while the amplitude 200 ms from the beginning +establishes the maximum (signal peak) value. The slice level is midway +between these two values. The negative-going envelope transition at the +slice level establishes the length of the data pulse, which in turn +establish probabilities for binary zero (P0) or binary one (P1). The +values are established by linear interpolation between the pulse lengths +for P0 (300 ms) and P1 (500 ms) so that the sum is equal to one. If the +driver has not synchronized to the minute pulse, or if the data bit +amplitude, signal/noise ratio (SNR) or length are below thresholds, the +bit is considered invalid and all three probabilities are set to zero. + +<p>The difference between the P1 and P0 probabilities, or likelihood, +for each data bit is exponentially averaged in a set of 60 accumulators, +one for each second, to determine the semi-static miscellaneous bits, +such as DST indicator, leap second warning and DUT1 correction. In this +design, an average value larger than a positive threshold is interpreted +as a hit on one and a value smaller than a negative threshold as a hit +on zero. Values between the two thresholds, which can occur due to +signal fades or loss of signal, are interpreted as a miss, and result in +no change of indication. + +<p>The BCD digit in each digit position of the timecode is represented +as four data bits, all of which must be valid for the digit itself to be +considered valid. If so, the bits are correlated with the bits +corresponding to each of the valid decimal digits in this position. If +the digit is invalid, the correlated value for all digits in this +position is assumed zero. In either case, the values for all digits are +exponentially averaged in a likelihood vector associated with this +position. The digit associated with the maximum over all of the averaged +values then becomes the maximum likelihood selection for this position +and the ratio of the maximum over the next lower value becomes the +likelihood ratio. + +<p>The decoding matrix contains nine row vectors, one for each digit +position. Each row vector includes the maximum likelihood digit, +likelihood vector and other related data. The maximum likelihood digit +for each of the nine digit positions becomes the maximum likelihood time +of the century. A built-in transition function implements a conventional +clock with decimal digits that count the minutes, hours, days and years, +as corrected for leap seconds and leap years. The counting operation +also rotates the likelihood vector corresponding to each digit as it +advances. Thus, once the clock is set, each clock digit should +correspond to the maximum likelihood digit as transmitted. + +<p>Each row of the decoding matrix also includes a compare counter and +the difference (modulo the radix) between the current clock digit and +most recently determined maximum likelihood digit. If a digit likelihood +exceeds the decision level and the difference is constant for a number +of successive minutes in any row, the maximum likelihood digit replaces +the clock digit in that row. When this condition is true for all rows +and the second epoch has been reliably determined, the clock is set (or +verified if it has already been set) and delivers correct time to the +integral second. The fraction within the second is derived from the +logical master clock, which runs at 8000 Hz and drives all system timing +functions. + +<p>The logical master clock is derived from the audio codec clock. Its +frequency is disciplined by a frequency-lock loop (FLL) which operates +independently of the data recovery functions. At averaging intervals +determined by the measured jitter, the frequency error is calculated as +the difference between the most recent and the current second epoch +divided by the interval. The sample clock frequency is then corrected by +this amount using an exponential average. When first started, the +frequency averaging interval is eight seconds, in order to compensate +for intrinsic codec clock frequency offsets up to 125 PPM. Under most +conditions, the averaging interval doubles in stages from the initial +value to over 1000 seconds, which results in an ultimate frequency +precision of 0.125 PPM, or about 11 ms/day. + +<p>It is important that the logical clock frequency is stable and +accurately determined, since in most applications the shortwave radio +will be tuned to a fixed frequency where WWV or WWVH signals are not +available throughout the day. In addition, in some parts of the US, +especially on the west coast, signals from either or both WWV and WWVH +may be available at different times or even at the same time. Since the +propagation times from either station are almost always different, each +station must be reliably identified before attempting to set the clock. + +<p>Station identification uses the 800-ms minute pulse transmitted by +each station. In the acquisition phase the entire minute is searched +using both the WWV and WWVH using matched filters and a pulse gate +discriminator similar to that found in radar acquisition and tracking +receivers. The peak amplitude found determines a range gate and window +where the next pulse is expected to be found. The minute is scanned +again to verify the peak is indeed in the window and with acceptable +amplitude, SNR and jitter. At this point the receiver begins to track +the second sync pulse and operate as above until the clock is set. + +<p>Once the minute is synchronized, the range gate is fixed and only +energy within the window is considered for the minute sync pulse. A +compare counter increments by one if the minute pulse has acceptable +amplitude, SNR and jitter and decrements otherwise. This is used as a +quality indicator and reported in the timecode and also for the autotune +function described below. + +<h4>Performance</h4> + +<p>It is the intent of the design that the accuracy and stability of the +indicated time be limited only by the characteristics of the propagation +medium. Conventional wisdom is that synchronization via the HF medium is +good only to a millisecond under the best propagation conditions. The +performance of the NTP daemon disciplined by the driver is clearly +better than this, even under marginal conditions. Ordinarily, with +marginal to good signals and a frequency averaging interval of 1024 s, +the frequency is stabilized within 0.1 PPM and the time within 125 <font +face=Symbol>m</font>s. The frequency stability characteristic is highly +important, since the clock may have to free-run for several hours before +reacquiring the WWV/H signal. + +<p>The expected accuracy over a typical day was determined using the +DSP93 and an oscilloscope and cesium oscillator calibrated with a GPS +receiver. With marginal signals and allowing 15 minutes for initial +synchronization and frequency compensation, the time accuracy determined +from the WWV/H second sync pulse was reliably within 125 <font +face=Symbol>m</font>s. In the particular DSP-93 used for program +development, the uncorrected CPU clock frequency offset was +45.8±0.1 PPM. Over the first hour after initial synchronization, +the clock frequency drifted about 1 PPM as the frequency averaging +interval increased to the maximum 1024 s. Once reaching the maximum, the +frequency wandered over the day up to 1 PPM, but it is not clear whether +this is due to the stability of the DSP-93 clock oscillator or the +changing height of the ionosphere. Once the frequency had stabilized and +after loss of the WWV/H signal, the frequency drift was less than 0.5 +PPM, which is equivalent to 1.8 ms/h or 43 ms/d. This resulted in a step +phase correction up to several milliseconds when the signal returned. + +<p>The measured propagation delay from the WWV transmitter at Boulder, +CO, to the receiver at Newark, DE, is 23.5±0.1 ms. This is +measured to the peak of the pulse after the second sync comb filter and +includes components due to the ionospheric propagation delay, nominally +8.9 ms, communications receiver delay and program delay. The propagation +delay can be expected to change about 0.2 ms over the day, as the result +of changing ionosphere height. The DSP93 program delay was measured at +5.5 ms, most of which is due to the 400-Hz bandpass filter and 5-ms +matched filter. Similar delays can be expected of this driver. + +<h4>Program Operation</h4> + +The driver begins operation immediately upon startup. It first searches +for one or both of the stations WWV and WWVH and attempts to acquire +minute sync. This may take some fits and starts, as the driver expects +to see three consecutive minutes with good signals and low jitter. If +the autotune function is active, the driver will rotate over all five +frequencies and both WWV and WWVH stations until three good minutes are +found. + +<p>The driver then acquires second sync, which can take up to several +minutes, depending on signal quality. At the same time the driver +accumulates likelihood values for each of the nine digits of the clock, +plus the seven miscellaneous bits included in the WWV/H transmission +format. The minute units digit is decoded first and, when five +repetitions have compared correctly, the remaining eight digits are +decoded. When five repetitions of all nine digits have decoded +correctly, which normally takes 15 minutes with good signals and up to +an hour when buried in noise, and the second sync alarm has not been +raised for two minutes, the clock is set (or verified) and is selectable +to discipline the system clock. + +<p>As long as the clock is set or verified, the system clock offsets are +provided once each second to the reference clock interface, where they +are saved in a buffer. At the end of each minute, the buffer samples are +groomed by the median filter and trimmed-mean averaging functions. Using +these functions, the system clock can in principle be disciplined to a +much finer resolution than the 125-<font face=Symbol>m</font>s sample +interval would suggest, although the ultimate accuracy is probably +limited by propagation delay variations as the ionspheric height varies +throughout the day and night. + +<p>As long as signals are available, the clock frequency is disciplined +for use during times when the signals are unavailable. The algorithm +refines the frequency offset using increasingly longer averaging +intervals to 1024 s, where the precision is about 0.1 PPM. With good +signals, it takes well over two hours to reach this degree of precision; +however, it can take many more hours than this in case of marginal +signals. Once reaching the limit, the algorithm will follow frequency +variations due to temperature fluctuations and ionospheric height +variations. + +<p>It may happen as the hours progress around the clock that WWV and +WWVH signals may appear alone, together or not at all. When the driver +is first started, the NTP reference identifier appears as <tt>NONE</tt>. +When the driver has acquired one or both stations and mitigated which +one is best, it sets the station identifier in the timecode as described +below. In addition, the NTP reference identifier is set to the station +callsign. If the propagation delays has been properly set with the +<tt>fudge time1</tt> (WWV) and <tt>fudge time2</tt> (WWVH) commands in +the configuration file, handover from one station to the other will be +seamless. + +<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 fades to obscurity. A consequence of this design is +that, once the clock is set, the time and frequency are disciplined only +by the second sync pulse and the clock digits themselves are driven by +the clock state machine and ordinarily never changed. However, as long +as the clock is set correctly, it will continue to read correctly after +a period of signal loss, as long as it does not drift more than 500 ms +from the correct time. Assuming the clock frequency can be disciplined +within 1 PPM, the clock could coast without signals for some 5.8 days +without exceeding that limit. If for some reason this did happen, the +clock would be in the wrong second and would never resynchronize. 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>To work well, the driver needs a communications receiver with good +audio response at 100 Hz. Most shortwave and communications receivers +roll off the audio response below 250 Hz, so this can be a problem, +especially with receivers using DSP technology, since DSP filters can +have very fast rolloff outside the passband. Some DSP transceivers, in +particular the ICOM 775, have a programmable low frequency cutoff which +can be set as low as 80 Hz. However, this particular radio has a strong +low frequency buzz at about 10 Hz which appears in the audio output and +can affect data recovery under marginal conditions. Although not tested, +it would seem very likely that a cheap shortwave receiver could function +just as well as an expensive communications receiver. + +<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 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 driver source 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. A missing <tt>mode</tt> +keyword or a zero argument leaves the interface disabled. The driver +will attempt to open the device <tt>/dev/icom</tt> and, if successful +will activate the autotune function and tune the radio to each operating +frequency in turn while attempting to acquire minute sync from either +WWV or WWVH. 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>Once acquiring minute sync, the driver operates as described above to +set the clock. However, during seconds 59, 0 and 1 of each minute it +tunes the radio to one of the five broadcast frequencies to measure the +sync pulse and data pulse amplitudes and SNR and update the compare +counter. Each of the five frequencies are probed in a five-minute +rotation to build a database of current propagation conditions for all +signals that can be heard at the time. At the end of each rotation, a +mitigation procedure scans the database and retunes the radio to the +best frequency and station found. For this to work well, the radio +should be set for a fast AGC recovery time. This is most important while +tracking a strong signal, which is normally the case, and then probing +another frequency, which may have much weaker signals. + +<p>Reception conditions for each frequency and station are evaluated +according to a metric which considers the minute sync pulse amplitude, +SNR and jitter, as well as, the data pulse amplitude and SNR. The minute +pulse is evaluated at second 0, while the data pulses are evaluated at +seconds 59 and 1. The results are summarized in a scoreboard of three +bits + +<dl> + +<p><dt><tt>0x0001</tt> +<dd>Jitter exceeded. The difference in epoches between the last minute +sync pulse and the current one exceeds 50 ms (400 samples).</dd> + +<dt><tt>0x0002</tt> +<dd>Minute pulse error. For the minute sync pulse in second 0, either +the amplitude or SNR is below threshold (2000 and 20 dB, +respectively).</dd> + +<dt><tt>0x0004</tt> +<dd>Minute pulse error. For both of the data pulses in seocnds 59 and 1, +either the amplitude or SNR is below threshold (1000 and 10 dB, +respectively).</dd> + +</dl> + +<p>If none of the scoreboard bits are set, the compare counter is +increased by one to a maximum of six. If any bits are set, the counter +is decreased by one to a minimum of zero. At the end of each minute, the +frequency and station with the maximum compare count is chosen, with +ties going to the highest frequency. + +<h4>Diagnostics</h4> + +<p>The autotune process produces diagnostic information along with the +timecode. This is very useful for evaluating the performance of the +algorithm, as well as radio propagation conditions in general. The +message is produced once each minute for each frequency in turn after +minute sync has been acquired. + +<p><tt>wwv5 port agc wwv wwvh</tt> + +<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and gain, +respectively, for this frequency and <tt>wwv</tt> and <tt>wwvh</tt> are +two sets of fields, one each for WWV and WWVH. Each of the two fields +has the format + +<p><tt>ident score comp sync/snr/jitr</tt> + +<p>where <tt>ident</tt>encodes the station (<tt>C</tt> for WWV, +<tt>H</tt> for WWVH) and frequency (2, 5, 10, 15 and 20), <tt>score</tt> +is the scoreboard described above, <tt>comp</tt> is the compare counter, +<tt>sync</tt> is the minute sync pulse amplitude, <tt>snr</tt> the SNR +of the pulse and <tt>jitr</tt> is the sample difference between the +current epoch and the last epoch. An example is: + +<p><tt>wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</tt> + +<p>Here the radio is tuned to 20 MHz and the line-in port AGC is +currently 111 at that frequency. The message contains a report for WWV +(<tt>C20</tt>) and WWVH (<tt>H20</tt>). The WWV report scoreboard is +0100 and the compare count is 6, which suggests very good reception +conditions, and the minute sync amplitude and SNR are well above +thresholds (2000 and 20 dB, respectively). Probably the most sensitive +indicator of reception quality is the jitter, -3 samples, which is well +below threshold (50 ms or 400 samples). While the message shows solid +reception conditions from WWV, this is not the case for WWVH. Both the +minute sync amplitude and SNR are below thresholds and the jitter is +above threshold. + +<p>A sequence of five messages, one for each minute, might appear as +follows: + +<p><pre>wwv5 2 95 C2 0107 0 164/7.2/8100 H2 0207 0 80/-5.5/7754 +wwv5 2 99 C5 0104 0 3995/21.8/395 H5 0207 0 27/-9.3/18826 +wwv5 2 239 C10 0105 0 9994/30.0/2663 H10 0207 0 54/-16.1/-529 +wwv5 2 155 C15 0103 3 3300/17.8/-1962 H15 0203 0 236/17.0/4873 +wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</pre> + +<p>Clearly, the only frequencies that are available are 15 MHz and 20 +MHz and propagation may be failing for 15 MHz. However, minute sync +pulses are being heard on 5 and 10 MHz, even though the data pulses are +not. This is typical of late afternoon when the maximum usable frequency +(MUF) is falling and the ionospheric loss at the lower frequencies is +beginning to decrease. + +<h4>Debugging Aids</h4> + +<p>The most convenient way to track the driver 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 driver is not discipline the system clock. If the debugging +trace feature (<tt>-d</tt> on the <tt>ntpd</tt> command line)is enabled, +the driver 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>In the following descriptions the units of amplitude, phase, +probability and likelihood are normalized to the range 0-6000 for +convenience. In addition, the signal/noise ratio (SNR) and likelihood +ratio are measured in decibels and the words with bit fields are in +hex. Most messages begin with a leader in the following format: + +<p><tt>wwvn ss stat sigl</tt> + +<p>where <tt>wwvn</tt> is the message code, <tt>ss</tt> the second of +minute, <tt>stat</tt> the driver status word and <tt>sigl</tt> the +second sync pulse amplitude. A full explanation of the status bits is +contained in the driver source listing; however, the following are the +most useful for debugging. + +<dl> + +<p><dt><tt>0x0001</tt> +<dd>Minute sync. Set when the decoder has identified a station and +acquired the minute sync pulse.</dd> +<p><dt><tt>0x0002</tt> +<dd>Second sync. Set when the decoder has acquired the second sync pulse +and within 125 <font face=Symbol>m</font>s of the correct phase.</dd> + +<p><dt><tt>0x0004</tt> +<dd>Minute unit sync. Set when the decoder has reliably determined the +unit digit of the minute.</dd> + +<p><dt><tt>0x0008</tt> +<dd>Clock set. Set when the decoder has reliably determined all nine +digits of the timecode and is selectable to discipline the system +clock.</dd> + +</dl> + +<p>With debugging enabled the driver produces messages in the following +formats: + +<p>Format <tt>wwv8</tt> messages are produced once per minute by the WWV +and WWVH station processes before minute sync has been acquired. They +show the progress of identifying and tracking the minute pulse of each +station. + +<p><tt>wwv8 port agc ident comp ampl snr epoch jitr offs</tt> + +<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and gain, +respectively. The <tt>ident</tt>encodes the station (<tt>C</tt> for WWV, +<tt>H</tt> for WWVH) and frequency (2, 5, 10, 15 and 20). For the +encoded frequency, <tt>comp</tt> is the compare counter, <tt>ampl</tt> +the pulse amplitude, <tt>snr</tt> the SNR, <tt>epoch</tt> the sample +number of the minute pulse in the minute, <tt>jitr</tt> the change since +the last <tt>epoch</tt> and <tt>offs</tt> the minute pulse offset +relative to the second pulse. An example is: + +<p><tt> wwv8 2 127 C15 2 9247 30.0 18843 -1 1</tt> +<br><tt>wwv8 2 127 H15 0 134 -2.9 19016 193 174</tt> + +<p>Here the radio is tuned to 15 MHz and the line-in port AGC is +currently 127 at that frequency. The driver has not yet acquired minute +sync, WWV has been heard for at least two minutes, and WWVH is in the +noise. The WWV minute pulse amplitude and SNR are well above the +threshold (2000 and 6 dB, respectively) and the minute epoch has been +determined -1 sample relative to the last one and 1 sample relative to +the second sync pulse. The compare counter has incrmented to two; when +it gets to three, minute sync has been acquired. + +<p>Format <tt>wwv3</tt> messages are produced after minute sync has been +acquired and until the seconds unit digit is determined. They show the +results of decoding each bit of the transmitted timecode. + +<p><tt>wwv3 ss stat sigl ampl phas snr prob like</tt> + +<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above, +<tt>ampl</tt> is the subcarrier amplitude, <tt>phas</tt> the subcarrier +phase, <tt>snr</tt> the subcarrier SNR, <tt>prob</tt> the bit +probability and <tt>like</tt> the bit likelihood. An example is: + +<p><tt>wwv3 28 0123 4122 4286 0 24.8 -5545 -1735</tt> + +<p>Here the driver has acquired minute and second sync, but has not yet +determined the seconds unit digit. However, it has just decoded bit 28 +of the minute. The results show the second sync pulse amplitude well +over the threshold (500), subcarrier amplitude well above the threshold +(1000), good subcarrier tracking phase and SNR well above the threshold +(10 dB). The bit is almost certainly a zero and the likelihood of a zero +in this second is very high. +<p>Format <tt>wwv4</tt> messages are produced for each of the nine BCD +timecode digits until the clock has been set or verified. They show the +results of decoding each digit of the transmitted timecode. +<p><tt>wwv4 ss stat sigl radx ckdig mldig diff cnt like snr</tt> + +<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above, +<tt>radx</tt> is the digit radix (3, 4, 6, 10), <tt>ckdig</tt> the +current clock digit, <tt>mldig</tt> the maximum likelihood digit, +<tt>diff</tt> the difference between these two digits modulo the radix, +<tt>cnt</tt> the compare counter, <tt>like</tt> the digit likelihood and +<tt>snr</tt> the likelihood ratio. An example is: + +<p><tt>wwv4 8 010f 5772 10 9 9 0 6 4615 6.1</tt> + +<p>Here the driver has previousl set or verified the clock. It has just +decoded the digit preceding second 8 of the minute. The digit radix is +10, the current clock and maximum likelihood digits are both 9, the +likelihood is well above the threshold (1000) and the likelihood +function well above threshold (3.0 dB). Short of a hugely unlikely +probability conspiracy, the clock digit is most certainly a 9. + +<p>Format <tt>wwv2</tt> messages are produced at each master oscillator +frequency update, which starts at 8 s, but eventually climbs to 1024 s. +They show the progress of the algorithm as it refines the frequency +measurement to a precision of 0.1 PPM. + +<p><tt>wwv2 ss stat sigl avint avcnt avinc jitr delt freq</tt> + +<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above, +<tt>avint</tt> is the averaging interval, <tt>avcnt</tt> the averaging +interval counter, <tt>avinc</tt> the interval increment, <tt>jitr</tt> +the sample change between the beginning and end of the interval, +<tt>delt</tt> the computed frequency change and <tt>freq</tt> the +current frequency (PPM). An example is: + +<p><tt>wwv2 22 030f 5795 256 256 4 0 0.0 66.7</tt> + +<p>Here the driver has acquired minute and second sync and set the +clock. The averaging interval has increased to 256 s on the way to 1024 +s, has stayed at that interval for 4 averaging intervals, has measured +no change in frequency and the current frequency is 66.7 PPM. + +<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: + +<pre> + sq yy ddd hh:mm:ss.fff ld du lset agc stn rfrq errs freq cons + + s sync indicator + q quality character + yyyy Gregorian year + ddd day of year + hh hour of day + mm minute of hour + fff millisecond of second + l leap second warning + d DST state + dut DUT sign and magnitude + lset minutes since last set + agc audio gain + ident station identifier and frequency + comp minute sync compare counter + errs bit error counter + freq frequency offset + avgt averaging time +</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. + +<dl> + +<dt><tt>s</tt> +<dd>The sync indicator is initially <tt>?</tt> before the clock is set, +but turns to space when all nine digits of the timecode are correctly +set.</dd> + +<dt><tt>q</tt> +<dd>The quality character is a four-bit hexadecimal code showing which +alarms have been raised. Each bit is associated with a specific alarm +condition according to the following: +<dl> + +<dt><tt>0x8</tt> +<dd>Sync alarm. The decoder may not be in correct second or minute phase +relative to the transmitter.</dd> + +<dt><tt>0x4</tt> +<dd>Error alarm. More than 30 data bit errors occurred in the last +minute.</dd> + +<dt><tt>0x2</tt> +<dd>Symbol alarm. The probability of correct decoding for a digit or +miscellaneous bit has fallen below the threshold.</dd> + +<dt><tt>0x1</tt> +<dd>Decoding alarm. A maximum likelihood digit fails to agree with the +current associated clock digit.</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. + +<dt><tt>yyyy ddd hh:mm:ss.fff</tt></tt> +<dd>The timecode format itself is self explanatory. Since the driver +latches the on-time epoch directly from the second sync pulse, the +fraction <tt>fff</tt>is always zero. Although the transmitted timecode +includes only the year of century, the Gregorian year is augmented 2000 +if the indicated year is less than 72 and 1900 otherwise.</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> + +<dt><tt>d</tt> +<dd>The DST state is <tt>S</tt> or <tt>D</tt> when standard time or +daylight time is in effect, respectively. The state is <tt>I</tt> or +<tt>O</tt> when daylight time is about to go into effect or out of +effect, respectively.</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> + +<dt><tt>lset</tt> +<dd>Before the clock is set, the interval since last set is the number +of minutes since the driver was started; after the clock is set, this +is number of minutes since the time was last verified relative to the +broadcast signal.</dd> + +<dt><tt>agc</tt> +<dd>The audio gain shows the current codec gain setting in the range 0 +to 255. Ordinarily, the receiver audio gain control or IRIG level +control should be set for a value midway in this range. + +<dt><tt>ident</tt> +<dd>The station identifier shows the station, <tt>C</tt> for WWV or +<tt>H</tt> for WWVH, and frequency being tracked. If neither station is +heard on any frequency, the station identifier shows <tt>X</tt>.</dd> + +<dt><tt>comp</tt> +<dd>The minute sync compare counter is useful to determine the quality +of the minute sync signal and can range from 0 (no signal) to 5 +(best).</dd> + +<dt><tt>errs</tt> +<dd>The bit error counter is useful to determine the quality of the data +signal received in the most recent minute. It is normal to drop a couple +of data bits under good signal conditions and increasing numbers as +conditions worsen. While the decoder performs moderately well even with +half the bits are in error in any minute, usually by that point the sync +signals are lost and the decoder reverts to free-run anyway.</dd> + +<dt><tt>freq</tt> +<dd>The frequency offset is the current estimate of the codec frequency +offset to within 0.1 PPM. This may wander a bit over the day due to +local temperature fluctuations and propagation conditions.</dd> + +<dt><tt>avgt</tt> +<dd>The averaging time is the interval between frequency updates in +powers of two to a maximum of 1024 s. Attainment of the maximum +indicates the driver is operating at the best possible resolution in +time and frequency.</dd> + +</dl> + +<p>An example timecode is: + +<p><tt> 0 2000 006 22:36:00.000 S +3 1 115 C20 6 5 66.4 1024</tt> + +<p>Here the clock has been set and no alarms are raised. The year, day +and time are displayed along with no leap warning, standard time and DUT ++0.3 s. The clock was set on the last minute, the AGC is safely in the +middle ot the range 0-255, and the receiver is tracking WWV on 20 MHz. +Excellent reeiving conditions prevail, as indicated by the compare count +6 and 5 bit errors during the last minute. The current frequency is 66.4 +PPM and the averaging interval is 1024 s, indicating the maximum +precision available. + +<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><table cols=6 width=100%> + +<tr> +<td>Radio</td> +<td>Hex</td> +<td>Decimal</td> +<td>Radio</td> +<td>Hex</td> +<td>Decimal</td> +</tr> + +<tr> +<td>IC725</td> +<td>0x28</td> +<td>40</td> +<td>IC781</td> +<td>0x26</td> +<td>38</td> +</tr> + +<tr> +<td>IC726</td> +<td>0x30</td> +<td>48</td> +<td>R7000</td> +<td>0x08</td> +<td>8</td> +</tr> + +<tr> +<td>IC735</td> +<td>0x04</td> +<td>4</td> +<td>R71</td> +<td>0x1A</td> +<td>26</td> +</tr> +<tr> +<td>IC751</td> +<td>0x1c</td> +<td>28</td> +<td>R7100</td> +<td>0x34</td> +<td>52</td> +</tr> +<tr> +<td>IC761</td> +<td>0x1e</td> +<td>30</td> +<td>R72</td> +<td>0x32</td> +<td>50</td> +</tr> + +<tr> +<td>IC765</td> +<td>0x2c</td> +<td>44</td> +<td>R8500</td> +<td>0x4a</td> +<td>74</td> +</tr> + +<tr> +<td>IC775</td> +<td>0x46</td> +<td>68</td> +<td>R9000</td> +<td>0x2a</td> +<td>42</td> +</tr> + +</table> + +<h4>Fudge Factors</h4> + +<dl> + +<dt><tt>time1 <I>time</I></tt></dt> +<dd>Specifies the propagation delay for WWV (40:40:49.0N 105:02:27.0W), +in seconds and fraction, with default 0.0.dd> + +<dt><tt>time2 <I>time</I></tt></dt> +<dd>Specifies the propagation delay for WWVH (21:59:26.0N 159:46:00.0W), +in seconds and fraction, with default 0.0. +</dd> + +<dt><tt>stratum <I>number</I></tt></dt> +<dd>Specifies the driver stratum, in decimal from 0 to 15, with default +0.</dd> + +<dt><tt>refid <I>string</I></tt></dt> +<dd>Ordinarily, this field specifies the driver reference identifier; +however, the driver sets the reference identifier automatically as +described above. +<dt><tt>flag1 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> + +<dt><tt>flag2 0 | 1</tt></dt> +<dd>Specifies the microphone port if set to zero or the line-in port if +set to one. It does not seem useful to specify the compact disc player +port.</dd> +<dt><tt>flag3 0 | 1</tt></dt> +<dd>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> diff --git a/contrib/ntp/html/driver37.htm b/contrib/ntp/html/driver37.htm new file mode 100644 index 0000000..6f6c8b3 --- /dev/null +++ b/contrib/ntp/html/driver37.htm @@ -0,0 +1,75 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> +<html> +<head> +<title>Forum Graphic GPS Dating station</title> +</head> +<body> + +<h3>Forum Graphic GPS Dating station</h3> +<hr> + +<h4>Synopsis</h4> + +<p>Address: 127.127.37.<i>u</i><br> +Reference ID: <tt>GPS</tt><br> +Driver ID: <tt>GPS</tt><br> +Parallel Port: <tt>/dev/fgclock<i>u</i></tt> +</p> + +<h4>Description</h4> + +<p>This driver supports the Forum Graphic GPS Dating station sold by <a +href="http://www.emr.fr/gpsclock.htm">EMR company</a>. + +<p>Unfortunately sometime FG GPS start continues reporting of the same +date. The only way to fix this problem is GPS power cycling and ntpd +restart after GPS power-up. +</P> +After Jan,10 2000 my FG GPS unit start send a wrong answer after 10:00am +till 11:00am. It repeat hour value in result string twice. I wroite a small +code to avoid such problem. Unfortunately I have no second FG GPS unit +to evaluate this problem. Please let me know if your GPS has no problems +after Y2K. +<p> + +<h4>Monitor Data</h4> + +<p>Each timecode is written to the <tt>clockstats</tt> file in the format +<tt>YYYY YD HH MI SS</tt>.</p> + +<h4>Fudge Factors</h4> + +<dl> +<dt><tt>time1 <i>time</i></tt></dt> +<dd>Specifies the time offset calibration factor, 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> + +<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>FG</tt>.</dd> + +<dt><tt>flag1 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> + +<dt><tt>flag2 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> + +<dt><tt>flag3 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> + +<dt><tt>flag4 0 | 1</tt></dt> +<dd>Not used by this driver.</dd> +</dl> + +<hr> +<address>Dmitry Smirnov (das@amt.ru)</address> + +</body> +</html> diff --git a/contrib/ntp/html/driver6.htm b/contrib/ntp/html/driver6.htm index a728a54..9fac978 100644 --- a/contrib/ntp/html/driver6.htm +++ b/contrib/ntp/html/driver6.htm @@ -1,253 +1,242 @@ -<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>IRIG Audio Decoder II for Sun SPARCstation -</TITLE> -</HEAD> -<BODY> - -<H3> -IRIG Audio Decoder</H3> - -<HR> -<H4> -Synopsis</H4> +<html><head><title> +IRIG Audio Decoder +</title></head><body><h3> +IRIG Audio Decoder +</h3><hr> + +<H4>Synopsis</H4> + Address: 127.127.6.<I>u</I> <BR>Reference ID: <TT>IRIG</TT> <BR>Driver ID: <TT>IRIG_AUDIO</TT> <BR>Audio Device: <TT>/dev/audio</TT> and <TT>/dev/audioctl</TT> <P>Note: This driver supersedes an older one of the same name, address -and ID which required replacing the original kernel audio driver with another -which works only on older Sun SPARCstation systems. The new driver described -here uses the stock kernel audio driver and works in SunOS 4.1.3 and Solaris -2.6 versions and probably all versions in between. The new driver requires -no modification of the operating system. While it is generic and likely -portable to other systems, it is somewhat slower than the original, since -the extensive signal conditioning, filtering and decoding is done in user -space, not kernel space. -<H4> -Description</H4> -This driver supports the Inter-Range Instrumentation Group (IRIG) standard -time distribution signal using the audio codec native to the Sun SPARCstation. -This signal is generated by several radio clocks, including those made -by Arbiter, Austron, Bancomm, Odetics, Spectracom and TrueTime, among others, -although it is often an add-on option. The signal is connected via an optional -attenuator box and cable to either the microphone or line-in ports on a -Sun SPARCstation <TT>/dev/audio</TT> audio codec device. The driver receives, -demodulates and decodes the IRIG-B and IRIG-E signal formats using internal -filters designed to reduce the effects of noise and interfering signals. - -<P>The IRIG signal format uses an amplitude-modulated carrier with pulse-width -modulated data bits. For IRIG-B, the carrier frequency is 1000 Hz and bit -rate 100 b/s; for IRIG-E, the carrier frequenchy is 100 Hz and bit rate -10 b/s. While IRIG-B provides the best accuracy, generally within a few -tens of microseconds relative to IRIG time, it can also generate a significant -load on the processor with older workstations. Generally, the accuracy -with IRIG-E is about ten times worse than IRIG-B, but the processor load -is ten times less. +and ID which required replacing the original kernel audio driver with +another which works only on older Sun SPARCstation systems. The new +driver described here uses the stock kernel audio driver and works in +SunOS 4.1.3 and Solaris 2.6 versions and probably all versions in +between. The new driver requires no modification of the operating +system. While it is generic and likely portable to other systems, it is +somewhat slower than the original, since the extensive signal +conditioning, filtering and decoding is done in user space, not kernel +space. + +<H4>Description</H4> + +This driver supports the Inter-Range Instrumentation Group (IRIG) +standard time distribution signal using the audio codec native to some +workstations. This signal is generated by several radio clocks, +including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom +and TrueTime, among others, although it is often an add-on option. The +signal is connected via an optional attenuator box and cable to either +the microphone or line-in port. The driver receives, demodulates and +decodes the IRIG-B and IRIG-E signal formats using internal filters +designed to reduce the effects of noise and interference. + +<p>This driver incorporates several features in common with other audio +drivers such as described in the <a href=driver7.htm>Radio CHU Audio +Demodulator/Decoder</a> and the <a href=driver36.htm>Radio WWV/H Audio +Demodulator/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>The IRIG signal format uses an amplitude-modulated carrier with +pulse-width modulated data bits. For IRIG-B, the carrier frequency is +1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy is 100 +Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy, +generally within a few tens of microseconds relative to IRIG time, it +can also generate a significant load on the processor with older +workstations. Generally, the accuracy with IRIG-E is about ten times +worse than IRIG-B, but the processor load is ten times less. <P>The program processes 8000-Hz mu-law companded samples using separate signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector -and automatic threshold corrector. Cycle crossings relative to the corrected -slice level determine the width of each pulse and its value - zero, one -or position identifier. The data encode 20 BCD digits which determine the -second, minute, hour and day of the year and sometimes the year and synchronization -condition. The comb filter exponentially averages the corresponding samples -of successive baud intervals in order to reliably identify the reference -carrier cycle. A type-II phase-lock loop (PLL) performs additional integration -and interpolation to accurately determine the zero crossing of that cycle, -which determines the reference timestamp. A pulse-width discriminator demodulates -the data pulses, which are then encoded as the BCD digits of the timecode. +and automatic threshold corrector. Cycle crossings relative to the +corrected slice level determine the width of each pulse and its value - +zero, one or position identifier. The data encode 20 BCD digits which +determine the second, minute, hour and day of the year and sometimes the +year and synchronization condition. The comb filter exponentially +averages the corresponding samples of successive baud intervals in order +to reliably identify the reference carrier cycle. A type-II phase-lock +loop (PLL) performs additional integration and interpolation to +accurately determine the zero crossing of that cycle, which determines +the reference timestamp. A pulse-width discriminator demodulates the +data pulses, which are then encoded as the BCD digits of the timecode. The timecode and reference timestamp are updated once each second with -IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved for -later processing. At poll intervals of 64 s, the saved samples are processed -by a trimmed-mean filter and used to update the system clock. +IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved +for later processing. At poll intervals of 64 s, the saved samples are +processed by a trimmed-mean filter and used to update the system clock. <P>Infinite impulse response (IIR) filters are used with both IRIG-B and -IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a 130-Hz -lowpass filter for IRIG-E. These are intended for use with noisy signals, -such as might be received over a telephone line or radio circuit, or when -interfering signals may be present in the audio passband. The driver determines -which IRIG format is in use by sampling the amplitude of each filter output -and selecting the one with maximum signal. An automatic gain control feature -provides protection against overdriven or underdriven input signal amplitudes. -It is designed to maintain adequate demodulator signal amplitude while -avoiding occasional noise spikes. In order to assure reliable capture, -the decompanded input signal amplitude must be greater than 100 units and -the codec sample frequency error less than 250 PPM (.025 percent). - -<P>The program performs a number of error checks to protect against overdriven -or underdriven input signal levels, incorrect signal format or improper -hardware configuration. Specifically, if any of the following errors occur -for a timecode, the data are rejected. Secifically, if any of the following -errors occur for a time measurement, the data are rejected. +IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a +130-Hz lowpass filter for IRIG-E. These are intended for use with noisy +signals, such as might be received over a telephone line or radio +circuit, or when interfering signals may be present in the audio +passband. The driver determines which IRIG format is in use by sampling +the amplitude of each filter output and selecting the one with maximum +signal. An automatic gain control feature provides protection against +overdriven or underdriven input signal amplitudes. It is designed to +maintain adequate demodulator signal amplitude while avoiding occasional +noise spikes. In order to assure reliable capture, the decompanded input +signal amplitude must be greater than 100 units and the codec sample +frequency error less than 250 PPM (.025 percent). + +<P>The program performs a number of error checks to protect against +overdriven or underdriven input signal levels, incorrect signal format +or improper hardware configuration. Specifically, if any of the +following errors occur for a timecode, the data are rejected. +Secifically, if any of the following errors occur for a time +measurement, the data are rejected. + <OL> -<LI> -The peak carrier amplitude is less than 100 units. This usually means dead -IRIG signal source, broken cable or wrong input port.</LI> - -<BR> -<LI> -The frequency error is greater than +-250 PPM (.025 percent). This usually -means broken codec hardware or wrong codec configuration.</LI> - -<BR> -<LI> -The modulation index is less than 0.5. This usually means overdriven IRIG -signal or wrong IRIG format.</LI> - -<BR> -<LI> -A frame synchronization error has occured. This usually means wrong IRIG -signal format or the IRIG signal source has lost synchronization (signature -control).</LI> - -<BR> -<LI> -A data decoding error has occured. This usually means wrong IRIG signal -format.</LI> - -<BR> -<LI> -The current second of the day is not exactly one greater than the previous -one. This usually means a very noisy IRIG signal or insufficient CPU resources.</LI> - -<BR> -<LI> -An audio codec error (overrun) occured. This usually means insufficient -CPU resources, as sometimes happens with Sun SPARC IPCs when doing something -useful.</LI> -</OL> -Note that additional checks are done elsewhere in the reference clock interface -routines. - -<P>Unlike other drivers, which can have multiple instantiations, this one -supports only one. It does not seem likely that more than one audio codec -would be useful in a single machine. More than one would probably chew -up too much CPU time anyway. -<H4> -IRIG-B Timecode Format</H4> -The 100 elements of the IRIG timecode are numbered from 0 through 99. Position -identifiers occur at elements 0, 9, 19 and every ten thereafter to 99. -The control function (CF) elements begin at element 50 (CF 1) and extend -to element 78 (CF 27). The straight-binary-seconds (SBS) field, which encodes -the seconds of the UTC day, begins at element 80 (CF 28) and extends to -element 97 (CF 44). The encoding of elements 50 (CF 1) through 78 (CF 27) -is device dependent. This driver presently decodes the CF elements, but -does nothing with them. - -<P>Where feasible, the IRIG signal source should be operated with signature -control so that, if the signal is lost or mutilated, the source produces -an unmodulated signal, rather than possibly random digits. The driver will -automatically reject the data and declare itself unsynchronized in this -case. Some devices, in particular Spectracom radio/satellite clocks, provide -additional year and status indication in the format: -<PRE> Element CF Function - ------------------------------------- - 55 6 time sync status - 60-63 10-13 BCD year units - 65-68 15-18 BCD year tens</PRE> -Other devices set these elements to zero. -<H4> -Performance</H4> -The mu-law companded data format allows considerable latitude in signal -levels; however, an automatic gain control (AGC) function is implemented -to further compensate for varying input signal levels and to avoid signal -distortion. For proper operation, the IRIG signal source should be configured -for analog signal levels, NOT digital TTL levels. - -<P>The accuracy of the system clock synchronized to the IRIG-B source with -this driver and the <TT>ntpd</TT> daemon is 10-20 microseconds with a Sun -UltraSPARC II and maybe twice that with a Sun SPARC IPC. The processor -resources consumed by the daemon can be significant, ranging from about -1.2 percent on the faster UltraSPARC II to 38 percent on the slower SPARC -IPC. However, the overall timing accuracy is limited by the resolution -and stability of the CPU clock oscillator and the interval between clock -corrections, which is 64 s with this driver. This performance, while probably -the best that can be achieved by the daemon itself, can be improved with -assist from the PPS discipline as described elsewhere in the documentation. -<H4> -Monitor Data</H4> -The timecode format used for debugging and data recording includes data -helpful in diagnosing problems with the IRIG signal and codec connections. -With debugging enabled (-d -d -d on the ntpd command line), the driver -produces one line for each timecode in the following format: -<PRE>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5 3094572411.00027</PRE> -The first field containes the error flags in hex, where the hex bits are -interpreted as below. This is followed by the IRIG status indicator, year -of century, day of year and time of day. The status indicator and year -are not produced by some IRIG devices. Following these fields are the signal -amplitude (0-8100), codec gain (0-255), field phase (0-79), time constant -(2-20), modulation index (0-1), carrier phase error (0+-0.5) and carrier -frequency error (PPM). The last field is the on-time timestamp in NTP format. -The fraction part is a good indicator of how well the driver is doing. -With an UltrSPARC 30, this is normally within a few tens of microseconds -relative to the IRIG-B signal and within a few hundred microseconds with -IRIG-E. -<H4> -Fudge Factors</H4> -<DL> -<DT> -<TT>time1 <I>time</I></TT></DT> +<LI>The peak carrier amplitude is less than 100 units. This usually +means dead IRIG signal source, broken cable or wrong input port.</LI> + +<LI>The frequency error is greater than ±250 PPM (.025 percent). +This usually means broken codec hardware or wrong codec +configuration.</LI> + +<LI>The modulation index is less than 0.5. This usually means overdriven +IRIG signal or wrong IRIG format.</LI> -<DD> -Specifies the time offset calibration factor, in seconds and fraction, -with default 0.0.</DD> +<LI>A frame synchronization error has occured. This usually means wrong +IRIG signal format or the IRIG signal source has lost synchronization +(signature control).</LI> -<DT> -<TT>time2 <I>time</I></TT></DT> +<LI>A data decoding error has occured. This usually means wrong IRIG +signal format.</LI> -<DD> -Not used by this driver.</DD> +<LI>The current second of the day is not exactly one greater than the +previous one. This usually means a very noisy IRIG signal or +insufficient CPU resources.</LI> -<DT> -<TT>stratum <I>number</I></TT></DT> +<LI>An audio codec error (overrun) occured. This usually means +insufficient CPU resources, as sometimes happens with Sun SPARC IPCs +when doing something useful.</LI> -<DD> -Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD> +</OL> -<DT> -<TT>refid <I>string</I></TT></DT> +Note that additional checks are done elsewhere in the reference clock +interface routines. + +<P>Unlike other drivers, which can have multiple instantiations, this +one supports only one. It does not seem likely that more than one audio +codec would be useful in a single machine. More than one would probably +chew up too much CPU time anyway. + +<H4>IRIG-B Timecode Format</H4> +The 100 elements of the IRIG timecode are numbered from 0 through 99. +Position identifiers occur at elements 0, 9, 19 and every ten thereafter +to 99. The control function (CF) elements begin at element 50 (CF 1) and +extend to element 78 (CF 27). The straight-binary-seconds (SBS) field, +which encodes the seconds of the UTC day, begins at element 80 (CF 28) +and extends to element 97 (CF 44). The encoding of elements 50 (CF 1) +through 78 (CF 27) is device dependent. This driver presently decodes +the CF elements, but does nothing with them. + +<P>Where feasible, the IRIG signal source should be operated with +signature control so that, if the signal is lost or mutilated, the +source produces an unmodulated signal, rather than possibly random +digits. The driver will automatically reject the data and declare itself +unsynchronized in this case. Some devices, in particular Spectracom +radio/satellite clocks, provide additional year and status indication in +the format: + +<PRE> Element CF Function + ------------------------------------- + 55 6 time sync status + 60-63 10-13 BCD year units + 65-68 15-18 BCD year tens +</PRE> -<DD> -Specifies the driver reference identifier, an ASCII string from one to -four characters, with default <TT>IRIG</TT>.</DD> +Other devices set these elements to zero. -<DT> -<TT>flag1 0 | 1</TT></DT> +<H4>Performance</H4> -<DD> -Not used by this driver.</DD> +The mu-law companded data format allows considerable latitude in signal +levels; however, an automatic gain control (AGC) function is implemented +to further compensate for varying input signal levels and to avoid +signal distortion. For proper operation, the IRIG signal source should +be configured for analog signal levels, NOT digital TTL levels. + +<P>The accuracy of the system clock synchronized to the IRIG-B source +with this driver and the <TT>ntpd</TT> daemon is 10-20 <font +face=symbol>m</font>s with a Sun UltraSPARC II and maybe twice that with +a Sun SPARC IPC. The processor resources consumed by the daemon can be +significant, ranging from about 1.2 percent on the faster UltraSPARC II +to 38 percent on the slower SPARC IPC. However, the overall timing +accuracy is limited by the resolution and stability of the CPU clock +oscillator and the interval between clock corrections, which is 64 s +with this driver. This performance, while probably the best that can be +achieved by the daemon itself, can be improved with assist from the PPS +discipline as described elsewhere in the documentation. + +<H4>Monitor Data</H4> -<DT> -<TT>flag2 0 | 1</TT></DT> +The timecode format used for debugging and data recording includes data +helpful in diagnosing problems with the IRIG signal and codec +connections. With debugging enabled (-d on the ntpd command line), the +driver produces one line for each timecode in the following format: + +<p><tt>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5 +3094572411.00027</tt> + +<p>The first field containes the error flags in hex, where the hex bits +are interpreted as below. This is followed by the IRIG status indicator, +year of century, day of year and time of day. The status indicator and +year are not produced by some IRIG devices. Following these fields are +the signal amplitude (0-8100), codec gain (0-255), field phase (0-79), +time constant (2-20), modulation index (0-1), carrier phase error +(0±0.5) and carrier frequency error (PPM). The last field is the +on-time timestamp in NTP format. The fraction part is a good indicator +of how well the driver is doing. With an UltrSPARC 30, this is normally +within a few tens of microseconds relative to the IRIG-B signal and +within a few hundred microseconds with IRIG-E. + +<H4>Fudge Factors</H4> -<DD> -Specifies the microphone port if set to zero or the line-in port if set -to one. It does not seem useful to specify the compact disc player port.</DD> +<DL> -<DT> -<TT>flag3 0 | 1</TT></DT> +<DT><TT>time1 <I>time</I></TT></DT> +<DD>Specifies the time offset calibration factor, in seconds and +fraction, with default 0.0.</DD> -<DD> -Enables audio monitoring of the input signal. For this purpose, the speaker -volume must be set before the driver is started.</DD> +<DT><TT>time2 <I>time</I></TT></DT> +<DD>Not used by this driver.</DD> -<DT> -<TT>flag4 0 | 1</TT></DT> +<DT><TT>stratum <I>number</I></TT></DT> +<DD>Specifies the driver stratum, in decimal from 0 to 15, with default +0.</DD> -<DD> -Enable verbose <TT>clockstats</TT> recording if set.</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>IRIG</TT>.</DD> + +<DT><TT>flag1 0 | 1</TT></DT> +<DD>Not used by this driver.</DD> + +<DT><TT>flag2 0 | 1</TT></DT> +<DD>Specifies the microphone port if set to zero or the line-in port if +set to one. It does not seem useful to specify the compact disc player +port.</DD> + +<DT><TT>flag3 0 | 1</TT></DT> +<DD>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> -Additional Information -<P><A HREF="refclock.htm">Reference Clock Drivers</A> -<HR> -<ADDRESS> -David L. Mills (mills@udel.edu)</ADDRESS> +<H4>Additional Information</H4> + +<A HREF="refclock.htm">Reference Clock Drivers</A> +<br><A HREF="audio.htm">Reference Clock Audio Drivers</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> diff --git a/contrib/ntp/html/driver7.htm b/contrib/ntp/html/driver7.htm index 0394fbf..5995072 100644 --- a/contrib/ntp/html/driver7.htm +++ b/contrib/ntp/html/driver7.htm @@ -1,227 +1,591 @@ -<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>Canadian CHU Radio Modem/Audio Decoder -</TITLE> -</HEAD> -<BODY> - -<H3> -CHU Audio/Modem Decoder</H3> - -<HR> -<H4> -Synopsis</H4> +<html><head><title> +Radio CHU Audio Demodulator/Decoder +</title></head><body><h3> +Radio CHU Audio Demodulator/Decoder +</h3><hr> + +<h4>Synopsis</h4> + Address: 127.127.7.<I>u</I> -<BR>Reference ID: <TT>CHU</TT> -<BR>Driver ID: <TT>CHU</TT> -<BR>Serial Port: <TT>/dev/chu<I>u</I></TT>; 300 baud, 8-bits, no parity -<BR>Audio Device: <TT>/dev/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 using the <TT>minimuf</TT> and -<TT>icom</TT> programs as propagation conditions change throughout the -day and night. - -<P>This 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. +<br>Reference ID: <tt>CHU</tt> +<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>; 9600 baud, 8-bits, no parity +<br>Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt> -<P>While there are currently no known commercial CHU receivers, a simple +<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-bps modem or modem chip, -as described in the <A HREF="file:///J|/ntp4/html/pps.htm">Pulse-per-second -(PPS) Signal Interfacing</A> page. The driver can be compiled to use this -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 drivers. In the latter case, the driver +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 CHU time broadcast includes an audio signal compatible with the +<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. + +<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. A missing <tt>mode</tt> +keyword or a zero argument leaves the interface disabled. 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. + +<p>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 bps 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><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>in UTC), minute (<TT>mm</TT>) -and the 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 <TT>x </TT>is coded - -<P>1 Sign of DUT (0 = +) -<BR>2 Leap second warning. One second will be added. -<BR>4 Leap second warning. One second will be subtracted. -This is not likely to happen in our universe. -<BR>8 Even parity bit for this nibble. - -<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 -bps, 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 <TT>fudge time1</TT>. -<H4> -Debugging aids</H4> -The timecode format used for debugging and data recording includes data -helpful in diagnosing problems with the radio signal and serial connections. -With debugging enabled (<TT>-d -d -d</TT> on the <TT>ntpd </TT>command -line), the driver produces one line for each burst in two formats corresponding -to format A and B. Following is format A: - -<P><TT> 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><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>When the audio driver is compiled, format A is preceded by the gain -(0-255) and relative signal level (0-9999). The receiver volume control -should be set so that the gain is near the middle of the range 0-255, which -results in a signal level near 1000. - -<P>Following is format B: - -<P><TT> 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> <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>In addition to the above, the reference timecode is updated and written -to the clockstats file and debug score after the last burst received in -the minute. The format is - -<P> <TT> qq yyyy ddd hh:mm:ss nn dd tt</TT> - -<P>where <TT>qq </TT>are the error flags, as described below, <TT>yyyy -</TT>is the year, <TT>ddd </TT>the day, <TT>hh:mm:ss </TT>the time of day, -<TT>nn </TT>the number of format A bursts received during the previous -minute, <TT>dd </TT>the decoding distance and <TT>tt </TT>the number of -timestamps. The error flags are cleared after every update. - -<P>For accuracy better than the low milliseconds, the <TT>fudge time1</TT> -variable can be used to set the propagation delay and compensate for inherent -latencies in the serial port hardware and operating system. This can be -done conveniently using the <TT>minimuf</TT> program. -<H4> -Monitor Data</H4> -When enabled by the <TT>flag4</TT> fudge flag, every received timecode -burst in both format A or format B is written to the <TT>clockstats</TT> -file. -<H4> -Fudge Factors</H4> - -<DL> -<DT> -<TT>time1 <I>time</I></TT></DT> - -<DD> -Specifies the time offset calibration factor, 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> - -<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> - -<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 +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><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>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 <tt>x</tt> is coded + +<dl> + +<dt><tt>1</tt> +<dd>Sign of DUT (0 = +)/dd> + +<dt><tt>2</tt> +<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> + +<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. + +<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>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><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><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><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><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>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: + +<pre> + sq yy ddd hh:mm:ss.fff ld dut lset agc rfrq bcnt dist tsmp + + s sync indicator + q quality character + yyyy Gregorian year + ddd day of year + hh hour of day + mm minute of hour + ss second of minute + fff millisecond of second + l leap second warning + d DST state + dut DUT sign and magnitude in deciseconds + lset minutes since last set + agc audio gain (0-255) + rfrq radio frequency + bcnt burst count + dist decoding distance + 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. + +<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> + +<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: + +<dl> +<dt><tt>8</tt> +<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> + +<dt><tt>1</tt> +<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. + +<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> +<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> + +<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> + +<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 +is number of minutes since the time was last verified relative to the +broadcast signal.</dd> + +<dt><tt>agc</tt> +<dd>The audio gain shows the current codec gain setting in the range 0 +to 255. Ordinarily, the receiver audio gain control or IRIG level +control should be set for a value midway in this range. + +<dt><tt>rfrq</tt> +<dd>The current radio frequency, if the CI-V interface is active, or 'X' +if not.</dd> + +<dt><tt>bcnt</tt> +<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> + +<dt><tt>tsmp</tt> +<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><table cols=6 width=100%> + +<tr> +<td>Radio</td> +<td>Hex</td> +<td>Decimal</td> +<td>Radio</td> +<td>Hex</td> +<td>Decimal</td> +</tr> + +<tr> +<td>IC725</td> +<td>0x28</td> +<td>40</td> +<td>IC781</td> +<td>0x26</td> +<td>38</td> +</tr> + +<tr> +<td>IC726</td> +<td>0x30</td> +<td>48</td> +<td>R7000</td> +<td>0x08</td> +<td>8</td> +</tr> + +<tr> +<td>IC735</td> +<td>0x04</td> +<td>4</td> +<td>R71</td> +<td>0x1A</td> +<td>26</td> +</tr> + +<tr> +<td>IC751</td> +<td>0x1c</td> +<td>28</td> +<td>R7100</td> +<td>0x34</td> +<td>52</td> +</tr> + +<tr> +<td>IC761</td> +<td>0x1e</td> +<td>30</td> +<td>R72</td> +<td>0x32</td> +<td>50</td> +</tr> + +<tr> +<td>IC765</td> +<td>0x2c</td> +<td>44</td> +<td>R8500</td> +<td>0x4a</td> +<td>74</td> +</tr> + +<tr> +<td>IC775</td> +<td>0x46</td> +<td>68</td> +<td>R9000</td> +<td>0x2a</td> +<td>42</td> +</tr> + +</table> + +<h4>Fudge Factors</h4> + +<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> + +<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> + +<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> + +<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> - -<DT> -<TT>flag3 0 | 1</TT></DT> +does not seem useful to select the compact disc player port.</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>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> -<DT> -<TT>flag4 0 | 1</TT></DT> +<dt><tt>flag4 0 | 1</tt></dt> +<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd> -<DD> -Enable verbose <TT>clockstats</TT> recording if set.</DD> -</DL> -Additional Information +</dl> -<P><A HREF="file:///J|/ntp4/html/refclock.htm">Reference Clock Drivers</A> -<HR> -<ADDRESS> -David L. Mills (mills@udel.edu)</ADDRESS> +<h4>Additional Information</h4> +<A HREF="refclock.htm">Reference Clock Drivers</A> +<br><A HREF="audio.htm">Reference Clock Audio Drivers</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> diff --git a/contrib/ntp/html/driver8.htm b/contrib/ntp/html/driver8.htm index 890b6c5..17ab6c3 100644 --- a/contrib/ntp/html/driver8.htm +++ b/contrib/ntp/html/driver8.htm @@ -82,7 +82,7 @@ available. refclock_ppstime lists then the PPS timestamp and refclock_ppsskew lists the difference between RS232 derived timestamp and the PPS timestamp. -<P>Currently, fourteen clock types (devices /dev/refclock-0 - +<P>Currently, eighteen clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported by the PARSE driver. <BR>A note on the implementations: <UL><li>These implementations where mainly done <B><I>WITHOUT</I></B> @@ -120,16 +120,16 @@ the vendors web pages. They are linked to the respective vendors. <B><TT>server 127.127.8.0-3 mode 0</TT></B> <p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A>PZF535/<A -HREF="http://www.meinberg.de/english/pzf509.htm">PZF509 receiver</A> (FM +HREF="http://www.meinberg.de/english/products/pzf509.htm">PZF509 receiver</A> (FM demodulation/TCXO / 50us)</TT></B> <BR> <LI> <B><TT>server 127.127.8.0-3 mode 1</TT></B> <p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A> PZF535/<A -HREF="http://www.meinberg.de/english/pzf509.htm">PZF509 +HREF="http://www.meinberg.de/english/products/pzf509.htm">PZF509 receiver</A> (FM demodulation/OCXO / 50us)</TT></B> -<BR><A HREF="http://www.meinberg.de/english/pzf509.htm"><IMG +<BR><A HREF="http://www.meinberg.de/english/products/pzf509.htm"><IMG SRC="pic/pzf509.jpg" ALT="BILD PZF509" HEIGHT=300 WIDTH=260 ALIGN=TEXTTOP></A> <BR> @@ -137,9 +137,9 @@ ALIGN=TEXTTOP></A> <B><TT>server 127.127.8.0-3 mode 2</TT></B> <p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A> DCF U/A -31/<A HREF="http://www.meinberg.de/english/c51.htm">DCF C51 receiver</A> +31/<A HREF="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver</A> (AM demodulation / 4ms)</TT></B> -<BR><A HREF="http://www.meinberg.de/english/c51.htm"><IMG +<BR><A HREF="http://www.meinberg.de/english/products/c51.htm"><IMG SRC="pic/c51.jpg" ALT="BILD C51" HEIGHT=180 WIDTH=330 ALIGN=TEXTTOP></A> <BR> <LI> @@ -171,9 +171,9 @@ demodulation <B><TT>server 127.127.8.0-3 mode 7</TT></B> <p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A> <A -HREF="http://www.meinberg.de/english/gps167.htm">GPS166/GPS167 +HREF="http://www.meinberg.de/english/products/gps167.htm">GPS166/GPS167 receiver</A> (GPS / <<1us)</TT></B> -<BR><A HREF="http://www.meinberg.de/english/gps167.htm"><IMG +<BR><A HREF="http://www.meinberg.de/english/products/gps167.htm"><IMG SRC="pic/gps167.jpg" ALT="BILD GPS167" HEIGHT=300 WIDTH=280 ALIGN=TEXTTOP></A> <BR> @@ -237,6 +237,16 @@ ALIGN=TEXTTOP></A> <p><B><TT>WHARTON 400A Series Clocks with a 404.2 Serial Interface</TT></B> +<LI> +<B><TT>server 127.127.8.0-3 mode 16</TT></B> + +<p><B><TT>RAWDCF receiver (DTR=low/RTS=high) +</TT></B> +<LI> +<B><TT>server 127.127.8.0-3 mode 17</TT></B> + +<p><B><TT>VARITEXT Receiver (MSF) +</TT></B> </UL> <p> Actual data formats and set-up requirements of the various clocks can be diff --git a/contrib/ntp/html/hints/solaris-dosynctodr.html b/contrib/ntp/html/hints/solaris-dosynctodr.html new file mode 100644 index 0000000..d6b97a9 --- /dev/null +++ b/contrib/ntp/html/hints/solaris-dosynctodr.html @@ -0,0 +1,320 @@ + +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> + + +<!-- Sun Template V4.0 9/9/98 --> +<HTML> +<HEAD> +<TITLE>Symptoms and Resolutions Article 19195</TITLE> +<META NAME="GENERATOR" CONTENT="Sun Microsystems, Inc."> +<META HTTP-EQUIV="content-type" CONTENT="text/html;charset=iso-8859-1"> + +<!-- INSERT YOUR META TAGS HERE --> + +<META NAME="PUBLISHED_DATE" CONTENT=""> +<META NAME="KEYWORDS" CONTENT=""> +<META NAME="DESCRIPTION" CONTENT=""> + +<!-- END META TAGS --> + +<LINK REL="Stylesheet" TYPE="text/css" HREF="/style.css" TITLE="Style"> + +</HEAD> +<!--stopindex--> +<BODY BGCOLOR="#FFFFFF" LINK="#666699" ALINK="#FFFFFF"> + + +<TABLE WIDTH="623" BORDER="0" CELLSPACING="0" CELLPADDING="0"> + <TR> + <TD COLSPAN="2" VALIGN="TOP" WIDTH="623"> + <IMG BORDER="0" SRC="/images/homebuy.gif" WIDTH="149" HEIGHT="32" ALT="Home * Buy * My Sun(sm)" USEMAP="#lefttop"><IMG BORDER="0" SRC="/images/globalnavbar.gif" WIDTH="474" HEIGHT="32" ALT="sun.com Global Sections" USEMAP="#topnav"></TD> + </TR> + <TR> + <TD COLSPAN="2" VALIGN="TOP" WIDTH="623"> + + <!-- TITLEBAR IMAGE: INSERT CUSTOMIZED TITLEBAR IMAGE BELOW --> + + <A HREF="http://www.sun.com/"><IMG BORDER="0" SRC="/images/sunlogo.gif" WIDTH="149" HEIGHT="72" ALT="Sun Microsystems"></A><IMG BORDER="0" SRC="/images/titlebar/doc.title.gif" WIDTH="474" HEIGHT="72"></TD> + </TR> + <!-- Begin Search Elements --> + <TR VALIGN="top"> + <TD BGCOLOR="#666699"> + <TABLE BORDER="0" WIDTH="157" CELLSPACING="0" CELLPADDING="0"> + <TR> + <TD BGCOLOR="#666699" COLSPAN="2" WIDTH="157" VALIGN="TOP"><IMG BORDER="0" SRC="/images/search/contract/search1.gif" WIDTH="157" HEIGHT="16" ALT="Search SunSolve"></TD> + </TR> + <TR> + <TD VALIGN="top" ALIGN="center" WIDTH="141" BGCOLOR="#666699"><FORM ACTION="search.pl" METHOD="POST"><FONT SIZE="2"><INPUT TYPE="text" NAME="zone_32" SIZE="14"></FONT><input type=hidden name=mode value=results><BR> +<INPUT TYPE="image" SRC="/images/search/contract/search5.gif" BORDER="0" NAME="Search"><IMG SRC="/images/cg_clear.gif" ALT="" WIDTH="2" HEIGHT="1" BORDER="0" HSPACE="29" VSPACE="0"><BR> + +<A HREF="search.pl?mode=advanced"><IMG BORDER="0" SRC="/images/search/contract/search3.gif" WIDTH="144" HEIGHT="16" ALT="Advanced Search"></A><BR> + +<A HREF="search.pl?mode=product"><IMG SRC="/images/search/contract/search4.gif" BORDER="0" ALT="Product Search" WIDTH="144" HEIGHT="19"></A><BR> + +<A HREF="show.pl?target=help/search_tips"><IMG SRC="/images/search/contract/search6.gif" BORDER="0" ALT="Search Tips" WIDTH="144" HEIGHT="27"></A></TD> + <TD ALIGN="right"><IMG SRC="/images/search/contract/search2.gif" ALT="" WIDTH="13" HEIGHT="117" BORDER="0"></TD> + </TR> + <!-- End Search Elements --> + <!-- Begin User Personalization (Must limit to 10 Characters)--> + <TR> + <TD COLSPAN="2"><TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="157"><TR><TD COLSPAN="3" ALIGN="right"><IMG SRC="/images/home_con/welcom_1.gif" ALT="" WIDTH="156" HEIGHT="4" BORDER="0"></TD></TR> + <TR><TD BGCOLOR="#333366"><IMG SRC="/images/home_con/welcom_2.gif" ALT="" WIDTH="17" HEIGHT="19" BORDER="0"></TD><TD BGCOLOR="#333366" VALIGN="middle"><NOBR><FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" COLOR="#99CC33" SIZE="-2">sopko</FONT></NOBR></TD><TD BGCOLOR="#333366" ALIGN="right"><A HREF="edit-user-form.pl?viewmode=contractuser"><IMG SRC="/images/home_con/welcom_3.gif" ALT="Edit" WIDTH="45" HEIGHT="19" BORDER="0"></A></TD></TR> + </TABLE> + </TD> + </TR> + <!-- End User Personalization --> + + <TR> + <TD COLSPAN="2" ALIGN="right" VALIGN="top" WIDTH="157" BGCOLOR="#666699"><IMG BORDER="0" SRC="/images/ssolvecontents.gif" WIDTH="157" HEIGHT="37" ALT="Contents Of SunSolve"><BR> + + + + + + <!-- PILLS: CHANGE THE PILL FOR CURRENT SECTION TO THE HIGHLIGHTED PILL --> + <!-- Beginning of Nav area --> +<A HREF="show.pl?target=patches/patch-access" onmouseover="window.status='All Public Patches'; return true" onmouseout="window.status=''; return true"> +<IMG BORDER="0" SRC="/images/nav/p1.gif" WIDTH="157" HEIGHT="19" ALT="All Public Patches"></A><BR> +<A HREF="suncourier.pl" onmouseover="window.status='Submit a Service Order'; return true" onmouseout="window.status=''; return true"> +<IMG BORDER="0" SRC="/images/nav/p5.gif" WIDTH="157" HEIGHT="19" ALT="Submit a Service Order"></A><BR> +<A HREF="show.pl?target=resources/tools" onmouseover="window.status='Diagnostic Tools'; return true" onmouseout="window.status=''; return true"> +<IMG BORDER="0" SRC="/images/nav/p4.gif" WIDTH="157" HEIGHT="19" ALT="Diagnostic Tools"></A><BR> +<A HREF="show.pl?target=help/collections" onmouseover="window.status='Support Docs.'; return true" onmouseout="window.status=''; return true"> +<IMG BORDER="0" SRC="/images/nav/cp2.gif" WIDTH="157" HEIGHT="19" ALT="Support Docs."></A><BR> +<A HREF="show.pl?target=resources/y2k" onmouseover="window.status='Y2K Central'; return true" onmouseout="window.status=''; return true"> +<IMG BORDER="0" SRC="/images/nav/p3.gif" WIDTH="157" HEIGHT="19" ALT="Y2K Central"></A><BR> +<A HREF="show.pl?target=security/sec" onmouseover="window.status='Security Information'; return true" onmouseout="window.status=''; return true"> +<IMG BORDER="0" SRC="/images/nav/p2.gif" WIDTH="157" HEIGHT="19" ALT="Security Information"></A><BR> +<br><table cellpadding="0" cellspacing="0" border="0" width="157"> +<tr><td width="8"> </td><td width="149"> +<table cellpadding="0" cellspacing="0" border="0"> +<BR><tr><td><BR><img src="/images/line.gif" alt="------" width="140" height="11" border="0"><br> + <A HREF="mark.pl" + onmouseover="window.status='Marked Docs.';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Marked Docs.</FONT></A><BR> + <A HREF="notify.pl" + onmouseover="window.status='Notifications';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Notifications</FONT></A><BR> + <A HREF="/plain-cgi/show.pl?target=home_con" + onmouseover="window.status='Low Graphics';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Low Graphics</FONT></A><BR> + <A HREF="show.pl?target=link" + onmouseover="window.status='SunSolve Servers';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">SunSolve Servers</FONT></A><BR> + <A HREF="show.pl?target=about_sunsolve" + onmouseover="window.status='About SunSolve';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">About SunSolve</FONT></A><BR> + <A HREF="feedback.pl" + onmouseover="window.status='Contact Us';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Contact Us</FONT></A><BR> + <A HREF="show.pl?target=help/sitemap" + onmouseover="window.status='Site Map';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Site Map</FONT></A><BR> + <A HREF="show.pl?target=article/article" + onmouseover="window.status='Articles';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Articles</FONT></A><BR> + <A HREF="show.pl?target=home_con" + onmouseover="window.status='Home';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Home</FONT></A><BR> + <A HREF="show.pl?target=help/faq" + onmouseover="window.status='Help';return true" + onmouseout="window.status='';return true"> + <font class="locallink" color="#dddddd">Help</FONT></A><BR> +<br></td></tr></table></td></tr></table> +<!-- End of Nav area --> + + </FORM> + <br><br><!-- some spacers --> + </TD> + </TR> + </TABLE> + </TD> + <TD VALIGN="TOP" WIDTH="466"> + + + <!--startindex--> + <!-- ============ --> + <!-- MAIN CONTENT --> + <!-- ============ --> + + + +<table width=100% cellpadding=16 cellspacing=0 border=0> + <tr> +<td width=100% valign=top> +<CENTER><FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" SIZE="2"> +[ <a href="retrieve.pl?type=0&doc=srdb%2F19195&display=plain">Printer Friendly Page</a> ] +[ <b>Was this document useful? <a href="retrieve.pl?type=0&doc=srdb/19195&vote=yes">Yes</a> or <a href="retrieve.pl?type=0&doc=srdb/19195&vote=no">No</a></b> ]<br>[ <a href="notify.pl?action=add&doc=srdb%2F19195&type=synopsis">Notify if Document Changes</a> ] +[ <a href="mark.pl?action=add&doc=srdb%2F19195&type=0">Mark Document for Download</a> ]<br>[ <a href="notify.pl">View/Edit Notifications</a> ] +[ <a href="mark.pl">View/Edit Marked Documents</a> ]<br></FONT></CENTER><br> + <SCRIPT Language="JavaScript"> + <!-- Hide javascript from older browsers + function jump() + { + var ctl = document.docform.jumplist; + location.href = ctl.options[ctl.selectedIndex].value; + } + // End hiding contents --> + </SCRIPT> +<a name="top"> +<form name="docform"><div align=center><font size=2> Jump to <select name="jumplist" size=1 onchange="jump();"></font><option value="#Hardware">Hardware</option> +<option value="#Product">Product</option> +<option value="#Product-Area">Product Area</option> +<option value="#Synopsis">Synopsis</option> +<option value="#Problem-Description">Problem Description</option> +<option value="#Document-Content">Document Content</option> +<option value="#Problem-Solution">Problem Solution</option> +<option value="#SRDB-ID">SRDB ID</option> +<option value="#OS">OS</option> +</select></div></form> +<table width=100% cellpadding=2 cellspacing=0 border=0> +<tr bgcolor=#666699><td><font size=2 color=#ffffff><b>SRDB ID</b></font></td> +<td bgcolor=#ffffff><font size=2> </font></td> +<td><font size=2 color=#ffffff><b>Synopsis</b></font></td> +<td bgcolor=#ffffff><font size=2> </font></td> +<td><font size=2 color=#ffffff><b>Date</b></font></td> +</tr> +<tr bgcolor=#CCCCE7><td><font size=2><b>19195</b></font></td> +<td bgcolor=#ffffff><font size=2> </font></td> +<td><font size=2><b>Upgraded to 2.6, using xntpd, but the system clock is drifting. Worked fine</b></font></td> +<td bgcolor=#ffffff><font size=2> </font></td> +<td><font size=2><b>4 Sep 1999</b></font></td> +</tr> +</table><br clear> +<table width=100% cellpadding=2 cellspacing=0 border=0><tr bgcolor=#999999> +<td><font size=2 color=#ffffff><b><a name=Problem-Description>Problem Description</a></b></font></td> +<td align=right><b><a href="#top"><font size=2 color=#ffffff>Top</font></a></b></td></tr></table> +<pre>Ever since upgrading to Solaris 2.6, the system clock has been drifting and +there are messages like 'synchronisation lost', 'Previous time adjustment +didn''t complete' and 'time reset (step)' a lot in the /var/adm/messages +file. The system either was previously working fine with the freeware +xntpd or the configuration was copied from another system that was +using the freeware version. +-- 23-Apr-99 08:22 US/Eastern --</pre><table width=100% cellpadding=2 cellspacing=0 border=0><tr bgcolor=#999999> +<td><font size=2 color=#ffffff><b><a name=Problem-Solution>Problem Solution</a></b></font></td> +<td align=right><b><a href="#top"><font size=2 color=#ffffff>Top</font></a></b></td></tr></table> +<pre>The common lore for setting up xntpd on Solaris using +the freeware version included the warning to set the +kernel variable <font color=red>dosynctodr</font> to 0 in the /etc/system +file thus: set <font color=red>dosynctodr</font>=0 + +When using NTP on Solaris 2.6 or later, the kernel +variable MUST be left at the default value of 1. Prior +to 2.6 this variable controlled whether or not to rein +in the softclock using the hardware clock, with the result +that NTP and the hardware clock would fight for control of +the soft clock; thus before 2.6 you had to set <font color=red>dosynctodr</font> +to 0. At 2.6, every system call that adjusts the softclock +also sets the hard clock, thus while NTP controls the soft +clock, the hard clock is also controlled. Setting +<font color=red>dosynctodr</font> to 0 reverts the behavior back to the pre 2.6 +defaulkt behavior, having exactly the opposite effect +as that intended. + +Do not set <font color=red>dosynctodr</font> to 0.</pre><table width=100% cellpadding=2 cellspacing=0 border=0> +<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Product-Area>Product Area</a></b></font></td> +<td bgcolor=#cccccc valign=top width=75%><font size=2>Bundled Network</font></td></tr> +<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Product>Product</a></b></font></td> +<td bgcolor=#cccccc valign=top width=75%><font size=2>NTP</font></td></tr> +<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=OS>OS</a></b></font></td> +<td bgcolor=#cccccc valign=top width=75%><font size=2>Solaris 2.6</font></td></tr> +<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Hardware>Hardware</a></b></font></td> +<td bgcolor=#cccccc valign=top width=75%><font size=2>Ultra 2</font></td></tr> +<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Document-Content>Document Content</a></b></font></td> +<td bgcolor=#cccccc valign=top width=75%><font size=2>with freeware xntpd.</font></td></tr> +</table><br clear> +<font size=2><a href="#top">Top</a></font><br><br> +</td></tr></table> + + <!-- =================== --> + <!-- END OF MAIN CONTENT --> + <!-- =================== --> + <!--stopindex--> + + <!-- DON'T CHANGE INFORMATION OTHER THAN titlebar BELOW THIS LINE --> + + <!-- Altered Table Structure from Template to format properly with new design --> + </TD> + </TR> + <TR> + <TD> </TD> + <TD VALIGN="top"> + <center> + <IMG SRC="/images/cg_grey_line.gif" ALT="" WIDTH="466" HEIGHT="2" BORDER="0"><BR> + <IMG SRC="/images/cg_clear.gif" ALT="" WIDTH="1" HEIGHT="2" BORDER="0" HSPACE="0" VSPACE="4"> + </center> + <CENTER> + <FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" SIZE="2"> + [ <A HREF="edit-user-form.pl?viewmode=contractuser">Edit Account</A> ] + [ <A HREF="show.pl?target=patches/patch-access">Patches</A> ] + [ <A HREF="suncourier.pl">Submit a Service Order</A> ]<br> + [ <A HREF="show.pl?target=resources/tools">Diagnostic Tools</A> ] + [ <A HREF="show.pl?target=help/collections">Support Docs.</A> ] + [ <A HREF="show.pl?target=resources/y2k">Y2K Central</A> ] + [ <A HREF="show.pl?target=security/sec">Security Information</A> ] <br> + [ <A HREF="show.pl?target=link">SunSolve Servers </A> ] + [ <A HREF="show.pl?target=about_sunsolve">About SunSolve</A> ] + [ <A HREF="feedback.pl">Contact Us</A> ] + [ <A HREF="show.pl?target=help/sitemap">Site Map</A> ] + [ <A HREF="show.pl?target=article/article">Articles</A> ] + [ <A HREF="show.pl?target=home_con">Home</A> ] + [ <A HREF="show.pl?target=help/faq">Help</A> ] + </FONT> + </CENTER> + +<!-- MAPS --> +<MAP NAME="lefttop"> +<AREA SHAPE="rect" HREF="http://www.sun.com/MySun/" ALT="My Sun" COORDS="89,0 149,32"> +<AREA SHAPE="rect" HREF="show.pl?target=home_con" ALT="Home" COORDS="0,0 42,32"> +<AREA SHAPE="rect" HREF="http://www.sun.com/sales/" ALT="Buy" COORDS="54,0 78,32"> +</MAP> + + +<MAP NAME="topnav"> +<AREA SHAPE="rect" HREF="http://www.sun.com/java/" ALT="Java Technologies" COORDS="4,0,67,32"> +<AREA SHAPE="rect" HREF="http://www.sun.com/products-n-solutions/" ALT="Products and Solutions" COORDS="74,0,141,32"> +<AREA SHAPE="rect" HREF="http://www.sun.com/service/" ALT="Support, Education, and Consulting" COORDS="148,0,249,32"> +<AREA SHAPE="rect" HREF="http://www.sun.com/tech/" ALT="Technology and Research" COORDS="261,0,324,32"> +<AREA SHAPE="rect" HREF="http://www.sun.com/developers/developers.html" ALT="For Developers" COORDS="334,0,396,32"> +<AREA SHAPE="rect" HREF="http://www.sun.com/corporateoverview/" ALT="Corporate Information" COORDS="406,0,482,32"> +</MAP> + +<!-- INSERT titlebar HREFS BELOW --> +<MAP NAME="titlebar"> +<!-- LINK TO SEC HOME Removed because no longer needed on this template --> +<AREA SHAPE="rect" HREF="/visual/home/" ALT="SunSolve Online(tm)" COORDS="0,21,215,51"> <!-- LINK TO CURRENT PILL HOME --> +</MAP> + + +<!-- begin copyright notice --> + +<BR> +<CENTER> +<FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" COLOR="#999999" SIZE="2"> +<br> +Copyright 1994-1999 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA. +<br> +All rights reserved. +<a href="http://www.sun.com/share/text/SMICopyright.html">Legal Terms</a>. +<a href="http://www.sun.com/privacy/">Privacy Policy</a>. +</font> +</CENTER> + +<!-- end copyright notice --> + + </TD> + </TR> +</TABLE> + +</BODY> +</HTML> + diff --git a/contrib/ntp/html/hints/solaris.html b/contrib/ntp/html/hints/solaris.html index 8595fbf..64b361a 100644 --- a/contrib/ntp/html/hints/solaris.html +++ b/contrib/ntp/html/hints/solaris.html @@ -14,9 +14,13 @@ that you will have problems; upgrading would be a really good plan. <P> <H3>All Solaris versions</H3> <P> -Proper operation of ntp under Solaris requires setting the kernel + We have a report that says starting with Solaris 2.6 we should leave + <I>dosynctodr</I> alone. + <A HREF="solaris-dosynctodr.html">Here is the report</A>. +<P> +Proper operation of ntp under Solaris may require setting the kernel variable <I>dosynctodr</I> to zero (meaning "do not synchronize the clock -to the hardware time-of-day clock"). This can be done with the +to the hardware time-of-day clock"). This can be done with the tickadj utility: <BLOCKQUOTE><TT> tickadj -s diff --git a/contrib/ntp/html/hints/solaris.xtra.S99ntpd b/contrib/ntp/html/hints/solaris.xtra.S99ntpd index 33662ba..d8058fd 100644 --- a/contrib/ntp/html/hints/solaris.xtra.S99ntpd +++ b/contrib/ntp/html/hints/solaris.xtra.S99ntpd @@ -2,6 +2,7 @@ if [ $1 = "start" ]; then if [ -x /usr/local/bin/xntpd ]; then echo "Starting NTP daemon, takes about 1 minute... " + # dosynctodr may need to be left alone as of with Solaris 2.6 # The following line is unnecessary if you turn off # dosynctodr in /etc/system. /usr/local/bin/tickadj -s diff --git a/contrib/ntp/html/hints/winnt.htm b/contrib/ntp/html/hints/winnt.htm new file mode 100644 index 0000000..06c0e41 --- /dev/null +++ b/contrib/ntp/html/hints/winnt.htm @@ -0,0 +1,315 @@ +<html> +<head> + <title>NTP on Windows NT</title> +</head> +<body> + +<h1> +NTP 4.x for Windows NT</h1> + +<h2> +Introduction</h2> +The NTP 4 distribution runs as service on (i386) Windows NT 4.0 and Windows +2000. The binaries now work on all dual processor systems (mostly Dell) +that have been tested. This port has not been tested on the Alpha platform. +<p>Refer to System Requirements and Instructions for how to compile the +program. +<h2> +Reference Clocks</h2> +Refernce clock support under Windows NT is tricky because the IO functions +are so much different. The following reference clocks are supported by +Windows NT: +<p><a href="../driver1.htm">Type 1</a> Undisciplined Local Clock (LOCAL) +<br><a href="../driver29.htm">Type 29</a> Trimble Navigation Palisade GPS +(GPS_PALISADE) +<h2> +Functions Supported</h2> +All NTP functions are supported with some constraints. See the TODO list +below. +<h2> +Accuracy</h2> +Greg Brackley has implemented a fantastic interpolation scheme that improves +the precision of the NTP clock using a realtime thread (is that poetic +or what!) which captures a tick count from the 8253 counter after each +OS tick. The count is used to interpolate the time between operating system +ticks. +<p>On a typical 200+ MHz system NTP achieves a precision of about 5 microseconds +and synchronizes the clock to +/-500 microseconds using the <a href="http://www.trimble.com/products/ntp">Trimble +Palisade</a> as UTC reference. This allows distributed applications to +use the 10 milliseconds ticks available to them with high confidence. +<h2> +Binaries</h2> +Recent InstallShield based executable versions of NTP for Windows NT (i386) +are available from: +<br><a href="http://www.trimble.com/oem/ntp">http://www.trimble.com/oem/ntp</a> +and <a href="http://www.five-ten-sg.com/">http://www.five-ten-sg.com/</a> +<h2> +ToDo</h2> + +<ul> +<li> +MD5 authentication causes problems with DNS. If you use encryption/authentication, +you have to use IP numbers in <tt>ntp.conf.</tt></li> + +<li> +NMEA refclock support is in development.</li> + +<li> +See if precision can be improved by using CPU cycle counter for tick interpolation.</li> + +<li> +Make precision time available to applications using NTP_GETTIME API</li> +</ul> + +<h2> +Compiling Requirements</h2> + +<ul> +<li> +<tt>Windows NT 4.0 or 5.0 (2000)</tt></li> + +<li> +<tt>Microsoft Visual C++ 6.0</tt></li> + +<li> +<tt>Perl5 </tt><a href="http://www.perl.org">http://www.perl.org</a></li> + +<li> +Some version of the archiving program <tt>ZIP</tt>.</li> +</ul> + +<h2> +Compiling Instructions</h2> + +<ol> +<li> +Install Perl and set the PERL environment variable to your Perl directory +(e.g. C:\PERL)</li> + +<li> +Unpack the NTP-4.x.tar.gz</li> + +<li> +Open the .\ports\winnt\ntp.dsw Visual C workspace</li> + +<li> +Batch build all projects</li> +</ol> + +<h2> +Configuration File</h2> +The default NTP configuration file path is %SystemRoot%<tt>\system32\drivers\etc\. +</tt>(%SystemRoot% +is an environmental variable that can be determined by typing "set" at +the "Command Prompt" or from the "System" icon in the "Control Panel"). +<br>Refer to your system environment and <tt>c</tt>reate your<tt> ntp.conf</tt> +file in the directory corresponding to your system installation. +<br><tt>The older <WINDIR>\ntp.conf </tt>is still supported but you +will get a log entry reporting that the first file wasn't found. +<h2> +Installation Instructions</h2> +The <tt>instsrv</tt> program in the instsrv subdirectory of the distribution +can be used to install 'ntpd' as a service and start automatically at boot +time. Instsrv is automatically compiled with the rest of the distribution +if you followed the steps above. +<ol> +<li> +Start a command prompt and enter "instsrv.exe <pathname_for_ntpd.exe>"</li> + +<li> +Clicking on the "Services" icon in the "Control Panel" will display the +list of currently installed services in a dialog box. The NetworkTimeProtocol +service should show up in this list. Select it in the list and hit the +"Start" button in the dialog box. The NTP service should start.</li> + +<li> +View the event log by clicking on the "Event Viewer" icon in the "Administrative +Tools" group, there should be several successful startup messages from +NTP. NTP will keep running and restart automatically when the machine is +rebooted.</li> +</ol> +You can change the start mode (automatic/manual) and other startup parameters +correponding to the NTP service (eg. location of conf file) also in the +"Services" dialog box if you wish. +<h2> +Removing NTP</h2> +You can also use <tt>instsrv</tt> to delete the NTP service by entering: +"instsrv.exe remove" +<h2> +Command Line Parameters and Registry Entries</h2> +Unlike the Unix environment, there is no clean way to run 'ntpdate' and +reset the clock before starting 'ntpd' at boot time. +<br>NTP will step the clock up to 1000 seconds by default. While there +is no reason that the system clock should be that much off during bootup +if 'ntpd' was running before, you may wish to override this default and/or +pass other command line directives. +<p>Use the registry editor to edit the value for the ntpd executable under +LocalMachine\System\CurrentControlSet\Services\NetworkTimeProtocol. +<p>Add the -g option behind "%INSTALLDIR>\ntpd". This will force NTP to +accept large time errors (including 1.1.1980 00:00) +<h2> +Bug Reports</h2> +Send bug reports to <a href="news://comp.protocols.time.ntp">news://comp.protocols.time.ntp</a> +and Sven_Dietrich@Trimble.COM +<h2> +Change Log</h2> + +<h3> +Last revision 15 November 1999 Version 4.0.98f.</h3> +<b>by Sven Dietrich (sven_dietrich@trimble.com)</b> +<p><b>Significant Changes:</b> +<ul> +<li> +Fixed I/O problem delaying packet responses which resulted in no-replys +to NTPQ and others.</li> + +<li> +The default configuration file path is <tt><WINDIR>\system32\drivers\etc\ntp.conf. +The old <WINDIR>\ntp.conf </tt>is still supported but you will get a +log entry reporting that the first file wasn't found. The NTP 3.x legacy +<tt>ntp.ini</tt> +file is no longer supported.</li> +</ul> +<b>Known Problems / TODO:</b> +<ul> +<li> +MD5 and name resolution do not yet get along. If you define MD5, you cannot +use DNS names, only IP numbers.</li> +</ul> + +<h3> +Last revision 27 July 1999 Version 4.0.95.</h3> +This version compiles under WINNT with Visual C 6.0. +<p>Greg Brackley and Sven Dietrich +<p>Significant changes: +<br>-Visual Studio v6.0 support +<br>-Winsock 2.0 support +<br>-Use of I/O completion ports for sockets and comm port I/O +<br>-Removed the use of multimedia timers (from ntpd, others need removing) +<br>-Use of waitable timers (with user mode APC) and performance counters +to fake getting a better time +<br>-Trimble Palisade NTP Reference Clock support +<br>-General cleanup, prototyping of functions +<br>-Moved receiver buffer code to a separate module (removed unused members +from the recvbuff struct) +<br>-Moved io signal code to a separate module +<h3> +Last revision: 20-Oct-1996</h3> +This version corrects problems with building the XNTP +<br>version 3.5-86 distribution under Windows NT. +<p>The following files were modified: +<br> blddbg.bat +<br> bldrel.bat +<br> include\ntp_machine.h +<br> xntpd\ntp_unixclock.c +<br> xntpd\ntp_refclock.c +<br> scripts\wininstall\build.bat +<br> scripts\wininstall\setup.rul +<br> scripts\wininstall\readme.nt +<br> scripts\wininstall\distrib\ntpog.wri +<br> html\hints\winnt (this file) +<p>In order to build the entire Windows NT distribution you +<br>need to modify the file scripts\wininstall\build.bat +<br>with the installation directory of the InstallShield +<br>software. Then, simply type "bldrel" for non-debug +<br>or "blddbg" for debug executables. +<p>Greg Schueman +<br> <schueman@acm.org> +<h3> +Last revision: 07-May-1996</h3> +This set of changes fixes all known bugs, and it includes +<br>several major enhancements. +<p>Many changes have been made both to the build environment as +<br>well as the code. There is no longer an ntp.mak file, instead +<br>there is a buildntall.bat file that will build the entire +<br>release in one shot. The batch file requires Perl. Perl +<br>is easily available from the NT Resource Kit or on the Net. +<p>The multiple interface support was adapted from Larry Kahn's +<br>work on the BIND NT port. I have not been able to test it +<br>adequately as I only have NT servers with one network +<br>interfaces on which to test. +<p>Enhancements: +<br>* Event Logging now works correctly. +<br>* Version numbers now work (requires Perl during build) +<br>* Support for multiple network interface cards (untested) +<br>* NTP.CONF now default, but supports ntp.ini if not found +<br>* Installation procedure automated. +<br>* All paths now allow environment variables such as %windir% +<p>Bug fixes: +<br>* INSTSRV replaced, works correctly +<br>* Cleaned up many warnings +<br>* Corrected use of an uninitialized variable in XNTPD +<br>* Fixed ntpdate -b option +<br>* Fixed ntpdate to accept names as well as IP addresses +<br> (Winsock WSAStartup was +called after a gethostbyname()) +<br>* Fixed problem with "longjmp" in xntpdc/ntpdc.c that +<br> caused a software exception +on doing a Control-C in xntpdc. +<br> A Cntrl-C now terminates the program. +<p>See below for more detail: +<p> Note: SIGINT is not supported for any +Win32 application including +<br> Windows NT and Windows 95. When a CTRL+C +interrupt occurs, Win32 +<br> operating systems generate a new thread +to specifically handle that +<br> interrupt. This can cause a single-thread +application such as UNIX, +<br> to become multithreaded, resulting in +unexpected behavior. +<br> +<p>Possible enhancements and things left to do: +<br>* Reference clock drivers for NT (at least Local Clock support) +<br>* Control Panel Applet +<br>* InstallShield based installation, like NT BIND has +<br>* Integration with NT Performance Monitor +<br>* SNMP integration +<br>* Fully test multiple interface support +<br> +<p>Known problems: +<br>* bug in ntptrace - if no Stratum +1 servers are available, +<br> +such as on an IntraNet, the application crashes. +<h3> +Last revision: 12-Apr-1995</h3> +This NTPv3 distribution includes a sample configuration file and the project +<br>makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0 +compiler. +<br>Also included is a small routine to install the NTP daemon as a "service" +<br>on a WindowsNT box. Besides xntpd, the utilities that have been ported +are +<br>ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using +a Bancomm +<br>TimeServe2000 GPS receiver clock that acts as a strata 1 NTP server +with no +<br>authentication (it has not been tested with any refclock drivers compiled +in). +<br>Following are the known flaws in this port: +<br>1) currently, I do not know of a way in NT to get information about +multiple +<br> network interface cards. The current port uses just one +socket bound to +<br> INADDR_ANY address. Therefore when dealing with a multihomed +NT time server, +<br> clients should point to the default address on the server +(otherwise the +<br> reply is not guaranteed to come from the same interface +to which the +<br> request was sent). Working with Microsoft to get this +resolved. +<br>2) There is some problem with "longjmp" in xntpdc/ntpdc.c that causes +a +<br> software exception on doing a Control-C in xntpdc. Be +patient! +<br>3) The error messages logged by xntpd currently contain only the numerical +<br> error code. Corresponding error message string has to +be looked up in +<br> "Books Online" on Visual C++ 2.0 under the topic "Numerical +List of Error +<br> Codes". +<p>Last HTML Update: November 17, 1999 +<br><a href="mailto://sven_dietrich@trimble.com">Sven_Dietrich@Trimble.COM</a> +</body> +</html> diff --git a/contrib/ntp/html/index.htm b/contrib/ntp/html/index.htm index a676c87..c5cca91 100644 --- a/contrib/ntp/html/index.htm +++ b/contrib/ntp/html/index.htm @@ -1,8 +1,8 @@ -<HTML><HEAD><TITLE> +<html><head><title> The Network Time Protocol (NTP) Distribution -</TITLE></HEAD><BODY><H3> +</title></head><body><h3> The Network Time Protocol (NTP) Distribution -</H3> +</h3> <IMG align=left SRC=pic/barnstable.gif>From <i>pogo</i>, Walt Kelly diff --git a/contrib/ntp/html/monopt.htm b/contrib/ntp/html/monopt.htm index fc6ba84..267bbcc 100644 --- a/contrib/ntp/html/monopt.htm +++ b/contrib/ntp/html/monopt.htm @@ -1,370 +1,250 @@ -<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>Monitoring Options -</TITLE> -</HEAD> -<BODY> - -<H3> -Monitoring Options</H3> - -<HR> -<H4> -Monitoring Support</H4> -<TT>ntpd</TT> includes a comprehensive monitoring facility suitable for -continuous, long term recording of server and client timekeeping performance. -See the <TT>statistics</TT> command below for a listing and example of -each type of statistics currently supported. Statistic files are managed -using file generation sets and scripts in the ./scripts directory of this -distribution. Using these facilities and Unix <TT>cron</TT> jobs, the data -can be automatically summarized and archived for retrospective analysis. -<H4> -Monitoring Commands</H4> - -<DL> -<DT> -<TT>statistics <I>name</I> [...]</TT></DT> - -<DD> -Enables writing of statistics records. Currently, four kinds of <I><TT>name</TT></I> -statistics are supported.</DD> - -<DD> - </DD> - -<DL> -<DT> -<TT>loopstats</TT></DT> - -<DD> -Enables recording of loop filter statistics information. Each update of -the local clock outputs a line of the following form to the file generation -set named <TT>loopstats</TT>:</DD> - -<PRE>50935 75440.031 0.000006019 13.778190 0.000351733 0.013380 6</PRE> - -<DD> -The first two fields show the date (Modified Julian Day) and time (seconds -and fraction past UTC midnight). The next five fields show time offset -(seconds), frequency offset (parts per million - PPM), RMS jitter (seconds), -Allan deviation (PPM) and clock discipline time constant.</DD> - -<DD> - </DD> - -<DT> -<TT>peerstats</TT></DT> - -<DD> -Enables recording of peer statistics information. This includes statistics -records of all peers of a NTP server and of special signals, where present -and configured. Each valid update appends a line of the following form -to the current element of a file generation set named <TT>peerstats</TT>:</DD> - -<PRE>48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142</PRE> - -<DD> -The first two fields show the date (Modified Julian Day) and time (seconds -and fraction past UTC midnight). The next two fields show the peer address -in dotted-quad notation and status, respectively. The status field is encoded -in hex in the format described in Appendix A of the NTP specification RFC -1305. The final three fields show the offset, delay and RMS jitter, all -in seconds.</DD> - -<DD> - </DD> - -<DT> -<TT>clockstats</TT></DT> - -<DD> -Enables recording of clock driver statistics information. Each update received -from a clock driver appends a line of the following form to the file generation -set named <TT>clockstats</TT>:</DD> - -<PRE>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</PRE> - -<DD> -The first two fields show the date (Modified Julian Day) and time (seconds -and fraction past UTC midnight). The next field shows the clock address -in dotted-quad notation, The final field shows the last timecode received -from the clock in decoded ASCII format, where meaningful. In some clock -drivers a good deal of additional information can be gathered and displayed -as well. See information specific to each clock for further details.</DD> - -<DD> - </DD> - -<DT> -<TT>rawstats</TT></DT> - -<DD> -Enables recording of raw-timestamp statistics information. This includes +<html><head><title> +Monitoring Options +</title></head><body><h3> +Monitoring Options +</h3><hr> + +<h4>Monitoring Support</h4> + +<tt>ntpd</tt> includes a comprehensive monitoring facility suitable for +continuous, long term recording of server and client timekeeping +performance. See the <tt>statistics</tt> command below for a listing and +example of each type of statistics currently supported. Statistic files +are managed using file generation sets and scripts in the ./scripts +directory of this distribution. Using these facilities and Unix +<tt>cron</tt> jobs, the datacan be automatically summarized and archived +for retrospective analysis. + +<h4>Monitoring Commands</h4> + +<dl> + +<dt><tt>statistics <I>name</I> [...]</tt></dt> +<dd>Enables writing of statistics records. Currently, four kinds of +<I><tt>name</tt></I>statistics are supported.</dd> + +<dl> + +<dt><tt>loopstats</tt></dt> +<dd>Enables recording of loop filter statistics information. Each update +of the local clock outputs a line of the following form to the file +generation set named <tt>loopstats</tt>:</dd> + +<p><dd><tt>50935 75440.031 0.000006019 13.778190 0.000351733 0.013380 +6</tt></dd> + +<p><dd>The first two fields show the date (Modified Julian Day) and time +(seconds and fraction past UTC midnight). The next five fields show time +offset (seconds), frequency offset (parts per million - PPM), RMS jitter +(seconds), Allan deviation (PPM) and clock discipline time +constant.</dd> + +<dt><tt>peerstats</tt></dt> +<dd>Enables recording of peer statistics information. This includes statistics records of all peers of a NTP server and of special signals, -where present and configured. Each NTP message received from a peer or -clock driver appends a line of the following form to the file generation -set named <TT>rawstats</TT>:</DD> - -<DD> - </DD> - -<DD> -<TT>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 -02453332.540806000 3102453332.541458000</TT></DD> - -<DD> -<TT> </TT></DD> - -<DD> -The first two fields show the date (Modified Julian Day) and time (seconds -and fraction past UTC midnight). The next field shows the peer or clock -address in dotted-quad notation, The final four fields show the originate, -receive, transmit and final NTP timestamps in order. The timestamp values -are as received and before processing by the various data smoothing and -mitigation algorithms.</DD> -</DL> - -<DD> - </DD> - -<DT> -<TT>statsdir <I>directory_path</I></TT></DT> - -<DD> -Indicates the full path of a directory where statistics files should be -created (see below). This keyword allows the (otherwise constant) <TT>filegen</TT> -filename prefix to be modified for file generation sets, which is useful -for handling statistics logs.</DD> - -<DD> - </DD> - -<DT> -<TT>filegen <I>name</I> [file <I>filename</I>] [type <I>typename</I>] [link -| nolink] [enable | disable]</TT></DT> - -<DT> -<TT> </TT></DT> - -<DD> -Configures setting of generation file set <I>name</I>. Generation file -sets provide a means for handling files that are continuously growing during -the lifetime of a server. Server statistics are a typical example for such -files. Generation file sets provide access to a set of files used to store -the actual data. At any time at most one element of the set is being written -to. The type given specifies when and how data will be directed to a new -element of the set. This way, information stored in elements of a file -set that are currently unused are available for administrational operations -without the risk of disturbing the operation of <TT>ntpd</TT>. (Most important: -they can be removed to free space for new data produced.)</DD> - -<DD> - </DD> - -<DD> -Note that this command can be sent from the <TT>ntpdc</TT> program running -at a remote location.</DD> - -<DD> - </DD> - -<DL> -<DT> -<I><TT>name</TT></I></DT> - -<DD> -This is the type of the statistics records, as shown in the <TT>statististics</TT> -command.</DD> - -<DD> - </DD> -</DL> - -<DD> -<TT>file <I>filename</I></TT></DD> - -<DL> -<DD> -This is the file name for the statistics records. Filenames of set members -are built from three elements:</DD> - -<DD> - </DD> - -<DL> -<DT> -prefix</DT> - -<DD> -This is a constant filename path. It is not subject to modifications via -the <TT>filegen</TT> option. It is defined by the server, usually specified -as a compile-time constant. It may, however, be configurable for individual -file generation sets via other commands. For example, the prefix used with -<TT>loopstats</TT> and <TT>peerstats</TT> generation can be configured -using the <TT>statsdir</TT> option explained above.</DD> - -<DD> - </DD> - -<DT> -<I><TT>filename</TT></I></DT> - -<DD> -This string is directly concatenated to the prefix mentioned above (no -intervening <TT>/</TT> (slash)). This can be modified using the <TT>file</TT> -argument to the <TT>filegen</TT> statement. No <TT>..</TT> elements are -allowed in this component to prevent filenames referring to parts outside -the filesystem hierarchy denoted by <TT>prefix</TT>.</DD> - -<DD> - </DD> - -<DT> -suffix</DT> - -<DD> -This part is reflects individual elements of a file set. It is generated -according to the type of a file set.</DD> -</DL> - -<DD> - </DD> -</DL> - -<DD> -<TT>type <I>typename</I></TT></DD> - -<DL> -<DD> -A file generation set is characterized by its type. The following types -are supported:</DD> - -<DD> - </DD> - -<DL> -<DT> -<TT>none</TT></DT> - -<DD> -The file set is actually a single plain file.</DD> - -<DD> - </DD> - -<DT> -<TT>pid</TT></DT> - -<DD> -One element of file set is used per incarnation of a <TT>ntpd</TT> server. -This type does not perform any changes to file set members during runtime, -however it provides an easy way of separating files belonging to different -<TT>ntpd</TT> server incarnations. The set member filename is built by -appending a <TT>.</TT> (dot) to concatenated <I>prefix</I> and <I>filename</I> -strings, and appending the decimal representation of the process ID of -the <TT>ntpd</TT> server process.</DD> - -<DD> - </DD> - -<DT> -<TT>day</TT></DT> - -<DD> -One file generation set element is created per day. A day is defined as -the period between 00:00 and 24:00 UTC. The file set member suffix consists -of a <TT>.</TT> (dot) and a day specification in the form <TT>YYYYMMDD. -YYYY</TT> is a 4-digit year number (e.g., 1992). <TT>MM</TT> is a two digit -month number. <TT>DD</TT> is a two digit day number. Thus, all information -written at 10 December 1992 would end up in a file named <TT><I>prefix -filename</I>.19921210</TT>.</DD> - -<DD> - </DD> - -<DT> -<TT>week</TT></DT> - -<DD> -Any file set member contains data related to a certain week of a year. -The term week is defined by computing day-of-year modulo 7. Elements of -such a file generation set are distinguished by appending the following -suffix to the file set filename base: A dot, a 4-digit year number, the -letter <TT>W</TT>, and a 2-digit week number. For example, information -from January, 10th 1992 would end up in a file with suffix <TT>.1992W1</TT>.</DD> - -<DD> - </DD> - -<DT> -<TT>month</TT></DT> - -<DD> -One generation file set element is generated per month. The file name suffix -consists of a dot, a 4-digit year number, and a 2-digit month.</DD> - -<DD> - </DD> - -<DT> -<TT>year</TT></DT> - -<DD> -One generation file element is generated per year. The filename suffix -consists of a dot and a 4 digit year number.</DD> - -<DD> - </DD> - -<DT> -<TT>age</TT></DT> - -<DD> -This type of file generation sets changes to a new element of the file -set every 24 hours of server operation. The filename suffix consists of -a dot, the letter <TT>a</TT>, and an 8-digit number. This number is taken -to be the number of seconds the server is running at the start of the corresponding -24-hour period. Information is only written to a file generation by specifying -<TT>enabl</TT>; output is prevented by specifying <TT>disable</TT>.</DD> - -<DD> - </DD> -</DL> -</DL> - -<DD> -<TT>link | nolink</TT></DD> - -<DL> -<DD> -It is convenient to be able to access the current element of a file generation -set by a fixed name. This feature is enabled by specifying <TT>link</TT> -and disabled using <TT>nolink</TT>. If <TT>link</TT> is specified, a hard -link from the current file set element to a file without suffix is created. -When there is already a file with this name and the number of links of -this file is one, it is renamed appending a dot, the letter <TT>C</TT>, -and the pid of the <TT>ntpd</TT> server process. When the number of links -is greater than one, the file is unlinked. This allows the current file -to be accessed by a constant name.</DD> - -<DD> - </DD> -</DL> - -<DD> -<TT>enable | disable</TT></DD> - -<DL> -<DD> -Enables or disables the recording function.</DD> -</DL> -</DL> - -<HR> -<ADDRESS> -David L. Mills (mills@udel.edu)</ADDRESS> - -</BODY> -</HTML> +where present and configured. Each valid update appends a line of the +following form to the current element of a file generation set named +<tt>peerstats</tt>:</dd> + +<p><dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 +0.00142</tt></dd> + +<p><dd>The first two fields show the date (Modified Julian Day) and time +(seconds and fraction past UTC midnight). The next two fields show the +peer address in dotted-quad notation and status, respectively. The +status field is encoded in hex in the format described in Appendix A of +the NTP specification RFC 1305. The final three fields show the offset, +delay and RMS jitter, all in seconds.</dd> + +<dt><tt>clockstats</tt></dt> +<dd>Enables recording of clock driver statistics information. Each +update received from a clock driver appends a line of the following form +to the file generation set named <tt>clockstats</tt>:</dd> + +<p><dd><tt>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</tt></dd> +<p><dd>The first two fields show the date (Modified Julian Day) and time +(seconds and fraction past UTC midnight). The next field shows the clock +address in dotted-quad notation, The final field shows the last timecode +received from the clock in decoded ASCII format, where meaningful. In +some clock drivers a good deal of additional information can be gathered +and displayed as well. See information specific to each clock for +further details.</dd> + +<dt><tt>rawstats</tt></dt> +<dd>Enables recording of raw-timestamp statistics information. This +includes statistics records of all peers of a NTP server and of special +signals, where present and configured. Each NTP message received from a +peer or clock driver appends a line of the following form to the file +generation set named <tt>rawstats</tt>:</dd> + +<p><dd><tt>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 +3102453281.58622800031 02453332.540806000 3102453332.541458000</tt></dd> + +<p><dd>The first two fields show the date (Modified Julian Day) and time +(seconds and fraction past UTC midnight). The next two fields show the +remote peer or clock address followed by the local address in +dotted-quad notation, The final four fields show the originate, receive, +transmit and final NTP timestamps in order. The timestamp values are as +received and before processing by the various data smoothing and +mitigation algorithms.</dd> + +</dl> + +<dt><tt>statsdir <I>directory_path</I></tt></dt> +<dd>Indicates the full path of a directory where statistics files should +be created (see below). This keyword allows the (otherwise constant) +<tt>filegen</tt> filename prefix to be modified for file generation +sets, which is useful for handling statistics logs.</dd> + +<dt><tt>filegen <I>name</I> [file <I>filename</I>] [type +<I>typename</I>] [link | nolink] [enable | disable]</tt></dt> +<dd>Configures setting of generation file set <I>name</I>. Generation +file sets provide a means for handling files that are continuously +growing during the lifetime of a server. Server statistics are a typical +example for such files. Generation file sets provide access to a set of +files used to store the actual data. At any time at most one element of +the set is being written to. The type given specifies when and how data +will be directed to a new element of the set. This way, information +stored in elements of a file set that are currently unused are available +for administrational operations without the risk of disturbing the +operation of <tt>ntpd</tt>. (Most important: they can be removed to free +space for new data produced.)</dd> + +<dd>Note that this command can be sent from the <tt>ntpdc</tt> program +running at a remote location.</dd> + +<dl> + +<dt><I><tt>name</tt></I></dt> +<dd>This is the type of the statistics records, as shown in the +<tt>statististics</tt> command.</dd> + +</dl> + +<dd><tt>file <I>filename</I></tt></dd> + +<dl> + +<dd>This is the file name for the statistics records. Filenames of set +members are built from three concatenated elements +<I><tt>prefix</tt></I>, <I><tt>filename</tt></I> and +<I><tt>suffix</tt></I>:</dd> + +<dl> + +<dt><I><tt>prefix</tt></I></dt> +<dd>This is a constant filename path. It is not subject to modifications +via the <tt>filegen</tt> option. It is defined by the server, usually +specified as a compile-time constant. It may, however, be configurable +for individual file generation sets via other commands. For example, the +prefix used with <tt>loopstats</tt> and <tt>peerstats</tt> generation +can be configured using the <tt>statsdir</tt> option explained +above.</dd> + +<dt><I><tt>filename</tt></I></dt> +<dd>This string is directly concatenated to the prefix mentioned above +(no intervening <tt>/</tt> (slash)). This can be modified using the +<tt>file</tt> argument to the <tt>filegen</tt> statement. No <tt>..</tt> +elements are allowed in this component to prevent filenames referring to +parts outside the filesystem hierarchy denoted by <tt>prefix</tt>.</dd> + +<dt><I><tt>suffix</tt></I></dt> +<dd>This part is reflects individual elements of a file set. It is +generated according to the type of a file set.</dd> + +</dl> + +</dl> + +<dd><tt>type <I>typename</I></tt></dd> + +<dl> + +<dd>A file generation set is characterized by its type. The following +types are supported:</dd> + +<dl> + +<dt><tt>none</tt></dt> +<dd>The file set is actually a single plain file.</dd> + +<dt><tt>pid</tt></dt> +<dd>One element of file set is used per incarnation of a <tt>ntpd</tt> +server. This type does not perform any changes to file set members +during runtime, however it provides an easy way of separating files +belonging to different <tt>ntpd</tt> server incarnations. The set member +filename is built by appending a <tt>.</tt> (dot) to concatenated +<I>prefix</I> and <I>filename</I> strings, and appending the decimal +representation of the process ID of the <tt>ntpd</tt> server +process.</dd> + +<dt><tt>day</tt></dt> +<dd>One file generation set element is created per day. A day is defined +as the period between 00:00 and 24:00 UTC. The file set member suffix +consists of a <tt>.</tt> (dot) and a day specification in the form +<tt>YYYYMMdd. YYYY</tt> is a 4-digit year number (e.g., 1992). +<tt>MM</tt> is a two digit month number. <tt>dd</tt> is a two digit day +number. Thus, all information written at 10 December 1992 would end up +in a file named <tt><I>prefix filename</I>.19921210</tt>.</dd> + +<dt><tt>week</tt></dt> +<dd>Any file set member contains data related to a certain week of a +year. The term week is defined by computing day-of-year modulo 7. +Elements of such a file generation set are distinguished by appending +the following suffix to the file set filename base: A dot, a 4-digit +year number, the letter <tt>W</tt>, and a 2-digit week number. For +example, information from January, 10th 1992 would end up in a file with +suffix <tt>.1992W1</tt>.</dd> + +<dt><tt>month</tt></dt> +<dd>One generation file set element is generated per month. The file +name suffix consists of a dot, a 4-digit year number, and a 2-digit +month.</dd> + +<dt><tt>year</tt></dt> +<dd>One generation file element is generated per year. The filename +suffix consists of a dot and a 4 digit year number.</dd> + +<dt><tt>age</tt></dt> +<dd>This type of file generation sets changes to a new element of the +file set every 24 hours of server operation. The filename suffix +consists of a dot, the letter <tt>a</tt>, and an 8-digit number. This +number is taken to be the number of seconds the server is running at the +start of the corresponding 24-hour period. Information is only written +to a file generation by specifying <tt>enable</tt>; output is prevented +by specifying <tt>disable</tt>.</dd> + +</dl> + +</dl> + +<dd><tt>link | nolink</tt></dd> + +<dl> + +<dd>It is convenient to be able to access the current element of a file +generation set by a fixed name. This feature is enabled by specifying +<tt>link</tt> and disabled using <tt>nolink</tt>. If <tt>link</tt> is +specified, a hard link from the current file set element to a file +without suffix is created. When there is already a file with this name +and the number of links of this file is one, it is renamed appending a +dot, the letter <tt>C</tt>, and the pid of the <tt>ntpd</tt> server +process. When the number of links is greater than one, the file is +unlinked. This allows the current file to be accessed by a constant +name.</dd> + +</dl> + +<dd><tt>enable | disable</tt></dd> + +<dl> + +<dd>Enables or disables the recording function.</dd> + +</dl> + +</dl> + +<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> diff --git a/contrib/ntp/html/notes.htm b/contrib/ntp/html/notes.htm index 6b20cbc..e9f648c 100644 --- a/contrib/ntp/html/notes.htm +++ b/contrib/ntp/html/notes.htm @@ -1244,18 +1244,21 @@ value of <TT>tick</TT>. <P>The <TT>tickadj</TT> program can reset several other kernel variables if asked. It can change the value of <TT>tick</TT> if asked. This is -handy -to compensate for kernel bugs which cause the clock to run with a very -large frequency error, as with SunOS 4.1.1 systems. It can also be used -to set the value of the kernel <TT>dosynctodr</TT> variable to zero. -This -variable controls whether to synchronize the system clock to the time- -of-day -clock, something you really don't want to be happen when <TT>ntpd</TT> -is trying to keep it under control. In some systems, such as recent Sun -Solaris kernels, the <TT>dosynctodr </TT>variable is the only one that -can be changed by the <TT>tickadj </TT>program. In this and other modern -kernels, it is not necessary to change the other variables in any case. +handy to compensate for kernel bugs which cause the clock to run with a +very large frequency error, as with SunOS 4.1.1 systems. It can also be +used to set the value of the kernel <TT>dosynctodr</TT> variable to +zero. This variable controls whether to synchronize the system clock to +the time-of-day clock, something you really don't want to be happen +when <TT>ntpd</TT> is trying to keep it under control. In some systems, +such as recent Sun Solaris kernels, the <TT>dosynctodr </TT>variable is +the only one that can be changed by the <TT>tickadj </TT>program. In +this and other modern kernels, it is not necessary to change the other +variables in any case. + +<P> +We have a report that says starting with Solaris 2.6 we should +leave <I>dosynctodr</I> alone. +<A HREF="solaris-dosynctodr.html">Here is the report</A>. <P>In order to maintain reasonable correctness bounds, as well as reasonably diff --git a/contrib/ntp/html/ntpd.htm b/contrib/ntp/html/ntpd.htm index a90dfcb..0ba0ac7 100644 --- a/contrib/ntp/html/ntpd.htm +++ b/contrib/ntp/html/ntpd.htm @@ -6,11 +6,10 @@ <H4>Synopsis</H4> -<TT>ntpd [ -aAbdm ] [ -c <I>conffile</I> ] [ -f <I>driftfile</I> ] [ -k -<I>keyfile</I> ] [ -l <I>logfile</I> ] [ -p <I>pidfile</I> ] [ -r +<TT>ntpd [ -aAbdm ] [ -c <I>conffile</I> ] [ -f <I>driftfile</I> ] [ -g +] [ -k <I>keyfile</I> ] [ -l <I>logfile</I> ] [ -p <I>pidfile</I> ] [ -r <I>broadcastdelay</I> ] [ -s <I>statsdir</I> ] [ -t <I>key</I> ] [ -v -<I>variable</I> ] [ -V -<I>variable</I> ]</TT> +<I>variable</I> ] [ -V <I>variable</I> ] [ -x ]</TT> <H4>Description</H4> @@ -43,9 +42,10 @@ local host is to be configured as a broadcast/multicast client or manycast client, with all peers being determined by listening to broadcasts at run time. -<P>If NetInfo support is built into <TT>ntpd</TT>, then <TT>ntpd</TT> will -attempt to read its configuration from the NetInfo if the default ntp.conf -file cannot be read and no file is specified by the <TT>-c</TT> option. +<P>If NetInfo support is built into <TT>ntpd</TT>, then <TT>ntpd</TT> +will attempt to read its configuration from the NetInfo if the default +ntp.conf file cannot be read and no file is specified by the <TT>-c</TT> +option. <P>Various internal <TT>ntpd</TT> variables can be displayed and configuration options altered while the daemon is running using the @@ -85,7 +85,8 @@ each occurrence indicating greater detail of display.</DD> <DT><TT>-g</TT></DT> <DD>Normally, the daemon exits if the offset exceeds a 1000-s sanity limit. This option overrides this limit and allows the time to be set to -any value without restriction.</DD> +any value without restriction; however, this can happen only once. After +that, the daemon will exit of the limit is exceeded. <DT><TT>-k <I>keyfile</I></TT></DT> <DD>Specify the name and path of the file containing the NTP @@ -128,7 +129,6 @@ stepped, not gradually slewed. This option forces the time to be slewed in all cases. Note: Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize.</DD> - </DL> <H4>The Configuration File</H4> diff --git a/contrib/ntp/html/pps.htm b/contrib/ntp/html/pps.htm index a002c1f..97850d7 100644 --- a/contrib/ntp/html/pps.htm +++ b/contrib/ntp/html/pps.htm @@ -1,18 +1,19 @@ -<HTML><HEAD><TITLE> +<html><head><title> Pulse-per-second (PPS) Signal Interfacing -</TITLE></HEAD><BODY><H3> +</title></head><body><h3> Pulse-per-second (PPS) Signal Interfacing -</H3><HR> +</h3><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 20 <FONT FACE=Symbol>m</FONT>s in time and 0.01 PPM in frequency. -The PPS signal can be connected in either of two ways: via the data -leads of a serial port or via the modem control leads. Either way -requires conversion of the PPS signal, usually at TTL levels, 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. +<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 20 <font face=Symbol>m</font>s in time and 0.01 PPM in +frequency. The PPS signal can be connected in either of two ways: via +the data leads of a serial port or via the modem control leads. Either +way requires conversion of the PPS signal, usually at TTL levels, 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. <P>The data leads interface requires regenerating the PPS pulse and converting to RS232 signal levels, so that the pulse looks like a diff --git a/contrib/ntp/html/qth.htm b/contrib/ntp/html/qth.htm new file mode 100644 index 0000000..200d3fb --- /dev/null +++ b/contrib/ntp/html/qth.htm @@ -0,0 +1,64 @@ +<html><head><title> +Stations, Frequencies and Geographic Coordinates +</title></head><body><h3> +Stations, Frequencies and Geographic Coordinates +</h3><hr> + +The following data were obtained from the International Frequency List +published by the ITU and other sources. + +<p><table cols=3 width=100%> + +<tr> +<td>Station</td> +<td>Frequencies</td> +<td>Coordinates</td> +</tr> + +<tr> +<td>WWV Ft. Collins, CO</td> +<td>2.5/5/10/15/20 MHz</td> +<td>40:40:49.0N 105:02:27.0W</td> +</tr> + +<tr> +<td>WWVB Ft. Collins, CO</td> +<td>60 kHz</td> +<td>40:40:28.3N 105:02:39.5W</td> +</tr> + +<tr> +<td>WWVH Kauai, HI</td> +<td>2.5/5/10/15 MHz</td> +<td>21:59:26.0N 159:46:00.0W</td> +</tr> + +<tr> +<td>CHU Ottawa, CA</td> +<td>3330/7335/14670 kHz</td> +<td>45:18N 75:45N</td> +</tr> + +<tr> +<td>DCF77 Mainflingen, DE</td> +<td>77.5 kHz</td> +<td>50:01N 9:00E</td> +</tr> + +<tr> +<td>MSF Rugby, UK</td> +<td>60 kHz</td> +<td>52:22N 1:11W</td> +</tr> + +<tr> +<td>TDF Allouis, FR</td> +<td>162 kHz</td> +<td>47:10N 2:12E</td> +</tr> + +</table> + +<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> diff --git a/contrib/ntp/html/refclock.htm b/contrib/ntp/html/refclock.htm index 5747e3f..80c62a2 100644 --- a/contrib/ntp/html/refclock.htm +++ b/contrib/ntp/html/refclock.htm @@ -1,6 +1,6 @@ -<HTML><HEAD><TITLE> +<html><head><title> Reference Clock Drivers -</TITLE></HEAD><BODY><H3> +</title></head><body><h3> Reference Clock Drivers </H3> @@ -19,13 +19,11 @@ Reference Clock Drivers The Tardis <hr> -<H4>Reference Clock Drivers</H4> - -Support for most of the commonly available radio and modem 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 +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. @@ -39,13 +37,42 @@ device is normally specified by adding a soft link <TT>/dev/device<I>u</I></TT> to the particular hardware device involved, where <I><TT>u</TT></I> correspond to the unit number above. +<p>Most clock drivers communicate with the reference clock using a +serial port, usually at 9600 bps. There are several application program +interfaces (API) used in the various Unix and NT systems, most of which +can be detected at configuration time. Thus, it is important that the +NTP daemon and utilities be compiled on the target system or clone. In +some cases special features are available, such as timestamping in the +kernel or pulse-per-second (PPS) interface. In most cases these features +can be detected at configuration time as well; however, the kernel may +have to be recompiled in order for them to work. + +<p>The audio drivers are a special case. These include support for the +NIST time/frequency stations WWV and WWVH, the Canadian time/frequency +station CHU and generic IRIG signals. Currently, support for the Solaris +and SunOS audio API is included in the distribution. It is left to the +volunteer corps to extend this support to other systems. Further +information on hookup, debugging and monitoring is given in the <a +href=audio.htm>Audio Drivers</a> page. + +<p>Some drivers depending on longwave and shortwave radio services need +to know the radio propagation time from the transmitter to the receiver, +which can amount to some tens of milliseconds. This must be calculated +for each specific receiver location and requires the geographic +coordinates of both the transmitter and receiver. The transmitter +coordinates for various radio services are given in the <a +href=qth.htm>Stations, Frequencies and Geographic Coordinates</a> page. +Receiver coordinates can be obtained or estimated from various sources. +The actual calculations are beyond the scope of this document. + <P>Following is a list showing the type and title of each driver currently implemented. The compile-time identifier for each is shown in parentheses. Click on a selected type for specific description and configuration documentation, including the clock address, reference ID, -driver ID, device name and speed, and features (line disciplines, etc.). -For those drivers without specific documentation, please contact the -author listed in the <A HREF=copyright.htm>copyright page</A>. +driver ID, device name and serial line speed, and features (line +disciplines, etc.). For those drivers without specific documentation, +please contact the author listed in the <A HREF=copyright.htm>Copyright +Notice</A> page. <P><A HREF=driver1.htm>Type 1</A> Undisciplined Local Clock (<TT>LOCAL</TT>) @@ -54,13 +81,13 @@ author listed in the <A HREF=copyright.htm>copyright page</A>. <BR><A HREF=driver3.htm>Type 3</A> PSTI/Traconex 1020 WWV/WWVH Receiver (<TT>WWV_PST</TT>) -<BR><A HREF=driver4.htm>Type 4</A> Spectracom 8170 and Netclock/2 WWVB -Receivers (<TT>WWVB_SPEC</TT>) +<BR><A HREF=driver4.htm>Type 4</A> Spectracom WWVB and GPS Receivers +(<TT>WWVB_SPEC</TT>) <BR><A HREF=driver5.htm>Type 5</A> TrueTime GPS/GOES/OMEGA Receivers (<TT>TRUETIME</TT>) <BR><A HREF=driver6.htm>Type 6</A> IRIG Audio Decoder (<TT>IRIG_AUDIO</TT>) -<BR><A HREF=driver7.htm>Type 7</A> CHU Audio/Modem Decoder +<BR><A HREF=driver7.htm>Type 7</A> Radio CHU Audio Demodulator/Decoder (<TT>CHU</TT>) <BR><A HREF=driver8.htm>Type 8</A> Generic Reference Driver (<TT>PARSE</TT>) @@ -93,29 +120,33 @@ Receivers (<TT>WWVB_SPEC</TT>) (<TT>ACTS_USNO</TT>) <BR><A HREF=driver5.htm>Type 25</A> * TrueTime generic receivers <BR><A HREF=driver26.htm>Type 26</A> Hewlett Packard 58503A GPS -Receiver -(<TT>GPS_HP</TT>) +Receiver (<TT>GPS_HP</TT>) <BR><A HREF=driver27.htm>Type 27</A> Arcron MSF Receiver (<TT>MSF_ARCRON</TT>) -<BR><A HREF=driver28.htm>Type 28</A> Shared memory driver +<BR><A HREF=driver28.htm>Type 28</A> Shared Memory Driver (<TT>SHM</TT>) -<BR><A HREF=driver29.htm>Type 29</A> Trimble Navigation Palisade GPS (<TT>GPS_PALISADE</TT>) -<BR><A HREF=driver30.htm>Type 30 Motorola UT Oncore GPS +<BR><A HREF=driver29.htm>Type 29</A> Trimble Navigation Palisade GPS +(<TT>GPS_PALISADE</TT>) +<BR><A HREF=driver30.htm>Type 30</A> Motorola UT Oncore GPS (<TT>GPS_ONCORE</TT>) <BR>Type 31 Rockwell Jupiter GPS (<TT>GPS_JUPITER</TT>) -<BR><A HREF=driver34.htm>Type 34</A> Ultralink WWVB receivers +<BR><A HREF=driver34.htm>Type 34</A> Ultralink WWVB Receivers +<BR><A HREF=driver35.htm>Type 35</A> Conrad Parallel Port Radio Clock +(<TT>PCF</TT>) +<BR><A HREF=driver36.htm>Type 36</A> Radio WWV/H Audio +Demodulator/Decoder(<TT>WWV</TT>) +<BR><A HREF=driver37.htm>Type 37</A> Forum Graphic GPS Dating station +(<TT>FG</TT>) <P>* All TrueTime receivers are now supported by one driver, type 5. -Types -15 and 25 will be retained only for a limited time and may be reassigned -in future. - +Types 15 and 25 will be retained only for a limited time and may be +reassigned in future. <P>Additional Information - <P><A HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT> Keyword</A> <BR><A HREF=rdebug.htm>Debugging Hints for Reference Clock Drivers</A> <BR><A HREF=ldisc.htm>Line Disciplines and Streams Drivers</A> +<BR><A HREF=audio.htm>Reference Clock Audio Drivers</A> <BR><A HREF=pps.htm>Pulse-per-second (PPS) Signal Interfacing</A> <BR><A HREF=howto.htm>How To Write a Reference Clock Driver</A> <BR><A HREF=index.htm>The Network Time Protocol (NTP) diff --git a/contrib/ntp/html/tickadj.htm b/contrib/ntp/html/tickadj.htm index 7d3a863..7dc11c0 100644 --- a/contrib/ntp/html/tickadj.htm +++ b/contrib/ntp/html/tickadj.htm @@ -25,6 +25,10 @@ call, and <TT>dosynctodr</TT>, which indicates to the kernels on some machines whether they should internally adjust the system clock to keep it in line with time-of-day clock or not. +<P>We have a report that says starting with Solaris 2.6 we should +leave <I>dosynctodr</I> alone. +<A HREF="solaris-dosynctodr.html">Here is the report</A>. + <P>By default, with no arguments, <TT>tickadj</TT> reads the variables of interest in the kernel and displays them. At the same time, it determines an "optimal" value for the value of the <TT>tickadj</TT> variable if the |
