d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Vendor import ntp 4.2.8.

Browse Source 
Reviewed by:	roberto
Security:	VUXML: 4033d826-87dd-11e4-9079-3c970e169bc2
Security:	http://www.kb.cert.org/vuls/id/852879
Security:	CVE-2014-9293
Security	CVE-2014-9294
Security	CVE-2014-9295
Security	CVE-2014-9296
This commit is contained in:
Cy Schubert 2014-12-20 22:52:39 +00:00
parent 2b45e011ca
commit b5e14a1344
1438 changed files with 501219 additions and 71633 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

140
COPYRIGHT
View File

@ -4,7 +4,7 @@ This file is automatically generated from html/copyright.html
jpg "Clone me," says Dolly sheepishly.
Last update: 1-Jan-2011 08:34 UTC
Last update: 9-Aug-2014 07:56 UTC
_________________________________________________________________
The following copyright notice applies to all files collectively
@ -13,7 +13,7 @@ This file is automatically generated from html/copyright.html
applies as if the text was explicitly included in the file.
***********************************************************************
* *
* Copyright (c) University of Delaware 1992-2011 *
* Copyright (c) University of Delaware 1992-2014 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *
@ -75,53 +75,58 @@ This file is automatically generated from html/copyright.html
27. [29]Poul-Henning Kamp <phk@FreeBSD.ORG> Oncore driver (Original
author)
28. [30]Frank Kardel [31]<kardel (at) ntp (dot) org> PARSE <GENERIC>
driver (>14 reference clocks), STREAMS modules for PARSE, support
(driver 14 reference clocks), STREAMS modules for PARSE, support
scripts, syslog cleanup, dynamic interface handling
29. [32]William L. Jones <jones@hermes.chpc.utexas.edu> RS/6000 AIX
29. [32]Johannes Maximilian Kuehn <kuehn@ntp.org> Rewrote sntp to
comply with NTPv4 specification, ntpq saveconfig
30. [33]William L. Jones <jones@hermes.chpc.utexas.edu> RS/6000 AIX
modifications, HPUX modifications
30. [33]Dave Katz <dkatz@cisco.com> RS/6000 AIX port
31. [34]Craig Leres <leres@ee.lbl.gov> 4.4BSD port, ppsclock, Magnavox
31. [34]Dave Katz <dkatz@cisco.com> RS/6000 AIX port
32. [35]Craig Leres <leres@ee.lbl.gov> 4.4BSD port, ppsclock, Magnavox
GPS clock driver
32. [35]George Lindholm <lindholm@ucs.ubc.ca> SunOS 5.1 port
33. [36]Louis A. Mamakos <louie@ni.umd.edu> MD5-based authentication
34. [37]Lars H. Mathiesen <thorinn@diku.dk> adaptation of foundation
33. [36]George Lindholm <lindholm@ucs.ubc.ca> SunOS 5.1 port
34. [37]Louis A. Mamakos <louie@ni.umd.edu> MD5-based authentication
35. [38]Lars H. Mathiesen <thorinn@diku.dk> adaptation of foundation
code for Version 3 as specified in RFC-1305
35. [38]Danny Mayer <mayer@ntp.org>Network I/O, Windows Port, Code
36. [39]Danny Mayer <mayer@ntp.org>Network I/O, Windows Port, Code
Maintenance
36. [39]David L. Mills <mills@udel.edu> 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
37. [40]Wolfgang Moeller <moeller@gwdgv1.dnet.gwdg.de> VMS port
38. [41]Jeffrey Mogul <mogul@pa.dec.com> ntptrace utility
39. [42]Tom Moore <tmoore@fievel.daytonoh.ncr.com> i386 svr4 port
40. [43]Kamal A Mostafa <kamal@whence.com> SCO OpenServer port
41. [44]Derek Mulcahy <derek@toybox.demon.co.uk> and [45]Damon
37. [40]David L. Mills <mills@udel.edu> Version 4 foundation,
precision kernel; clock drivers: 1, 3, 4, 6, 7, 11, 13, 18, 19,
22, 36
38. [41]Wolfgang Moeller <moeller@gwdgv1.dnet.gwdg.de> VMS port
39. [42]Jeffrey Mogul <mogul@pa.dec.com> ntptrace utility
40. [43]Tom Moore <tmoore@fievel.daytonoh.ncr.com> i386 svr4 port
41. [44]Kamal A Mostafa <kamal@whence.com> SCO OpenServer port
42. [45]Derek Mulcahy <derek@toybox.demon.co.uk> and [46]Damon
Hart-Davis <d@hd.org> ARCRON MSF clock driver
42. [46]Rob Neal <neal@ntp.org> Bancomm refclock and config/parse code
43. [47]Rob Neal <neal@ntp.org> Bancomm refclock and config/parse code
maintenance
43. [47]Rainer Pruy <Rainer.Pruy@informatik.uni-erlangen.de>
44. [48]Rainer Pruy <Rainer.Pruy@informatik.uni-erlangen.de>
monitoring/trap scripts, statistics file handling
44. [48]Dirce Richards <dirce@zk3.dec.com> Digital UNIX V4.0 port
45. [49]Wilfredo Sánchez <wsanchez@apple.com> added support for
45. [49]Dirce Richards <dirce@zk3.dec.com> Digital UNIX V4.0 port
46. [50]Wilfredo Sánchez <wsanchez@apple.com> added support for
NetInfo
46. [50]Nick Sayer <mrapple@quack.kfu.com> SunOS streams modules
47. [51]Jack Sasportas <jack@innovativeinternet.com> Saved a Lot of
47. [51]Nick Sayer <mrapple@quack.kfu.com> SunOS streams modules
48. [52]Jack Sasportas <jack@innovativeinternet.com> Saved a Lot of
space on the stuff in the html/pic/ subdirectory
48. [52]Ray Schnitzler <schnitz@unipress.com> Unixware1 port
49. [53]Michael Shields <shields@tembel.org> USNO clock driver
50. [54]Jeff Steinman <jss@pebbles.jpl.nasa.gov> Datum PTS clock
49. [53]Ray Schnitzler <schnitz@unipress.com> Unixware1 port
50. [54]Michael Shields <shields@tembel.org> USNO clock driver
51. [55]Jeff Steinman <jss@pebbles.jpl.nasa.gov> Datum PTS clock
driver
51. [55]Harlan Stenn <harlan@pfcs.com> GNU automake/autoconfigure
52. [56]Harlan Stenn <harlan@pfcs.com> GNU automake/autoconfigure
makeover, various other bits (see the ChangeLog)
52. [56]Kenneth Stone <ken@sdd.hp.com> HP-UX port
53. [57]Ajit Thyagarajan <ajit@ee.udel.edu>IP multicast/anycast
53. [57]Kenneth Stone <ken@sdd.hp.com> HP-UX port
54. [58]Ajit Thyagarajan <ajit@ee.udel.edu>IP multicast/anycast
support
54. [58]Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp>TRAK clock
55. [59]Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp>TRAK clock
driver
55. [59]Paul A Vixie <vixie@vix.com> TrueTime GPS driver, generic
56. [60]Brian Utterback <brian.utterback@oracle.com> General codebase,
Solaris issues
57. [61]Loganaden Velvindron <loganaden@gmail.com> Sandboxing
(libseccomp) support
58. [62]Paul A Vixie <vixie@vix.com> TrueTime GPS driver, generic
TrueTime clock driver
56. [60]Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> corrected and
59. [63]Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> corrected and
validated HTML documents according to the HTML DTD
_________________________________________________________________
@ -141,7 +146,7 @@ References
12. mailto:%20Jean-Francois.Boudreault@viagenie.qc.ca
13. mailto:%20reg@dwf.com
14. mailto:%20clift@ml.csiro.au
15. mailto:casey@csc.co.za
15. mailto:%20casey@csc.co.za
16. mailto:%20Sven_Dietrich@trimble.COM
17. mailto:%20dundas@salt.jpl.nasa.gov
18. mailto:%20duwe@immd4.informatik.uni-erlangen.de
@ -153,37 +158,40 @@ References
24. mailto:%20iglesias@uci.edu
25. mailto:%20jagubox.gsfc.nasa.gov
26. mailto:%20jbj@chatham.usdesign.com
27. mailto:Hans.Lambermont@nl.origin-it.com
27. mailto:%20Hans.Lambermont@nl.origin-it.com
28. mailto:H.Lambermont@chello.nl
29. mailto:%20phk@FreeBSD.ORG
30. http://www4.informatik.uni-erlangen.de/%7ekardel
31. mailto:%20kardel(at)ntp(dot)org
32. mailto:%20jones@hermes.chpc.utexas.edu
33. mailto:%20dkatz@cisco.com
34. mailto:%20leres@ee.lbl.gov
35. mailto:%20lindholm@ucs.ubc.ca
36. mailto:%20louie@ni.umd.edu
37. mailto:%20thorinn@diku.dk
38. mailto:%20mayer@ntp.org
39. mailto:%20mills@udel.edu
40. mailto:%20moeller@gwdgv1.dnet.gwdg.de
41. mailto:%20mogul@pa.dec.com
42. mailto:%20tmoore@fievel.daytonoh.ncr.com
43. mailto:%20kamal@whence.com
44. mailto:%20derek@toybox.demon.co.uk
45. mailto:%20d@hd.org
46. mailto:%20neal@ntp.org
47. mailto:%20Rainer.Pruy@informatik.uni-erlangen.de
48. mailto:%20dirce@zk3.dec.com
49. mailto:%20wsanchez@apple.com
50. mailto:%20mrapple@quack.kfu.com
51. mailto:%20jack@innovativeinternet.com
52. mailto:%20schnitz@unipress.com
53. mailto:%20shields@tembel.org
54. mailto:%20pebbles.jpl.nasa.gov
55. mailto:%20harlan@pfcs.com
56. mailto:%20ken@sdd.hp.com
57. mailto:%20ajit@ee.udel.edu
58. mailto:%20tsuruoka@nc.fukuoka-u.ac.jp
59. mailto:%20vixie@vix.com
60. mailto:%20Ulrich.Windl@rz.uni-regensburg.de
31. mailto:%20kardel%20%28at%29%20ntp%20%28dot%29%20org
32. mailto:kuehn@ntp.org
33. mailto:%20jones@hermes.chpc.utexas.edu
34. mailto:%20dkatz@cisco.com
35. mailto:%20leres@ee.lbl.gov
36. mailto:%20lindholm@ucs.ubc.ca
37. mailto:%20louie@ni.umd.edu
38. mailto:%20thorinn@diku.dk
39. mailto:%20mayer@ntp.org
40. mailto:%20mills@udel.edu
41. mailto:%20moeller@gwdgv1.dnet.gwdg.de
42. mailto:%20mogul@pa.dec.com
43. mailto:%20tmoore@fievel.daytonoh.ncr.com
44. mailto:%20kamal@whence.com
45. mailto:%20derek@toybox.demon.co.uk
46. mailto:%20d@hd.org
47. mailto:%20neal@ntp.org
48. mailto:%20Rainer.Pruy@informatik.uni-erlangen.de
49. mailto:%20dirce@zk3.dec.com
50. mailto:%20wsanchez@apple.com
51. mailto:%20mrapple@quack.kfu.com
52. mailto:%20jack@innovativeinternet.com
53. mailto:%20schnitz@unipress.com
54. mailto:%20shields@tembel.org
55. mailto:%20pebbles.jpl.nasa.gov
56. mailto:%20harlan@pfcs.com
57. mailto:%20ken@sdd.hp.com
58. mailto:%20ajit@ee.udel.edu
59. mailto:%20tsuruoka@nc.fukuoka-u.ac.jp
60. mailto:%20brian.utterback@oracle.com
61. mailto:%20loganaden@gmail.com
62. mailto:%20vixie@vix.com
63. mailto:%20Ulrich.Windl@rz.uni-regensburg.de

2084
ChangeLog
View File

File diff suppressed because it is too large Load Diff

118579
CommitLog
View File

File diff suppressed because it is too large Load Diff

3
FREEBSD-Xlist
View File

@ -1,3 +0,0 @@
*ports
*html/pic
*ElectricFence

64
FREEBSD-upgrade
View File

@ -1,64 +0,0 @@
# ex:ts=8
#
# $FreeBSD$
NTP 4.2.4p5
originals can be found on http://www.ntp.org/downloads.html
Import
------
For the import of NTP the following files were removed:
ports/* NT files
html/pic/* GIF files
ElectricFence/* Support for the ElectricFence library
(only useful if you want to debug ntpd)
html/build/hints/solaris.xtra.4095849 Trigger merge conflict script
The stripped down version was created using FREEBSD-Xlist during extraction:
tar -X FREEBSD-Xlist -xvzf ntp-4.2.4p5.tar.gz
mv ntp-4.2.4p5 4.2.4p5
Imported by:
See procedure on http://wiki.freebsd.org/SubversionPrimer/VendorImports
Updating usr.sbin/ntp
---------------------
./configure --disable-all-clocks --enable-NMEA --enable-ONCORE
--enable-RAWDCF --with-crypto --disable-debugging
--enable-LOCAL-CLOCK --with-sntp --with-arlib --prefix=/usr
config.h was generated by running configure and excluding almost all clock
drivers (what is included is DCF77 -- what I use --, NMEA, Motorola OnCORE
and local clocks).
The file is then edited to edit the value of "NO_PARENB_IGNPAR" because we
need to set no parity on the serial port (needed for DCF77). All clock
drivers are then disabled (some of them are included by default by ntpd).
Note that there are two #ifdef to support other architectures (WRT to long
size and endianness). They'll need to be redone for each upgrade to the
vendor branch to keep config.h in sync.
ntpd/ntp_control.c is now the only file that is different from the vendor
branch for unsigned char/int fixes and removal of a DoS.
Documentation in /usr/share/doc/ntp is generated from the HTML files with
lynx (without the GIF files of course).
One patch needs to be applied after that to close two buffer overflows. See
bin/92839 for details.
A patch to fix IPV6_MULTICAST_LOOP was committed to head as r222444 and
filed as http://bugs.ntp.org/show_bug.cgi?id=1936. Check if still needed
or re-apply on update.
A patch to fix badhost sendto() logging was committed to head as r223626.
The patch is not applicable to later upstream versions.
A patch to fix various problems in case of fqdn resolving fails on
startup was committed to head as r223667. The patch is not applicable
to later upstream versions.

127
Makefile.am
View File

@ -1,36 +1,12 @@
## LIBOPTS_CHECK_NOBUILD works with Automake 1.10 now
AUTOMAKE_OPTIONS = foreign 1.10
ACLOCAL_AMFLAGS = -I m4 -I sntp/libopts/m4
ACLOCAL_AMFLAGS = -I sntp/m4 -I sntp/libevent/m4 -I sntp/libopts/m4
NULL =
SUBDIRS =
SUBDIRS += \
scripts \
include \
ElectricFence \
libntp \
sntp \
libparse \
ntpd \
ntpdate \
ntpdc \
ntpq \
ntpsnmpd \
parseutil \
adjtimed \
clockstuff \
kernel \
util \
$(NULL)
DIST_SUBDIRS = \
SUBDIRS = \
scripts \
include \
ElectricFence \
libntp \
libparse \
sntp \
ntpd \
ntpdate \
ntpdc \
@ -41,9 +17,11 @@ DIST_SUBDIRS = \
clockstuff \
kernel \
util \
sntp \
tests \
$(NULL)
DISTCHECK_CONFIGURE_FLAGS = -C
DISTCHECK_CONFIGURE_FLAGS = -C --with-sntp
EXTRA_DIST = \
$(srcdir)/COPYRIGHT \
@ -61,13 +39,9 @@ EXTRA_DIST = \
WHERE-TO-START \
bootstrap \
build \
config.guess \
config.h.in \
config.sub \
dot.emacs \
excludes \
flock-build \
install-sh \
packageinfo.sh \
readme.y2kfixes \
results.y2kfixes \
@ -75,33 +49,48 @@ EXTRA_DIST = \
conf \
html \
lib/isc \
libjsmn \
ports \
\
bincheck.mf \
depsver.mf \
deps-ver \
$(srcdir)/version \
version.m4 \
\
$(NULL)
CLEANFILES =
DISTCLEANFILES = .gcc-warning
ETAGS_ARGS = Makefile.am configure.ac
# HMS: Keep .gcc-warning first, as that way it gets printed first.
BUILT_SOURCES = \
.gcc-warning \
libtool \
html/.datecheck \
sntp/built-sources-only \
$(srcdir)/COPYRIGHT \
$(srcdir)/version \
$(srcdir)/version.m4 \
$(srcdir)/include/version.def \
$(srcdir)/include/version.texi \
$(srcdir)/.checkChangeLog \
$(NULL)
.gcc-warning:
@echo "Compiling with GCC now generates lots of new warnings."
@echo " "
@echo "Don't be concerned. They're just warnings."
@echo " "
@echo "Don't send bug reports about the warnings, either."
@echo " "
@echo "Feel free to send patches that fix these warnings, though."
@echo " "
@sleep 1
@touch $@
html/.datecheck: FRC.html
cd $(srcdir)/html && \
../scripts/build/checkHtmlFileDates
libtool: $(LIBTOOL_DEPS)
./config.status --recheck
sntp/built-sources-only: FRC.sntp
@cd sntp && $(MAKE) $(AM_MAKEFLAGS) built-sources-only
$(srcdir)/COPYRIGHT: $(srcdir)/html/copyright.html
{ echo "This file is automatically generated from html/copyright.html" ; \
lynx -dump $(srcdir)/html/copyright.html ;} > COPYRIGHT.new \
@ -115,61 +104,31 @@ COPYRIGHT-please: $(srcdir)/COPYRIGHT
Rather than determine our $(srcdir) from sntp/Makefile.am \
COPYRIGHT-please serves as a fixed target.
# HMS: The next bit is still suboptimal. If bk is present but this NTP
# repo is not a bk repo, we'll get an error message from the prs command.
# Unfortunately, I haven't found the necessary magic to redirect this error
# output to /dev/null under ancient/unique shells like the one Ultrix uses.
# We'll also get an error if srcdir or version is unwritable.
$(srcdir)/version: FRC.version
-(bk version) >/dev/null 2>&1 && \
cd $(srcdir) && \
x=`bk -R prs -hr+ -nd:I: ChangeSet` && \
y=`cat version 2>/dev/null` || true && \
case "$$x" in ''|$$y) ;; *) echo $$x > version ;; esac
$(srcdir)/version.m4: $(srcdir)/packageinfo.sh
TEMPDIR=`pwd` && export TEMPDIR && cd $(srcdir) && \
./scripts/genver version.m4
$(srcdir)/include/version.def: $(srcdir)/packageinfo.sh
TEMPDIR=`pwd` && export TEMPDIR && cd $(srcdir) && \
./scripts/genver include/version.def
$(srcdir)/include/version.texi: $(srcdir)/packageinfo.sh
TEMPDIR=`pwd` && export TEMPDIR && cd $(srcdir) && \
./scripts/genver include/version.texi
$(srcdir)/.checkChangeLog: $(srcdir)/ChangeLog $(srcdir)/scripts/checkChangeLog
$(srcdir)/.checkChangeLog: $(srcdir)/ChangeLog $(srcdir)/scripts/build/checkChangeLog
cd $(srcdir) && \
./scripts/checkChangeLog
libtool: $(LIBTOOL_DEPS)
./config.status --recheck
./scripts/build/checkChangeLog
dist-hook:
@find $(distdir) -type d -name SCCS -print | xargs rm -rf
.gcc-warning:
@echo "Compiling with GCC now generates lots of new warnings."
@echo " "
@echo "Don't be concerned. They're just warnings."
@echo " "
@echo "Don't send bug reports about the warnings, either."
@echo " "
@echo "Feel free to send patches that fix these warnings, though."
@echo " "
@sleep 1
@touch $@
install-data-local:
( cd $(srcdir) && find html -name SCCS -prune -o -type d \
-exec $(INSTALL) -d $(DESTDIR)$(htmldir)/{} ";" )
( cd $(srcdir) && find html -name SCCS -prune -o -type f \
-exec $(INSTALL_DATA) {} $(DESTDIR)$(htmldir)/{} ";" )
uninstall-local:
rm -rf $(DESTDIR)$(htmldir)/html
CommitLog: FRC.CommitLog
cd $(srcdir) \
&& $(PATH_TEST) -e CommitLog \
-a SCCS/s.ChangeSet -ot CommitLog \
|| scripts/genCommitLog
|| scripts/build/genCommitLog
# HMS: The following seems to be a work-in-progress...
CVO=`$(srcdir)/config.guess`
CVO=`$(srcdir)/sntp/libevent/build-aux/config.guess`
.buildcvo:
echo "$(CVO)" > .buildcvo
@ -192,7 +151,7 @@ BHOST=`(hostname || uname -n)`
echo " "; \
fi
FRC.CommitLog FRC.distwarn FRC.checkcvo FRC.checkhost FRC.version:
FRC.CommitLog FRC.checkcvo FRC.checkhost FRC.distwarn FRC.html FRC.sntp:
@: do-nothing action prevents any default
# HMS: what was I trying to do with this?

303
Makefile.in
View File

@ -38,19 +38,50 @@ DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
$(srcdir)/Makefile.in $(srcdir)/config.h.in \
$(top_srcdir)/configure ChangeLog INSTALL NEWS TODO compile \
config.guess config.sub depcomp install-sh ltmain.sh missing \
sntp/libevent/build-aux/compile \
sntp/libevent/build-aux/config.guess \
sntp/libevent/build-aux/config.sub \
sntp/libevent/build-aux/depcomp \
sntp/libevent/build-aux/install-sh \
sntp/libevent/build-aux/ltmain.sh \
sntp/libevent/build-aux/missing sntp/libevent/build-aux/ylwrap \
ylwrap
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/sntp/libopts/m4/libopts.m4 \
$(top_srcdir)/m4/define_dir.m4 $(top_srcdir)/m4/libtool.m4 \
$(top_srcdir)/m4/ltoptions.m4 $(top_srcdir)/m4/ltsugar.m4 \
$(top_srcdir)/m4/ltversion.m4 $(top_srcdir)/m4/lt~obsolete.m4 \
$(top_srcdir)/m4/ntp_cacheversion.m4 \
$(top_srcdir)/m4/ntp_dir_sep.m4 \
$(top_srcdir)/m4/ntp_lineeditlibs.m4 \
$(top_srcdir)/m4/ntp_openssl.m4 \
$(top_srcdir)/m4/ntp_vpathhack.m4 \
$(top_srcdir)/m4/os_cflags.m4 $(top_srcdir)/version.m4 \
$(top_srcdir)/configure.ac
$(top_srcdir)/sntp/libopts/m4/stdnoreturn.m4 \
$(top_srcdir)/sntp/libevent/m4/openldap-thread-check.m4 \
$(top_srcdir)/sntp/libevent/m4/openldap.m4 \
$(top_srcdir)/sntp/m4/define_dir.m4 \
$(top_srcdir)/sntp/m4/hms_search_lib.m4 \
$(top_srcdir)/sntp/m4/libtool.m4 \
$(top_srcdir)/sntp/m4/ltoptions.m4 \
$(top_srcdir)/sntp/m4/ltsugar.m4 \
$(top_srcdir)/sntp/m4/ltversion.m4 \
$(top_srcdir)/sntp/m4/lt~obsolete.m4 \
$(top_srcdir)/sntp/m4/ntp_cacheversion.m4 \
$(top_srcdir)/sntp/m4/ntp_compiler.m4 \
$(top_srcdir)/sntp/m4/ntp_crosscompile.m4 \
$(top_srcdir)/sntp/m4/ntp_crypto_rand.m4 \
$(top_srcdir)/sntp/m4/ntp_debug.m4 \
$(top_srcdir)/sntp/m4/ntp_dir_sep.m4 \
$(top_srcdir)/sntp/m4/ntp_facilitynames.m4 \
$(top_srcdir)/sntp/m4/ntp_googletest.m4 \
$(top_srcdir)/sntp/m4/ntp_ipv6.m4 \
$(top_srcdir)/sntp/m4/ntp_lib_m.m4 \
$(top_srcdir)/sntp/m4/ntp_libevent.m4 \
$(top_srcdir)/sntp/m4/ntp_libntp.m4 \
$(top_srcdir)/sntp/m4/ntp_lineeditlibs.m4 \
$(top_srcdir)/sntp/m4/ntp_locinfo.m4 \
$(top_srcdir)/sntp/m4/ntp_openssl.m4 \
$(top_srcdir)/sntp/m4/ntp_pkg_config.m4 \
$(top_srcdir)/sntp/m4/ntp_prog_cc.m4 \
$(top_srcdir)/sntp/m4/ntp_rlimit.m4 \
$(top_srcdir)/sntp/m4/ntp_sntp.m4 \
$(top_srcdir)/sntp/m4/ntp_ver_suffix.m4 \
$(top_srcdir)/sntp/m4/ntp_vpathhack.m4 \
$(top_srcdir)/sntp/m4/os_cflags.m4 \
$(top_srcdir)/sntp/m4/snprintf.m4 \
$(top_srcdir)/sntp/m4/version.m4 $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
@ -59,6 +90,12 @@ mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_GEN = $(am__v_GEN_$(V))
am__v_GEN_ = $(am__v_GEN_$(AM_DEFAULT_VERBOSITY))
am__v_GEN_0 = @echo " GEN " $@;
AM_V_at = $(am__v_at_$(V))
am__v_at_ = $(am__v_at_$(AM_DEFAULT_VERBOSITY))
am__v_at_0 = @
SOURCES =
DIST_SOURCES =
RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
@ -75,6 +112,7 @@ AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
distdir dist dist-all distcheck
ETAGS = etags
CTAGS = ctags
DIST_SUBDIRS = $(SUBDIRS)
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)
@ -112,20 +150,32 @@ GZIP_ENV = --best
distuninstallcheck_listfiles = find . -type f -print
distcleancheck_listfiles = find . -type f -print
ACLOCAL = @ACLOCAL@
ALLOCA = @ALLOCA@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
AR = @AR@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BINSUBDIR = @BINSUBDIR@
CALC_TICKADJ_DB = @CALC_TICKADJ_DB@
CALC_TICKADJ_DL = @CALC_TICKADJ_DL@
CALC_TICKADJ_DS = @CALC_TICKADJ_DS@
CALC_TICKADJ_MS = @CALC_TICKADJ_MS@
CALC_TICKADJ_NI = @CALC_TICKADJ_NI@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CFLAGS_NTP = @CFLAGS_NTP@
CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CONFIG_SHELL = @CONFIG_SHELL@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CPPFLAGS_NTP = @CPPFLAGS_NTP@
CXX = @CXX@
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
CXXFLAGS = @CXXFLAGS@
CYGPATH_W = @CYGPATH_W@
DCFD = @DCFD@
DEFS = @DEFS@
@ -137,21 +187,31 @@ ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
EDITLINE_LIBS = @EDITLINE_LIBS@
EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
FGREP = @FGREP@
GREP = @GREP@
GTEST_CONFIG = @GTEST_CONFIG@
GTEST_CPPFLAGS = @GTEST_CPPFLAGS@
GTEST_CXXFLAGS = @GTEST_CXXFLAGS@
GTEST_LDFLAGS = @GTEST_LDFLAGS@
GTEST_LIBS = @GTEST_LIBS@
HAVE_INLINE = @HAVE_INLINE@
HAVE_RLIMIT_MEMLOCK = @HAVE_RLIMIT_MEMLOCK@
HAVE_RLIMIT_STACK = @HAVE_RLIMIT_STACK@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LCRYPTO = @LCRYPTO@
LD = @LD@
LDADD_LIBNTP = @LDADD_LIBNTP@
LDADD_NLIST = @LDADD_NLIST@
LDADD_NTP = @LDADD_NTP@
LDFLAGS = @LDFLAGS@
LDFLAGS_NTP = @LDFLAGS_NTP@
LIBISC_PTHREADS_NOTHREADS = @LIBISC_PTHREADS_NOTHREADS@
LIBM = @LIBM@
LIBOBJS = @LIBOBJS@
LIBOPTS_CFLAGS = @LIBOPTS_CFLAGS@
LIBOPTS_DIR = @LIBOPTS_DIR@
@ -159,6 +219,7 @@ LIBOPTS_LDADD = @LIBOPTS_LDADD@
LIBPARSE = @LIBPARSE@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LIBTOOL_DEPS = @LIBTOOL_DEPS@
LIPO = @LIPO@
LN_S = @LN_S@
LSCF = @LSCF@
@ -177,14 +238,68 @@ MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
MANIFEST_TOOL = @MANIFEST_TOOL@
MANTAGFMT = @MANTAGFMT@
MKDIR_P = @MKDIR_P@
NM = @NM@
NMEDIT = @NMEDIT@
NTPDATE_DB = @NTPDATE_DB@
NTPDATE_DL = @NTPDATE_DL@
NTPDATE_DS = @NTPDATE_DS@
NTPDATE_MS = @NTPDATE_MS@
NTPDATE_NI = @NTPDATE_NI@
NTPDC_DB = @NTPDC_DB@
NTPDC_DL = @NTPDC_DL@
NTPDC_DS = @NTPDC_DS@
NTPDC_MS = @NTPDC_MS@
NTPDC_NI = @NTPDC_NI@
NTPDSIM_DB = @NTPDSIM_DB@
NTPDSIM_DL = @NTPDSIM_DL@
NTPDSIM_DS = @NTPDSIM_DS@
NTPDSIM_MS = @NTPDSIM_MS@
NTPDSIM_NI = @NTPDSIM_NI@
NTPD_DB = @NTPD_DB@
NTPD_DL = @NTPD_DL@
NTPD_DS = @NTPD_DS@
NTPD_MS = @NTPD_MS@
NTPD_NI = @NTPD_NI@
NTPQ_DB = @NTPQ_DB@
NTPQ_DL = @NTPQ_DL@
NTPQ_DS = @NTPQ_DS@
NTPQ_MS = @NTPQ_MS@
NTPQ_NI = @NTPQ_NI@
NTPSNMPD_DB = @NTPSNMPD_DB@
NTPSNMPD_DL = @NTPSNMPD_DL@
NTPSNMPD_DS = @NTPSNMPD_DS@
NTPSNMPD_MS = @NTPSNMPD_MS@
NTPSNMPD_NI = @NTPSNMPD_NI@
NTPSWEEP_DB = @NTPSWEEP_DB@
NTPSWEEP_DL = @NTPSWEEP_DL@
NTPSWEEP_DS = @NTPSWEEP_DS@
NTPSWEEP_MS = @NTPSWEEP_MS@
NTPSWEEP_NI = @NTPSWEEP_NI@
NTPTIME_DB = @NTPTIME_DB@
NTPTIME_DL = @NTPTIME_DL@
NTPTIME_DS = @NTPTIME_DS@
NTPTIME_MS = @NTPTIME_MS@
NTPTIME_NI = @NTPTIME_NI@
NTPTRACE_DB = @NTPTRACE_DB@
NTPTRACE_DL = @NTPTRACE_DL@
NTPTRACE_DS = @NTPTRACE_DS@
NTPTRACE_MS = @NTPTRACE_MS@
NTPTRACE_NI = @NTPTRACE_NI@
NTP_KEYGEN_DB = @NTP_KEYGEN_DB@
NTP_KEYGEN_DL = @NTP_KEYGEN_DL@
NTP_KEYGEN_DS = @NTP_KEYGEN_DS@
NTP_KEYGEN_MS = @NTP_KEYGEN_MS@
NTP_KEYGEN_NI = @NTP_KEYGEN_NI@
NTP_KEYSDIR = @NTP_KEYSDIR@
NTP_WAIT_DB = @NTP_WAIT_DB@
NTP_WAIT_DL = @NTP_WAIT_DL@
NTP_WAIT_DS = @NTP_WAIT_DS@
NTP_WAIT_MS = @NTP_WAIT_MS@
NTP_WAIT_NI = @NTP_WAIT_NI@
OBJDUMP = @OBJDUMP@
OBJEXT = @OBJEXT@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
OPENSSL_LIB = @OPENSSL_LIB@
OTOOL = @OTOOL@
OTOOL64 = @OTOOL64@
PACKAGE = @PACKAGE@
@ -197,10 +312,12 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_NET_SNMP_CONFIG = @PATH_NET_SNMP_CONFIG@
PATH_PERL = @PATH_PERL@
PATH_SEPARATOR = @PATH_SEPARATOR@
PATH_SH = @PATH_SH@
PATH_TEST = @PATH_TEST@
PERLLIBDIR = @PERLLIBDIR@
PKG_CONFIG = @PKG_CONFIG@
POSIX_SHELL = @POSIX_SHELL@
PROPDELAY = @PROPDELAY@
PTHREAD_LIBS = @PTHREAD_LIBS@
RANLIB = @RANLIB@
SED = @SED@
SET_MAKE = @SET_MAKE@
@ -208,9 +325,27 @@ SHELL = @SHELL@
SNMP_CFLAGS = @SNMP_CFLAGS@
SNMP_CPPFLAGS = @SNMP_CPPFLAGS@
SNMP_LIBS = @SNMP_LIBS@
SNTP = @SNTP@
SNTP_DB = @SNTP_DB@
SNTP_DL = @SNTP_DL@
SNTP_DS = @SNTP_DS@
SNTP_MS = @SNTP_MS@
SNTP_NI = @SNTP_NI@
STDNORETURN_H = @STDNORETURN_H@
STRIP = @STRIP@
TESTDCF = @TESTDCF@
TICKADJ_DB = @TICKADJ_DB@
TICKADJ_DL = @TICKADJ_DL@
TICKADJ_DS = @TICKADJ_DS@
TICKADJ_MS = @TICKADJ_MS@
TICKADJ_NI = @TICKADJ_NI@
TIMETRIM_DB = @TIMETRIM_DB@
TIMETRIM_DL = @TIMETRIM_DL@
TIMETRIM_DS = @TIMETRIM_DS@
TIMETRIM_MS = @TIMETRIM_MS@
TIMETRIM_NI = @TIMETRIM_NI@
VERSION = @VERSION@
VER_SUFFIX = @VER_SUFFIX@
YACC = @YACC@
YFLAGS = @YFLAGS@
abs_builddir = @abs_builddir@
@ -219,6 +354,7 @@ abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_AR = @ac_ct_AR@
ac_ct_CC = @ac_ct_CC@
ac_ct_CXX = @ac_ct_CXX@
ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
@ -266,19 +402,13 @@ target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
AUTOMAKE_OPTIONS = foreign 1.10
ACLOCAL_AMFLAGS = -I m4 -I sntp/libopts/m4
ACLOCAL_AMFLAGS = -I sntp/m4 -I sntp/libevent/m4 -I sntp/libopts/m4
NULL =
SUBDIRS = scripts include ElectricFence libntp sntp libparse ntpd \
ntpdate ntpdc ntpq ntpsnmpd parseutil adjtimed clockstuff \
kernel util $(NULL)
DIST_SUBDIRS = \
SUBDIRS = \
scripts \
include \
ElectricFence \
libntp \
libparse \
sntp \
ntpd \
ntpdate \
ntpdc \
@ -289,9 +419,11 @@ DIST_SUBDIRS = \
clockstuff \
kernel \
util \
sntp \
tests \
$(NULL)
DISTCHECK_CONFIGURE_FLAGS = -C
DISTCHECK_CONFIGURE_FLAGS = -C --with-sntp
EXTRA_DIST = \
$(srcdir)/COPYRIGHT \
ChangeLog \
@ -308,13 +440,9 @@ EXTRA_DIST = \
WHERE-TO-START \
bootstrap \
build \
config.guess \
config.h.in \
config.sub \
dot.emacs \
excludes \
flock-build \
install-sh \
packageinfo.sh \
readme.y2kfixes \
results.y2kfixes \
@ -322,35 +450,29 @@ EXTRA_DIST = \
conf \
html \
lib/isc \
libjsmn \
ports \
\
bincheck.mf \
depsver.mf \
deps-ver \
$(srcdir)/version \
version.m4 \
\
$(NULL)
CLEANFILES =
DISTCLEANFILES = .gcc-warning
ETAGS_ARGS = Makefile.am configure.ac
# HMS: Keep .gcc-warning first, as that way it gets printed first.
BUILT_SOURCES = \
.gcc-warning \
libtool \
html/.datecheck \
sntp/built-sources-only \
$(srcdir)/COPYRIGHT \
$(srcdir)/version \
$(srcdir)/version.m4 \
$(srcdir)/include/version.def \
$(srcdir)/include/version.texi \
$(srcdir)/.checkChangeLog \
$(NULL)
# HMS: The following seems to be a work-in-progress...
CVO = `$(srcdir)/config.guess`
CVO = `$(srcdir)/sntp/libevent/build-aux/config.guess`
BHOST = `(hostname || uname -n)`
all: $(BUILT_SOURCES) config.h
$(MAKE) $(AM_MAKEFLAGS) all-recursive
@ -787,7 +909,7 @@ info: info-recursive
info-am:
install-data-am:
install-data-am: install-data-local
install-dvi: install-dvi-recursive
@ -833,7 +955,7 @@ ps: ps-recursive
ps-am:
uninstall-am:
uninstall-am: uninstall-local
.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) all check \
ctags-recursive install install-am install-strip \
@ -846,16 +968,39 @@ uninstall-am:
dist-zip distcheck distclean distclean-generic distclean-hdr \
distclean-libtool distclean-tags distcleancheck distdir \
distuninstallcheck dvi dvi-am html html-am info info-am \
install install-am install-data install-data-am install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-strip installcheck installcheck-am installdirs \
installdirs-am maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic mostlyclean-libtool pdf pdf-am \
ps ps-am tags tags-recursive uninstall uninstall-am
install install-am install-data install-data-am \
install-data-local install-dvi install-dvi-am install-exec \
install-exec-am install-html install-html-am install-info \
install-info-am install-man install-pdf install-pdf-am \
install-ps install-ps-am install-strip installcheck \
installcheck-am installdirs installdirs-am maintainer-clean \
maintainer-clean-generic mostlyclean mostlyclean-generic \
mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \
uninstall uninstall-am uninstall-local
.gcc-warning:
@echo "Compiling with GCC now generates lots of new warnings."
@echo " "
@echo "Don't be concerned. They're just warnings."
@echo " "
@echo "Don't send bug reports about the warnings, either."
@echo " "
@echo "Feel free to send patches that fix these warnings, though."
@echo " "
@sleep 1
@touch $@
html/.datecheck: FRC.html
cd $(srcdir)/html && \
../scripts/build/checkHtmlFileDates
libtool: $(LIBTOOL_DEPS)
./config.status --recheck
sntp/built-sources-only: FRC.sntp
@cd sntp && $(MAKE) $(AM_MAKEFLAGS) built-sources-only
$(srcdir)/COPYRIGHT: $(srcdir)/html/copyright.html
{ echo "This file is automatically generated from html/copyright.html" ; \
lynx -dump $(srcdir)/html/copyright.html ;} > COPYRIGHT.new \
@ -869,57 +1014,27 @@ COPYRIGHT-please: $(srcdir)/COPYRIGHT
Rather than determine our $(srcdir) from sntp/Makefile.am \
COPYRIGHT-please serves as a fixed target.
# HMS: The next bit is still suboptimal. If bk is present but this NTP
# repo is not a bk repo, we'll get an error message from the prs command.
# Unfortunately, I haven't found the necessary magic to redirect this error
# output to /dev/null under ancient/unique shells like the one Ultrix uses.
# We'll also get an error if srcdir or version is unwritable.
$(srcdir)/version: FRC.version
-(bk version) >/dev/null 2>&1 && \
cd $(srcdir) && \
x=`bk -R prs -hr+ -nd:I: ChangeSet` && \
y=`cat version 2>/dev/null` || true && \
case "$$x" in ''|$$y) ;; *) echo $$x > version ;; esac
$(srcdir)/version.m4: $(srcdir)/packageinfo.sh
TEMPDIR=`pwd` && export TEMPDIR && cd $(srcdir) && \
./scripts/genver version.m4
$(srcdir)/include/version.def: $(srcdir)/packageinfo.sh
TEMPDIR=`pwd` && export TEMPDIR && cd $(srcdir) && \
./scripts/genver include/version.def
$(srcdir)/include/version.texi: $(srcdir)/packageinfo.sh
TEMPDIR=`pwd` && export TEMPDIR && cd $(srcdir) && \
./scripts/genver include/version.texi
$(srcdir)/.checkChangeLog: $(srcdir)/ChangeLog $(srcdir)/scripts/checkChangeLog
$(srcdir)/.checkChangeLog: $(srcdir)/ChangeLog $(srcdir)/scripts/build/checkChangeLog
cd $(srcdir) && \
./scripts/checkChangeLog
libtool: $(LIBTOOL_DEPS)
./config.status --recheck
./scripts/build/checkChangeLog
dist-hook:
@find $(distdir) -type d -name SCCS -print | xargs rm -rf
.gcc-warning:
@echo "Compiling with GCC now generates lots of new warnings."
@echo " "
@echo "Don't be concerned. They're just warnings."
@echo " "
@echo "Don't send bug reports about the warnings, either."
@echo " "
@echo "Feel free to send patches that fix these warnings, though."
@echo " "
@sleep 1
@touch $@
install-data-local:
( cd $(srcdir) && find html -name SCCS -prune -o -type d \
-exec $(INSTALL) -d $(DESTDIR)$(htmldir)/{} ";" )
( cd $(srcdir) && find html -name SCCS -prune -o -type f \
-exec $(INSTALL_DATA) {} $(DESTDIR)$(htmldir)/{} ";" )
uninstall-local:
rm -rf $(DESTDIR)$(htmldir)/html
CommitLog: FRC.CommitLog
cd $(srcdir) \
&& $(PATH_TEST) -e CommitLog \
-a SCCS/s.ChangeSet -ot CommitLog \
|| scripts/genCommitLog
|| scripts/build/genCommitLog
.buildcvo:
echo "$(CVO)" > .buildcvo
@ -940,7 +1055,7 @@ CommitLog: FRC.CommitLog
echo " "; \
fi
FRC.CommitLog FRC.distwarn FRC.checkcvo FRC.checkhost FRC.version:
FRC.CommitLog FRC.checkcvo FRC.checkhost FRC.distwarn FRC.html FRC.sntp:
@: do-nothing action prevents any default
# HMS: what was I trying to do with this?

184
NEWS
View File

@ -1,3 +1,187 @@
---
NTP 4.2.8 (Harlan Stenn <stenn@ntp.org>, 2014/12/18)
Focus: Security and Bug fixes, enhancements.
Severity: HIGH
In addition to bug fixes and enhancements, this release fixes the
following high-severity vulnerabilities:
* Weak default key in config_auth().
References: [Sec 2665] / CVE-2014-9293 / VU#852879
CVSS: (AV:N/AC:L/Au:M/C:P/I:P/A:C) Base Score: 7.3
Vulnerable Versions: all releases prior to 4.2.7p11
Date Resolved: 28 Jan 2010
Summary: If no 'auth' key is set in the configuration file, ntpd
would generate a random key on the fly. There were two
problems with this: 1) the generated key was 31 bits in size,
and 2) it used the (now weak) ntp_random() function, which was
seeded with a 32-bit value and could only provide 32 bits of
entropy. This was sufficient back in the late 1990s when the
code was written. Not today.
Mitigation: Upgrade to 4.2.7p11 or later.
Credit: This vulnerability was noticed in ntp-4.2.6 by Neel Mehta
of the Google Security Team.
* Non-cryptographic random number generator with weak seed used by
ntp-keygen to generate symmetric keys.
References: [Sec 2666] / CVE-2014-9294 / VU#852879
CVSS: (AV:N/AC:L/Au:M/C:P/I:P/A:C) Base Score: 7.3
Vulnerable Versions: All NTP4 releases before 4.2.7p230
Date Resolved: Dev (4.2.7p230) 01 Nov 2011
Summary: Prior to ntp-4.2.7p230 ntp-keygen used a weak seed to
prepare a random number generator that was of good quality back
in the late 1990s. The random numbers produced was then used to
generate symmetric keys. In ntp-4.2.8 we use a current-technology
cryptographic random number generator, either RAND_bytes from
OpenSSL, or arc4random().
Mitigation: Upgrade to 4.2.7p230 or later.
Credit: This vulnerability was discovered in ntp-4.2.6 by
Stephen Roettger of the Google Security Team.
* Buffer overflow in crypto_recv()
References: Sec 2667 / CVE-2014-9295 / VU#852879
CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5
Versions: All releases before 4.2.8
Date Resolved: Stable (4.2.8) 18 Dec 2014
Summary: When Autokey Authentication is enabled (i.e. the ntp.conf
file contains a 'crypto pw ...' directive) a remote attacker
can send a carefully crafted packet that can overflow a stack
buffer and potentially allow malicious code to be executed
with the privilege level of the ntpd process.
Mitigation: Upgrade to 4.2.8, or later, or
Disable Autokey Authentication by removing, or commenting out,
all configuration directives beginning with the crypto keyword
in your ntp.conf file.
Credit: This vulnerability was discovered by Stephen Roettger of the
Google Security Team.
* Buffer overflow in ctl_putdata()
References: Sec 2668 / CVE-2014-9295 / VU#852879
CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5
Versions: All NTP4 releases before 4.2.8
Date Resolved: Stable (4.2.8) 18 Dec 2014
Summary: A remote attacker can send a carefully crafted packet that
can overflow a stack buffer and potentially allow malicious
code to be executed with the privilege level of the ntpd process.
Mitigation: Upgrade to 4.2.8, or later.
Credit: This vulnerability was discovered by Stephen Roettger of the
Google Security Team.
* Buffer overflow in configure()
References: Sec 2669 / CVE-2014-9295 / VU#852879
CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5
Versions: All NTP4 releases before 4.2.8
Date Resolved: Stable (4.2.8) 18 Dec 2014
Summary: A remote attacker can send a carefully crafted packet that
can overflow a stack buffer and potentially allow malicious
code to be executed with the privilege level of the ntpd process.
Mitigation: Upgrade to 4.2.8, or later.
Credit: This vulnerability was discovered by Stephen Roettger of the
Google Security Team.
* receive(): missing return on error
References: Sec 2670 / CVE-2014-9296 / VU#852879
CVSS: (AV:N/AC:L/Au:N/C:N/I:N/A:P) Base Score: 5.0
Versions: All NTP4 releases before 4.2.8
Date Resolved: Stable (4.2.8) 18 Dec 2014
Summary: Code in ntp_proto.c:receive() was missing a 'return;' in
the code path where an error was detected, which meant
processing did not stop when a specific rare error occurred.
We haven't found a way for this bug to affect system integrity.
If there is no way to affect system integrity the base CVSS
score for this bug is 0. If there is one avenue through which
system integrity can be partially affected, the base score
becomes a 5. If system integrity can be partially affected
via all three integrity metrics, the CVSS base score become 7.5.
Mitigation:
Upgrade to 4.2.8, or later,
or Remove or comment out all configuration directives
beginning with the crypto keyword in your ntp.conf file.
Credit: This vulnerability was discovered by Stephen Roettger of the
Google Security Team.
See http://support.ntp.org/security for more information.
New features / changes in this release:
Important Changes
* Internal NTP Era counters
The internal counters that track the "era" (range of years) we are in
rolls over every 136 years'. The current "era" started at the stroke of
midnight on 1 Jan 1900, and ends just before the stroke of midnight on
1 Jan 2036.
In the past, we have used the "midpoint" of the range to decide which
era we were in. Given the longevity of some products, it became clear
that it would be more functional to "look back" less, and "look forward"
more. We now compile a timestamp into the ntpd executable and when we
get a timestamp we us the "built-on" to tell us what era we are in.
This check "looks back" 10 years, and "looks forward" 126 years.
* ntpdc responses disabled by default
Dave Hart writes:
For a long time, ntpq and its mostly text-based mode 6 (control)
protocol have been preferred over ntpdc and its mode 7 (private
request) protocol for runtime queries and configuration. There has
been a goal of deprecating ntpdc, previously held back by numerous
capabilities exposed by ntpdc with no ntpq equivalent. I have been
adding commands to ntpq to cover these cases, and I believe I've
covered them all, though I've not compared command-by-command
recently.
As I've said previously, the binary mode 7 protocol involves a lot of
hand-rolled structure layout and byte-swapping code in both ntpd and
ntpdc which is hard to get right. As ntpd grows and changes, the
changes are difficult to expose via ntpdc while maintaining forward
and backward compatibility between ntpdc and ntpd. In contrast,
ntpq's text-based, label=value approach involves more code reuse and
allows compatible changes without extra work in most cases.
Mode 7 has always been defined as vendor/implementation-specific while
mode 6 is described in RFC 1305 and intended to be open to interoperate
with other implementations. There is an early draft of an updated
mode 6 description that likely will join the other NTPv4 RFCs
eventually. (http://tools.ietf.org/html/draft-odonoghue-ntpv4-control-01)
For these reasons, ntpd 4.2.7p230 by default disables processing of
ntpdc queries, reducing ntpd's attack surface and functionally
deprecating ntpdc. If you are in the habit of using ntpdc for certain
operations, please try the ntpq equivalent. If there's no equivalent,
please open a bug report at http://bugs.ntp.org./
In addition to the above, over 1100 issues have been resolved between
the 4.2.6 branch and 4.2.8. The ChangeLog file in the distribution
lists these.
---
NTP 4.2.6p5 (Harlan Stenn <stenn@ntp.org>, 2011/12/24)

3
WHERE-TO-START
View File

@ -35,7 +35,8 @@ files in the base directory of this distribution is in the README file.
A list of "significant" changes for the release is in the NEWS file.
If you're interested in helping us test pre-release versions of ntpd,
please look in <ftp://huey.udel.edu/pub/ntp/testing/>.
please visit http://support.ntp.org/downloads and look for RC and/or
Development tarballs.
David L. Mills (mills@udel.edu)
21 June 1998

203
aclocal.m4 vendored
View File

@ -19,6 +19,125 @@ You have another version of autoconf. It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.])])
# serial 9 -*- Autoconf -*-
# Enable extensions on systems that normally disable them.
# Copyright (C) 2003, 2006-2010 Free Software Foundation, Inc.
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This definition of AC_USE_SYSTEM_EXTENSIONS is stolen from CVS
# Autoconf. Perhaps we can remove this once we can assume Autoconf
# 2.62 or later everywhere, but since CVS Autoconf mutates rapidly
# enough in this area it's likely we'll need to redefine
# AC_USE_SYSTEM_EXTENSIONS for quite some time.
# If autoconf reports a warning
# warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
# or warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
# the fix is
# 1) to ensure that AC_USE_SYSTEM_EXTENSIONS is never directly invoked
# but always AC_REQUIREd,
# 2) to ensure that for each occurrence of
# AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
# or
# AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
# the corresponding gnulib module description has 'extensions' among
# its dependencies. This will ensure that the gl_USE_SYSTEM_EXTENSIONS
# invocation occurs in gl_EARLY, not in gl_INIT.
# AC_USE_SYSTEM_EXTENSIONS
# ------------------------
# Enable extensions on systems that normally disable them,
# typically due to standards-conformance issues.
# Remember that #undef in AH_VERBATIM gets replaced with #define by
# AC_DEFINE. The goal here is to define all known feature-enabling
# macros, then, if reports of conflicts are made, disable macros that
# cause problems on some platforms (such as __EXTENSIONS__).
AC_DEFUN_ONCE([AC_USE_SYSTEM_EXTENSIONS],
[AC_BEFORE([$0], [AC_COMPILE_IFELSE])dnl
AC_BEFORE([$0], [AC_RUN_IFELSE])dnl
AC_REQUIRE([AC_CANONICAL_HOST])
AC_CHECK_HEADER([minix/config.h], [MINIX=yes], [MINIX=])
if test "$MINIX" = yes; then
AC_DEFINE([_POSIX_SOURCE], [1],
[Define to 1 if you need to in order for `stat' and other
things to work.])
AC_DEFINE([_POSIX_1_SOURCE], [2],
[Define to 2 if the system does not provide POSIX.1 features
except with this defined.])
AC_DEFINE([_MINIX], [1],
[Define to 1 if on MINIX.])
fi
dnl HP-UX 11.11 defines mbstate_t only if _XOPEN_SOURCE is defined to 500,
dnl regardless of whether the flags -Ae or _D_HPUX_SOURCE=1 are already
dnl provided.
case "$host_os" in
hpux*)
AC_DEFINE([_XOPEN_SOURCE], [500],
[Define to 500 only on HP-UX.])
;;
esac
AH_VERBATIM([__EXTENSIONS__],
[/* Enable extensions on AIX 3, Interix. */
#ifndef _ALL_SOURCE
# undef _ALL_SOURCE
#endif
/* Enable GNU extensions on systems that have them. */
#ifndef _GNU_SOURCE
# undef _GNU_SOURCE
#endif
/* Enable threading extensions on Solaris. */
#ifndef _POSIX_PTHREAD_SEMANTICS
# undef _POSIX_PTHREAD_SEMANTICS
#endif
/* Enable extensions on HP NonStop. */
#ifndef _TANDEM_SOURCE
# undef _TANDEM_SOURCE
#endif
/* Enable general extensions on Solaris. */
#ifndef __EXTENSIONS__
# undef __EXTENSIONS__
#endif
])
AC_CACHE_CHECK([whether it is safe to define __EXTENSIONS__],
[ac_cv_safe_to_define___extensions__],
[AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM([[
# define __EXTENSIONS__ 1
]AC_INCLUDES_DEFAULT])],
[ac_cv_safe_to_define___extensions__=yes],
[ac_cv_safe_to_define___extensions__=no])])
test $ac_cv_safe_to_define___extensions__ = yes &&
AC_DEFINE([__EXTENSIONS__])
AC_DEFINE([_ALL_SOURCE])
AC_DEFINE([_GNU_SOURCE])
AC_DEFINE([_POSIX_PTHREAD_SEMANTICS])
AC_DEFINE([_TANDEM_SOURCE])
])# AC_USE_SYSTEM_EXTENSIONS
# gl_USE_SYSTEM_EXTENSIONS
# ------------------------
# Enable extensions on systems that normally disable them,
# typically due to standards-conformance issues.
AC_DEFUN_ONCE([gl_USE_SYSTEM_EXTENSIONS],
[
dnl Require this macro before AC_USE_SYSTEM_EXTENSIONS.
dnl gnulib does not need it. But if it gets required by third-party macros
dnl after AC_USE_SYSTEM_EXTENSIONS is required, autoconf 2.62..2.63 emit a
dnl warning: "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS".
dnl Note: We can do this only for one of the macros AC_AIX, AC_GNU_SOURCE,
dnl AC_MINIX. If people still use AC_AIX or AC_MINIX, they are out of luck.
AC_REQUIRE([AC_GNU_SOURCE])
AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
])
# Copyright (C) 2002, 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
@ -406,18 +525,6 @@ AC_DEFUN([AM_OUTPUT_DEPENDENCY_COMMANDS],
[AMDEP_TRUE="$AMDEP_TRUE" ac_aux_dir="$ac_aux_dir"])
])
# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 8
# AM_CONFIG_HEADER is obsolete. It has been replaced by AC_CONFIG_HEADERS.
AU_DEFUN([AM_CONFIG_HEADER], [AC_CONFIG_HEADERS($@)])
# Do all the work for Automake. -*- Autoconf -*-
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
@ -853,6 +960,33 @@ Check your system clock])
fi
AC_MSG_RESULT(yes)])
# Copyright (C) 2009 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 1
# AM_SILENT_RULES([DEFAULT])
# --------------------------
# Enable less verbose build rules; with the default set to DEFAULT
# (`yes' being less verbose, `no' or empty being verbose).
AC_DEFUN([AM_SILENT_RULES],
[AC_ARG_ENABLE([silent-rules],
[ --enable-silent-rules less verbose build output (undo: `make V=1')
--disable-silent-rules verbose build output (undo: `make V=0')])
case $enable_silent_rules in
yes) AM_DEFAULT_VERBOSITY=0;;
no) AM_DEFAULT_VERBOSITY=1;;
*) AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
esac
AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
AM_BACKSLASH='\'
AC_SUBST([AM_BACKSLASH])dnl
_AM_SUBST_NOTMAKE([AM_BACKSLASH])dnl
])
# Copyright (C) 2001, 2003, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
@ -997,15 +1131,36 @@ AC_SUBST([am__untar])
]) # _AM_PROG_TAR
m4_include([sntp/libopts/m4/libopts.m4])
m4_include([m4/define_dir.m4])
m4_include([m4/libtool.m4])
m4_include([m4/ltoptions.m4])
m4_include([m4/ltsugar.m4])
m4_include([m4/ltversion.m4])
m4_include([m4/lt~obsolete.m4])
m4_include([m4/ntp_cacheversion.m4])
m4_include([m4/ntp_dir_sep.m4])
m4_include([m4/ntp_lineeditlibs.m4])
m4_include([m4/ntp_openssl.m4])
m4_include([m4/ntp_vpathhack.m4])
m4_include([m4/os_cflags.m4])
m4_include([sntp/libopts/m4/stdnoreturn.m4])
m4_include([sntp/libevent/m4/openldap-thread-check.m4])
m4_include([sntp/libevent/m4/openldap.m4])
m4_include([sntp/m4/define_dir.m4])
m4_include([sntp/m4/hms_search_lib.m4])
m4_include([sntp/m4/libtool.m4])
m4_include([sntp/m4/ltoptions.m4])
m4_include([sntp/m4/ltsugar.m4])
m4_include([sntp/m4/ltversion.m4])
m4_include([sntp/m4/lt~obsolete.m4])
m4_include([sntp/m4/ntp_cacheversion.m4])
m4_include([sntp/m4/ntp_compiler.m4])
m4_include([sntp/m4/ntp_crosscompile.m4])
m4_include([sntp/m4/ntp_crypto_rand.m4])
m4_include([sntp/m4/ntp_debug.m4])
m4_include([sntp/m4/ntp_dir_sep.m4])
m4_include([sntp/m4/ntp_facilitynames.m4])
m4_include([sntp/m4/ntp_googletest.m4])
m4_include([sntp/m4/ntp_ipv6.m4])
m4_include([sntp/m4/ntp_lib_m.m4])
m4_include([sntp/m4/ntp_libevent.m4])
m4_include([sntp/m4/ntp_libntp.m4])
m4_include([sntp/m4/ntp_lineeditlibs.m4])
m4_include([sntp/m4/ntp_locinfo.m4])
m4_include([sntp/m4/ntp_openssl.m4])
m4_include([sntp/m4/ntp_pkg_config.m4])
m4_include([sntp/m4/ntp_prog_cc.m4])
m4_include([sntp/m4/ntp_rlimit.m4])
m4_include([sntp/m4/ntp_sntp.m4])
m4_include([sntp/m4/ntp_ver_suffix.m4])
m4_include([sntp/m4/ntp_vpathhack.m4])
m4_include([sntp/m4/os_cflags.m4])
m4_include([sntp/m4/snprintf.m4])

28
adjtimed/Makefile.am
View File

@ -1,17 +1,21 @@
AUTOMAKE_OPTIONS=
## adjtimed Makefile.am
if NTP_BINSUBDIR_IS_BIN
bin_PROGRAMS= @MAKE_ADJTIMED@
else
sbin_PROGRAMS= @MAKE_ADJTIMED@
endif
bin_PROGRAMS = $(ADJTIMED_DB)
libexec_PROGRAMS = $(ADJTIMED_DL)
sbin_PROGRAMS = $(ADJTIMED_DS)
BUILT_SOURCES=
CLEANFILES=
EXTRA_PROGRAMS= adjtimed
AM_CPPFLAGS= -I$(top_srcdir)/include
LDADD= ../libntp/libntp.a
ETAGS_ARGS= Makefile.am
BUILT_SOURCES =
CLEANFILES =
EXTRA_PROGRAMS = adjtimed
AM_CFLAGS = $(CFLAGS_NTP)
AM_CPPFLAGS = $(NTP_INCS)
AM_CPPFLAGS += $(CPPFLAGS_NTP)
LDADD = ../libntp/libntp.a $(LDADD_LIBNTP) $(LIBM) $(PTHREAD_LIBS)
include $(top_srcdir)/bincheck.mf
include $(top_srcdir)/sntp/check-libntp.mf
include $(top_srcdir)/depsver.mf
include $(top_srcdir)/includes.mf

361
adjtimed/Makefile.in
View File

@ -38,67 +38,126 @@ PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
bin_PROGRAMS =
libexec_PROGRAMS =
sbin_PROGRAMS =
EXTRA_PROGRAMS = adjtimed$(EXEEXT)
DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
$(top_srcdir)/bincheck.mf $(top_srcdir)/depsver.mf
$(top_srcdir)/bincheck.mf $(top_srcdir)/depsver.mf \
$(top_srcdir)/includes.mf $(top_srcdir)/sntp/check-libntp.mf
subdir = adjtimed
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/sntp/libopts/m4/libopts.m4 \
$(top_srcdir)/m4/define_dir.m4 $(top_srcdir)/m4/libtool.m4 \
$(top_srcdir)/m4/ltoptions.m4 $(top_srcdir)/m4/ltsugar.m4 \
$(top_srcdir)/m4/ltversion.m4 $(top_srcdir)/m4/lt~obsolete.m4 \
$(top_srcdir)/m4/ntp_cacheversion.m4 \
$(top_srcdir)/m4/ntp_dir_sep.m4 \
$(top_srcdir)/m4/ntp_lineeditlibs.m4 \
$(top_srcdir)/m4/ntp_openssl.m4 \
$(top_srcdir)/m4/ntp_vpathhack.m4 \
$(top_srcdir)/m4/os_cflags.m4 $(top_srcdir)/version.m4 \
$(top_srcdir)/configure.ac
$(top_srcdir)/sntp/libopts/m4/stdnoreturn.m4 \
$(top_srcdir)/sntp/libevent/m4/openldap-thread-check.m4 \
$(top_srcdir)/sntp/libevent/m4/openldap.m4 \
$(top_srcdir)/sntp/m4/define_dir.m4 \
$(top_srcdir)/sntp/m4/hms_search_lib.m4 \
$(top_srcdir)/sntp/m4/libtool.m4 \
$(top_srcdir)/sntp/m4/ltoptions.m4 \
$(top_srcdir)/sntp/m4/ltsugar.m4 \
$(top_srcdir)/sntp/m4/ltversion.m4 \
$(top_srcdir)/sntp/m4/lt~obsolete.m4 \
$(top_srcdir)/sntp/m4/ntp_cacheversion.m4 \
$(top_srcdir)/sntp/m4/ntp_compiler.m4 \
$(top_srcdir)/sntp/m4/ntp_crosscompile.m4 \
$(top_srcdir)/sntp/m4/ntp_crypto_rand.m4 \
$(top_srcdir)/sntp/m4/ntp_debug.m4 \
$(top_srcdir)/sntp/m4/ntp_dir_sep.m4 \
$(top_srcdir)/sntp/m4/ntp_facilitynames.m4 \
$(top_srcdir)/sntp/m4/ntp_googletest.m4 \
$(top_srcdir)/sntp/m4/ntp_ipv6.m4 \
$(top_srcdir)/sntp/m4/ntp_lib_m.m4 \
$(top_srcdir)/sntp/m4/ntp_libevent.m4 \
$(top_srcdir)/sntp/m4/ntp_libntp.m4 \
$(top_srcdir)/sntp/m4/ntp_lineeditlibs.m4 \
$(top_srcdir)/sntp/m4/ntp_locinfo.m4 \
$(top_srcdir)/sntp/m4/ntp_openssl.m4 \
$(top_srcdir)/sntp/m4/ntp_pkg_config.m4 \
$(top_srcdir)/sntp/m4/ntp_prog_cc.m4 \
$(top_srcdir)/sntp/m4/ntp_rlimit.m4 \
$(top_srcdir)/sntp/m4/ntp_sntp.m4 \
$(top_srcdir)/sntp/m4/ntp_ver_suffix.m4 \
$(top_srcdir)/sntp/m4/ntp_vpathhack.m4 \
$(top_srcdir)/sntp/m4/os_cflags.m4 \
$(top_srcdir)/sntp/m4/snprintf.m4 \
$(top_srcdir)/sntp/m4/version.m4 $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(sbindir)"
PROGRAMS = $(bin_PROGRAMS) $(sbin_PROGRAMS)
am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" \
"$(DESTDIR)$(sbindir)"
PROGRAMS = $(bin_PROGRAMS) $(libexec_PROGRAMS) $(sbin_PROGRAMS)
adjtimed_SOURCES = adjtimed.c
adjtimed_OBJECTS = adjtimed.$(OBJEXT)
adjtimed_LDADD = $(LDADD)
adjtimed_DEPENDENCIES = ../libntp/libntp.a
am__DEPENDENCIES_1 =
adjtimed_DEPENDENCIES = ../libntp/libntp.a $(am__DEPENDENCIES_1) \
$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
AM_V_lt = $(am__v_lt_$(V))
am__v_lt_ = $(am__v_lt_$(AM_DEFAULT_VERBOSITY))
am__v_lt_0 = --silent
DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
depcomp = $(SHELL) $(top_srcdir)/depcomp
depcomp = $(SHELL) $(top_srcdir)/sntp/libevent/build-aux/depcomp
am__depfiles_maybe = depfiles
am__mv = mv -f
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CFLAGS) $(CFLAGS)
AM_V_CC = $(am__v_CC_$(V))
am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))
am__v_CC_0 = @echo " CC " $@;
AM_V_at = $(am__v_at_$(V))
am__v_at_ = $(am__v_at_$(AM_DEFAULT_VERBOSITY))
am__v_at_0 = @
CCLD = $(CC)
LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@
LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
$(AM_LDFLAGS) $(LDFLAGS) -o $@
AM_V_CCLD = $(am__v_CCLD_$(V))
am__v_CCLD_ = $(am__v_CCLD_$(AM_DEFAULT_VERBOSITY))
am__v_CCLD_0 = @echo " CCLD " $@;
AM_V_GEN = $(am__v_GEN_$(V))
am__v_GEN_ = $(am__v_GEN_$(AM_DEFAULT_VERBOSITY))
am__v_GEN_0 = @echo " GEN " $@;
SOURCES = adjtimed.c
DIST_SOURCES = adjtimed.c
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ALLOCA = @ALLOCA@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
AR = @AR@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BINSUBDIR = @BINSUBDIR@
CALC_TICKADJ_DB = @CALC_TICKADJ_DB@
CALC_TICKADJ_DL = @CALC_TICKADJ_DL@
CALC_TICKADJ_DS = @CALC_TICKADJ_DS@
CALC_TICKADJ_MS = @CALC_TICKADJ_MS@
CALC_TICKADJ_NI = @CALC_TICKADJ_NI@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CFLAGS_NTP = @CFLAGS_NTP@
CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CONFIG_SHELL = @CONFIG_SHELL@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CPPFLAGS_NTP = @CPPFLAGS_NTP@
CXX = @CXX@
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
CXXFLAGS = @CXXFLAGS@
CYGPATH_W = @CYGPATH_W@
DCFD = @DCFD@
DEFS = @DEFS@
@ -110,21 +169,31 @@ ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
EDITLINE_LIBS = @EDITLINE_LIBS@
EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
FGREP = @FGREP@
GREP = @GREP@
GTEST_CONFIG = @GTEST_CONFIG@
GTEST_CPPFLAGS = @GTEST_CPPFLAGS@
GTEST_CXXFLAGS = @GTEST_CXXFLAGS@
GTEST_LDFLAGS = @GTEST_LDFLAGS@
GTEST_LIBS = @GTEST_LIBS@
HAVE_INLINE = @HAVE_INLINE@
HAVE_RLIMIT_MEMLOCK = @HAVE_RLIMIT_MEMLOCK@
HAVE_RLIMIT_STACK = @HAVE_RLIMIT_STACK@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LCRYPTO = @LCRYPTO@
LD = @LD@
LDADD_LIBNTP = @LDADD_LIBNTP@
LDADD_NLIST = @LDADD_NLIST@
LDADD_NTP = @LDADD_NTP@
LDFLAGS = @LDFLAGS@
LDFLAGS_NTP = @LDFLAGS_NTP@
LIBISC_PTHREADS_NOTHREADS = @LIBISC_PTHREADS_NOTHREADS@
LIBM = @LIBM@
LIBOBJS = @LIBOBJS@
LIBOPTS_CFLAGS = @LIBOPTS_CFLAGS@
LIBOPTS_DIR = @LIBOPTS_DIR@
@ -132,6 +201,7 @@ LIBOPTS_LDADD = @LIBOPTS_LDADD@
LIBPARSE = @LIBPARSE@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LIBTOOL_DEPS = @LIBTOOL_DEPS@
LIPO = @LIPO@
LN_S = @LN_S@
LSCF = @LSCF@
@ -150,14 +220,68 @@ MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
MANIFEST_TOOL = @MANIFEST_TOOL@
MANTAGFMT = @MANTAGFMT@
MKDIR_P = @MKDIR_P@
NM = @NM@
NMEDIT = @NMEDIT@
NTPDATE_DB = @NTPDATE_DB@
NTPDATE_DL = @NTPDATE_DL@
NTPDATE_DS = @NTPDATE_DS@
NTPDATE_MS = @NTPDATE_MS@
NTPDATE_NI = @NTPDATE_NI@
NTPDC_DB = @NTPDC_DB@
NTPDC_DL = @NTPDC_DL@
NTPDC_DS = @NTPDC_DS@
NTPDC_MS = @NTPDC_MS@
NTPDC_NI = @NTPDC_NI@
NTPDSIM_DB = @NTPDSIM_DB@
NTPDSIM_DL = @NTPDSIM_DL@
NTPDSIM_DS = @NTPDSIM_DS@
NTPDSIM_MS = @NTPDSIM_MS@
NTPDSIM_NI = @NTPDSIM_NI@
NTPD_DB = @NTPD_DB@
NTPD_DL = @NTPD_DL@
NTPD_DS = @NTPD_DS@
NTPD_MS = @NTPD_MS@
NTPD_NI = @NTPD_NI@
NTPQ_DB = @NTPQ_DB@
NTPQ_DL = @NTPQ_DL@
NTPQ_DS = @NTPQ_DS@
NTPQ_MS = @NTPQ_MS@
NTPQ_NI = @NTPQ_NI@
NTPSNMPD_DB = @NTPSNMPD_DB@
NTPSNMPD_DL = @NTPSNMPD_DL@
NTPSNMPD_DS = @NTPSNMPD_DS@
NTPSNMPD_MS = @NTPSNMPD_MS@
NTPSNMPD_NI = @NTPSNMPD_NI@
NTPSWEEP_DB = @NTPSWEEP_DB@
NTPSWEEP_DL = @NTPSWEEP_DL@
NTPSWEEP_DS = @NTPSWEEP_DS@
NTPSWEEP_MS = @NTPSWEEP_MS@
NTPSWEEP_NI = @NTPSWEEP_NI@
NTPTIME_DB = @NTPTIME_DB@
NTPTIME_DL = @NTPTIME_DL@
NTPTIME_DS = @NTPTIME_DS@
NTPTIME_MS = @NTPTIME_MS@
NTPTIME_NI = @NTPTIME_NI@
NTPTRACE_DB = @NTPTRACE_DB@
NTPTRACE_DL = @NTPTRACE_DL@
NTPTRACE_DS = @NTPTRACE_DS@
NTPTRACE_MS = @NTPTRACE_MS@
NTPTRACE_NI = @NTPTRACE_NI@
NTP_KEYGEN_DB = @NTP_KEYGEN_DB@
NTP_KEYGEN_DL = @NTP_KEYGEN_DL@
NTP_KEYGEN_DS = @NTP_KEYGEN_DS@
NTP_KEYGEN_MS = @NTP_KEYGEN_MS@
NTP_KEYGEN_NI = @NTP_KEYGEN_NI@
NTP_KEYSDIR = @NTP_KEYSDIR@
NTP_WAIT_DB = @NTP_WAIT_DB@
NTP_WAIT_DL = @NTP_WAIT_DL@
NTP_WAIT_DS = @NTP_WAIT_DS@
NTP_WAIT_MS = @NTP_WAIT_MS@
NTP_WAIT_NI = @NTP_WAIT_NI@
OBJDUMP = @OBJDUMP@
OBJEXT = @OBJEXT@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
OPENSSL_LIB = @OPENSSL_LIB@
OTOOL = @OTOOL@
OTOOL64 = @OTOOL64@
PACKAGE = @PACKAGE@
@ -170,10 +294,12 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_NET_SNMP_CONFIG = @PATH_NET_SNMP_CONFIG@
PATH_PERL = @PATH_PERL@
PATH_SEPARATOR = @PATH_SEPARATOR@
PATH_SH = @PATH_SH@
PATH_TEST = @PATH_TEST@
PERLLIBDIR = @PERLLIBDIR@
PKG_CONFIG = @PKG_CONFIG@
POSIX_SHELL = @POSIX_SHELL@
PROPDELAY = @PROPDELAY@
PTHREAD_LIBS = @PTHREAD_LIBS@
RANLIB = @RANLIB@
SED = @SED@
SET_MAKE = @SET_MAKE@
@ -181,9 +307,27 @@ SHELL = @SHELL@
SNMP_CFLAGS = @SNMP_CFLAGS@
SNMP_CPPFLAGS = @SNMP_CPPFLAGS@
SNMP_LIBS = @SNMP_LIBS@
SNTP = @SNTP@
SNTP_DB = @SNTP_DB@
SNTP_DL = @SNTP_DL@
SNTP_DS = @SNTP_DS@
SNTP_MS = @SNTP_MS@
SNTP_NI = @SNTP_NI@
STDNORETURN_H = @STDNORETURN_H@
STRIP = @STRIP@
TESTDCF = @TESTDCF@
TICKADJ_DB = @TICKADJ_DB@
TICKADJ_DL = @TICKADJ_DL@
TICKADJ_DS = @TICKADJ_DS@
TICKADJ_MS = @TICKADJ_MS@
TICKADJ_NI = @TICKADJ_NI@
TIMETRIM_DB = @TIMETRIM_DB@
TIMETRIM_DL = @TIMETRIM_DL@
TIMETRIM_DS = @TIMETRIM_DS@
TIMETRIM_MS = @TIMETRIM_MS@
TIMETRIM_NI = @TIMETRIM_NI@
VERSION = @VERSION@
VER_SUFFIX = @VER_SUFFIX@
YACC = @YACC@
YFLAGS = @YFLAGS@
abs_builddir = @abs_builddir@
@ -192,6 +336,7 @@ abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_AR = @ac_ct_AR@
ac_ct_CC = @ac_ct_CC@
ac_ct_CXX = @ac_ct_CXX@
ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
@ -239,20 +384,20 @@ target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
AUTOMAKE_OPTIONS =
@NTP_BINSUBDIR_IS_BIN_TRUE@bin_PROGRAMS = @MAKE_ADJTIMED@
@NTP_BINSUBDIR_IS_BIN_FALSE@sbin_PROGRAMS = @MAKE_ADJTIMED@
BUILT_SOURCES = .deps-ver
CLEANFILES = .deps-ver
AM_CPPFLAGS = -I$(top_srcdir)/include
LDADD = ../libntp/libntp.a
ETAGS_ARGS = Makefile.am
BUILT_SOURCES = check-libntp .deps-ver
CLEANFILES = check-libntp .deps-ver
AM_CFLAGS = $(CFLAGS_NTP)
AM_CPPFLAGS = $(NTP_INCS) $(CPPFLAGS_NTP)
LDADD = ../libntp/libntp.a $(LDADD_LIBNTP) $(LIBM) $(PTHREAD_LIBS)
NTP_INCS = -I$(top_srcdir)/include -I$(top_srcdir)/lib/isc/include \
-I$(top_srcdir)/lib/isc/$(LIBISC_PTHREADS_NOTHREADS)/include \
-I$(top_srcdir)/lib/isc/unix/include
all: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) all-am
.SUFFIXES:
.SUFFIXES: .c .lo .o .obj
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/bincheck.mf $(top_srcdir)/depsver.mf $(am__configure_deps)
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/bincheck.mf $(top_srcdir)/sntp/check-libntp.mf $(top_srcdir)/depsver.mf $(top_srcdir)/includes.mf $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
@ -325,6 +470,49 @@ clean-binPROGRAMS:
list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
echo " rm -f" $$list; \
rm -f $$list
install-libexecPROGRAMS: $(libexec_PROGRAMS)
@$(NORMAL_INSTALL)
test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
for p in $$list; do echo "$$p $$p"; done | \
sed 's/$(EXEEXT)$$//' | \
while read p p1; do if test -f $$p || test -f $$p1; \
then echo "$$p"; echo "$$p"; else :; fi; \
done | \
sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
-e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
sed 'N;N;N;s,\n, ,g' | \
$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
{ d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
if ($$2 == $$4) files[d] = files[d] " " $$1; \
else { print "f", $$3 "/" $$4, $$1; } } \
END { for (d in files) print "f", d, files[d] }' | \
while read type dir files; do \
if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
test -z "$$files" || { \
echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
$(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
} \
; done
uninstall-libexecPROGRAMS:
@$(NORMAL_UNINSTALL)
@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
files=`for p in $$list; do echo "$$p"; done | \
sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
-e 's/$$/$(EXEEXT)/' `; \
test -n "$$list" || exit 0; \
echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
clean-libexecPROGRAMS:
@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
echo " rm -f" $$list; \
rm -f $$list || exit $$?; \
test -n "$(EXEEXT)" || exit 0; \
list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
echo " rm -f" $$list; \
rm -f $$list
install-sbinPROGRAMS: $(sbin_PROGRAMS)
@$(NORMAL_INSTALL)
test -z "$(sbindir)" || $(MKDIR_P) "$(DESTDIR)$(sbindir)"
@ -370,7 +558,7 @@ clean-sbinPROGRAMS:
rm -f $$list
adjtimed$(EXEEXT): $(adjtimed_OBJECTS) $(adjtimed_DEPENDENCIES)
@rm -f adjtimed$(EXEEXT)
$(LINK) $(adjtimed_OBJECTS) $(adjtimed_LDADD) $(LIBS)
$(AM_V_CCLD)$(LINK) $(adjtimed_OBJECTS) $(adjtimed_LDADD) $(LIBS)
mostlyclean-compile:
-rm -f *.$(OBJEXT)
@ -381,22 +569,25 @@ distclean-compile:
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/adjtimed.Po@am__quote@
.c.o:
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_TRUE@ $(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_FALSE@ $(AM_V_CC) @AM_BACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c $<
.c.obj:
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_TRUE@ $(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_FALSE@ $(AM_V_CC) @AM_BACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c `$(CYGPATH_W) '$<'`
.c.lo:
@am__fastdepCC_TRUE@ $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
@am__fastdepCC_TRUE@ $(AM_V_CC)$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
@am__fastdepCC_FALSE@ $(AM_V_CC) @AM_BACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(LTCOMPILE) -c -o $@ $<
@ -494,7 +685,7 @@ check: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) check-am
all-am: Makefile $(PROGRAMS)
installdirs:
for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(sbindir)"; do \
for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(sbindir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: $(BUILT_SOURCES)
@ -527,8 +718,8 @@ maintainer-clean-generic:
-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
clean: clean-am
clean-am: clean-binPROGRAMS clean-generic clean-libtool \
clean-sbinPROGRAMS mostlyclean-am
clean-am: clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
clean-libtool clean-sbinPROGRAMS mostlyclean-am
distclean: distclean-am
-rm -rf ./$(DEPDIR)
@ -554,7 +745,8 @@ install-dvi: install-dvi-am
install-dvi-am:
install-exec-am: install-binPROGRAMS install-sbinPROGRAMS
install-exec-am: install-binPROGRAMS install-libexecPROGRAMS \
install-sbinPROGRAMS
@$(NORMAL_INSTALL)
$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
install-html: install-html-am
@ -595,44 +787,54 @@ ps: ps-am
ps-am:
uninstall-am: uninstall-binPROGRAMS uninstall-sbinPROGRAMS
uninstall-am: uninstall-binPROGRAMS uninstall-libexecPROGRAMS \
uninstall-sbinPROGRAMS
.MAKE: all check install install-am install-exec-am install-strip
.PHONY: CTAGS GTAGS all all-am check check-am clean clean-binPROGRAMS \
clean-generic clean-libtool clean-sbinPROGRAMS ctags distclean \
distclean-compile distclean-generic distclean-libtool \
distclean-tags distdir dvi dvi-am html html-am info info-am \
install install-am install-binPROGRAMS install-data \
install-data-am install-dvi install-dvi-am install-exec \
install-exec-am install-exec-hook install-html install-html-am \
install-info install-info-am install-man install-pdf \
install-pdf-am install-ps install-ps-am install-sbinPROGRAMS \
install-strip installcheck installcheck-am installdirs \
maintainer-clean maintainer-clean-generic mostlyclean \
mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
pdf pdf-am ps ps-am tags uninstall uninstall-am \
uninstall-binPROGRAMS uninstall-sbinPROGRAMS
clean-generic clean-libexecPROGRAMS clean-libtool \
clean-sbinPROGRAMS ctags distclean distclean-compile \
distclean-generic distclean-libtool distclean-tags distdir dvi \
dvi-am html html-am info info-am install install-am \
install-binPROGRAMS install-data install-data-am install-dvi \
install-dvi-am install-exec install-exec-am install-exec-hook \
install-html install-html-am install-info install-info-am \
install-libexecPROGRAMS install-man install-pdf install-pdf-am \
install-ps install-ps-am install-sbinPROGRAMS install-strip \
installcheck installcheck-am installdirs maintainer-clean \
maintainer-clean-generic mostlyclean mostlyclean-compile \
mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
tags uninstall uninstall-am uninstall-binPROGRAMS \
uninstall-libexecPROGRAMS uninstall-sbinPROGRAMS
install-exec-hook:
@case ${BINSUBDIR} in \
bin) ODIR=${sbindir} ;; \
sbin) ODIR=${bindir} ;; \
esac; \
test -z "${bin_PROGRAMS}${bin_SCRIPTS}" \
|| for i in ${bin_PROGRAMS} ${bin_SCRIPTS} " "; do \
test ! -f $$ODIR/$$i || echo "*** $$i is also in $$ODIR!"; \
@test -z "${bin_PROGRAMS}${bin_SCRIPTS}" \
|| for i in ${bin_PROGRAMS} ${bin_SCRIPTS} " "; do \
test ! -f ${sbindir}/$$i \
|| echo "*** $$i is also in ${sbindir}!"; \
done
@test -z "${sbin_PROGRAMS}${asbin_SCRIPTS}" \
|| for i in ${sbin_PROGRAMS} ${sbin_SCRIPTS} " "; do \
test ! -f ${bindir}/$$i \
|| echo "*** $$i is also in ${bindir}!"; \
done
#
check-libntp: ../libntp/libntp.a
@echo stamp > $@
../libntp/libntp.a:
cd ../libntp && $(MAKE) $(AM_MAKEFLAGS) libntp.a
$(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
@[ -f $@ ] || \
cp $(top_srcdir)/deps-ver $@
@[ -w $@ ] || \
chmod ug+w $@
@cmp $(top_srcdir)/deps-ver $@ > /dev/null || ( \
$(MAKE) clean && \
$(MAKE) $(AM_MAKEFLAGS) clean && \
echo -n "Prior $(subdir)/$(DEPDIR) version " && \
cat $@ && \
rm -rf $(DEPDIR) && \
@ -641,17 +843,10 @@ $(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
.) \
./config.status Makefile depfiles \
;; \
..) \
cd .. && \
./config.status $(subdir)/Makefile depfiles && \
cd $(subdir) \
;; \
*) \
echo 'Fatal: depsver.mf Automake fragment limited' \
'to immediate subdirectories.' && \
echo "top_builddir: $(top_builddir)" && \
echo "subdir: $(subdir)" && \
exit 1 \
cd "$(top_builddir)" && \
./config.status $(subdir)/Makefile depfiles && \
cd $(subdir) \
;; \
esac && \
echo -n "Cleaned $(subdir)/$(DEPDIR) version " && \
@ -660,7 +855,7 @@ $(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
cp $(top_srcdir)/deps-ver $@
.deps-ver: $(top_srcdir)/deps-ver
@[ ! -d $(DEPDIR) ] || $(MAKE) $(DEPDIR)/deps-ver
@[ ! -d $(DEPDIR) ] || $(MAKE) $(AM_MAKEFLAGS) $(DEPDIR)/deps-ver
@touch $@
#

16
bincheck.mf
View File

@ -3,13 +3,15 @@
# subdir to warn folks if there is another version there.
install-exec-hook:
@case ${BINSUBDIR} in \
bin) ODIR=${sbindir} ;; \
sbin) ODIR=${bindir} ;; \
esac; \
test -z "${bin_PROGRAMS}${bin_SCRIPTS}" \
|| for i in ${bin_PROGRAMS} ${bin_SCRIPTS} " "; do \
test ! -f $$ODIR/$$i || echo "*** $$i is also in $$ODIR!"; \
@test -z "${bin_PROGRAMS}${bin_SCRIPTS}" \
|| for i in ${bin_PROGRAMS} ${bin_SCRIPTS} " "; do \
test ! -f ${sbindir}/$$i \
|| echo "*** $$i is also in ${sbindir}!"; \
done
@test -z "${sbin_PROGRAMS}${asbin_SCRIPTS}" \
|| for i in ${sbin_PROGRAMS} ${sbin_SCRIPTS} " "; do \
test ! -f ${bindir}/$$i \
|| echo "*** $$i is also in ${bindir}!"; \
done
#

90
bootstrap
View File

@ -29,7 +29,8 @@
set -e
scripts/genver || { echo scripts/genver failed ; exit 1; }
(cd sntp && ../scripts/build/genver) || {
echo scripts/build/genver failed ; exit 1; }
# autoreconf says:
# The environment variables AUTOCONF, AUTOHEADER, AUTOMAKE, ACLOCAL,
@ -37,17 +38,17 @@ scripts/genver || { echo scripts/genver failed ; exit 1; }
AUTORECONF=${AUTORECONF:-autoreconf}
case `hostname` in
pogo.udel.edu)
if fgrep -q 4.2.4 version.m4; then
AUTOCONF=autoconf-2.59
AUTOHEADER=autoheader-2.59
AUTOMAKE=automake-1.9
ACLOCAL=aclocal-1.9
export AUTOCONF AUTOHEADER AUTOMAKE ACLOCAL
fi
;;
esac
# case `hostname` in
# pogo.udel.edu)
# if fgrep -q 4.2.4 sntp/m4/version.m4; then
# AUTOCONF=autoconf-2.59
# AUTOHEADER=autoheader-2.59
# AUTOMAKE=automake-1.9
# ACLOCAL=aclocal-1.9
# export AUTOCONF AUTOHEADER AUTOMAKE ACLOCAL
# fi
# ;;
# esac
# 20060629: HMS: Let's try checking in libopts and the autogen-generated files
## The copy for ntp...
@ -80,22 +81,23 @@ prog_opt_files=`grep -l '^prog.name' $def_files`
## Non-AutoGen stuff
for i in autogen-version.def version.def version.texi
do
cmp -s include/$i sntp/$i || cp -fp include/$i sntp/$i
done
# touch the stuff generated by the opt files
l=
lh=
li=
for f in ${prog_opt_files}
do
f=`echo $f | sed -e 's/-opts.def//'`
l=
lh=
for i in `ls -1 $f*`
f=`echo $f | sed -e 's/-opts.def//' -e 's/.def//'`
dfi=`dirname $f`
dfi=`echo $dfi | sed -e 's:$:/invoke-*:'`
for i in `ls -1 $f* $dfi`
do
case "$i" in
*.c|*.h|*.1|*.texi|*.menu)
*invoke-*)
li="$li $i"
;;
*.c|*.h|*.[1-9]*man|*.[1-9]*mdoc|*.man.in|*.mdoc.in|*-opts|*.texi|*.menu)
l="$l $i"
;;
*.html)
@ -103,12 +105,27 @@ do
;;
esac
done
case "$l:$lh" in
':') ;;
*) touch $l $lh
;;
esac
done
case "$l" in
'') ;;
*) touch $l
echo "Touching <$l>"
sleep 1
;;
esac
case "$li" in
'') ;;
*) touch $li
echo "Touching <$li>"
sleep 1
;;
esac
case "$lh" in
'') ;;
*) touch $lh
echo "Touching <$lh>"
;;
esac
## EOAutoGen stuff
@ -122,8 +139,23 @@ touch ntpd/ntp_parser.[ch] ntpd/keyword-gen-utd ntpd/ntp_keyword.h
cp bincheck.mf sntp/
cp depsver.mf sntp/
${AUTORECONF} -i -v --no-recursive "$@"
${AUTORECONF} -i -v "$@"
# Because some systems do not support 'test a -nt b'
case `ls -1tr config.h.in aclocal.m4 | tail -1` in
aclocal.m4) touch config.h.in ;;
esac
case `ls -1tr sntp/config.h.in sntp/aclocal.m4 | tail -1` in
sntp/aclocal.m4) touch sntp/config.h.in ;;
esac
case `ls -1tr sntp/libevent/config.h.in sntp/libevent/aclocal.m4 | tail -1` in
sntp/libevent/aclocal.m4) touch sntp/libevent/config.h.in ;;
esac
# DH: 20110118: Due to our workaround for the AM_COND_IF bug that was
# triggering the buggy recursive autoreconf, we can once again use a
# single autoreconf invocation. See
# http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7860
# DH: 20101120: We are back to a single copy of libopts, and
# once again it seems we need to run autoreconf in sntp after
# the top-level run to get a correct sntp/libopts/Makefile.in.
@ -136,4 +168,4 @@ ${AUTORECONF} -i -v --no-recursive "$@"
## we get the correct srcdir path in sntp/libopts/Makefile.in
#rm -rf sntp/autom4te.cache
#
(cd sntp && ${AUTORECONF} -i -v "$@")
# (cd sntp && ${AUTORECONF} -i -v "$@")

39
build
View File

@ -30,18 +30,21 @@ esac
#set -e
#set -x
# scripts/cvo.sh invokes config.guess, and we want it to use the copy
# in the top directory (alongside build) if there's not another
# config.guess earlier on the path, so we invoke it using env to append
# . to the PATH.
if [ ! -r sntp/libevent/build-aux/config.guess ] ; then
echo "Error: bootstrap required." 1>&2 && exit 1
fi
CVO=`env PATH="$PATH:." scripts/cvo.sh @cvo@`
# sntp/scripts/cvo.sh invokes config.guess, and we want it to use the copy
# in the build-aux directory if there's not another config.guess earlier
# on the path, so we invoke it using env to append to the PATH.
CVO=`env PATH="$PATH:./sntp/libevent/build-aux" sntp/scripts/cvo.sh @cvo@`
case "$CVO" in
*-*-*-*) echo "scripts/cvo.sh returned <$CVO>, which makes no sense to me."
*-*-*-*) echo "sntp/scripts/cvo.sh returned <$CVO>, which makes no sense to me."
exit 1
;;
*-*-*) ;;
*) echo "scripts/cvo.sh returned <$CVO>, which makes no sense to me."
*) echo "sntp/scripts/cvo.sh returned <$CVO>, which makes no sense to me."
exit 1
;;
esac
@ -114,7 +117,7 @@ case "$CC" in
;;
esac
BDIR="$BASEDIR$KEYSUF$CCSUF"
BDIR="$BASEDIR$KEYSUF$CCSUF"
[ -d "$BDIR" ] || mkdir $BDIR
[ -f "$BDIR/.buildcvo" ] || echo $CVO > $BDIR/.buildcvo
@ -159,20 +162,28 @@ if [ -z "$TEST" ] ; then
fi
fi
CONFIGURE="../configure --cache-file=../config.cache-$IAM$CCSUF $CONFIG_ARGS"
CONFIGURE="../configure --cache-file=../config.cache-$IAM$KEYSUF$CCSUF $CONFIG_ARGS"
( # This sequence of commands is logged to make.log.
# If config.status is newer than ../configure, and the same
# is true for sntp, we do not need to re-run configure.
# For libevent, the twist is we may not be configuring the
# tearoff, so only act if its config.status exists.
# Solaris /bin/sh doesn't grok -nt.
( "$TEST" config.status -nt ../configure &&
$TEST sntp/config.status -nt ../sntp/configure ) ||
"$TEST" sntp/config.status -nt ../sntp/configure &&
( "$TEST" '!' -f sntp/libevent/config.status ||
"$TEST" sntp/libevent/config.status -nt ../sntp/libevent/configure ) ) ||
"$NICEB" -7 $CONFIGURE
"$NICEB" -5 ./config.status &&
( cd sntp && "$NICEB" -5 ./config.status ) &&
"$NICEB" -14 ${MAKE-make} &&
"$NICEB" -11 ${MAKE-make} check
"$TEST" Makefile -nt config.status ||
"$NICEB" -5 ./config.status
"$TEST" sntp/Makefile -nt sntp/config.status ||
( cd sntp && "$NICEB" -5 ./config.status )
"$TEST" '!' -f sntp/libevent/Makefile ||
"$TEST" sntp/libevent/Makefile -nt sntp/libevent/config.status ||
( cd sntp/libevent && "$NICEB" -5 ./config.status )
"$NICEB" -14 ${MAKE-make} && "$NICEB" -11 ${MAKE-make} check
) > $LOGF 2>&1
EXITCODE=$?

14
check-libopts.mf Normal file
View File

@ -0,0 +1,14 @@
## check-libopts.mf - automake fragment
##
## If we are not using the tearoff libopts, we won't be
## building its libopts.la, so the submake is allowed
## to fail.
BUILT_SOURCES += check-libopts
CLEANFILES += check-libopts
check-libopts: ../sntp/libopts/libopts.la
@echo stamp > $@
../sntp/libopts/libopts.la:
-cd ../sntp/libopts && $(MAKE) $(AM_MAKEFLAGS) libopts.la

29
clockstuff/Makefile.am
View File

@ -1,22 +1,17 @@
#AUTOMAKE_OPTIONS = ../ansi2knr no-dependencies
AUTOMAKE_OPTIONS =
noinst_PROGRAMS = @PROPDELAY@ @CHUTEST@ @CLKTEST@
EXTRA_PROGRAMS = propdelay chutest clktest
noinst_PROGRAMS = @PROPDELAY@ @CHUTEST@
EXTRA_PROGRAMS = propdelay chutest
AM_CFLAGS = $(CFLAGS_NTP)
AM_CPPFLAGS = $(NTP_INCS)
AM_CPPFLAGS += $(CPPFLAGS_NTP)
LDADD = ../libntp/libntp.a $(LDADD_LIBNTP) $(LIBM) $(PTHREAD_LIBS)
propdelay_LDADD = $(LDADD)
INCLUDES = -I$(top_srcdir)/include
# We need -lm (and perhaps $(COMPAT) for propdelay, -lntp for {chu,clk}test
propdelay_LDADD = -lm ../libntp/libntp.a
chutest_LDADD = ../libntp/libntp.a
clktest_LDADD = ../libntp/libntp.a
ETAGS_ARGS = Makefile.am
#EXTRA_DIST = TAGS
BUILT_SOURCES =
CLEANFILES =
# clktest-opts.def wants ../include/copyright.def ../include/homerc.def
chutest$(EXEEXT): ../libntp/libntp.a
clktest$(EXEEXT): ../libntp/libntp.a
include $(top_srcdir)/sntp/check-libntp.mf
include $(top_srcdir)/depsver.mf
include $(top_srcdir)/includes.mf

282
clockstuff/Makefile.in
View File

@ -34,22 +34,47 @@ PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
EXTRA_PROGRAMS = propdelay$(EXEEXT) chutest$(EXEEXT) clktest$(EXEEXT)
EXTRA_PROGRAMS = propdelay$(EXEEXT) chutest$(EXEEXT)
DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
$(top_srcdir)/depsver.mf
$(top_srcdir)/depsver.mf $(top_srcdir)/includes.mf \
$(top_srcdir)/sntp/check-libntp.mf
subdir = clockstuff
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/sntp/libopts/m4/libopts.m4 \
$(top_srcdir)/m4/define_dir.m4 $(top_srcdir)/m4/libtool.m4 \
$(top_srcdir)/m4/ltoptions.m4 $(top_srcdir)/m4/ltsugar.m4 \
$(top_srcdir)/m4/ltversion.m4 $(top_srcdir)/m4/lt~obsolete.m4 \
$(top_srcdir)/m4/ntp_cacheversion.m4 \
$(top_srcdir)/m4/ntp_dir_sep.m4 \
$(top_srcdir)/m4/ntp_lineeditlibs.m4 \
$(top_srcdir)/m4/ntp_openssl.m4 \
$(top_srcdir)/m4/ntp_vpathhack.m4 \
$(top_srcdir)/m4/os_cflags.m4 $(top_srcdir)/version.m4 \
$(top_srcdir)/configure.ac
$(top_srcdir)/sntp/libopts/m4/stdnoreturn.m4 \
$(top_srcdir)/sntp/libevent/m4/openldap-thread-check.m4 \
$(top_srcdir)/sntp/libevent/m4/openldap.m4 \
$(top_srcdir)/sntp/m4/define_dir.m4 \
$(top_srcdir)/sntp/m4/hms_search_lib.m4 \
$(top_srcdir)/sntp/m4/libtool.m4 \
$(top_srcdir)/sntp/m4/ltoptions.m4 \
$(top_srcdir)/sntp/m4/ltsugar.m4 \
$(top_srcdir)/sntp/m4/ltversion.m4 \
$(top_srcdir)/sntp/m4/lt~obsolete.m4 \
$(top_srcdir)/sntp/m4/ntp_cacheversion.m4 \
$(top_srcdir)/sntp/m4/ntp_compiler.m4 \
$(top_srcdir)/sntp/m4/ntp_crosscompile.m4 \
$(top_srcdir)/sntp/m4/ntp_crypto_rand.m4 \
$(top_srcdir)/sntp/m4/ntp_debug.m4 \
$(top_srcdir)/sntp/m4/ntp_dir_sep.m4 \
$(top_srcdir)/sntp/m4/ntp_facilitynames.m4 \
$(top_srcdir)/sntp/m4/ntp_googletest.m4 \
$(top_srcdir)/sntp/m4/ntp_ipv6.m4 \
$(top_srcdir)/sntp/m4/ntp_lib_m.m4 \
$(top_srcdir)/sntp/m4/ntp_libevent.m4 \
$(top_srcdir)/sntp/m4/ntp_libntp.m4 \
$(top_srcdir)/sntp/m4/ntp_lineeditlibs.m4 \
$(top_srcdir)/sntp/m4/ntp_locinfo.m4 \
$(top_srcdir)/sntp/m4/ntp_openssl.m4 \
$(top_srcdir)/sntp/m4/ntp_pkg_config.m4 \
$(top_srcdir)/sntp/m4/ntp_prog_cc.m4 \
$(top_srcdir)/sntp/m4/ntp_rlimit.m4 \
$(top_srcdir)/sntp/m4/ntp_sntp.m4 \
$(top_srcdir)/sntp/m4/ntp_ver_suffix.m4 \
$(top_srcdir)/sntp/m4/ntp_vpathhack.m4 \
$(top_srcdir)/sntp/m4/os_cflags.m4 \
$(top_srcdir)/sntp/m4/snprintf.m4 \
$(top_srcdir)/sntp/m4/version.m4 $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
mkinstalldirs = $(install_sh) -d
@ -59,46 +84,76 @@ CONFIG_CLEAN_VPATH_FILES =
PROGRAMS = $(noinst_PROGRAMS)
chutest_SOURCES = chutest.c
chutest_OBJECTS = chutest.$(OBJEXT)
chutest_DEPENDENCIES = ../libntp/libntp.a
clktest_SOURCES = clktest.c
clktest_OBJECTS = clktest.$(OBJEXT)
clktest_DEPENDENCIES = ../libntp/libntp.a
chutest_LDADD = $(LDADD)
am__DEPENDENCIES_1 =
chutest_DEPENDENCIES = ../libntp/libntp.a $(am__DEPENDENCIES_1) \
$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
AM_V_lt = $(am__v_lt_$(V))
am__v_lt_ = $(am__v_lt_$(AM_DEFAULT_VERBOSITY))
am__v_lt_0 = --silent
propdelay_SOURCES = propdelay.c
propdelay_OBJECTS = propdelay.$(OBJEXT)
propdelay_DEPENDENCIES = ../libntp/libntp.a
am__DEPENDENCIES_2 = ../libntp/libntp.a $(am__DEPENDENCIES_1) \
$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
propdelay_DEPENDENCIES = $(am__DEPENDENCIES_2)
DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
depcomp = $(SHELL) $(top_srcdir)/depcomp
depcomp = $(SHELL) $(top_srcdir)/sntp/libevent/build-aux/depcomp
am__depfiles_maybe = depfiles
am__mv = mv -f
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CFLAGS) $(CFLAGS)
AM_V_CC = $(am__v_CC_$(V))
am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))
am__v_CC_0 = @echo " CC " $@;
AM_V_at = $(am__v_at_$(V))
am__v_at_ = $(am__v_at_$(AM_DEFAULT_VERBOSITY))
am__v_at_0 = @
CCLD = $(CC)
LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@
SOURCES = chutest.c clktest.c propdelay.c
DIST_SOURCES = chutest.c clktest.c propdelay.c
LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
$(AM_LDFLAGS) $(LDFLAGS) -o $@
AM_V_CCLD = $(am__v_CCLD_$(V))
am__v_CCLD_ = $(am__v_CCLD_$(AM_DEFAULT_VERBOSITY))
am__v_CCLD_0 = @echo " CCLD " $@;
AM_V_GEN = $(am__v_GEN_$(V))
am__v_GEN_ = $(am__v_GEN_$(AM_DEFAULT_VERBOSITY))
am__v_GEN_0 = @echo " GEN " $@;
SOURCES = chutest.c propdelay.c
DIST_SOURCES = chutest.c propdelay.c
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ALLOCA = @ALLOCA@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
AR = @AR@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BINSUBDIR = @BINSUBDIR@
CALC_TICKADJ_DB = @CALC_TICKADJ_DB@
CALC_TICKADJ_DL = @CALC_TICKADJ_DL@
CALC_TICKADJ_DS = @CALC_TICKADJ_DS@
CALC_TICKADJ_MS = @CALC_TICKADJ_MS@
CALC_TICKADJ_NI = @CALC_TICKADJ_NI@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CFLAGS_NTP = @CFLAGS_NTP@
CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CONFIG_SHELL = @CONFIG_SHELL@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CPPFLAGS_NTP = @CPPFLAGS_NTP@
CXX = @CXX@
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
CXXFLAGS = @CXXFLAGS@
CYGPATH_W = @CYGPATH_W@
DCFD = @DCFD@
DEFS = @DEFS@
@ -110,21 +165,31 @@ ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
EDITLINE_LIBS = @EDITLINE_LIBS@
EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
FGREP = @FGREP@
GREP = @GREP@
GTEST_CONFIG = @GTEST_CONFIG@
GTEST_CPPFLAGS = @GTEST_CPPFLAGS@
GTEST_CXXFLAGS = @GTEST_CXXFLAGS@
GTEST_LDFLAGS = @GTEST_LDFLAGS@
GTEST_LIBS = @GTEST_LIBS@
HAVE_INLINE = @HAVE_INLINE@
HAVE_RLIMIT_MEMLOCK = @HAVE_RLIMIT_MEMLOCK@
HAVE_RLIMIT_STACK = @HAVE_RLIMIT_STACK@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LCRYPTO = @LCRYPTO@
LD = @LD@
LDADD_LIBNTP = @LDADD_LIBNTP@
LDADD_NLIST = @LDADD_NLIST@
LDADD_NTP = @LDADD_NTP@
LDFLAGS = @LDFLAGS@
LDFLAGS_NTP = @LDFLAGS_NTP@
LIBISC_PTHREADS_NOTHREADS = @LIBISC_PTHREADS_NOTHREADS@
LIBM = @LIBM@
LIBOBJS = @LIBOBJS@
LIBOPTS_CFLAGS = @LIBOPTS_CFLAGS@
LIBOPTS_DIR = @LIBOPTS_DIR@
@ -132,6 +197,7 @@ LIBOPTS_LDADD = @LIBOPTS_LDADD@
LIBPARSE = @LIBPARSE@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LIBTOOL_DEPS = @LIBTOOL_DEPS@
LIPO = @LIPO@
LN_S = @LN_S@
LSCF = @LSCF@
@ -150,14 +216,68 @@ MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
MANIFEST_TOOL = @MANIFEST_TOOL@
MANTAGFMT = @MANTAGFMT@
MKDIR_P = @MKDIR_P@
NM = @NM@
NMEDIT = @NMEDIT@
NTPDATE_DB = @NTPDATE_DB@
NTPDATE_DL = @NTPDATE_DL@
NTPDATE_DS = @NTPDATE_DS@
NTPDATE_MS = @NTPDATE_MS@
NTPDATE_NI = @NTPDATE_NI@
NTPDC_DB = @NTPDC_DB@
NTPDC_DL = @NTPDC_DL@
NTPDC_DS = @NTPDC_DS@
NTPDC_MS = @NTPDC_MS@
NTPDC_NI = @NTPDC_NI@
NTPDSIM_DB = @NTPDSIM_DB@
NTPDSIM_DL = @NTPDSIM_DL@
NTPDSIM_DS = @NTPDSIM_DS@
NTPDSIM_MS = @NTPDSIM_MS@
NTPDSIM_NI = @NTPDSIM_NI@
NTPD_DB = @NTPD_DB@
NTPD_DL = @NTPD_DL@
NTPD_DS = @NTPD_DS@
NTPD_MS = @NTPD_MS@
NTPD_NI = @NTPD_NI@
NTPQ_DB = @NTPQ_DB@
NTPQ_DL = @NTPQ_DL@
NTPQ_DS = @NTPQ_DS@
NTPQ_MS = @NTPQ_MS@
NTPQ_NI = @NTPQ_NI@
NTPSNMPD_DB = @NTPSNMPD_DB@
NTPSNMPD_DL = @NTPSNMPD_DL@
NTPSNMPD_DS = @NTPSNMPD_DS@
NTPSNMPD_MS = @NTPSNMPD_MS@
NTPSNMPD_NI = @NTPSNMPD_NI@
NTPSWEEP_DB = @NTPSWEEP_DB@
NTPSWEEP_DL = @NTPSWEEP_DL@
NTPSWEEP_DS = @NTPSWEEP_DS@
NTPSWEEP_MS = @NTPSWEEP_MS@
NTPSWEEP_NI = @NTPSWEEP_NI@
NTPTIME_DB = @NTPTIME_DB@
NTPTIME_DL = @NTPTIME_DL@
NTPTIME_DS = @NTPTIME_DS@
NTPTIME_MS = @NTPTIME_MS@
NTPTIME_NI = @NTPTIME_NI@
NTPTRACE_DB = @NTPTRACE_DB@
NTPTRACE_DL = @NTPTRACE_DL@
NTPTRACE_DS = @NTPTRACE_DS@
NTPTRACE_MS = @NTPTRACE_MS@
NTPTRACE_NI = @NTPTRACE_NI@
NTP_KEYGEN_DB = @NTP_KEYGEN_DB@
NTP_KEYGEN_DL = @NTP_KEYGEN_DL@
NTP_KEYGEN_DS = @NTP_KEYGEN_DS@
NTP_KEYGEN_MS = @NTP_KEYGEN_MS@
NTP_KEYGEN_NI = @NTP_KEYGEN_NI@
NTP_KEYSDIR = @NTP_KEYSDIR@
NTP_WAIT_DB = @NTP_WAIT_DB@
NTP_WAIT_DL = @NTP_WAIT_DL@
NTP_WAIT_DS = @NTP_WAIT_DS@
NTP_WAIT_MS = @NTP_WAIT_MS@
NTP_WAIT_NI = @NTP_WAIT_NI@
OBJDUMP = @OBJDUMP@
OBJEXT = @OBJEXT@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
OPENSSL_LIB = @OPENSSL_LIB@
OTOOL = @OTOOL@
OTOOL64 = @OTOOL64@
PACKAGE = @PACKAGE@
@ -170,10 +290,12 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_NET_SNMP_CONFIG = @PATH_NET_SNMP_CONFIG@
PATH_PERL = @PATH_PERL@
PATH_SEPARATOR = @PATH_SEPARATOR@
PATH_SH = @PATH_SH@
PATH_TEST = @PATH_TEST@
PERLLIBDIR = @PERLLIBDIR@
PKG_CONFIG = @PKG_CONFIG@
POSIX_SHELL = @POSIX_SHELL@
PROPDELAY = @PROPDELAY@
PTHREAD_LIBS = @PTHREAD_LIBS@
RANLIB = @RANLIB@
SED = @SED@
SET_MAKE = @SET_MAKE@
@ -181,9 +303,27 @@ SHELL = @SHELL@
SNMP_CFLAGS = @SNMP_CFLAGS@
SNMP_CPPFLAGS = @SNMP_CPPFLAGS@
SNMP_LIBS = @SNMP_LIBS@
SNTP = @SNTP@
SNTP_DB = @SNTP_DB@
SNTP_DL = @SNTP_DL@
SNTP_DS = @SNTP_DS@
SNTP_MS = @SNTP_MS@
SNTP_NI = @SNTP_NI@
STDNORETURN_H = @STDNORETURN_H@
STRIP = @STRIP@
TESTDCF = @TESTDCF@
TICKADJ_DB = @TICKADJ_DB@
TICKADJ_DL = @TICKADJ_DL@
TICKADJ_DS = @TICKADJ_DS@
TICKADJ_MS = @TICKADJ_MS@
TICKADJ_NI = @TICKADJ_NI@
TIMETRIM_DB = @TIMETRIM_DB@
TIMETRIM_DL = @TIMETRIM_DL@
TIMETRIM_DS = @TIMETRIM_DS@
TIMETRIM_MS = @TIMETRIM_MS@
TIMETRIM_NI = @TIMETRIM_NI@
VERSION = @VERSION@
VER_SUFFIX = @VER_SUFFIX@
YACC = @YACC@
YFLAGS = @YFLAGS@
abs_builddir = @abs_builddir@
@ -192,6 +332,7 @@ abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_AR = @ac_ct_AR@
ac_ct_CC = @ac_ct_CC@
ac_ct_CXX = @ac_ct_CXX@
ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
@ -239,25 +380,22 @@ target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
#AUTOMAKE_OPTIONS = ../ansi2knr no-dependencies
AUTOMAKE_OPTIONS =
noinst_PROGRAMS = @PROPDELAY@ @CHUTEST@ @CLKTEST@
INCLUDES = -I$(top_srcdir)/include
# We need -lm (and perhaps $(COMPAT) for propdelay, -lntp for {chu,clk}test
propdelay_LDADD = -lm ../libntp/libntp.a
chutest_LDADD = ../libntp/libntp.a
clktest_LDADD = ../libntp/libntp.a
ETAGS_ARGS = Makefile.am
#EXTRA_DIST = TAGS
BUILT_SOURCES = .deps-ver
CLEANFILES = .deps-ver
noinst_PROGRAMS = @PROPDELAY@ @CHUTEST@
AM_CFLAGS = $(CFLAGS_NTP)
AM_CPPFLAGS = $(NTP_INCS) $(CPPFLAGS_NTP)
LDADD = ../libntp/libntp.a $(LDADD_LIBNTP) $(LIBM) $(PTHREAD_LIBS)
propdelay_LDADD = $(LDADD)
BUILT_SOURCES = check-libntp .deps-ver
CLEANFILES = check-libntp .deps-ver
NTP_INCS = -I$(top_srcdir)/include -I$(top_srcdir)/lib/isc/include \
-I$(top_srcdir)/lib/isc/$(LIBISC_PTHREADS_NOTHREADS)/include \
-I$(top_srcdir)/lib/isc/unix/include
all: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) all-am
.SUFFIXES:
.SUFFIXES: .c .lo .o .obj
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/depsver.mf $(am__configure_deps)
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/sntp/check-libntp.mf $(top_srcdir)/depsver.mf $(top_srcdir)/includes.mf $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
@ -296,9 +434,12 @@ clean-noinstPROGRAMS:
list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
echo " rm -f" $$list; \
rm -f $$list
chutest$(EXEEXT): $(chutest_OBJECTS) $(chutest_DEPENDENCIES)
@rm -f chutest$(EXEEXT)
$(AM_V_CCLD)$(LINK) $(chutest_OBJECTS) $(chutest_LDADD) $(LIBS)
propdelay$(EXEEXT): $(propdelay_OBJECTS) $(propdelay_DEPENDENCIES)
@rm -f propdelay$(EXEEXT)
$(LINK) $(propdelay_OBJECTS) $(propdelay_LDADD) $(LIBS)
$(AM_V_CCLD)$(LINK) $(propdelay_OBJECTS) $(propdelay_LDADD) $(LIBS)
mostlyclean-compile:
-rm -f *.$(OBJEXT)
@ -307,26 +448,28 @@ distclean-compile:
-rm -f *.tab.c
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/chutest.Po@am__quote@
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/clktest.Po@am__quote@
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/propdelay.Po@am__quote@
.c.o:
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_TRUE@ $(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_FALSE@ $(AM_V_CC) @AM_BACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c $<
.c.obj:
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_TRUE@ $(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@am__fastdepCC_FALSE@ $(AM_V_CC) @AM_BACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c `$(CYGPATH_W) '$<'`
.c.lo:
@am__fastdepCC_TRUE@ $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
@am__fastdepCC_TRUE@ $(AM_V_CC)$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
@am__fastdepCC_FALSE@ $(AM_V_CC) @AM_BACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(LTCOMPILE) -c -o $@ $<
@ -539,18 +682,18 @@ uninstall-am:
pdf pdf-am ps ps-am tags uninstall uninstall-am
# clktest-opts.def wants ../include/copyright.def ../include/homerc.def
check-libntp: ../libntp/libntp.a
@echo stamp > $@
chutest$(EXEEXT): ../libntp/libntp.a
clktest$(EXEEXT): ../libntp/libntp.a
../libntp/libntp.a:
cd ../libntp && $(MAKE) $(AM_MAKEFLAGS) libntp.a
$(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
@[ -f $@ ] || \
cp $(top_srcdir)/deps-ver $@
@[ -w $@ ] || \
chmod ug+w $@
@cmp $(top_srcdir)/deps-ver $@ > /dev/null || ( \
$(MAKE) clean && \
$(MAKE) $(AM_MAKEFLAGS) clean && \
echo -n "Prior $(subdir)/$(DEPDIR) version " && \
cat $@ && \
rm -rf $(DEPDIR) && \
@ -559,17 +702,10 @@ $(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
.) \
./config.status Makefile depfiles \
;; \
..) \
cd .. && \
./config.status $(subdir)/Makefile depfiles && \
cd $(subdir) \
;; \
*) \
echo 'Fatal: depsver.mf Automake fragment limited' \
'to immediate subdirectories.' && \
echo "top_builddir: $(top_builddir)" && \
echo "subdir: $(subdir)" && \
exit 1 \
cd "$(top_builddir)" && \
./config.status $(subdir)/Makefile depfiles && \
cd $(subdir) \
;; \
esac && \
echo -n "Cleaned $(subdir)/$(DEPDIR) version " && \
@ -578,7 +714,7 @@ $(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
cp $(top_srcdir)/deps-ver $@
.deps-ver: $(top_srcdir)/deps-ver
@[ ! -d $(DEPDIR) ] || $(MAKE) $(DEPDIR)/deps-ver
@[ ! -d $(DEPDIR) ] || $(MAKE) $(AM_MAKEFLAGS) $(DEPDIR)/deps-ver
@touch $@
#

18
clockstuff/README
View File

@ -1,19 +1,14 @@
README file for directory ./clockstuff of the NTP Version 4 distribution
This directory contains the sources for utility programs designed to
support radio clocks. The chutest.c and clktest.c are desgined to
test the chu_clk and tty_clk line disciplines and STREAMS modules in
the ../kernel directory.
support radio clocks. chutest.c is desgined to test the depredated
chu_clk line discipline or STREAMS module and can also test a CHU
modem in raw mode.
These files have been modified to work with either the line disciplines
or the STREAMS modules. Be sure to define -DSTREAM if appropriate.
These are random bits of things written to help with clocks. You can
make things in here by typing one or more of:
You can make things in here by typing one or more of:
make propdelay (or `make')
make chutest
make clktest
Propdelay computes high frequency propagation delays, given the
longitude and latitude of the transmitter and receiver. Use
@ -24,8 +19,3 @@ Chutest can be used to input and process data from a CHU modem
attached to a serial port. It will use the CHU line discipline
(if installed), or raw mode otherwise. This was used to test
out the initial reduction algorithms, and may not be up to date.
Clktest can be used to test the clock line discipline (CLKLDISC,
it must be available), and to take a look at radio clocks attached to a
serial port.

89
clockstuff/chutest.c
View File

@ -2,36 +2,48 @@
* chutest - test the CHU clock
*/
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#include <stdio.h>
#include <fcntl.h>
#ifdef HAVE_UNISTD_H
# include <unistd.h>
#endif
#ifdef HAVE_STROPTS_H
# include <stropts.h>
#else
# ifdef HAVE_SYS_STROPTS_H
# include <sys/stropts.h>
# endif
#endif
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/file.h>
#include <sgtty.h>
#ifdef HAVE_TERMIOS_H
# include <termios.h>
#else
# ifdef HAVE_SGTTY_H
# include <sgtty.h>
# endif
#endif
#include "../include/ntp_fp.h"
#include "../include/ntp.h"
#include "../include/ntp_unixtime.h"
#ifdef CHULDISC
#ifdef STREAM
# ifdef HAVE_SYS_CHUDEFS_H
#include <sys/chudefs.h>
#endif
#include <stropts.h>
#endif
#endif
#include "ntp_fp.h"
#include "ntp.h"
#include "ntp_unixtime.h"
#include "ntp_calendar.h"
#ifdef CHULDISC
# ifdef HAVE_SYS_CHUDEFS_H
#include <sys/chudefs.h>
#endif
# include <sys/chudefs.h>
# endif
#endif
#ifndef CHULDISC
#ifndef STREAM
#define NCHUCHARS (10)
struct chucode {
@ -41,12 +53,10 @@ struct chucode {
struct timeval codetimes[NCHUCHARS]; /* arrival times */
};
#endif
#endif
#define STREQ(a, b) (*(a) == *(b) && strcmp((a), (b)) == 0)
char *progname;
int debug;
int dofilter = 0; /* set to 1 when we should run filter algorithm */
int showtimes = 0; /* set to 1 when we should show char arrival times */
@ -61,9 +71,14 @@ int usechuldisc = 0; /* set to 1 when CHU line discipline should be used */
struct timeval lasttv;
struct chucode chudata;
extern u_long ustotslo[];
extern u_long ustotsmid[];
extern u_long ustotshi[];
void error(char *fmt, char *s1, char *s2);
void init_chu(void);
int openterm(char *dev);
int process_raw(int s);
int process_ldisc(int s);
void raw_filter(unsigned int c, struct timeval *tv);
void chufilter(struct chucode *chuc, l_fp *rtime);
/*
* main - parse arguments and handle options
@ -77,8 +92,6 @@ main(
int c;
int errflg = 0;
extern int ntp_optind;
extern char *ntp_optarg;
void init_chu();
progname = argv[0];
while ((c = ntp_getopt(argc, argv, "cdfpt")) != EOF)
@ -261,21 +274,20 @@ process_raw(
/*
* raw_filter - run the line discipline filter over raw data
*/
int
void
raw_filter(
unsigned int c,
struct timeval *tv
)
{
static struct timeval diffs[10] = { 0 };
static struct timeval diffs[10];
struct timeval diff;
l_fp ts;
void chufilter();
if ((c & 0xf) > 9 || ((c>>4)&0xf) > 9) {
if (debug)
(void) fprintf(stderr,
"character %02x failed BCD test\n");
"character %02x failed BCD test\n", c);
chudata.ncodechars = 0;
return;
}
@ -496,14 +508,6 @@ static u_long yearstart;
extern u_long current_time;
extern struct event timerqueue[];
/*
* Time conversion tables imported from the library
*/
extern u_long ustotslo[];
extern u_long ustotsmid[];
extern u_long ustotshi[];
/*
* init_chu - initialize internal chu driver data
*/
@ -543,10 +547,6 @@ chufilter(
l_fp ts;
int day, hour, minute, second;
static u_char lastcode[NCHUCHARS];
extern u_long calyearstart();
extern char *mfptoa();
void chu_process();
extern char *prettydate();
/*
* We'll skip the checks made in the kernel, but assume they've
@ -632,6 +632,7 @@ chufilter(
* work most of the time.
*/
date_ui = tmp + yearstart;
#define CLOCK_WAYTOOBIG 1000 /* revived from ancient sources */
if (date_ui < (rtime->l_ui + CLOCK_WAYTOOBIG)
&& date_ui > (rtime->l_ui - CLOCK_WAYTOOBIG))
goto codeokay; /* looks good */
@ -640,7 +641,7 @@ chufilter(
* Trouble. Next check is to see if the year rolled over and, if
* so, try again with the new year's start.
*/
date_ui = calyearstart(rtime->l_ui);
date_ui = calyearstart(rtime->l_ui, NULL);
if (date_ui != yearstart) {
yearstart = date_ui;
date_ui += tmp;
@ -666,7 +667,9 @@ chufilter(
* than CLOCK_WAYTOOBIG seconds into the new year.
*/
if ((rtime->l_ui - yearstart) < CLOCK_WAYTOOBIG) {
date_ui = tmp + calyearstart(yearstart - CLOCK_WAYTOOBIG);
date_ui = tmp;
date_ui += calyearstart(yearstart - CLOCK_WAYTOOBIG,
NULL);
if ((rtime->l_ui - date_ui) < CLOCK_WAYTOOBIG)
goto codeokay;
}
@ -676,7 +679,9 @@ chufilter(
* following the year the system is in. Try this one before
* giving up.
*/
date_ui = tmp + calyearstart(yearstart + (400*24*60*60)); /* 400 days */
date_ui = tmp;
date_ui += calyearstart(yearstart + (400 * SECSPERDAY),
NULL);
if ((date_ui - rtime->l_ui) >= CLOCK_WAYTOOBIG) {
printf("Date hopelessly off\n");
return; /* hopeless, let it sync to other peers */

412
clockstuff/clktest.c
View File

@ -1,412 +0,0 @@
/* clktest.c,v 3.1 1993/07/06 01:05:23 jbj Exp
* clktest - test the clock line discipline
*
* usage: clktest -b bps -f -t timeo -s cmd -c char1 -a char2 /dev/whatever
*/
#include "clktest-opts.h"
#define STREQ(a, b) (*(a) == *(b) && strcmp((a), (b)) == 0)
#if defined(ULT_2_0_SUCKS)
#ifndef sigmask
#define sigmask(m) (1<<(m))
#endif
#endif
#ifndef STREAM
# ifndef CLKLDISC
CLOCK_LINE_DISCIPLINE_NEEDED_BY_THIS_PROGRAM;
# endif
#else
# ifdef CLKLDISC
ONLY_ONE_CLOCK_LINE_DISCIPLINE_FOR_THIS_PROGRAM;
# endif
#endif
/*
* Mask for blocking SIGIO and SIGALRM
*/
#define BLOCKSIGMASK (sigmask(SIGIO)|sigmask(SIGALRM))
#define progname clktestOptions.pzProgName
struct timeval timeout = { 0 };
char *cmd = NULL;
int cmdlen;
#ifdef CLKLDISC
u_long magic1 = DEFMAGIC;
u_long magic2 = DEFMAGIC;
#endif
int speed = B9600;
int ttflags = RAW|EVENP|ODDP;
volatile int wasalarmed;
volatile int iosig;
struct timeval lasttv;
extern u_long ustotslo[];
extern u_long ustotsmid[];
extern u_long ustotshi[];
int alarming();
int ioready();
/*
* main - parse arguments and handle options
*/
int
main(
int argc,
char *argv[]
)
{
int fd;
struct sgttyb ttyb;
struct itimerval itimer;
#ifdef STREAM
magic[0] = 0;
#endif
{
int ct = optionProcess( &clktestOptions, argc, argv );
if (HAVE_OPT(COMMAND) && (strlen(OPT_ARG(COMMAND)) == 0)) {
fputs( "The command option string must not be empty\n", stderr );
USAGE( EXIT_FAILURE );
}
if ((argc -= ct) != 1) {
fputs( "Missing tty device name\n", stderr );
USAGE( EXIT_FAILURE );
}
argv += ct;
}
#ifdef STREAM
if (!strlen(magic))
strcpy(magic,DEFMAGIC);
#endif
fd = open(*argv, HAVE_OPT(TIMEOUT) ? O_RDWR : O_RDONLY, 0777);
if (fd == -1) {
fprintf(stderr, "%s: open(%s): ", progname, *argv);
perror("");
exit(1);
}
if (ioctl(fd, TIOCEXCL, (char *)0) < 0) {
(void) fprintf(stderr, "%s: ioctl(TIOCEXCL): ", progname);
perror("");
exit(1);
}
/*
* If we have the clock discipline, set the port to raw. Otherwise
* we run cooked.
*/
ttyb.sg_ispeed = ttyb.sg_ospeed = speed;
#ifdef CLKLDISC
ttyb.sg_erase = (char)magic1;
ttyb.sg_kill = (char)magic2;
#endif
ttyb.sg_flags = (short)ttflags;
if (ioctl(fd, TIOCSETP, (char *)&ttyb) < 0) {
(void) fprintf(stderr, "%s: ioctl(TIOCSETP): ", progname);
perror("");
exit(1);
}
if (fcntl(fd, F_SETOWN, getpid()) == -1) {
(void) fprintf(stderr, "%s: fcntl(F_SETOWN): ", progname);
perror("");
exit(1);
}
#ifdef CLKLDISC
{
int ldisc;
ldisc = CLKLDISC;
if (ioctl(fd, TIOCSETD, (char *)&ldisc) < 0) {
(void) fprintf(stderr, "%s: ioctl(TIOCSETD): ", progname);
perror("");
exit(1);
}
}
#endif
#ifdef STREAM
if (ioctl(fd, I_POP, 0) >=0 ) ;
if (ioctl(fd, I_PUSH, "clk") < 0) {
(void) fprintf(stderr, "%s: ioctl(I_PUSH): ", progname);
perror("");
exit(1);
}
if (ioctl(fd, CLK_SETSTR, magic) < 0) {
(void) fprintf(stderr, "%s: ioctl(CLK_SETSTR): ", progname);
perror("");
exit(1);
}
#endif
(void) gettimeofday(&lasttv, (struct timezone *)0);
if (HAVE_OPT(TIMEOUT)) {
/*
* set non-blocking, async I/O on the descriptor
*/
iosig = 0;
(void) signal(SIGIO, ioready);
if (fcntl(fd, F_SETFL, FNDELAY|FASYNC) < 0) {
(void) fprintf(stderr, "%s: fcntl(F_SETFL): ",
progname);
perror("");
exit(1);
}
/*
* Set up the alarm interrupt.
*/
wasalarmed = 0;
(void) signal(SIGALRM, alarming);
timeout.tv_sec = OPT_VALUE_TIMEOUT;
itimer.it_interval = itimer.it_value = timeout;
setitimer(ITIMER_REAL, &itimer, (struct itimerval *)0);
doboth(fd);
}
doioonly(fd);
}
/*
* doboth - handle both I/O and alarms via SIGIO
*/
int
doboth(
int fd
)
{
int n;
int sawalarm;
int sawiosig;
int omask;
fd_set fds;
struct timeval tvzero;
sawalarm = 0;
sawiosig = 0;
FD_ZERO(&fds);
for (;;) {
omask = sigblock(BLOCKSIGMASK);
if (wasalarmed) { /* alarmed? */
sawalarm = 1;
wasalarmed = 0;
}
if (iosig) {
sawiosig = 1;
iosig = 0;
}
if (!sawalarm && !sawiosig) {
/*
* Nothing to do. Wait for something.
*/
sigpause(omask);
if (wasalarmed) { /* alarmed? */
sawalarm = 1;
wasalarmed = 0;
}
if (iosig) {
sawiosig = 1;
iosig = 0;
}
}
(void)sigsetmask(omask);
if (sawiosig) {
do {
tvzero.tv_sec = tvzero.tv_usec = 0;
FD_SET(fd, &fds);
n = select(fd+1, &fds, (fd_set *)0,
(fd_set *)0, &tvzero);
if (n > 0)
doio(fd);
} while (n > 0);
if (n == -1) {
(void) fprintf(stderr, "%s: select: ",
progname);
perror("");
exit(1);
}
sawiosig = 0;
}
if (sawalarm) {
doalarm(fd);
sawalarm = 0;
}
}
}
/*
* doioonly - do I/O. This avoids the use of signals
*/
int
doioonly(
int fd
)
{
int n;
fd_set fds;
FD_ZERO(&fds);
for (;;) {
FD_SET(fd, &fds);
n = select(fd+1, &fds, (fd_set *)0, (fd_set *)0,
(struct timeval *)0);
if (n > 0)
doio(fd);
}
}
/*
* doio - read a buffer full of stuff and print it out
*/
int
doio(
int fd
)
{
register char *rp, *rpend;
register char *cp;
register int i;
char raw[512];
struct timeval tv, tvd;
int rlen;
int ind;
char cooked[2049];
static char *digits = "0123456789abcdef";
rlen = read(fd, raw, sizeof(raw));
if (rlen < 0) {
(void) fprintf(stderr, "%s: read(): ", progname);
perror("");
return;
}
if (rlen == 0) {
(void) printf("Zero length read\n");
return;
}
cp = cooked;
rp = raw;
rpend = &raw[rlen];
ind = 0;
while (rp < rpend) {
ind = 1;
if (isprint(*rp))
*cp++ = *rp;
else {
*cp++ = '<';
*cp++ = digits[((*rp)>>4) & 0xf];
*cp++ = digits[*rp & 0xf];
*cp++ = '>';
}
if (
#ifdef CLKLDISC
(*rp == (char)magic1 || *rp == (char)magic2)
#else
( strchr( magic, *rp) != NULL )
#endif
) {
rp++;
ind = 0;
*cp = '\0';
if ((rpend - rp) < sizeof(struct timeval)) {
(void)printf(
"Too little data (%d): %s\n",
rpend-rp, cooked);
return;
}
tv.tv_sec = 0;
for (i = 0; i < 4; i++) {
tv.tv_sec <<= 8;
tv.tv_sec |= ((long)*rp++) & 0xff;
}
tv.tv_usec = 0;
for (i = 0; i < 4; i++) {
tv.tv_usec <<= 8;
tv.tv_usec |= ((long)*rp++) & 0xff;
}
tvd.tv_sec = tv.tv_sec - lasttv.tv_sec;
tvd.tv_usec = tv.tv_usec - lasttv.tv_usec;
if (tvd.tv_usec < 0) {
tvd.tv_usec += 1000000;
tvd.tv_sec--;
}
(void)printf("%lu.%06lu %lu.%06lu %s\n",
tv.tv_sec, tv.tv_usec, tvd.tv_sec, tvd.tv_usec,
cooked);
lasttv = tv;
} else {
rp++;
}
}
if (ind) {
*cp = '\0';
(void)printf("Incomplete data: %s\n", cooked);
}
}
/*
* doalarm - send a string out the port, if we have one.
*/
int
doalarm(
int fd
)
{
int n;
if (! HAVE_OPT(COMMAND))
return;
n = write(fd, cmd, cmdlen);
if (n < 0) {
(void) fprintf(stderr, "%s: write(): ", progname);
perror("");
} else if (n < cmdlen) {
(void) printf("Short write (%d bytes, should be %d)\n",
n, cmdlen);
}
}
/*
* alarming - receive alarm interupt
*/
void
alarming(void)
{
wasalarmed = 1;
}
/*
* ioready - handle SIGIO interrupt
*/
void
ioready(void)
{
iosig = 1;
}

6
clockstuff/propdelay.c
View File

@ -47,6 +47,9 @@
* to find delays to GOES via each of the three satellites.
*/
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#include <stdio.h>
#include <string.h>
@ -115,7 +118,6 @@ int Gflag = 0;
int height;
char *progname;
volatile int debug;
static void doit (double, double, double, double, double, char *);
static double latlong (char *, int);
@ -142,6 +144,8 @@ main(
double lat2, long2;
double lat3, long3;
init_lib();
progname = argv[0];
while ((c = ntp_getopt(argc, argv, "dh:CWG")) != EOF)
switch (c) {

619
config.h.in
View File

File diff suppressed because it is too large Load Diff

24216
configure vendored
View File

File diff suppressed because it is too large Load Diff

2938
configure.ac
View File

File diff suppressed because it is too large Load Diff

2
deps-ver
View File

@ -1 +1 @@
Tue Nov 16 19:50:15 UTC 2010
Fri Dec 30 11:24:57 UTC 2011

17
depsver.mf
View File

@ -4,7 +4,7 @@ $(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
@[ -w $@ ] || \
chmod ug+w $@
@cmp $(top_srcdir)/deps-ver $@ > /dev/null || ( \
$(MAKE) clean && \
$(MAKE) $(AM_MAKEFLAGS) clean && \
echo -n "Prior $(subdir)/$(DEPDIR) version " && \
cat $@ && \
rm -rf $(DEPDIR) && \
@ -13,17 +13,10 @@ $(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
.) \
./config.status Makefile depfiles \
;; \
..) \
cd .. && \
./config.status $(subdir)/Makefile depfiles && \
cd $(subdir) \
;; \
*) \
echo 'Fatal: depsver.mf Automake fragment limited' \
'to immediate subdirectories.' && \
echo "top_builddir: $(top_builddir)" && \
echo "subdir: $(subdir)" && \
exit 1 \
cd "$(top_builddir)" && \
./config.status $(subdir)/Makefile depfiles && \
cd $(subdir) \
;; \
esac && \
echo -n "Cleaned $(subdir)/$(DEPDIR) version " && \
@ -32,7 +25,7 @@ $(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
cp $(top_srcdir)/deps-ver $@
.deps-ver: $(top_srcdir)/deps-ver
@[ ! -d $(DEPDIR) ] || $(MAKE) $(DEPDIR)/deps-ver
@[ ! -d $(DEPDIR) ] || $(MAKE) $(AM_MAKEFLAGS) $(DEPDIR)/deps-ver
@touch $@
BUILT_SOURCES += .deps-ver

1
excludes
View File

@ -1 +0,0 @@
*.obj *.pch *.bsc *.pdb *.sbr nt*.zip *.tar *.gz *.ilk beta*.zip

15
flock-build
View File

@ -52,6 +52,10 @@ esac
# * pogo sparc-sun-solaris2.10
# * rackety freebsd-6.1
if [ ! -r sntp/libevent/build-aux/config.guess ] ; then
echo "Error: bootstrap required." 1>&2 && exit 1
fi
# HMS: we need $PWD because solaris produces /deacon/backroom when
# we are in /backroom and in general there is no /deacon/backroom.
c_d=${PWD:-`pwd`}
@ -59,7 +63,7 @@ c_d=${PWD:-`pwd`}
SIG=`perl -e 'print rand'`
case "$LIST" in
'') LIST="malarky rackety" ;;
'') LIST="pogo" ;;
esac
for i in $LIST
@ -76,8 +80,9 @@ do
case "1" in
0)
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD --without-crypto $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $STD --disable-all-clocks $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD --disable-debugging $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD --without-crypto --enable-c99-snprintf $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $STD --disable-all-clocks --disable-autokey --without-sntp --disable-thread-support $BUILD_ARGS" &
;;
1)
cat > .flockbuild-$i-$SIG <<-ENDQUOT
@ -104,13 +109,13 @@ do
echo \`date -u '+%H:%M:%S'\` $i started build \$COUNT of 4
[ 0 -lt \`expr \$COUNT % $PARALLEL_BUILDS\` ] || wait
./build $SIG $PARSE $STD --without-crypto $BUILD_ARGS &
./build $SIG $PARSE $STD --without-crypto --enable-c99-snprintf $BUILD_ARGS &
COUNT=\`expr \$COUNT + 1\`
echo \`date -u '+%H:%M:%S'\` $i started build \$COUNT of 4
[ 0 -lt \`expr \$COUNT % $PARALLEL_BUILDS\` ] || wait
./build $SIG $STD --disable-all-clocks $BUILD_ARGS &
./build $SIG $STD --disable-all-clocks --disable-autokey --without-sntp --disable-thread-support $BUILD_ARGS &
COUNT=\`expr \$COUNT + 1\`
echo \`date -u '+%H:%M:%S'\` $i started build \$COUNT of 4

50
html/access.html Normal file
View File

@ -0,0 +1,50 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Access Control Support</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
<!--
<style1 {
color: #FF0000;
font-weight: bold;
}
-->
</style>
</head>
<body>
<h3>Access Control Support</h3>
<p><img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a></p>
<p>The skunk watches for intruders and sprays.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:53<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/accopt.txt"></script>
<hr>
<h4>Access Control Support</h4>
<p>The <tt>ntpd</tt> daemon implements a general purpose access control list (ACL) containing address/match entries sorted first by increasing address values and then by increasing mask values. A match occurs when the bitwise AND of the mask and the packet source address is equal to the bitwise AND of the mask and address in the list. The list is searched in order with the last match found defining the restriction flags associated with the entry.</p>
<p>The ACL is specified as a list of <tt>restrict</tt> commands in the following format:</p>
<p><tt>restrict <i>address</i> [mask <i>mask</i>] [<i>flag</i>][...]</tt></p>
<p>The <tt><i>address</i></tt> argument expressed in dotted-quad form is the address of a host or network. Alternatively, the <tt><i>address</i></tt> argument can be a valid host DNS name. The <tt><i>mask</i></tt> argument expressed in IPv4 or IPv6 numeric address form defaults to all mask bits on, meaning that the <tt><i>address</i></tt> is treated as the address of an individual host. A default entry (address 0.0.0.0, mask 0.0.0.0 for IPv4 and address :: mask :: for IPv6) is always the first entry in the list. <tt>restrict default</tt>, with no mask option, modifies both IPv4 and IPv6 default entries. <tt>restrict source</tt> configures a template restriction automatically added at runtime for each association, whether configured, ephemeral, or preemptable, and removed when the association is demobilized.</p>
<p>Some flags have the effect to deny service, some have the effect to enable service and some are conditioned by other flags. The flags. are not orthogonal, in that more restrictive flags will often make less restrictive ones redundant. The flags that deny service are classed in two categories, those that restrict time service and those that restrict informational queries and attempts to do run-time reconfiguration of the server.</p>
<p>An example may clarify how it works. Our campus has two class-B networks, 128.4 for the ECE and CIS departments and 128.175 for the rest of campus. Let's assume (not true!) that subnet 128.4.1 homes critical services like class rosters and spread sheets. A suitable ACL might look like this:</p>
<pre>
restrict default nopeer # deny new associations
restrict 128.175.0.0 mask 255.255.0.0 # allow campus access
restrict 128.4.0.0 mask 255.255.0.0 none # allow ECE and CIS access
restrict 128.4.1.0 mask 255.255.255.0 notrust # require authentication on subnet 1
restrict time.nist.gov # allow access
</pre>
<p>While this facility may be useful for keeping unwanted, broken or malicious clients from congesting innocent servers, it should not be considered an alternative to the NTP authentication facilities. Source address based restrictions are easily circumvented by a determined cracker.</p>
<p>Default restriction list entries with the flags <tt>ignore, ntpport</tt>, for each of the local host's interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time. A default entry is also always present, though if it is otherwise unconfigured; no flags are associated with the default entry (i.e., everything besides your own NTP server is unrestricted).</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

243
html/accopt.html
View File

@ -1,202 +1,91 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Access Control Options</title>
<title>Access Control Commands and Options</title>
<!-- Changed by: Harlan &, 13-Nov-2014 -->
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
<!--
.style1 {
color: #FF0000;
font-weight: bold;
<style1 {
color: #FF0000;
font-weight: bold;
}
-->
</style>
</head>
<body>
<h3>Access Control Options</h3>
<h3>Access Control Commands and Options</h3>
<img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The skunk watches for intruders and sprays.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->30-Sep-2009 17:16<!-- #EndDate -->
UTC</p>
<p>Last update:
<!-- #BeginDate format:En2m -->13-Nov-2014 03:00<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/accopt.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#acx">Access Control Support</a></li>
<li class="inline"><a href="#cmd">Access Control Commands</a></li>
</ul>
<hr>
<h4 id="acx">Access Control Support</h4>
<p>The <tt>ntpd</tt> daemon implements a general purpose access control list
(ACL) containing address/match entries sorted first by increasing address
values and then by increasing mask values. A match occurs when the bitwise
AND of the mask and the packet source address is equal to the bitwise AND of
the mask and address in the list. The list is searched in order with the last
match found defining the restriction flags associated with the entry.</p>
<p>An example may clarify how it works. Our campus has two class-B networks,
128.4 for the ECE and CIS departments and 128.175 for the rest of campus.
Let's assume (not true!) that subnet 128.4.1 homes critical services like class
rosters and spread sheets. A suitable ACL might be</p>
<pre>
restrict default nopeer # deny new associations
restrict 128.175.0.0 mask 255.255.0.0 # allow campus access
restrict 128.4.0.0 mask 255.255.0.0 none # allow ECE and CIS access
restrict 128.4.1.0 mask 255.255.255.0 notrust # require authentication on subnet 1
restrict time.nist.gov # allow access
</pre>
<p>While this facility may be useful for keeping unwanted, broken or malicious clients from congesting innocent servers, it should not be considered an alternative to the NTP authentication facilities. Source address based restrictions are easily circumvented by a determined cracker.</p>
<h4 id="cmd">Access Control Commands</h4>
<h4>Commands and Options</h4>
<p>Unless noted otherwise, further information about these ccommands is on the <a href="accopt.html">Access Control Support</a> page.</p>
<dl>
<dt id="discard"><tt>discard [ average <i>avg</i> ][ minimum <i>min</i> ] [ monitor <i>prob</i> ]</tt></dt>
<dd>Set the parameters of the rate control facility which protects the server
from client abuse. If the <tt>limited</tt> flag is present in the ACL, packets
that violate these limits are discarded. If in addition the <tt>kod</tt> restriction
is present, a kiss-o'-death packet is returned.</dd>
<dd><dl>
<dt><tt>average <i>avg</i></tt></dt>
<dd>Specify the minimum average interpacket spacing (minimum average headway
time) in log<sub>2</sub> s with default 3.</dd>
<dt><tt>minimum <i>min</i></tt></dt>
<dd>Specify the minimum interpacket spacing (guard time) in log<sub>2</sub> s
with default 1.</dd>
<dt><tt>monitor</tt></dt>
<dd>Specify the probability of discard for packets that overflow the rate-control
window. This is a performance optimization for servers with aggregate arrivals
of 1000 packets per second or more.</dd>
</dl></dd>
<dt id="restrict"><tt>restrict <i>address</i> [mask <i>mask</i>] [<i>flag</i>][...]</tt></dt>
<dd>The <tt><i>address</i></tt> argument expressed in dotted-quad form is the
address of a host or network. Alternatively, the <tt><i>address</i></tt> argument
can be a valid host DNS name. The <tt><i>mask</i></tt> argument expressed in
dotted-quad form defaults to 255.255.255.255, meaning that the <tt><i>address</i></tt> is
treated as the address of an individual host. A default entry (address 0.0.0.0,
mask 0.0.0.0) is always included and is always the first entry in the list.
Note that the text string <tt>default</tt>, with no mask option, may be used
to indicate the default entry.</dd>
<dd>Some flags have the effect to deny service, some have the effect to
enable service and some are conditioned by other flags. The flags. are
not orthogonal, in that more restrictive flags will often make less restrictive
ones redundant. The flags that deny service are classed in two categories,
those that restrict time service and those that restrict informational queries
and attempts to do run-time reconfiguration of the server. One or more of the
following flags may be specified:</dd>
<dd><dl>
<dt><tt>flake</tt></dt>
<dd>Discard received NTP packets with probability 0.1; that is, on average drop
one packet in ten. This is for testing and amusement. The name comes from Bob
Braden's <i>flakeway</i>, which once did a similar thing for early Internet
testing.</dd>
<dt><tt>ignore</tt></dt>
<dd>Deny packets of all kinds, including <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>kod</tt></dt>
<dd>Send a kiss-o'-death (KoD) packet if the <tt>limited</tt> flag is present
and a packet violates the rate limits established by the <tt>discard</tt> command.
KoD packets are themselves rate limited for each source address separately.
If this flag is not present, packets that violate the rate limits are discarded.</dd>
<dt><tt>limited</tt></dt>
<dd>Deny time service if the packet violates the rate limits established by the <tt>discard</tt> command.
This does not apply to <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>lowpriotrap</tt></dt>
<dd>Declare traps set by matching hosts to be low priority. The number of traps
a server can maintain is limited (the current limit is 3). Traps are usually
assigned on a first come, first served basis, with later trap requestors being
denied service. This flag modifies the assignment algorithm by allowing low
priority traps to be overridden by later requests for normal priority traps.</dd>
<dt><tt>mssntp</tt></dt>
<dd>Enable Microsoft Windows MS-SNTP authentication using Active Directory services.
<span class="style1">Note: Potential users should be aware that these services
involve a TCP connection to another process that could potentially block,
denying services to other users. Therefore, this flag should be used only
for a dedicated server with no clients other than MS-SNTP.</span></dd>
<dt><tt>nomodify</tt></dt>
<dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries which attempt to modify the
state of the server (i.e., run time reconfiguration). Queries which return information
are permitted.</dd>
<dt><tt>noquery</tt></dt>
<dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries. Time service is not affected.</dd>
<dt><tt>nopeer</tt></dt>
<dd>Deny packets that might mobilize an association unless authenticated. This
includes broadcast, symmetric-active and manycast server packets when a configured
association does not exist. Note that this flag does not apply to packets
that do not attempt to mobilize an association. </dd>
<dt><tt>noserve</tt></dt>
<dd>Deny all packets except <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>notrap</tt></dt>
<dd>Decline to provide mode 6 control message trap service to matching hosts.
The trap service is a subsystem of the <tt>ntpdc</tt> control message protocol
which is intended for use by remote event logging programs.</dd>
<dt><tt>notrust</tt></dt>
<dd>Deny packets that are not cryptographically authenticated. Note carefully
how this flag interacts with the <tt>auth</tt> option of the <tt>enable</tt> and <tt>disable</tt> commands.
If <tt>auth</tt> is enabled, which is the default, authentication is required
for all packets that might mobilize an association.
If <tt>auth</tt> is
disabled, but the <tt>notrust</tt> flag is not present, an association can be
mobilized whether or not authenticated. If <tt>auth</tt> is disabled, but the <tt>notrust</tt> flag
is present, authentication is required only for the specified address/mask
range. </dd>
<dt><tt>ntpport</tt></dt>
<dt><tt>non-ntpport</tt></dt>
<dd>This is actually a match algorithm modifier, rather than a restriction
flag. Its presence causes the restriction entry to be matched only if the
source port in the packet is the standard NTP UDP port (123). Both <tt>ntpport</tt> and <tt>non-ntpport</tt> may
be specified. The <tt>ntpport</tt> is considered more specific and is sorted
later in the list.</dd>
<dt><tt>version</tt></dt>
<dd>Deny packets that do not match the current NTP version.</dd>
</dl>
</dd>
<dd>Default restriction list entries with the flags <tt>ignore, ntpport</tt>,
for each of the local host's interface addresses are inserted into the table
at startup to prevent the server from attempting to synchronize to its own time.
A default entry is also always present, though if it is otherwise unconfigured;
no flags are associated with the default entry (i.e., everything besides your
own NTP server is unrestricted).</dd>
<dt id="discard"><tt>discard [ average <i>avg</i> ][ minimum <i>min</i> ] [ monitor <i>prob</i> ]</tt></dt>
<dd>Set the parameters of the rate control facility which protects the server from client abuse. If the <tt>limited</tt> flag is present in the ACL, packets that violate these limits are discarded. If, in addition, the <tt>kod</tt> flag is present, a kiss-o'-death packet is returned. See the <a href="rate.html">Rate Management</a> page for further information. The options are:
<dl>
<dt><tt>average <i>avg</i></tt></dt>
<dd>Specify the minimum average interpacket spacing (minimum average headway
time) in log<sub>2</sub> s with default 3.</dd>
<dt><tt>minimum <i>min</i></tt></dt>
<dd>Specify the minimum interpacket spacing (guard time) in seconds with default 2.</dd>
<dt><tt>monitor</tt></dt>
<dd>Specify the probability of being recorded for packets that overflow the MRU list size limit set by <tt>mru maxmem</tt> or <tt>mru maxdepth</tt>. This is a performance optimization for servers with aggregate arrivals of 1000 packets per second or more.</dd>
</dl>
</dd>
<dt id="restrict"><tt>restrict default [<i>flag</i>][...]<br>
restrict source [<i>flag</i>][...]<br>
restrict <i>address</i> [mask <i>mask</i>] [<i>flag</i>][...]</tt></dt>
<dd>The <tt><i>address</i></tt> argument expressed in dotted-quad form is the address of a host or network. Alternatively, the <tt><i>address</i></tt> argument can be a valid host DNS name. The <tt><i>mask</i></tt> argument expressed in IPv4 or IPv6 numeric address form defaults to all mask bits on, meaning that the <tt><i>address</i></tt> is treated as the address of an individual host. A default entry (address 0.0.0.0, mask 0.0.0.0 for IPv4 and address :: mask :: for IPv6) is always the first entry in the list. <tt>restrict default</tt>, with no mask option, modifies both IPv4 and IPv6 default entries. <tt>restrict source</tt> configures a template restriction automatically added at runtime for each association, whether configured, ephemeral, or preemptible, and removed when the association is demobilized.</dd>
<dd>Some flags have the effect to deny service, some have the effect to enable service and some are conditioned by other flags. The flags. are not orthogonal, in that more restrictive flags will often make less restrictive ones redundant. The flags that deny service are classed in two categories, those that restrict time service and those that restrict informational queries and attempts to do run-time reconfiguration of the server. One or more of the following flags may be specified:</dd>
<dd>
<dl>
<dt><tt>flake</tt></dt>
<dd>Discard received NTP packets with probability 0.1; that is, on average drop one packet in ten. This is for testing and amusement. The name comes from Bob Braden's <i>flakeway</i>, which once did a similar thing for early Internet testing.</dd>
<dt><tt>ignore</tt></dt>
<dd>Deny packets of all kinds, including <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>kod</tt></dt>
<dd>Send a kiss-o'-death (KoD) packet if the <tt>limited</tt> flag is present and a packet violates the rate limits established by the <tt>discard</tt> command. KoD packets are themselves rate limited for each source address separately. If the <tt>kod</tt> flag is used in a restriction which does not have the <tt>limited</tt> flag, no KoD responses will result.</dd>
<dt id="limited"><tt>limited</tt></dt>
<dd>Deny time service if the packet violates the rate limits established by the <tt>discard</tt> command. This does not apply to <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>lowpriotrap</tt></dt>
<dd>Declare traps set by matching hosts to be low priority. The number of traps a server can maintain is limited (the current limit is 3). Traps are usually assigned on a first come, first served basis, with later trap requestors being denied service. This flag modifies the assignment algorithm by allowing low priority traps to be overridden by later requests for normal priority traps.</dd>
<dt><tt>mssntp</tt></dt>
<dd>Enable Microsoft Windows MS-SNTP authentication using Active Directory services. <span class="style1"><b>Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</b></span></dd>
<dt><tt>nomodify</tt></dt>
<dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries which attempt to modify the state of the server (i.e., run time reconfiguration). Queries which return information are permitted.</dd>
<dt><tt>noquery</tt></dt>
<dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries. Time service is not affected.</dd>
<dt><tt>nopeer</tt></dt>
<dd>Deny packets that might mobilize an association unless authenticated. This includes broadcast, symmetric-active and manycast server packets when a configured association does not exist. It also includes <tt>pool</tt> associations, so if you want to use servers from a <tt>pool</tt> directive and also want to use <tt>nopeer</tt> by default, you'll want a <tt>"restrict source ..."</tt> line as well that does <i>not</i> include the <tt>nopeer</tt> directive. Note that this flag does not apply to packets that do not attempt to mobilize an association. </dd>
<dt><tt>noserve</tt></dt>
<dd>Deny all packets except <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>notrap</tt></dt>
<dd>Decline to provide mode 6 control message trap service to matching hosts. The trap service is a subsystem of the <tt>ntpdc</tt> control message protocol which is intended for use by remote event logging programs.</dd>
<dt><tt>notrust</tt></dt>
<dd>Deny packets that are not cryptographically authenticated. Note carefully how this flag interacts with the <tt>auth</tt> option of the <tt>enable</tt> and <tt>disable</tt> commands. If <tt>auth</tt> is enabled, which is the default, authentication is required for all packets that might mobilize an association. If <tt>auth</tt> is disabled, but the <tt>notrust</tt> flag is not present, an association can be mobilized whether or not authenticated. If <tt>auth</tt> is disabled, but the <tt>notrust</tt> flag is present, authentication is required only for the specified address/mask range. </dd>
<dt><tt>ntpport</tt></dt>
<dd>This is actually a match algorithm modifier, rather than a restriction
flag. Its presence causes the restriction entry to be matched only if the
source port in the packet is the standard NTP UDP port (123). A restrict line
containing <tt>ntpport</tt> is considered more specific than one with the
same address and mask, but lacking <tt>ntpport</tt>.</dd>
<dt><tt>version</tt></dt>
<dd>Deny packets that do not match the current NTP version.</dd>
</dl>
</dd>
<dd>Default restriction list entries with the flags <tt>ignore, ntpport</tt>, for each of the local host's interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time. A default entry is also always present, though if it is otherwise unconfigured; no flags are associated with the default entry (i.e., everything besides your own NTP server is unrestricted).</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

173
html/assoc.html
View File

@ -1,96 +1,81 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Association Management</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Association Management</h3>
<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:56</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="277">Friday, December 28, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#modes">Association Modes</a>
<li class="inline"><a href="#client">Client/Server Mode</a>
<li class="inline"><a href="#symact">Symmetric Active/Passive Mode</a>
<li class="inline"><a href="#broad">Broadcast/Multicast Modes</a>
<li class="inline"><a href="#many">Manycast Mode</a>
<li class="inline"><a href="#orphan">Orphan Mode</a>
<li class="inline"><a href="#burst">Burst Options</a>
</ul>
<hr>
<h4 id="modes">Association Modes</h4>
<p>This page describes the various modes of operation provided in NTPv4. Details about the configuration commands and options are given on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are given on the <a href="authopt.html">Authentication Options</a> page. Details about the automatic server discovery schemes are described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.</p>
<p>There are three types of associations in NTP: persistent, preemptable and ephemeral. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>prempt</tt> option and are demobilized by a &quot;better&quot; server or by timeout, but only if the number of survivors exceeds the threshold set by the <tt>tos maxclock</tt> configuration command. Ephemeral associations are mobilized upon arrival of designated messages and demobilized by timeout.</p>
<p>Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described in the <a href="authopt.html">Authentication Options</a> page.</p>
<p>There are three principal modes of operation in NTP: client/server, symmetric active/passive and broadcast/multicast. There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and pool described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. In addition, the orphan mode and burst options described on this page can be used in appropriate cases.</p>
<p>Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
<h4 id="client">Client/Server Mode</h4>
<p>Client/server mode is the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers and stateful clients. In this mode a host sends a client (mode 3) request to the specified server and expects a server (mode 4) reply at some future time. In some contexts this would be described as a &quot;pull&quot; operation, in that the host pulls the time and related values from the server.</p>
<p>A host is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS&nbsp;name or IPv4 or IPv6 address; the server requires no prior configuration. The <tt>iburst</tt> option described later on this page is recommended for clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt> option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.</p>
<p>Ordinarily, the program automatically manages the poll interval between the default minimum and maximum values. The <tt>minpoll</tt> and <tt>maxpoll</tt> options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.</p>
<h4 id="symact">Symmetric Active/Passive Mode</h4>
<p>Symmetric active/passive mode is intended for configurations were a clique
of low-stratum peers operate as mutual backups for each other. Each peer operates
with one or more primary reference sources, such as a radio clock, or a set
of secondary (stratum, 2) servers known to be reliable and authentic. Should
one of the peers lose all reference sources or simply cease operation, the
other peers will automatically reconfigure so that time and related values
can flow from the surviving peers to all hosts in the subnet. In some contexts
this would be described as a &quot;push-pull&quot; operation, in that the
peer either pulls or pushes the time and related values depending on the particular
configuration.</p>
<p>In symmetric active mode a peer symmetric active (mode 1) message to a designated peer. If a matching configured symmetric active association is found, the designated peer returns a symmetric active message. If no matching association is found, the designated peer mobilizes a ephemeral symmetric passive association and returns a symmetric passive (mode 2) message. Since an intruder can impersonate a symmetric active peer and cause a spurious symmetric passive association to be mobilized, symmetric passive mode should always be cryptographically validated.</p>
<p>A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or IPv4 or IPv6 address. The <tt>burst</tt> and <tt>iburst</tt> options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages.</p>
<p>As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the <tt>minpoll</tt> and <tt>maxpoll</tt> options.</p>
<h4 id="broad">Broadcast/Multicast Modes</h4>
<p>NTP broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population. Broadcast mode can be used with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast packets do not extend beyond a level-3 router. Where service is intended beyond a level-3 router, multicast mode can be used. Additional information is on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
<h4 id="many">Manycast Mode</h4>
<p>Manycast mode is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each manycast client mobilizes ephemeral client associations with some number of the &quot;best&quot; of the nearby manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
<h4 id="orphan">Orphan Mode</h4>
<p>Sometimes an NTP subnet becomes isolated from all UTC sources such as local reference clocks or Internet time servers. In such cases it may be necessary that the subnet servers and clients remain synchronized to a common timescale, not necessarily the UTC timescale. Previously, this function was provided by the local clock driver to simulate a UTC source. A server with this driver could be used to synchronize other hosts in the subnet directly or indirectly.</p>
<p>There are many disadvantages using the local clock driver, primarily that the subnet is vulnerable to single-point failures and multiple server redundancy is not possible. Orphan mode is intended to replace the local clock driver. It provides a single simulated UTC source with multiple servers and provides seamless switching as servers fail and recover.</p>
<p>A common configuration for private networks includes one or more core servers operating at the lowest stratum. Good practice is to configure each of these servers as backup for the others using symmetric or broadcast modes. As long as at least one core server can reach a UTC source, the entire subnet can synchronize to it.</p>
<p>If no UTC sources are available to any core server, one of them can provide a simulated UTC source for all other hosts in the subnet. However, only one core server can simulate the UTC source and all direct dependents, called orphan children, must select the same one, called the orphan parent.</p>
<p>A host is enabled for orphan mode using the <tt>tos orphan <i>stratum</i></tt> command, where <tt><i>stratum</i></tt> is some stratum less than 16 and greater than any anticipated stratum that might occur with configured Internet time servers. However, sufficient headroom should remain so every subnet host dependent on the orphan children has stratum less than 16. Where no associations for other servers or reference clocks are configured, the orphan stratum can be set to 1. These are the same considerations that guide the local clock driver stratum selection.</p>
<p>A orphan parent with no sources shows reference ID <font face="Courier New, Courier, Monaco, monospace">LOOP</font>&nbsp;if
operating at stratum 1 and 127.0.0.1 (Unix loopback address) otherwise.
While ordinary NTP clients use a selection metric based on delay
and dispersion, orphan children use a metric computed from the IP
address of each core server. Each orphan child chooses the orphan
parent as the root server with the smallest metric.</p>
<p>For orphan mode to work well, each core server with available sources should operate at the same stratum. All core servers and orphan children should include the same <font face="Courier New, Courier, Monaco, monospace">tos</font> command in the configuration file. Each orphan child should include in the configuration file all root servers.</p>
<div align-"center">
<img src="pic/peer.gif" alt="gif">
</div>
<p>For example, consider the peer network configuration above, where two or more campus primary or secondary (stratum 2) servers are configured with reference clocks or public Internet primary servers and with each other using symmetric modes. With this configuration a server that loses all sources continues to discipline the system clock using the other servers as backup. Only the core servers and orphan children need to be enabled for orphan mode.</p>
<div align-"center">
<img src="pic/broad.gif" alt="gif">
</div>
<p>For broadcast networks each core server is configured in both broadcast server and broadcast client modes as shown above. Orphan children operate as broadcast clients of all core servers. As in peer networks, the core servers back up each other and only they and the orphan children need to be enabled for orphan mode.</p>
<p>In normal operation subnet hosts operate below stratum 5, so the subnet is automatically configured as described in the NTP specification. If all UTC sources are lost, all core servers become orphans and the orphan children will select the same root server to become the orphan parent.</p>
<h4 id="burst">Burst Options</h4>
<p>There are two burst options where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal one packet. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands, but not with reference clock drivers nor symmetric peers. The <tt>burst</tt> option sends a burst when the server is reachable, while the <tt>iburst</tt> option sends a burst when the server is unreachable. Each mode is independently of the other and both can be used at the same time. In either mode the client sends one packet, waits for the reply, then sends the remaining packets in the burst. This may be useful to allow a modem to complete a call.</p>
<p>In both modes received server packets update the clock filter, which selects the best (most accurate) time values. When the last packet in the burst is sent, the next received packet updates the system variables and adjusts the system clock as if only a single packet exchange had occurred.</p>
<p>The <tt>iburst</tt> option is useful where the system clock must be set quickly or when the network attachment requires an initial calling or training sequence. The burst is initiated only when the server first becomes reachable. This improves accuracy with intermittent connections typical of PPP and ISDN services. Outliers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first received packet.</p>
<p>The <tt>burst</tt> option can be configured in cases of excessive network
jitter or when the network attachment requires an initial calling or training
sequence. The burst is initiated at each poll interval when the server is
reachable. The number of packets in the burst is determined by the poll interval
so that the average interval between packets is no less than 16. At a poll
interval of 16 s, only one packet is sent in the burst; at 32 s, two packets
are sent and so forth until at 128 s and above eight packets are sent.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Association Management</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Association Management</h3>
<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->31-Jan-2014 06:54<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#modes">Association Modes</a></li>
<li class="inline"><a href="#client">Client/Server Mode</a></li>
<li class="inline"><a href="#symact">Symmetric Active/Passive Mode</a></li>
<li class="inline"><a href="#broad">Broadcast/Multicast Modes</a></li>
<li class="inline"><a href="#many">Manycast Mode</a></li>
<li class="inline"><a href="#poll">Poll Interval Management</a></li>
<li class="inline"><a href="#burst">Burst Options</a></li>
</ul>
<hr>
<h4 id="modes">Association Modes</h4>
<p>This page describes the various modes of operation provided in NTPv4. There are three types of associations in NTP: <em>persistent</em>, <em>preemptable</em> and <em>ephemeral</em>. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>preempt</tt> option or upon arrival of an automatic server discovery packet. They are are demobilized by timeout or when preempted by a &quot;better&quot; server, as described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. Ephemeral associations are mobilized upon arrival of broadcast or multicast server packets and demobilized by timeout.</p>
<p>Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described on the <a href="authentic.html">Authentication Support</a> page.</p>
<p>There are three principal modes of operation in NTP: client/server, symmetric active/passive and broadcast/multicast. There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and pool described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. In addition, the <a href="#burst">burst options</a> and <a href="orphan.html">orphan mode</a> can be used in appropriate cases.</p>
<p>Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the <a href="confopt.html">Server Commands and Options</a> page. See that page for applicability and defaults.</p>
<h4 id="client">Client/Server Mode</h4>
<p>Client/server mode is the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers and stateful clients. In this mode a host sends a client (mode 3) request to the specified server and expects a server (mode 4) reply at some future time. In some contexts this would be described as a &quot;pull&quot; operation, in that the host pulls the time and related values from the server.</p>
<p>A host is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS&nbsp;name or IPv4 or IPv6 address; the server requires no prior configuration. The <tt>iburst</tt> option described later on this page is recommended for clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt> option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.</p>
<p>Ordinarily, the program automatically manages the poll interval between the default minimum and maximum values. The <tt>minpoll</tt> and <tt>maxpoll</tt> options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.</p>
<h4 id="symact">Symmetric Active/Passive Mode</h4>
<p>Symmetric active/passive mode is intended for configurations where a clique
of low-stratum peers operate as mutual backups for each other. Each peer operates
with one or more primary reference sources, such as a reference clock, or a set
of secondary (stratum, 2) servers known to be reliable and authentic. Should
one of the peers lose all reference sources or simply cease operation, the
other peers will automatically reconfigure so that time and related values
can flow from the surviving peers to all hosts in the subnet. In some contexts
this would be described as a &quot;push-pull&quot; operation, in that the
peer either pulls or pushes the time and related values depending on the particular
configuration.</p>
<p>A symmetric active peer sends a symmetric active (mode 1) message to a designated peer. If a matching configured symmetric active association is found, the designated peer returns a symmetric active message. If no matching association is found, the designated peer mobilizes a ephemeral symmetric passive association and returns a symmetric passive (mode 2) message. Since an intruder can impersonate a symmetric active peer and cause a spurious symmetric passive association to be mobilized, symmetric passive mode should always be cryptographically validated.</p>
<p>A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or IPv4 or IPv6 address. The <tt>burst</tt> and <tt>iburst</tt> options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages.</p>
<p>As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the <tt>minpoll</tt> and <tt>maxpoll</tt> options.</p>
<h4 id="broad">Broadcast/Multicast Modes</h4>
<p>NTP broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population. Broadcast mode can be used with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast packets do not extend beyond a level-3 router. Where service is intended beyond a level-3 router, multicast mode can be used. Additional information is on the <a href="discover.html">Automatic NTP Configuration Options</a> page.</p>
<p>A server is configured to send broadcast or multicast messages using the <tt>broadcast</tt> command and specifying the subnet address for broadcast or the multicast group address for multicast. A broadcast client is enabled using the <a href="confopt.html#broadcastclient"><tt>broadcastclient</tt></a> command, while a multicast client is enabled using the <a href="confopt.html#multicastclient"><tt>multicastclient</tt></a> command and specifying the multicast group address. Multiple commands of either type can be used. However, the association is not mobilized until the first broadcast or multicast message is actually received.</p>
<h4 id="many">Manycast and Pool Modes</h4>
<p>Manycast and pool modes are automatic discovery and configuration paradigms new to NTPv4. They are intended as a means for a client to troll the nearby network neighborhood to find cooperating willing servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each client mobilizes ephemeral client associations with some number of the &quot;best&quot; of the nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="discover.html">Automatic Server Discovery Schemes</a> page.</p>
<h4 id="poll">Poll Interval Management</h4>
<p>NTP uses an intricate heuristic algorithm to automatically control the poll interval for maximum accuracy consistent with minimum network overhead. The algorithm measures the incidental offset and jitter to determine the best poll interval. When <tt>ntpd</tt> starts, the interval is the default minimum 64 s. Under normal conditions when the clock discipline has stabilized, the interval increases in steps to the default maximum 1024 s. In addition, should a server become unreachable after some time, the interval increases in steps to the maximum in order to reduce network overhead. Additional information about the algorithm is on the <a href="poll.html">Poll Program</a> page.</p>
<p>The default poll interval range is suitable for most conditions, but can be changed using options on the <a href="confopt.html">Server Commands and Options</a> and <a href="miscopt.html">Miscellaneous Options</a> pages. However, when using maximum intervals much larger than the default, the residual clock frequency error must be small enough for the discipline loop to capture and correct. The capture range is 500 PPM with a 64-s interval decreasing by a factor of two for each interval doubling. At a 36-hr interval, for example, the capture range is only 0.24 PPM.</p>
<p>In the NTPv4 specification and reference implementation, the poll interval is expressed in log<sub>2</sub> units, properly called the <em>poll exponent.</em> It is constrained by the lower limit <tt>minpoll</tt> and upper limit <tt>maxpoll</tt> options of the <a href="confopt.html"><tt>server</tt></a> command. The limits default to 6 (64 s) and 10 (1024 s), respectively, which are appropriate for the vast majority of cases.</p>
<p>As a rule of thumb, the expected errors increase by a factor of two as the poll interval increases by a factor of four. The poll interval algorithm slowly increases the poll interval when jitter dominates the error budget, but quickly reduces the interval when wander dominates it. More information about this algorithm is on the <a href="warp.html">How NTP Works</a> page.</p>
<p>There is normally no need to change the poll limits, as the poll interval is managed automatically as a function of prevailing jitter and wander. The most common exceptions are the following.</p>
<ul>
<li>With fast, lightly loaded LANs and modern processors, the nominal Allan intercept is about 500 s. In these cases the expected errors can be further reduced using a poll exponent of 4 (16 s). In the case of the pulse-per-second (PPS) driver, this is the recommended value.</li>
<li>With symmetric modes the most stable behavior results when both peers are configured in symmetric active mode with matching poll intervals of 6 (64 s).</li>
<li>The poll interval should not be modified for reference clocks, with the single exception the ACTS telephone modem driver. In this case the recommended minimum and maximum intervals are 12 (1.1 hr) and 17 (36 hr), respectively.</li>
</ul>
<h4 id="burst">Burst Options</h4>
<p>Occasionally it is necessary to send packets temporarily at intervals less than the poll interval. For instance, with the <tt>burst</tt> and <tt>iburst</tt> options of the <a href="confopt.html"><tt>server</tt></a> command, the poll program sends a burst of several packets at 2-s intervals. In either case the poll program avoids sending needless packets if the server is not responding. The client begins a burst with a single packet. When the first packet is received from the server, the client continues with the remaining packets in the burst. If the first packet is not received within 64 s, it will be sent again for two additional retries before beginning backoff. The result is to minimize network load if the server is not responding. Additional details are on the <a href="poll.html">Poll Program</a> page.</p>
<p>There are two burst options where a single poll event triggers a burst. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands, but not with reference clock drivers nor symmetric mode peers. In both modes, received server packets update the clock filter, which selects the best (most accurate) time values. When the last packet in the burst is sent, the next received packet updates the system variables and adjusts the system clock as if only a single packet exchange had occurred.</p>
<p>The <tt>iburst</tt> option is useful where the system clock must be set quickly or when the network attachment requires an initial calling or training sequence, as in PPP or ISDN services. In general, this option is recommended for <tt>server</tt> and <tt>pool</tt> commands. A burst is sent only when the server is unreachable; in particular, when first starting up. Ordinarily, the clock is set within a few seconds after the first received packet. See the <a href="clock.html">Clock State Machine</a> page for further details about the startup behavior.</p>
<p>The <tt>burst</tt> option is useful in cases of severe network
jitter or when the network attachment requires an initial calling or training
sequence. This option is recommended when the minimum poll exponent is larger than 10 (1024 s). A burst is sent only when the server is reachable. The number of packets in the burst is determined by the poll interval
so that the average interval between packets (headway) is no less than the minimum poll interval for the association.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

357
html/audio.html
View File

@ -1,181 +1,180 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Reference Clock Audio Drivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Reference Clock Audio Drivers</h3>
<img src="pic/radio2.jpg" alt="jpg" align="left">ICOM R-72 shortwave receiver and Sure audio mixer
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">00:48</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#sound">Sound Card Drivers</a>
<li class="inline"><a href="#short">Shortwave Radio Drivers</a>
<li class="inline"><a href="#setup">Setup and Debugging Aids</a>
</ul>
<hr>
<h4 id="sound">Sound Card Drivers</h4>
<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 many 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>
<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, modeled and evaluated in a technical report.</p>
<p>Currently, the audio drivers work with with Sun operating systems and audio codecs, including SunOS 4.1.3 and Solaris from 2.6 and probably all others in between. They also work with FreeBSD from 4.1 with compatible sound card. 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>
<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>
<p>The IRIG&nbsp;and WWV 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 WWV driver. The largest error observed so far is about 60 PPM, but it is possible some sound cards or codecs may exceed that value. In any case, the configuration file command <tt>tinker codec</tt> command can be used to change the systematic offset in units of 125 PPM.</p>
<p>The drivers include provisions to select the input port and to monitor the input signal. The <tt>fudge flag 2</tt> command 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> command 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.</p>
<h4 id="short">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>
<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>
<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 building ground.</p>
<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>
<p>Shortwave (3-30 MHz) radio propagation phenomena are well known to shortwave enthusiasts. The phenomena generally obey the following rules:</p>
<ul>
<li>The optimum frequency is higher in daytime than nighttime, stays high longer on summer days and low longer on winter nights.
<li>Transitions between daytime and nighttime conditions generally occur somewhat
after sunrise and sunset at the midpoint of the path from transmitter to
receiver.
<li>Ambient noise (static) on the lower frequencies follows the thunderstorm season, so is higher on summer afternoons and evenings.
<li>The lower frequency bands are best for shorter distances, while the higher bands are best for longer distances.
<li>The optimum frequencies are higher at the peak of the 11-year sunspot cycle and lower at the trough. The current sunspot cycle began at the minimum in late 2006 and should reach its peak in 2012.</ul>
<p>The best way to choose a frequency is to listen at various times over the day and determine the highest (daytime) and lowest (nighttime) frequencies that work well. Choose the frequency that works for the most number of hours in the day, usually the highest frequency. For instance, on the east coast the best compromise CHU frequency is 7335 kHz and the best WWV frequency is 15 MHz.</p>
<h4>Autotune Modes</h4>
<p>The shortwave drivers include support for an optional autotune function compatible with ICOM&nbsp;receivers and transceivers. The <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies the ICOM ID select code in decimal. A missing or zero argument disables the CI-V interface. Since all ICOM select codes are less than 128, the high order bit of the code is used by the driver to specify the baud rate. If this bit is not set, the rate is 9600 bps for the newer radios; if set, the rate is 1200 bps for the older radios. Following are the ID select codes for the known radios.</p>
<table width="100%" cols="6">
<tr>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
</tr>
<tr>
<td>706</td>
<td>0x4e</td>
<td>78</td>
<td>775</td>
<td>0x46</td>
<td>70</td>
</tr>
<tr>
<td>706MKIIG</td>
<td>0x58</td>
<td>88</td>
<td>781</td>
<td>0x26</td>
<td>38</td>
</tr>
<tr>
<td>725</td>
<td>0x28</td>
<td>40</td>
<td>970</td>
<td>0x2e</td>
<td>46</td>
</tr>
<tr>
<td>726</td>
<td>0x30</td>
<td>48</td>
<td>7000</td>
<td>0x70</td>
<td>113</td>
</tr>
<tr>
<td>735</td>
<td>0x04</td>
<td>4</td>
<td>R71</td>
<td>0x1A</td>
<td>26</td>
</tr>
<tr>
<td>746</td>
<td>0x66</td>
<td>102</td>
<td>R72</td>
<td>0x32</td>
<td>50</td>
</tr>
<tr>
<td>751</td>
<td>0x1c</td>
<td>28</td>
<td>R75</td>
<td>0x5a</td>
<td>90</td>
</tr>
<tr>
<td>756PROII</td>
<td>0x64</td>
<td>100</td>
<td>R7000</td>
<td>0x08</td>
<td>8</td>
</tr>
<tr>
<td>761</td>
<td>0x1e</td>
<td>30</td>
<td>R7100</td>
<td>0x34</td>
<td>52</td>
</tr>
<tr>
<td>765</td>
<td>0x2c</td>
<td>44</td>
<td>R8500</td>
<td>0x4a</td>
<td>74</td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td>R9000</td>
<td>0x2a</td>
<td>42</td>
</tr>
</table>
<h4 id="setup">Setup and Debugging Aids</h4>
<p>The audio drivers include extensive setup and 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>
<p>Connecting radios and IRIG devices to the computer and verifying correct
configuration is somewhat of a black art. The signals have to be connected
to the correct ports and the signal level maintained within tolerances. Some
radios have recorder outputs which produce a microphone-level signal not affected
by the volume control. These signals can be connected to the microphone port
on the computer. If the radio does not have a recorder output, connect the
headphone or speaker output to the line-in port and adjust the volume control
so the driver indicates comfortably above the minimum specified and the AGC
level somewhere in the middle of the range 0-255. IRIG signals are usually
much larger than radio outputs, usually in the range to several volts and
may even overload the line-in port. In such cases the signal is designed to
drive a cable terminated with a 50-ohm resistor, which results in a level
the line-in port can handle..</p>
<p>It is very easy to underdriven or overdrive the audio codec, in which case
the drivers will not synchronize to the signal. The drivers use <tt>fudge
flag2</tt> to enable audio monitoring of the input signal. This is useful
during setup to confirm the signal is actually reaching the audio
codec and generally free of noise and interference. Note that the monitor
volume must be set before the driver is started.</p>
<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 UTC 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.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Reference Clock Audio Drivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Reference Clock Audio Drivers</h3>
<img src="pic/radio2.jpg" alt="jpg" align="left">ICOM R-72 shortwave receiver and Sure audio mixer
<p>Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#sound">Sound Card Drivers</a></li>
<li class="inline"><a href="#short">Shortwave Radio Drivers</a></li>
<li class="inline"><a href="#setup">Setup and Debugging Aids</a></li>
</ul>
<hr>
<h4 id="sound">Sound Card Drivers</h4>
<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 many 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>
<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, modeled and evaluated in a technical report.</p>
<p>Currently, the audio drivers work with with Sun operating systems and audio codecs, including SunOS 4.1.3 and Solaris from 2.6 and probably all others in between. They also work with FreeBSD from 4.1 with compatible sound card. 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>
<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>
<p>The IRIG&nbsp;and WWV 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 WWV driver. The largest error observed so far is about 60 PPM, but it is possible some sound cards or codecs may exceed that value. In any case, the configuration file command <tt>tinker codec</tt> command can be used to change the systematic offset in units of 125 PPM.</p>
<p>The drivers include provisions to select the input port and to monitor the input signal. The <tt>fudge flag 2</tt> command 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> command 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.</p>
<h4 id="short">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>
<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>
<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 building ground.</p>
<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>
<p>Shortwave (3-30 MHz) radio propagation phenomena are well known to shortwave enthusiasts. The phenomena generally obey the following rules:</p>
<ul>
<li>The optimum frequency is higher in daytime than nighttime, stays high longer on summer days and low longer on winter nights.</li>
<li>Transitions between daytime and nighttime conditions generally occur somewhat
after sunrise and sunset at the midpoint of the path from transmitter to
receiver.</li>
<li>Ambient noise (static) on the lower frequencies follows the thunderstorm season, so is higher on summer afternoons and evenings.</li>
<li>The lower frequency bands are best for shorter distances, while the higher bands are best for longer distances.</li>
<li>The optimum frequencies are higher at the peak of the 11-year sunspot cycle and lower at the trough. The current sunspot cycle began at the minimum in late 2006 and should reach its peak in 2012.</li>
</ul>
<p>The best way to choose a frequency is to listen at various times over the day and determine the highest (daytime) and lowest (nighttime) frequencies that work well. Choose the frequency that works for the most number of hours in the day, usually the highest frequency. For instance, on the east coast the best compromise CHU frequency is 7335 kHz and the best WWV frequency is 15 MHz.</p>
<h4>Autotune Modes</h4>
<p>The shortwave drivers include support for an optional autotune function compatible with ICOM&nbsp;receivers and transceivers. The <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies the ICOM ID select code in decimal. A missing or zero argument disables the CI-V interface. Since all ICOM select codes are less than 128, the high order bit of the code is used by the driver to specify the baud rate. If this bit is not set, the rate is 9600 bps for the newer radios; if set, the rate is 1200 bps for the older radios. Following are the ID select codes for the known radios.</p>
<table width="100%" cols="6">
<tr>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
</tr>
<tr>
<td>706</td>
<td>0x4e</td>
<td>78</td>
<td>775</td>
<td>0x46</td>
<td>70</td>
</tr>
<tr>
<td>706MKIIG</td>
<td>0x58</td>
<td>88</td>
<td>781</td>
<td>0x26</td>
<td>38</td>
</tr>
<tr>
<td>725</td>
<td>0x28</td>
<td>40</td>
<td>970</td>
<td>0x2e</td>
<td>46</td>
</tr>
<tr>
<td>726</td>
<td>0x30</td>
<td>48</td>
<td>7000</td>
<td>0x70</td>
<td>113</td>
</tr>
<tr>
<td>735</td>
<td>0x04</td>
<td>4</td>
<td>R71</td>
<td>0x1A</td>
<td>26</td>
</tr>
<tr>
<td>746</td>
<td>0x66</td>
<td>102</td>
<td>R72</td>
<td>0x32</td>
<td>50</td>
</tr>
<tr>
<td>751</td>
<td>0x1c</td>
<td>28</td>
<td>R75</td>
<td>0x5a</td>
<td>90</td>
</tr>
<tr>
<td>756PROII</td>
<td>0x64</td>
<td>100</td>
<td>R7000</td>
<td>0x08</td>
<td>8</td>
</tr>
<tr>
<td>761</td>
<td>0x1e</td>
<td>30</td>
<td>R7100</td>
<td>0x34</td>
<td>52</td>
</tr>
<tr>
<td>765</td>
<td>0x2c</td>
<td>44</td>
<td>R8500</td>
<td>0x4a</td>
<td>74</td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td>R9000</td>
<td>0x2a</td>
<td>42</td>
</tr>
</table>
<h4 id="setup">Setup and Debugging Aids</h4>
<p>The audio drivers include extensive setup and 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>
<p>Connecting radios and IRIG devices to the computer and verifying correct
configuration is somewhat of a black art. The signals have to be connected
to the correct ports and the signal level maintained within tolerances. Some
radios have recorder outputs which produce a microphone-level signal not affected
by the volume control. These signals can be connected to the microphone port
on the computer. If the radio does not have a recorder output, connect the
headphone or speaker output to the line-in port and adjust the volume control
so the driver indicates comfortably above the minimum specified and the AGC
level somewhere in the middle of the range 0-255. IRIG signals are usually
much larger than radio outputs, usually in the range to several volts and
may even overload the line-in port. In such cases the signal is designed to
drive a cable terminated with a 50-ohm resistor, which results in a level
the line-in port can handle..</p>
<p>It is very easy to underdriven or overdrive the audio codec, in which case
the drivers will not synchronize to the signal. The drivers use <tt>fudge
flag2</tt> to enable audio monitoring of the input signal. This is useful
during setup to confirm the signal is actually reaching the audio
codec and generally free of noise and interference. Note that the monitor
volume must be set before the driver is started.</p>
<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 UTC 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.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

65
html/authentic.html Normal file
View File

@ -0,0 +1,65 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Authentication Support</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
<!--
<style1 {
color: #FF0000;
font-weight: bold;
}
.style1 {color: #FF0000}
-->
</style>
</head>
<body>
<h3>Authentication Support</h3>
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->1-Dec-2012 04:44<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#auth">Introduction</a></li>
<li class="inline"><a href="#symm">Symmetric Key Cryptography</a></li>
<li class="inline"><a href="#windows">Microsoft Windows Authentication</a></li>
<li class="inline"><a href="#pub">Public Key Cryptography</a></li>
</ul>
<hr>
<h4 id="auth">Introduction</h4>
<p>This page describes the various cryptographic authentication provisions in NTPv4. Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. A detailed discussion of the NTP multi-layer security model and vulnerability analysis is in the white paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP Security Analysis</a>.</p>
<p> The NTPv3 specification (RFC-1305) defined an authentication scheme properly described as <em>symmetric key cryptography</em>. It used the Data Encryption Standard (DES) algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this algorithm was replaced by the RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same message digest as the server. The MD5 message digest algorithm is included in the distribution, so without further cryptographic support, the distribution can be freely exported.</p>
<p>If the OpenSSL cryptographic library is installed prior to building the distribution, all message digest algorithms included in the library may be used, including SHA and SHA1. However, if conformance to FIPS 140-2 is required, only a limited subset of these algorithms can be used. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the library routines
required.</p>
<p>In addition to the symmetric key algorithms, this distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 &quot;Network Time Protocol Version 4: Autokey Specification&quot;. This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is used when the distribution is built.</p>
<p> Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, the OpenSSL application program, or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
<p>Note that according to US law, NTP binaries including OpenSSL library components, including the OpenSSL library itself, cannot be exported outside the US without license from the US Department of Commerce. Builders outside the US are advised to obtain the OpenSSL library directly from OpenSSL, which is outside the US, and build outside the US.</p>
<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt> configuration command, as described in the <a href="confopt.html">Server Options</a> page. The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
<p>By default, the client sends non-authenticated packets and the server responds with non-authenticated packets. If the client sends authenticated packets, the server responds with authenticated packets if correct, or a crypto-NAK packet if not.. In the case of unsolicited packets which might consume significant resources, such as broadcast or symmetric mode packets, , authentication is required, unless overridden by a <tt>disable auth</tt> command. In the current climate of targeted broadcast or &quot;letterbomb&quot; attacks, defeating this requirement would be decidedly dangerous. In any case, the <tt>notrust </tt>flag, described on the <a href="authopt.html">Access Control Options</a> page, can be used to disable access to all but correctly authenticated clients..</p>
<h4 id="symm">Symmetric Key Cryptography</h4>
<p>The original NTPv3 specification (RFC-1305), as well as the current NTPv4 specification (RFC-5905), allows any one of possibly 65,534 message digest keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key ID, key type and key to authenticate NTP packets.</p>
<p>The message digest is a cryptographic hash computed by an algorithm such as MD5 or SHA. When authentication is specified, a message authentication code (MAC) is appended to the NTP packet header. The MAC consists of a 32-bit key identifier (key ID) followed by a 128- or 160-bit message digest. The algorithm computes the digest as the hash of a 128- or 160- bit message digest key concatenated with the NTP packet header fields with the exception of the MAC. On transmit, the message digest is computed and inserted in the MAC. On receive, the message digest is computed and compared with the MAC. The packet is accepted only if the two MACs are identical. If a discrepancy is found by the client, the client ignores the packet, but raises an alarm. If this happens at the server, the server returns a special message called a <em>crypto-NAK</em>. Since the crypto-NAK is protected by the loopback test, an intruder cannot disrupt the protocol by sending a bogus crypto-NAK.</p>
<p>Keys and related information are specified in a keys file, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor.</p>
<p> Each line of the keys file consists of three fields: a key ID in the range 1 to 65,534, inclusive, a key type, and a message digest key consisting of a printable ASCII string less than 40 characters, or a 40-character hex digit string. If the OpenSSL library is installed, the key type can be any message digest algorithm supported by the library. If the OpenSSL library is not installed, the only permitted key type is MD5.</p>
<div align="center">
<p><img src="pic/sx5.gif" alt="gif"></p>
<p>Figure 1. Typical Symmetric Key File</p>
</div>
<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed. In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is a 40-character hex digit string. The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The line can be edited later or new lines can be added to change any field. The key can be change to a password, such as <tt>2late4Me</tt> for key ID 10. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</p>
<p>When <tt>ntpd</tt> is started, it reads the keys file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpq</tt> or <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
<h4 id="windows">Microsoft Windows Authentication</h4>
<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="accopt.html#restrict">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>
<h4 id="pub">Public Key Cryptography</h4>
<p>See the <a href="autokey.html">Autokey Public-Key Authentication</a> page.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

538
html/authopt.html
View File

@ -1,493 +1,95 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Authentication Options</title>
<title>Authentication Commands and Options</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
<!--
.style1 { color: #FF0000;
.style1 {
color: #FF0000;
font-weight: bold;
}
-->
</style>
</head>
<body>
<h3>Authentication Options</h3>
<h3>Authentication Commands and Options</h3>
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->14-Apr-2010 20:49<!-- #EndDate -->
UTC</p>
<p>Last update:
<!-- #BeginDate format:En2m -->15-Oct-2011 01:00<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#auth">Introduction</a></li>
<li class="inline"><a href="#symm">Symmetric Key Cryptography</a></li>
<li class="inline"><a href="#pub">Public Key Cryptography</a></li>
<li class="inline"><a href="#group">NTP Secure Groups</a></li>
<li class="inline"><a href="#ident">Identity Schemes and Cryptotypes</a></li>
<li class="inline"><a href="#cfg">Configuration</a></li>
<li class="inline"><a href="#exam">Examples</a></li>
<li class="inline"><a href="#cmd">Authentication Commands</a></li>
<li class="inline"><a href="#err">Error Codes</a></li>
<li class="inline"><a href="#file">Files</a></li>
</ul>
<hr>
<h4 id="auth">Introduction</h4>
<p>This page describes the various cryptographic authentication provisions in
NTPv4. Details about the configuration commands and options are given on
the <a href="confopt.html">Configuration
Options</a> page. Details about the automatic server discovery schemes are described
on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. Additional
information is available in the papers, reports, memoranda and briefings
cited on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.
Authentication support allows the NTP client to verify that servers are in
fact known and trusted and not intruders intending accidentally or intentionally
to masquerade as a legitimate server.</p>
<p> The NTPv3 specification RFC-1305 defines a scheme properly described as
symmetric key cryptography. It uses the Data Encryption Standard (DES)
algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this
scheme was replaced by the RSA Message Digest 5 (MD5) algorithm commonly
called keyed-MD5. Either algorithm computes a message digest or one-way hash
which can be used to verify the client has the same key and key identifier
as the server. If the OpenSSL cryptographic library is installed, support
is available for all algorithms included in the library. Note however, if
conformance to FIPS 140-2 is required, only a limited subset of these algorithms
is available.</p>
<p>NTPv4 includes the NTPv3 scheme
and optionally a new scheme based on public key cryptography and called
Autokey. Public key cryptography is generally considered more secure than
symmetric key cryptography, since the security is based on private and public
values which are generated by each participant and where the private value
is never revealed. Autokey uses X.509 public certificates, which can be produced
by commercial services, utility programs in the OpenSSL software library
or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility
program in the NTP software distribution.</p>
<p>While the algorithms for MD5 symmetric key cryptography are included in the
NTPv4 software distribution, modern algorithms for symmetric key and public
key cryptograpny requires the OpenSSL software library
to be installed before building the NTP distribution. This library is available
from <a href="http://www.openssl.org">http://www.openssl.org</a> and
can be installed using the procedures outlined in the <a href="build.html">Building
and Installing the Distribution</a> page. Once installed, the configure and
build process automatically detects the library and links the library routines
required.</p>
<p>Note that according to US law, NTP binaries including OpenSSL library components,
including the OpenSSL library itself, cannot be exported outside the
US without license from the US Department of Commerce. Builders outside the
US are advised to obtain the OpenSSL library directly from OpenSSL, which
is outside the US, and build outside the US.</p>
<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt> configuration command, as described in the <a href="confopt.html">Server Options</a> page, and the options described on this page. The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
<h4 id="symm">Symmetric Key Cryptography</h4>
<p>The original RFC-1305 specification allows any one of possibly 65,534 keys
(excluding zero), each distinguished by a 32-bit key ID, to authenticate
an association. The servers and clients involved must agree on the key, key
ID and key type to authenticate NTP packets. If an NTP packet includes a
message authentication code (MAC), consisting of a key ID and message digest,
it is accepted only if the key ID matches a trusted key and the message digest
is verified with this key. Note that for historic reasons the message digest
algorithm is not consistent with RFC-1828. The digest is computed directly
from the concatenation of the key string followed by the packet contents
with the exception of the MAC itself.</p>
<p>Keys and related information are specified in a keys file, usually called <tt>ntp.keys</tt>,
which must be distributed and stored using secure means beyond the scope
of the NTP protocol itself. Besides the keys used for ordinary NTP associations,
additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility
programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program,
but it can be constructed and edited using an ordinary text editor. The
program generates pseudo-random keys, one key for each line. Each line consists
of three fields, the key identifier as a decimal number from 1 to 65534 inclusive,
a key type chosen from the keywords of the <tt>digest</tt> option of the <tt>crypto</tt> command,
and a 20-character printable ASCII string or a 40-character hex string as
the key itself.</p>
<p>When <tt>ntpd</tt> is first started, it reads the key file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
<p>By default, the message digest algorithm is MD5 selected by the key type
<tt>M</tt> in the keys file. However, if the OpenSSL library is installed,
any message digest algorithm supported by that library can be used. The key
type is selected as the algorithm name given in the OpenSSL documentation.
The key type is associated with the key and can be different for different
keys. The server and client
must share the same key, key ID and key type and both must be trusted. Note
that if conformance to FIPS 140-2 is required, the message digest algorithm
must conform to the Secure Hash Standard (SHS), which requires an algorithm
from the Secure Hash Algorithm (SHA) family, and the digital signature encryption
algorithm, if used, must conform to the Digital Signature Standard (DSS),
which requires the Digital Signature Algorithm (DSA).</p>
<p>In addition to the above means, <tt>ntpd</tt> now supports
Microsoft Windows MS-SNTP authentication using Active Directory services.
This support was contributed by the Samba Team and is still in development.
It is enabled using the <tt>mssntp</tt> flag
of the <tt>restrict</tt> command described on
the <a href="authopt.html">Access Control Options</a> page. <span class="style1">Note:
Potential users should be aware that these services involve a TCP connection
to another process that could potentially block, denying services to other
users. Therefore, this flag should be used only for a dedicated server with
no clients other than MS-SNTP.</span></p>
<h4 id="pub">Public Key Cryptography</h4>
<p>NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. These schemes provide strong security against replay with or without message modification, spoofing, masquerade and most forms of clogging attacks. These schemes are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
<p>Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers are operated outside firewall perimeters.</p>
<p>There are three timeouts associated with the Autokey scheme. The key list timeout, which defaults to about 1.1 h, specifies the interval between generating new key lists. The revoke timeout, which defaults to about 36 h, specifies the interval between generating new private values. The restart timeout, with default about 5 d, specifies the interval between protocol restarts to refresh public values. In general, the behavior when these timeouts expire is not affected by the issues discussed on this page.</p>
<h4 id="group">NTP Secure Groups</h4>
<p>NTP secure groups are used to define cryptographic compartments and security
hierarchies. All hosts belonging to a secure group have the same group name
but different host names. The string specified in the <tt>host</tt> option of
the <tt>crypto</tt> command is the name of the host and the name used in the
host key, sign key and certificate files. The string specified in the <tt>ident</tt> option
of the <tt>crypto</tt> command is the group name of all group hosts and the
name used in the identity files. The file naming conventions are described on
the <a href="keygen.html">ntp-keygen</a> page.</p>
<p>Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The group name is used in the subject and issuer fields of the TH self-signed trusted certificate for these hosts. The host name is used in the subject and issuer fields of the self-signed certificates for all other hosts.</p>
<p>All group hosts are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts and ending at a TH. When a host starts up, it recursively retrieves the certificates along the trail in order to verify group membership and avoid masquerade and middleman attacks.</p>
<p>Secure groups can be configured as hierarchies where a TH of one group can be a client of one or more other groups operating at a lower stratum. A certificate trail consist of a chain of hosts starting at a client, leading through secondary servers of progressively lower stratum and ending at a TH. In one scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. There are many other scenarios, but all must be configured to include only acyclic certificate trails.</p>
<h4 id="ident">Identity Schemes and Cryptotypes</h4>
<p>All configurations include a public/private host key pair and matching certificate. Absent an identity scheme, this is a Trusted Certificate (TC) scheme. There are three identity schemes, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page. With these schemes all servers in the group have encrypted server identity keys, while clients have nonencrypted client identity parameters. The client parameters can be obtained from a trusted agent (TA), usually one of the THs of the lower stratum group. Further information on identity schemes is on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page.</p>
<p>A specific combination of authentication and identity schemes is called a
cryptotype, which applies to clients and servers separately. A group can be
configured using more than one cryptotype combination, although not all combinations
are interoperable. Note however that some cryptotype combinations may successfully
intemperate with each other, but may not represent good security practice. The
server and client cryptotypes are defined by the the following codes.</p>
<h4>Commands and Options</h4>
<p>Unless noted otherwise, further information about these commands is on the <a href="authentic.html">Authentication Support</a> page.</p>
<dl>
<dt>NONE</dt>
<dd>A client or server is type NONE if authentication is not available or not configured. Packets exchanged between client and server have no MAC.</dd>
<dt>AUTH</dt>
<dd>A client or server is type AUTH&nbsp;if the <tt>key</tt> option is specified with the <tt>server</tt> configuration command and the client and server keys are compatible. Packets exchanged between clients and servers have a MAC.</dd>
<dt>PC</dt>
<dd>A client or server is type PC if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key and private certificate files are present. Packets exchanged between clients and servers have a MAC.</dd>
<dt>TC</dt>
<dd>A client or server is type TC if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key and public certificate files are present. Packets exchanged between clients and servers have a MAC.</dd>
<dt>IDENT</dt>
<dd>A client or server is type IDENT if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key, public certificate and identity scheme files are present. Packets exchanged between clients and servers have a MAC.</dd>
</dl>
<p>The compatible cryptotypes for clients and servers are listed in the following table.</p>
<table width="100%" border="1" cellpadding="4">
<tr>
<td align="center">Client/Server</td>
<td align="center">NONE</td>
<td align="center">AUTH</td>
<td align="center">PC</td>
<td align="center">TC</td>
<td align="center">IDENT</td>
</tr>
<tr>
<td align="center">NONE</td>
<td align="center">yes</td>
<td align="center">yes*</td>
<td align="center">yes*</td>
<td align="center">yes*</td>
<td align="center">yes*</td>
</tr>
<tr>
<td align="center">AUTH</td>
<td align="center">no</td>
<td align="center">yes</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
</tr>
<tr>
<td align="center">PC</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">yes</td>
<td align="center">no</td>
<td align="center">no</td>
</tr>
<tr>
<td align="center">TC</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">yes</td>
<td align="center">yes</td>
</tr>
<tr>
<td align="center">IDENT</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">yes</td>
</tr>
</table>
<p>* These combinations are not valid if the restriction list includes the <tt>notrust</tt> option.</p>
<h4 id="cfg">Configuration</h4>
<p>Autokey has an intimidating number of configuration options, most of which are not necessary in typical scenarios. The simplest scenario consists of a TH where the host name of the TH is also the name of the group. For the simplest identity scheme TC, the TH generates host key and trusted certificate files using the <tt>ntp-keygen -T</tt> command, while the remaining group hosts use the same command with no options to generate the host key and public certificate files. All hosts use the <tt>crypto</tt> configuration command with no options. Configuration with passwords is described in the <a href="keygen.html">ntp-keygen</a> page. All group hosts are configured as an acyclic tree with root the TH.</p>
<p>When an identity scheme is included, for example IFF, the TH generates host
key, trusted certificate and private server identity key files using the <tt>ntp-keygen
-T -I -i <i>group</i></tt> command, where <tt><i>group</i></tt> is the group
name. The remaining group hosts use the same command as above. All hosts
use the <tt>crypto ident group<i></i></tt> configuration command.</p>
<p>Hosts with no dependent clients can retrieve client parameter files from an
archive or web page. The <tt>ntp-keygen</tt> can export these data using the <tt>-e</tt> option.
Hosts with dependent clients other than the TH must retrieve copies of the server
key files using secure means. The <tt>ntp-keygen</tt> can export these data
using the <tt>-q</tt> option. In either case the data are installed as a file
and then renamed using the name given as the first line in the file, but without
the filestamp.</p>
<h4 id="exam">Examples</h4>
<div align="center">
<img src="pic/group.gif" alt="gif">
</div>
<p>Consider a scenario involving three secure groups RED, GREEN and BLUE. RED and BLUE are typical of national laboratories providing certified time to the Internet at large. As shown ion the figure, RED TH mort and BLUE TH macabre run NTP symmetric mode with each other for monitoring or backup. For the purpose of illustration, assume both THs are primary servers. GREEN is typical of a large university providing certified time to the campus community. GREEN TH howland is a broadcast client of both RED and BLUE. BLUE uses the IFF scheme, while both RED and GREEN use the GQ scheme, but with different keys. YELLOW is a client of GREEN and for purposes of illustration a TH for YELLOW.</p>
<p>The BLUE TH macabre uses configuration commands</p>
<p><tt>crypto pw qqsv ident blue</tt><br>
<tt>peer mort autokey</tt><br>
<tt>broadcast <i>address</i> autokey</tt></p>
<p>where <tt>qqsv</tt> is the password for macabre files and <i>address</i> is the broadcast address for the local LAN. It generates BLUE files using the commands</p>
<p><tt>ntp-keygen -p qqsv -T -G -i blue</tt><br>
<tt>ntp-keygen -p qqsv -e &gt;ntpkey_gqpar_blue</tt></p>
<p>The first line generates the host, trusted certificate and private GQ server keys file. The second generates the public GQ client parameters file, which can have any nonconflicting mnemonic name.</p>
<p>The RED TH mort uses configuration commands</p>
<p><tt>crypto pw xxx ident red</tt><br>
<tt>peer macabre autokey</tt><br>
<tt>broadcast <i>address</i> autokey</tt></p>
<p>where <tt>xxx</tt> is the password for mort files. It generates RED files using the commands</p>
<p><tt>ntp-keygen -p xxx -T -I -i red</tt><br>
<tt>ntp-keygen -p xxx -e &gt;ntpkey_iffpar_red</tt></p>
<p> The GREEN TH howland uses configuration commands</p>
<p><tt>crypto pw yyy ident green</tt><br>
<tt>broadcastclient</tt></p>
<p>where <tt>yyy</tt> is the password for howland files. It generates GREEN files using the commands</p>
<p><tt>ntp-keygen -p yyy -T -G -i green</tt><br>
<tt>ntp-keygen -p yyy -e &gt;ntpkey_gqpar_green</tt><br>
<tt>ntp-keygen -p yyy -q zzz &gt;zzz_ntpkey_gqkey_green</tt></p>
<p>The first two lines serve the same purpose as the preceding examples. The
third line generates a copy of the private GREEN server file for use on another
server in the same group, say YELLOW, but encrypted with the <tt>zzz</tt> password.</p>
<p>A client of GREEN, for example YELLOW, uses the configuration commands</p>
<p><tt>crypto pw abc ident green</tt><br>
<tt>server howland autokey</tt></p>
<p>where <tt>abc</tt> is the password for its files. It generates files using the command</p>
<p><tt>ntp-keygen -p abc</tt></p>
<p>The client retrieves the client file for that group from a public archive or web page using nonsecure means. In addition, each server in a group retrieves the private server keys file from the TH of that group, but it is encrypted and so must be sent using secure means. The files are installed in the keys directory with name taken from the first line in the file, but without the filestamp.</p>
<p>Note that if servers of different groups, in this case RED and BLUE, share the same broadcast media, each server must have client files for all groups other than its own, while each client must have client files for all groups. Note also that this scenario is for illustration only and probably would not be wise for practical use, as if one of the TH reference clocks fails, the certificate trail becomes cyclic. In such cases the symmetric path between RED and BLUE, each in a different group, would not be a good idea.</p>
<h4 id="cmd">Authentication Commands</h4>
<dl>
<dt id=automax><tt>automax [<i>logsec</i>]</tt></dt>
<dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol, as a power of 2 in seconds. Note that the size of the key list for each association depends on this interval and the current poll interval. The default interval is 12 (about 1.1 h). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent.</dd>
<dt id="controlkey"><tt>controlkey <i>keyid</i></tt></dt>
<dd>Specifies the key ID to use with the <a
<dt id=automax><tt>automax [<i>logsec</i>]</tt></dt>
<dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol, as a power of 2 in seconds. Note that the size of the key list for each association depends on this interval and the current poll interval. The default interval is 12 (about 1.1 hr). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information.</dd>
<dt id="controlkey"><tt>controlkey <i>keyid</i></tt></dt>
<dd>Specifies the key ID for the <a
href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the
standard protocol defined in RFC-1305. The <tt><i>keyid</i></tt>
argument is the key ID for a <a href="#trustedkey">trusted
key</a>, where the value can be in the range 1 to 65534,
inclusive.</dd>
<dt id="crypto"><tt>crypto [randfile <i>file</i>] [host <i>name</i>] [ident <i>name</i>] [pw <i>password</i>]</tt></dt>
<dd>This command requires the OpenSSL library. It activates public key cryptography
and loads the required host key and public certificate. If one or more files
are left unspecified, the default names are used as described below. Unless
the complete path and name of the file are specified, the location of a file
is relative to the keys directory specified in the <tt>keysdir</tt> configuration
command or default <tt>/usr/local/etc</tt>. Following are the options.</dd>
<dd><dl>
<dt><tt>digest</tt> <tt>MD2</tt> | <tt>MD4</tt> | <tt>MD5</tt> | <tt>MDC2</tt> | <tt>RIPEMD160</tt> | <tt>SHA</tt> | <tt>SHA1</tt></dt>
<dd>Specify the message digest algorithm, with default MD5. If the OpenSSL library
is installed, <tt><i>name</i></tt> can be be any message digest algorithm supported
by the library not exceeding 160 bits in length. However, all Autokey
participants in an Autokey subnet must use the same algorithm. Note that
the Autokey message digest algorithm is separate and distinct form the symmetric
key message digest algorithms. Note: If compliance with FIPS 140-2 is required,
the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>.</dd>
<dt><tt>host <i>name</i></tt></dt>
<dd>Specifies the string used when constructing the names for the host, sign
and certificate files generated by the <tt>ntp-keygen</tt> program with the <tt>-s <i>name</i></tt> option.</dd>
<dt><tt>ident <i>name</i></tt></dt>
<dd>Specifies the string used in constructing the identity files generated by the <tt>ntp-keygen</tt> program with the <tt>-i <i>name</i></tt> option.</dd>
<dt><tt>pw <i>password</i></tt></dt>
<dd>Specifies the password to decrypt files previously encrypted by the <tt>ntp-keygen</tt> program with the <tt>-p</tt> option.</dd>
<dt><tt>randfile <i>file</i></tt></dt>
<dd>Specifies the location of the random seed file used by the OpenSSL library. The defaults are described on the <tt>ntp-keygen</tt> page.</dd>
</dl></dd>
<dt id="keys"><tt>keys <i>keyfile</i></tt></dt>
<dd>Specifies the complete path to the MD5 key file containing the keys and key IDs used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. This is the same operation as the <tt>-k </tt>command line option. Note that the directory path for Autokey media is specified by the <tt>keysdir</tt> command.</dd>
<dt id="keysdir"><tt>keysdir <i>path</i></tt>K</dt>
<dd>This command specifies the default directory path for Autokey cryptographic keys, parameters and certificates. The default is <tt>/usr/local/etc/</tt>. Note that the path for the symmetric keys file is specified by the <tt>keys</tt> command.</dd>
<dt id="requestkey"><tt>requestkey <i>keyid</i></tt></dt>
<dd>Specifies the key ID to use with the
<a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which
uses a proprietary protocol specific to this implementation of
<tt>ntpd</tt>. The <tt><i>keyid</i></tt> argument is a key ID
for a <a href="#trustedkey">trusted key</a>, in the range 1 to
65534, inclusive.</dd>
<dt id="revoke"><tt>revoke [<i>logsec</i>]</tt></dt>
<dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. These values need to be updated frequently in order to deflect brute-force attacks on the algorithms; however, updating some values is a relatively expensive operation. The default interval is 17 (about 36 h). For poll intervals above the specified interval, the values will be updated for every message sent.</dd>
<dt id="trustedkey"><tt>trustedkey [<i>keyid</i> | (<i>lowid</i> ... <i>highid</i>)] [...]</tt></dt>
<dd>Specifies the key ID(s) which are trusted for the purposes of
authenticating peers with symmetric key cryptography. Key IDs
used to authenticate <tt>ntpq</tt> and <tt>ntpdc</tt> operations
must be listed here and additionally be enabled with
<a href="#controlkey">controlkey</a> and/or
<a href="#requestkey">requestkey</a>. The authentication
procedure for time transfer require that both the local and
remote NTP servers employ the same key ID and secret for this
purpose, although different keys IDs may be used with different
servers. Ranges of trusted key IDs may be specified:
"<tt>trustedkey (1 ... 19) 1000 (100 ... 199)</tt>" enables the
lowest 120 key IDs which start with the digit 1. The spaces
surrounding the ellipsis are required when specifying a range.</dd>
standard protocol defined in RFC-1305. The <tt><i>keyid</i></tt> argument is the key ID for a <a href="#trustedkey">trusted
key</a>, where the value can be in the range 1 to 65534,
inclusive.</dd>
<dt id="crypto"><tt>crypto [digest</tt> <em><tt>digest</tt></em><tt>]</tt> <tt>[host <i>name</i>] [ident <i>name</i>] [pw <i>password</i>] [randfile <i>file</i>]</tt></dt>
<dd>This command activates the Autokey public key cryptography
and loads the required host keys and certificate. If one or more files
are unspecified, the default names are used. Unless
the complete path and name of the file are specified, the location of a file
is relative to the keys directory specified in the <tt>keysdir</tt> configuration
command with default <tt>/usr/local/etc</tt>. See the <a href="autokey.html">Autokey Public Key Authentication</a> page for further information. Following are the options.</dd>
<dd>
<dl>
<dt><tt>digest</tt> <em><tt>digest</tt></em></dt>
<dd>&nbsp;</dd>
<dd>Specify the message digest algorithm, with default MD5. If the OpenSSL library
is installed, <tt><i>digest</i></tt> can be be any message digest algorithm supported
by the library. The current selections are: <tt>MD2</tt>, <tt>MD4</tt>, <tt>MD5,</tt> <tt>MDC2</tt>, <tt>RIPEMD160</tt>, <tt>SHA</tt> and <tt>SHA1</tt>. All
participants in an Autokey subnet must use the same algorithm. The Autokey message digest algorithm is separate and distinct from the symmetric
key message digest algorithm. Note: If compliance with FIPS 140-2 is required,
the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>.</dd>
<dt><tt>host <i>name</i></tt></dt>
<dd>Specify the cryptographic media names for the host, sign and certificate files. If this option is not specified, the default name is the string returned by the Unix <tt>gethostname()</tt> routine.</dd>
<dd><span class="style1">Note: In the latest Autokey version, this option has no effect other than to change the cryptographic media file names.</span></dd>
<dt><tt>ident <i>group</i></tt></dt>
<dd>Specify the cryptographic media names for the identity scheme files. If this option is not specified, the default name is the string returned by the Unix <tt>gethostname()</tt> routine.</dd>
<dd><span class="style1">Note: In the latest Autokey version, this option has no effect other than to change the cryptographic media file names.</span></dd>
<dt><tt>pw <i>password</i></tt></dt>
<dd>Specifies the password to decrypt files previously encrypted by the <tt>ntp-keygen</tt> program with the <tt>-p</tt> option. If this option is not specified, the default password is the string returned by the Unix <tt>gethostname()</tt> routine. </dd>
<dt><tt>randfile <i>file</i></tt></dt>
<dd>Specifies the location of the random seed file used by the OpenSSL library. The defaults are described on the <a href="keygen.html"><tt>ntp-keygen</tt> page</a>.</dd>
</dl>
</dd>
<dt id="ident"><tt>ident <i>group</i></tt></dt>
<dd>Specifies the group name for ephemeral associations mobilized by broadcast and symmetric passive modes. See the <a href="autokey.html">Autokey Public-Key Authentication</a> page for further information.</dd>
<dt id="keys"><tt>keys <i>path</i></tt></dt>
<dd>Specifies the complete directory path for the key file containing the key IDs, key types and keys used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. The format of the keyfile is described on the <a href="keygen.html"><tt>ntp-keygen</tt> page</a>. This is the same operation as the <tt>-k</tt> command line option. Note that the directory path for Autokey cryptographic media is specified by the <tt>keysdir</tt> command.</dd>
<dt id="keysdir"><tt>keysdir <i>path</i></tt></dt>
<dd>Specifies the complete directory path for the Autokey cryptographic keys, parameters and certificates. The default is <tt>/usr/local/etc/</tt>. Note that the path for the symmetric keys file is specified by the <tt>keys</tt> command.</dd>
<dt id="requestkey"><tt>requestkey <i>keyid</i></tt></dt>
<dd>Specifies the key ID for the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which
uses a proprietary protocol specific to this implementation of <tt>ntpd</tt>. The <tt><i>keyid</i></tt> argument is a key ID
for a <a href="#trustedkey">trusted key</a>, in the range 1 to
65534, inclusive.</dd>
<dt id="revoke"><tt>revoke [<i>logsec</i>]</tt></dt>
<dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds, with default 17 (36 hr). See the <a href="autokey.html">Autokey Public-Key Authentication</a> page for further information.</dd>
<dt id="trustedkey"><tt>trustedkey [<i>keyid</i> | (<i>lowid</i> ... <i>highid</i>)] [...]</tt></dt>
<dd>Specifies the key ID(s) which are trusted for the purposes of
authenticating peers with symmetric key cryptography. Key IDs
used to authenticate <tt>ntpq</tt> and <tt>ntpdc</tt> operations
must be listed here and additionally be enabled with <a href="#controlkey">controlkey</a> and/or <a href="#requestkey">requestkey</a>. The authentication
procedure for time transfer requires that both the local and
remote NTP servers employ the same key ID and secret for this
purpose, although different keys IDs may be used with different
servers. Ranges of trusted key IDs may be specified: <tt>trustedkey (1 ... 19) 1000 (100 ... 199)</tt> enables the
lowest 120 key IDs which start with the digit 1. The spaces
surrounding the ellipsis are required when specifying a range.</dd>
</dl>
<h4 id="err">Error Codes</h4>
<p>Errors can occur due to mismatched configurations, unexpected protocol restarts, expired certificates and unfriendly people. In most cases the protocol state machine recovers automatically by retransmission, timeout and restart, where necessary. Some errors are due to mismatched keys, digest schemes or identity schemes and must be corrected by installing the correct media and/or correcting the configuration file. One of the most common errors is expired certificates, which must be regenerated and signed at least once per year using the <a href="keygen.html"><tt>ntp-keygen</tt> - generate public and private keys</a> program.</p>
<p>The following error codes are reported via the NTP control and monitoring protocol trap mechanism and to the <tt>cryptostats</tt> monitoring file if configured.</p>
<dl>
<dt>101 bad field format or length</dt>
<dd>The packet has invalid version, length or format.</dd>
<dt>102 bad timestamp</dt>
<dd>The packet timestamp is the same or older than the most recent received. This could be due to a replay or a server clock time step.</dd>
<dt>103 bad filestamp</dt>
<dd>The packet filestamp is the same or older than the most recent received. This could be due to a replay or a key file generation error.</dd>
<dt>104 bad or missing public key</dt>
<dd>The public key is missing, has incorrect format or is an unsupported type.</dd>
<dt>105 unsupported digest type</dt>
<dd>The server requires an unsupported digest/signature scheme.</dd>
<dt>106 unsupported identity type</dt>
<dd>The client or server has requested an identity scheme the other does not support.</dd>
<dt>107 bad signature length</dt>
<dd>The signature length does not match the current public key.</dd>
<dt>108 signature not verified</dt>
<dd>The message fails the signature check. It could be bogus or signed by a different private key.</dd>
<dt>109 certificate not verified</dt>
<dd>The certificate is invalid or signed with the wrong key.</dd>
<dt>110 host certificate expired</dt>
<dd>The old server certificate has expired.</dd>
<dt>111 bad or missing cookie</dt>
<dd>The cookie is missing, corrupted or bogus.</dd>
<dt>112 bad or missing leapseconds table</dt>
<dd>The leapseconds table is missing, corrupted or bogus.</dd>
<dt>113 bad or missing certificate</dt>
<dd>The certificate is missing, corrupted or bogus.</dd>
<dt>114 bad or missing group key</dt>
<dd>The identity key is missing, corrupt or bogus.</dd>
<dt>115 protocol error</dt>
<dd>The protocol state machine has wedged due to unexpected restart.</dd>
</dl>
<h4 id="file">Files</h4>
<p>See the <a href="keygen.html"><tt>ntp-keygen</tt></a> page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

215
html/autokey.html Normal file
View File

@ -0,0 +1,215 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Autokey Public-Key Authentication</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
<!--
.style1 {
color: #FF0000
}
-->
</style>
</head>
<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->3-Oct-2011 21:51<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a></li>
<li class="inline"><a href="#subnet">Autokey Subnets</a></li>
<li class="inline"><a href="#names">Subnet Group Names's</a></li>
<li class="inline"><a href="#secure">Secure Groups</a></li>
<li class="inline"><a href="#cfg">Configuration - Authentication Schemes</a></li>
<li class="inline"><a href="#scfg">Configuration - Identity Schemes</a></li>
<li class="inline"><a href="#ident">Identity Schemes and Cryptotypes</a></li>
<li class="inline"><a href="#files">Files</a></li>
</ul>
<hr>
<h4 id="intro">Introduction</h4>
<p>This distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 &quot;Network Time Protocol Version 4: Autokey Specification&quot;. This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is specified when the distribution is built.</p>
<p> Public key cryptography is generally considered more secure than symmetric key cryptography. Symmetric key cryptography is based on a shared secret key which must be distributed by secure means to all participants. Public key cryptography is based on a private secret key known only to the originator and a public key known to all participants. A recipient can verify the originator has the correct private key using the public key and any of several digital signature algorithms.</p>
<p>The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using message digest algorithms, such as MD5 or SHA, and verifies the source using digital signature schemes, such as RSA or DSA. As used in Autokey, message digests are exceptionally difficult to cryptanalyze, as the keys are used only once.</p>
<p> Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. Optional identity schemes provide strong security against masquerade and most forms of clogging attacks. These schemes are exceptionally difficult to cryptanalyze, as the challenge/response exchange data are used only once. They are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
<p>Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same IP addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers and clients are operated outside firewall perimeters.</p>
<p>Autokey is designed to authenticate servers to clients, not the other way around as in SSH. An Autokey server can support an authentication scheme such as the Trusted Certificate (TC) scheme described in RFC 5906, while a client is free to choose between the various options. It is important to understand that these provisions are optional and that selection of which option is at the discretion of the client. If the client does not require authentication, it is free to ignore it, even if some other client of the same server elects to participate in either symmetric key or public key cryptography.</p>
<p> Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution. A certificate includes the subject name of the client, the issuer name of the server, the public key of the client and the time period over which the the public and private keys are valid. All Autokey hosts have a self-signed certificate with the Autokey name as both the subject and issuer. During the protocol, additional certificates are produced with the Autokey host name as subject and the host that signs the certificate as issuer.</p>
<p>There are two timeouts associated with the Autokey scheme. The <em>key list timeout</em> is set by the <tt>automax</tt> command, which specifies the interval between generating new key lists by the client or server. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The <em>revoke timeout</em> is set by the <tt>revoke</tt> command, which specifies the interval between generating new server private values. It is intended to reduce the vulnerability to cryptanalysis; however, new values require the server to encrypt each client cookie separately. The default timeout of about 36 hr is appropriate for most servers, but might be too short for national time servers.</p>
<h4 id="subnet">Autokey Subnets</h4>
<p> An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. Note that the requirement that the NTP subnet be acyclic means that, if two hosts are configured with each other in symmetric modes, each must be a TH. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or one or more trusted agents (TAs) of a parent subnet. NTP subnets can be nested, with the THs of a child subnet configured for one or more TAs of a parent subnet. The TAs can serve one or more child subnets, each with its own security policy and set of THs.</p>
<p>A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. The requirement that the subnet be acyclic means certificate trails can never loop. NTP servers operate as certificate authorities (CAs) to sign certificates provided by their clients. The CAs include the TAs of the parent subnet and those subnet servers with dependent clients.</p>
<p> In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired.</p>
<p>The Autokey protocol runs for each association separately, During the protocol, the client recursively obtains the certificates on the trail to a TH, saving each in a cache ordered from most recent to oldest. If an expired certificate is found, it is invalidated and marked for later replacement. As the client certificate itself is not involved in the certificate trail, it can only be declared valid or expired when the server signs it. </p>
<p>The certificates derived from each association are combined in the cache with duplicates suppressed. If it happens that two different associations contribute certificates to the cache, a certificate on the trail from one association could expire before any on another trail. In this case the remaining trails will survive until the expired certificate is replaced. Once saved in the cache, a certificate remains valid until it expires or is replaced by a new one.</p>
<p> It is important to note that the certificate trail is validated only at startup when an association is mobilized. Once validated in this way, the server remains valid until it is demobilized, even if certificates on the trail to the THs expire. While the certificate trail authenticates each host on the trail to the THs, it does not validate the time values themselves. Ultimately, this is determined by the NTP on-wire protocol.</p>
<p>Example</p>
<div align="center"><img src="pic/flt8.gif" alt="gif">
<p>Figure 1. Example Configuration</p>
</div>
<p>Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Alice and Helen are parent groups for Carol with TA C belonging to Alice and TA S belonging to Helen. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server, child subnet TH X has two mobilized associations, one to Alice TA host C and the other to Carol TA host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.</p>
<p>Note that host D certificate trail is D&rarr;C&rarr;A or D&rarr;C&rarr;B, depending on the particular order the trails are built. Host Y certificate trail is only Y&rarr;X, since X is a TH. Host X has two certificate trails X&rarr;C&rarr;A or X&rarr;C&rarr;B, and X&rarr;S&rarr;R.</p>
<h4 id="names">Subnet Group Names</h4>
<p>In some configurations where more than one subnet shares an Ethernet or when multiple subnets exist in a manycast or pool configuration, it is useful to isolate one subnet from another. In Autokey this can be done using group names. An Autokey host name is specified by the <tt>-s</tt><tt><em> host</em>@<em>group</em></tt> option of the <tt>ntp-keygen</tt> program, where <em><tt>host</tt></em> is the host name and <em><tt>group</tt></em> is the group name. If <em><tt>host</tt></em> is omitted, the name defaults to the string returned by the Unix <tt>gethostname()</tt> routine, ordinarily the DNS name of the host. Thus, for host <tt>beauregard.udel.edu</tt> the option <tt>-s @red</tt> specifies the Autokey host name <tt>beauegard.udel.edu@red</tt>.</p>
<p>A subnet host with a given group name will discard ASSOC packets from all subnets with a different group name. This effectively disables the Autokey protocol without additional packet overhead. For instance, one or more manycast or pool servers will not respond to ASSOC packets from subnets with difference group names. Groups sharing an Ethernet will be filtered in the same way.</p>
<p>However, as shown in Figure 1, there are configurations where a TH of one group needs to listen to a TA of a different group. This is accomplished using the <tt>ident <em>group</em></tt> option of the <tt>crypto</tt> command and/or the <tt>ident <em>group</em></tt> option of the <tt>server</tt> command. The former case applies to all hosts sharing a common broadcast, manycast or symmetric passive modes, while the latter case applies to each individual client/server or symmetric active mode association. In either case the host listens to the specified group name in addition to the group name specified in the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program.</p>
<h4 id="secure">Secure Groups</h4>
<p>NTP security groups are an extension of the NTP subnets described in the previous section. They include in addition to certificate trails one or another identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page. NTP secure groups are used to define cryptographic compartments and security
hierarchies. The identity scheme insures that the server is authentic and not victim of masquerade by an intruder acting as a middleman.</p>
<p> An NTP secure group is an NTP subnet configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group. They run an identity exchange with the TAs of parent subnets All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH of that group. The TH verifies authenticity with the TA of the parent subnet using an identity exchange.</p>
<div align="center"><img src="pic/flt9.gif" alt="gif">
<p>Figure 2. Identify Scheme</p>
</div>
<p>The identity exchange is run between a TA acting as a server and a TH acting as a client. As shown in Figure 2, the identity exchange involves a challenge-response protocol where a client generates a nonce and sends it to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.</p>
<p> Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secret group key to persist long after the longest period of certificate validity. In the Schnorr (Identify Friend or Foe - IFF) scheme, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.</p>
<p>As described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted server keys file and a nonencrypted client keys file, also called the parameters file, which usually contains a subset of the keys file.</p>
<p> Figure 2 shows how keys and parameters are distributed to servers and clients. A TA constructs the encrypted keys file and the nonencrypted parameters file. Hosts with no dependent clients can retrieve client parameter files from an
archive or web page. The <tt>ntp-keygen</tt> program can export parameter files using the <tt>-e</tt> option. By convention, the file name is the name of the secure group and must match the <tt>ident</tt> option of the <tt>crypto</tt> command or the <tt>ident</tt> option of the <tt>server</tt> command.</p>
<p> When more than one TH Is involved in the secure group, it is convenient for the TAs and THs to use the same encrypted key files. To do this, one of the parent TAs includes the <tt>-i <em>group</em></tt> option on the <tt>ntp-keygen</tt> command line, where <em><tt>group</tt></em> is the name of the child secure group. The <tt>ntp-keygen</tt> program can export server keys files using the <tt>-q</tt> option and a chosen remote password. The files are installed on the TAs and then renamed using the name given as the first line in the file, but without the filestamp. The secure group name must match the <tt>ident</tt> option for all TAs.</p>
<dl>
<dd><span class="style1">In the latest Autokey version, the host name and group name are independent of each other and the <tt>host</tt> option of the <tt>crypto</tt> command is deprecated. When compatibility with older versions is required, specify the same name for both the <tt>-s</tt> and <tt>-i</tt> options.</span></dd>
</dl>
<p>In special circumstances the Autokey message digest algorithm can be changed using the <tt>digest</tt> option of the <tt>crypto</tt> command. The digest algorithm is separate and distinct from the symmetric
key message digest algorithm. If compliance with FIPS 140-2 is required,
the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.</p>
<p>Example</p>
<p>Returning to the example of Figure 1, Alice, Helen and Carol run run the Trusted Certificate (TC) scheme, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefore, both parent subnet TAs C and S run an identity exchange with child subnet TH X. Both have the same encrypted keys file and X the common parameters file.</p>
<h4 id="cfg">Configuration - Authentication Schemes</h4>
<p>Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple.</p>
<p> Referring to Figure 1, for each TH, A, B, R and X, as root:</p>
<p><tt># cd /usr/local/etc<br>
# ntp-keygen -T</tt></p>
<p>and for the other hosts the same commands without the <tt>-T</tt> option. This generates an RSA private/public host key file and a self-signed certificate file for the RSA digital signature algorithm with the MD5 message digest algorithm. For the THs a trusted certificate is generated; for the others a nontreusted certificate is generated. Include in the <tt>ntp.conf</tt> configuration file for all hosts other than the primary servers, A, B and R, something like</p>
<p><tt> # server <em>host</em> autokey<br>
# crypto<br>
# driftfile /etc/ntp.drift</tt></p>
<p>where <em><tt>host</tt></em> is the selected server name as shown in the figure. Servers A, B and R are configured for local reference clocks or trusted remoter servers as required.</p>
<p>In the above configuration examples, the default host name is the string returned by the Unix <tt>gethostname()</tt> routine, ordinarily the DNS name of the host. This name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys file. The host name can be changed using the <tt>-s</tt> option of the <tt>ntp-keygen</tt> program. The default password can be changed using the <tt>-p</tt> option of the <tt>ntp-keygen</tt> program and the <tt>pw</tt> option of the <tt>crypto</tt> configuration command.</p>
<p>Group names can be added to this configuration by including the <tt>-s <em>host</em>@<em>group</em></tt> option with the <tt>ntp-keygen</tt> program. For the purpose of illustration, the <tt><em>host</em></tt> string is empty, signifying the default host name. For example, @<tt>yellow</tt> can be used for the Alice group, @<tt>orange</tt> for the Helen group and @<tt>blue</tt> for the Carol group. In addition, for TH X the <tt>ident yellow</tt> option should be added to the <tt>server</tt> command for the Alice group and the <tt>ident orange</tt> option should be added to the <tt>server</tt> command for the Helen group.</p>
<h4 id="scfg">Configuration - Identity Schemes</h4>
<p> The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. It's best to start with a functioning TC configuration and add commands as necessary. We start with the subnets of Figure 1 configured as in the previous section. Recall that the parent subnet TA for Alice is C and for Helen is S. Each of the TAs generates an encrypted server keys file and nonencrypted client parameters file for the IFF identity scheme using the <tt>-I</tt> option of the <tt>ntp-keygen</tt> program. Note the TAs are not necessarily trusted hosts, so may not need the <tt>-T</tt> option.</p>
<p>The nonencrypted client parameters can be exported using the command</p>
<p><tt>ntp-keygen -e &gt;<i>file</i></tt>,</p>
<p>where the <tt>-e</tt> option redirects the client parameters to <em><tt>file</tt></em> via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command</p>
<p><tt>ntp-keygen -q <em>passw2</em> &gt;<i>file</i></tt>,</p>
<p>where <em><tt>passwd2</tt></em> is the read password for another TA. We won't need this file here.</p>
<p> While the file names used for the exported files are arbitrary, it is common practice to use the name given as the first line in the file with the filestamp suppressed. Thus, the nonencryted parameters file from each TA is copied to X with this name.</p>
<p>To complete the configuration, the TH includes the client parameters file name in the <tt>ident</tt> option of the the <tt>server</tt> command for the TA association</p>
<p><tt>server 1.2.3.4 ident <em>group</em>,</tt></p>
<p> where <em><tt>group</tt></em> is the file name given above. </p>
<h4 id="ident">Identity Schemes and Cryptotypes</h4>
<p>A specific combination of authentication and identity schemes is called a <em>cryptotype</em>, which applies to clients and servers separately. A group can be configured using more than one cryptotype combination, although not all combinations are interoperable. Note however that some cryptotype combinations may successfully intemperate with each other, but may not represent good security practice. The server and client cryptotypes are defined by the the following codes.</p>
<dl>
<dt>NONE</dt>
<dd>A client or server is type NONE if authentication is not available or not configured. Packets exchanged between client and server have no MAC.</dd>
<dt>AUTH</dt>
<dd>A client or server is type AUTH&nbsp;if the <tt>key</tt> option is specified with the <tt>server</tt> configuration command and the client and server keys are compatible. Packets exchanged between clients and servers have a MAC.</dd>
<dt>PC</dt>
<dd>A client or server is type PC if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key and private certificate files are present. Packets exchanged between clients and servers have a MAC.</dd>
<dt>TC</dt>
<dd>A client or server is type TC if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key and public certificate files are present. Packets exchanged between clients and servers have a MAC.</dd>
<dt>IDENT</dt>
<dd>A client or server is type IDENT if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key, public certificate and identity scheme files are present. Packets exchanged between clients and servers have a MAC.</dd>
</dl>
<p>The compatible cryptotypes for clients and servers are listed in the following table.</p>
<table width="100%" border="1" cellpadding="4">
<tr>
<td rowspan="2" align="center">Client</td>
<td colspan="5" align="center">Server</td>
</tr>
<tr>
<td align="center">NONE</td>
<td align="center">AUTH</td>
<td align="center">PC</td>
<td align="center">TC</td>
<td align="center">IDENT</td>
</tr>
<tr>
<td align="center">NONE</td>
<td align="center">yes</td>
<td align="center">yes*</td>
<td align="center">yes*</td>
<td align="center">yes*</td>
<td align="center">yes*</td>
</tr>
<tr>
<td align="center">AUTH</td>
<td align="center">no</td>
<td align="center">yes</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
</tr>
<tr>
<td align="center">PC</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">yes</td>
<td align="center">no</td>
<td align="center">no</td>
</tr>
<tr>
<td align="center">TC</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">yes</td>
<td align="center">yes</td>
</tr>
<tr>
<td align="center">IDENT</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">no</td>
<td align="center">yes</td>
</tr>
</table>
<p>* These combinations are not valid if the restriction list includes the <tt>notrust</tt> option.</p>
<h4 id="err">Error Codes</h4>
<p>Errors can occur due to mismatched configurations, unexpected protocol restarts, expired certificates and unfriendly people. In most cases the protocol state machine recovers automatically by retransmission, timeout and restart, where necessary. Some errors are due to mismatched keys, digest schemes or identity schemes and must be corrected by installing the correct media and/or correcting the configuration file. One of the most common errors is expired certificates, which must be regenerated and signed at least once per year using the <a href="keygen.html"><tt>ntp-keygen</tt> - generate public and private keys</a> program.</p>
<p>The following error codes are reported via the NTP control and monitoring protocol trap mechanism and to the <tt>cryptostats</tt> monitoring file if configured.</p>
<dl>
<dt>101 bad field format or length</dt>
<dd>The packet has invalid version, length or format.</dd>
<dt>102 bad timestamp</dt>
<dd>The packet timestamp is the same or older than the most recent received. This could be due to a replay or a server clock time step.</dd>
<dt>103 bad filestamp</dt>
<dd>The packet filestamp is the same or older than the most recent received. This could be due to a replay or a key file generation error.</dd>
<dt>104 bad or missing public key</dt>
<dd>The public key is missing, has incorrect format or is an unsupported type.</dd>
<dt>105 unsupported digest type</dt>
<dd>The server requires an unsupported digest/signature scheme.</dd>
<dt>106 unsupported identity type</dt>
<dd>The client or server has requested an identity scheme the other does not support.</dd>
<dt>107 bad signature length</dt>
<dd>The signature length does not match the current public key.</dd>
<dt>108 signature not verified</dt>
<dd>The message fails the signature check. It could be bogus or signed by a different private key.</dd>
<dt>109 certificate not verified</dt>
<dd>The certificate is invalid or signed with the wrong key.</dd>
<dt>110 host certificate expired</dt>
<dd>The old server certificate has expired.</dd>
<dt>111 bad or missing cookie</dt>
<dd>The cookie is missing, corrupted or bogus.</dd>
<dt>112 bad or missing leapseconds table</dt>
<dd>The leapseconds table is missing, corrupted or bogus.</dd>
<dt>113 bad or missing certificate</dt>
<dd>The certificate is missing, corrupted or bogus.</dd>
<dt>114 bad or missing group key</dt>
<dd>The identity key is missing, corrupt or bogus.</dd>
<dt>115 protocol error</dt>
<dd>The protocol state machine has wedged due to unexpected restart.</dd>
</dl>
<h4 id="files">Files</h4>
<p>See the <a href="keygen.html"><tt>ntp-keygen</tt></a> page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.</p>
<hr>
<p>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</p>
</body>
</html>

55
html/bugs.html
View File

@ -1,32 +1,27 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>NTP Bug Reporting Procedures</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>NTP Bug Reporting Procedures</h3>
<img src="pic/hornraba.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The rabbit toots to make sure you read this.</p>
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">04:05</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="250">Sunday, March 02, 2008</csobj></p>
.<br clear="left">
<hr>
<h4> Security Bug Reporting Procedures</h4>
<p>If you find or suspect a security related program bug in this distribution, please send a report to <a href="mailto:security@ntp.org">security@ntp.org</a>. Please do not contact developers directly.</p>
<h4>Non-Security Bug Reporting Procedures</h4>
<p>If you find or suspect a non-security related program bug in this distribution, please send a report to the NTP Public Service Project Bug Tracking System (Bugzilla) at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a>. Bugs reported this way are immediately forwarded to the developers. Please do not contact the developers directly.</p>
<p>If you find or suspect an error in the program documentation pages, please
send a report directly to the editor David Mills at <a href="mailto:mills@udel.edu">mills@udel.edu</a>.
The master documentation pages are not controlled by the bug tracking system.
You are invited to contribute new or revised pages in similar style and format.</p>
<p>If you wish to send a report via electronic mail, please remember that your report will be held until one of our volunteers enters it in Bugzilla. The email address for these reports is <a href="mailto:bugs@ntp.org">bugs@ntp.org</a>. You will need to register at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a> so that you may participate directly in any e-mail discussion regarding your report.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>NTP Bug Reporting Procedures</title>
<!-- Changed by: Harlan &, 23-Aug-2014 -->
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>NTP Bug Reporting Procedures</h3>
<img src="pic/hornraba.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The rabbit toots to make sure you read this.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->23-Aug-2014 05:32<!-- #EndDate -->
UTC</p>
.<br clear="left">
<hr>
<h4> Security Bug Reporting Procedures</h4>
<p>If you find or suspect a security related program bug in this distribution, please send a report to <a href="mailto:security@ntp.org">security@ntp.org</a>. Please do not contact developers directly.</p>
<h4>Non-Security Bug Reporting Procedures</h4>
<p>If you find or suspect a non-security related program or documentation bug in this distribution, please send a report to the NTP Public Service Project Bug Tracking System (Bugzilla) at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a>. Bugs reported this way are immediately forwarded to the developers. Please do not contact the developers directly.</p>
<p>If you wish to send a report via electronic mail, please remember that your report will be held until one of our volunteers enters it in Bugzilla. The email address for these reports is <a href="mailto:bugs@ntp.org">bugs@ntp.org</a>. You will need to register at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a> to participate directly in any e-mail discussion regarding your report. If you don't register and we have questions for you we won't be able to make progress on fixing your problem. Please directly register on and use our Bugzilla instance to report issues.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

112
html/build.html
View File

@ -1,59 +1,57 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=windows-1252">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Building and Installing the Distribution</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Building and Installing the Distribution</h3>
<img src="pic/beaver.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>For putting out compiler fires.</p>
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">16:45</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="250">Sunday, March 02, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#build">Building and Installing the Distribution</a>
<li class="inline"><a href="#unix">Building and Installing for Unix</a>
<li class="inline"><a href="#win">Building and Installing for Windows</a>
<li class="inline"><a href="#conf">Configuration</a>
<li class="inline"><a href="#prob">If You Have Problems</a>
<li class="inline"><a href="#make">Additional <tt>make</tt> Commands</a>
</ul>
<hr>
<h4 id="build">Building and Installing the Distribution</h4>
<p>It is not possible in a software distribution such as this to support every individual computer and operating system with a common executable, even with the same system but different versions and options. Therefore, it is necessary to configure, build and install for each system and version. In almost all cases, these procedures are completely automatic, The user types <tt>./configure</tt>, <tt>make</tt> and <tt>install</tt> in that order and the autoconfigure system does the rest. There are some exceptions, as noted below and on the <a href="hints.html">Hints and Kinks</a> pages.</p>
<p>If available, the OpenSSL library from <a href="http://www.openssl.org">http://www.openssl.org</a> is used to support public key cryptography. The library must be built and installed prior to building NTP. The procedures for doing that are included in the OpenSSL documentation. The library is found during the normal NTP configure phase and the interface routines compiled automatically. Only the <tt>libcrypto.a</tt> library file and <tt>openssl</tt> header files are needed. If the library is not available or disabled, this step is not required.</p>
<p>The <a href="config.html">Build Options</a> page describes a number of options that determine whether debug support is included, whether and which reference clock drivers are included and the locations of the executables and library files, if not the default. By default debugging options and all reference clock drivers are included.</p>
<h4 id="unix">Building and Installing for Unix</h4>
<p>This distribution uses common compilers and tools that come with most Unix distributions. Not all of these tools exist in the standard distribution of modern Unix versions (compilers are likely to be an add-on product). If this is the case, consider using the GNU tools and <tt>gcc</tt> compiler included as freeware in some systems. For a successful build, all of these tools should be accessible via the current path.</p>
<p>The first thing to do is uncompress the distribution and extract the source tree. In the distribution base directory use the <tt>./configure </tt>command to perform an automatic configuration procedure. This command inspects the hardware and software environment and configures the build process accordingly. Use the <tt>make</tt> command to compile and link the distribution and the <tt>install</tt> command to install the executables by default in <tt>/usr/local/bin</tt>.</p>
<p>If your site supports multiple architectures and uses NFS to share files, you can use a single source tree to build executables for multiple architectures. While running on a particular architecture, change to the base directory and create a subdirectory using a command like <tt>mkdir A.machine, </tt>which will create an architecture-specific directory, then change to this directory and mumble <tt>../configure</tt>. The remaining steps are the same whether building in the base directory or in the subdirectory.</p>
<h4 id="win">Building and Installing for Windows</h4>
<p>NTP supports Windows Vista, XP, NT4 and 2000 systems. See the <a href="hints/winnt.html">NTP 4.x for Windows NT</a> page for directions to compile the sources and install the executables. A precompiled executable is available.</p>
<h4 id="conf">Configuration</h4>
<p>You are now ready to configure the daemon. You will need to create a NTP configuration file by default in <tt>/etc/ntp.conf.</tt> Newbies should see the <a href="quick.html">Quick Start</a> page for orientation. Seasoned veterans can start with the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page and move on to the specific configuration option pages from there.</p>
<h4 id="prob">If You Have Problems</h4>
<p>If you have problems with your hardware and software environment (e.g. operating system-specific issues), browse the <a href="hints.html">Hints and Kinks</a> pages. For other problems a tutorial on debugging technique is in the <a href="debug.html">NTP Debugging Technique</a> page. A list of important system log messages is on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page.</p>
<p>The first line of general assistance is the NTP web site <a href="http://www.ntp.org">www.ntp.org</a> and the helpful documents resident there. Requests for assistance of a general nature and of interest to other timekeepers should be sent to the NTP newsgroup comp.protocols.time.ntp.</p>
<p>Users are invited to report bugs and offer suggestions via the <a href="bugs.html">NTPáBug Reporting Procedures</a> page.</p>
<h4 id="make">Additional <tt>make</tt> commands</h4>
<dl>
<dt><tt>make clean</tt>
<dd>Cleans out object files, programs and temporary files.
<dt><tt>make distclean</tt>
<dd>Does the work of <tt>clean</tt>, but cleans out all directories in preparation for a new distribution release.
<dt><tt>make dist</tt>
<dd>Does the work of <tt>make distclean</tt>, but constructs compressed tar files for distribution. You must have GNU automake to perform this function.
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=windows-1252">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Building and Installing the Distribution</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Building and Installing the Distribution</h3>
<img src="pic/beaver.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>For putting out compiler fires.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->31-Mar-2014 05:39<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#build">Building and Installing the Distribution</a></li>
<li class="inline"><a href="#unix">Building and Installing for Unix</a></li>
<li class="inline"><a href="#win">Building and Installing for Windows</a></li>
<li class="inline"><a href="#conf">Configuration</a></li>
<li class="inline"><a href="#prob">If You Have Problems</a></li>
<li class="inline"><a href="#make">Additional <tt>make</tt> Commands</a></li>
</ul>
<hr>
<h4 id="build">Building and Installing the Distribution</h4>
<p>It is not possible in a software distribution such as this to support every individual computer and operating system with a common executable, even with the same system but different versions and options. Therefore, it is necessary to configure, build and install for each system and version. In almost all cases, these procedures are completely automatic, The user types <tt>./configure</tt>, <tt>make</tt> and <tt>install</tt> in that order and the autoconfigure system does the rest. There are some exceptions, as noted below and on the <a href="hints.html">Hints and Kinks</a> pages.</p>
<p>If available, the OpenSSL library from <a href="http://www.openssl.org">http://www.openssl.org</a> is used to support public key cryptography. The library must be built and installed prior to building NTP. The procedures for doing that are included in the OpenSSL documentation. The library is found during the normal NTP configure phase and the interface routines compiled automatically. Only the <tt>libcrypto.a</tt> library file and <tt>openssl</tt> header files are needed. If the library is not available or disabled, this step is not required.</p>
<p>The <a href="config.html">Build Options</a> page describes a number of options that determine whether debug support is included, whether and which reference clock drivers are included and the locations of the executables and library files, if not the default. By default debugging options and all reference clock drivers are included.</p>
<h4 id="unix">Building and Installing for Unix</h4>
<p>This distribution uses common compilers and tools that come with most Unix distributions. Not all of these tools exist in the standard distribution of modern Unix versions (compilers are likely to be an add-on product). If this is the case, consider using the GNU tools and <tt>gcc</tt> compiler included as freeware in some systems. For a successful build, all of these tools should be accessible via the current path.</p>
<p>The first thing to do is uncompress the distribution and extract the source tree. In the distribution base directory use the <tt>./configure </tt>command to perform an automatic configuration procedure. This command inspects the hardware and software environment and configures the build process accordingly. Use the <tt>make</tt> command to compile and link the distribution and the <tt>install</tt> command to install the executables by default in <tt>/usr/local/bin</tt>.</p>
<p>If your site supports multiple architectures and uses NFS to share files, you can use a single source tree to build executables for multiple architectures. While running on a particular architecture, change to the base directory and create a subdirectory using a command like <tt>mkdir A.machine, </tt>which will create an architecture-specific directory, then change to this directory and mumble <tt>../configure</tt>. The remaining steps are the same whether building in the base directory or in the subdirectory.</p>
<h4 id="win">Building and Installing for Windows</h4>
<p>NTP supports Windows 2000 and later. See the <a href="hints/winnt.html">NTP 4.x for Windows NT</a> page for directions to compile the sources and install the executables. A precompiled executable is available.</p>
<h4 id="conf">Configuration</h4>
<p>You are now ready to configure the daemon. You will need to create a NTP configuration file by default in <tt>/etc/ntp.conf.</tt> Newbies should see the <a href="quick.html">Quick Start</a> page for orientation. Seasoned veterans can start with the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page and move on to the specific configuration option pages from there.</p>
<h4 id="prob">If You Have Problems</h4>
<p>If you have problems with your hardware and software environment (e.g. operating system-specific issues), browse the <a href="hints.html">Hints and Kinks</a> pages. For other problems a tutorial on debugging technique is in the <a href="debug.html">NTP Debugging Technique</a> page. A list of important system log messages is on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page.</p>
<p>The first line of general assistance is the NTP web site <a href="http://www.ntp.org">www.ntp.org</a> and the helpful documents resident there. Requests for assistance of a general nature and of interest to other timekeepers should be sent to the NTP newsgroup comp.protocols.time.ntp.</p>
<p>Users are invited to report bugs and offer suggestions via the <a href="bugs.html">NTP Bug Reporting Procedures</a> page.</p>
<h4 id="make">Additional <tt>make</tt> commands</h4>
<dl>
<dt><tt>make clean</tt></dt>
<dd>Cleans out object files, programs and temporary files.</dd>
<dt><tt>make distclean</tt></dt>
<dd>Does the work of <tt>clean</tt>, but cleans out all directories in preparation for a new distribution release.</dd>
<dt><tt>make dist</tt></dt>
<dd>Does the work of <tt>make distclean</tt>, but constructs compressed tar files for distribution. You must have GNU automake to perform this function.</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

65
html/clock.html Normal file
View File

@ -0,0 +1,65 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Clock State Machine</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Clock State Machine</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->4-Aug-2011 23:40<!-- #EndDate -->
UTC</p>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">General Overview</a></li>
<li class="inline"><a href="#panic">Panic Threshold</a></li>
<li class="inline"><a href="#step">Step and Stepout Thresholds</a></li>
<li class="inline"><a href="#hold">Hold Timer</a></li>
<li class="inline"><a href="#inter">Operating Intervals</a></li>
<li class="inline"><a href="#state">State Transition Function</a></li>
</ul>
<hr>
<h4 id="intro">General Overview</h4>
<p>In the NTPv4 specification and reference implementation a state machine is used to manage the system clock under exceptional conditions, as when the daemon is first started or when encountering severe network congestion. This page describes the design and operation of the state machine in detail.</p>
<p> The state machine is activated upon receipt of an update by the clock discipline algorithm. its primary purpose is to determines whether the clock is slewed or stepped and how the initial time and frequency are determined using three thresholds: <em>panic</em>, <em>step</em> and <em>stepout</em>, and one timer: <em>hold</em>.</p>
<h4 id="panic">Panic Threshold</h4>
<p>Most computers today incorporate a time-of-year (TOY) chip to maintain the time when the power is off. When the computer is restarted, the chip is used to initialize the operating system time. In case there is no TOY chip or the TOY&nbsp;time is different from NTP time by more than the panic threshold, the daemon <tt></tt> assumes something must be terribly wrong, so exits with a message to the system operator to set the time manually. With the <tt>-g</tt> option on the command line, the daemon sets the clock to NTP time at the first update, but exits if the offset exceeds the panic threshold at subsequent updates. The panic threshold default is 1000 s, but it can be changed with the <tt>panic</tt> option of the <a href="miscopt.html#tinker"><tt>tinker</tt></a> command.</p>
<h4 id="step"> Step and Stepout Thresholds</h4>
<p>Under ordinary conditions, the clock discipline gradually slews the clock to the correct time, so that the time is effectively continuous and never stepped forward or backward. If, due to extreme network congestion, an offset spike exceeds the step threshold, by default 128 ms, the spike is discarded. However, if offset spikes greater than the step threshold persist for an interval more than the stepout threshold, by default 300 s, the system clock is stepped to the correct time.</p>
<p> In practice, the need for a step has been extremely rare and almost always the result of a hardware failure or operator error. The step threshold and stepout threshold can be changed using the <tt>step</tt> and <tt>stepout</tt> options of the <a href="miscopt.html#tinker"><tt>tinker</tt></a> command, respectively. If the step threshold is set to zero, the step function is entirely disabled and the clock is always slewed. The daemon sets the step threshold to 600 s using the <tt>-x</tt> option on the command line. If the <tt>-g</tt> option is used or the step threshold is set greater than 0.5 s, the precision time kernel support is disabled.</p>
<p>Historically, the most important application of the step function was when a leap second was inserted in the Coordinated Universal Time (UTC) timescale and the kernel precision time support was not available. This also happened with older reference clocks that indicated an impending leap second, but the radio itself did not respond until it resynchronized some minutes later. Further details are on the <a href="leap.html">Leap Second Processing</a> page.</p>
<p>In some applications the clock can never be set backward, even it accidentally set forward a week by some evil means. The issues should be carefully considered before using these options. The slew rate is fixed at 500 parts-per-million (PPM) by the Unix kernel. As a result, the clock can take 33 minutes to amortize each second the clock is outside the acceptable range. During this interval the clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.</p>
<h4 id="hold">Hold Timer</h4>
<p>When the daemon is started after a considerable downtime, it could be the TOY chip clock has drifted significantly from NTP time. This can cause a transient at system startup. In the past, this has produced a phase transient and resulted in a frequency surge that could take some time, even hours, to subside. When the highest accuracy is required, some means is necessary to manage the startup process so that the the clock is quickly set correctly and the frequency is undisturbed. The hold timer is used to suppress frequency adjustments during the training and startup intervals described below. At the beginning of the interval the hold timer is set to the stepout threshold and decrements at one second intervals until reaching zero. However, the hold timer is forced to zero if the residual clock offset is less than 0.5 ms. When nonzero, the discipline algorithm uses a small time constant (equivalent to a poll exponent of 2), but does not adjust the frequency. Assuming that the frequency has been set to within 1 PPM, either from the frequency file or by the training interval described later, the clock is set to within 0.5 ms in less than 300 s.</p>
<h4 id="inter">Operating Intervals</h4>
<p>The state machine operates in one of four nonoverlapping intervals.</p>
<dl>
<dt>Training interval</dt>
<dd>This interval is used at startup when the frequency file is nor present at startup. It begins when the first update is received by the discipline algorithm and ends when an update is received following the stepout threshold. The clock phase is steered to the offset presented at the beginning of the interval, but without affecting the frequency. During the interval further updates are ignored. At the end of the interval the frequency is calculated as the phase change during the interval divided by the length of the interval. This generally results in a frequency error less than 0.5 PPM. Note that, if the intrinsic oscillator frequency error is large, the offset will in general have significant error. This is corrected during the subsequent startup interval.</dd>
<dt>Startup interval</dt>
<dd> This interval is used at startup to amortize the residual offset while not affecting the frequency. If the frequency file is present, it begins when the first update is received by the discipline. If not, it begins after the training interval. It ends when the hold timer decrements to zero or when the residual offset falls below 0.5 ms.</dd>
<dt>Step interval</dt>
<dd>This interval is used as a spike blanker during periods when the offsets exceed the step threshold. The interval continues as long as offsets are received that are greater than the step threshold, but ends when either an offset is received less than the step threshold or until the time since the last valid update exceeds the stepout threshold.</dd>
<dt>Sync Interval</dt>
<dd> This interval is implicit; that is, it is used when none of the above intervals are used.</dd>
</dl>
<h4 id="state">State Transition Function</h4>
<p>The state machine consists of five states. An event is created when an update is received by the discipline algorithm. Depending on the state and the the offset magnitude, the machine performs some actions and transitions to the same or another state. Following is a short description of the states.</p>
<dl>
<dt>FSET - The frequency file is present</dt>
<dd> Load the frequency file, initialize the hold timer and continue in SYNC state.</dd>
<dt>NSET - The frequency file is not present</dt>
<dd>Initialize the hold timer and continue in FREQ state.</dd>
<dt>FREQ - Frequency training state</dt>
<dd>Disable the clock discipline until the time since the last update exceeds the stepout threshold. When this happens, calculate the frequency, initialize the hold counter and transition to SYNC state.</dd>
<dt>SPIK - Spike state</dt>
<dd>A update greater than the step threshold has occurred. Ignore the update and continue in this state as long as updates greater than the step threshold occur. If a valid update is received, continue in SYNC state. When the time since the last valid update was received exceeds the stepout threshold, step the system clock and continue in SYNC state. </dd>
<dt>SYNC - Ordinary clock discipline state</dt>
<dd>Discipline the system clock time and frequency using the hybrid phase/frequency feedback loop. However, do not discipline the frequency if the hold timer is nonzero.</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

122
html/clockopt.html
View File

@ -1,71 +1,59 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Reference Clock Options</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Reference Clock Options</h3>
<img src="pic/stack1a.jpg" alt="gif" align="left">Master Time Facility at the <a href="http://www.eecis.udel.edu/%7emills/lab.html">UDel Internet Research Laboratory</a>
<p>Last update:
<!-- #BeginDate format:En2m -->04-Oct-2009 19:42<!-- #EndDate -->
UTC</p>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Reference Clock Commands and Options</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Reference Clock Commands and Options</h3>
<img src="pic/stack1a.jpg" alt="gif" align="left">Master Time Facility at the <a href="http://www.eecis.udel.edu/%7emills/lab.html">UDel Internet Research Laboratory</a>
<p>Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/clockopt.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#ref">Reference Clock Support</a>
<li class="inline"><a href="#cmd">Reference Clock Commands</a>
</ul>
<hr>
<h4 id="ref">Reference Clock Support</h4>
<p>The NTP Version 4 daemon supports some three dozen different radio, satellite and modem reference clocks plus a special pseudo-clock used for backup or when no other clock source is available. Detailed descriptions of individual device drivers and options can be found in the <a href="refclock.html">Reference Clock Drivers</a> page. Additional information can be found in the pages linked there, including the <a href="rdebug.html">Debugging Hints for Reference Clock Drivers</a> and <a href="howto.html">How To Write a Reference Clock Driver</a> pages. In addition, support for a PPS signal is available as described in <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
<p>A reference clock will generally (though not always) be a radio timecode receiver which is synchronized to a source of standard time such as the services offered by the NRC in Canada and NIST and USNO in the US. The interface between the computer and the timecode receiver is device dependent, but is usually a serial port. A device driver specific to each reference clock must be selected and compiled in the distribution; however, most common radio, satellite and modem clocks are included by default. Note that an attempt to configure a reference clock when the driver has not been compiled or the hardware port has not been appropriately configured results in a scalding remark to the system log file, but is otherwise non hazardous.</p>
<p>For the purposes of configuration, <tt>ntpd</tt> treats reference clocks in a manner analogous to normal NTP peers as much as possible. Reference clocks are identified by a syntactically correct but invalid IP address, in order to distinguish them from normal NTP peers. Reference clock addresses are of the form <tt>127.127.<i>t.u</i></tt>, where <i><tt>t</tt></i> is an integer denoting the clock type and <i><tt>u</tt></i> indicates the unit number in the range 0-3. While it may seem overkill, it is in fact sometimes useful to configure multiple reference clocks of the same type, in which case the unit numbers must be unique.</p>
<p>The <tt>server</tt> command is used to configure a reference clock, where the <i><tt>address</tt></i> argument in that command is the clock address. The <tt>key</tt>, <tt>version</tt> and <tt>ttl</tt> options are not used for reference clock support. The <tt>mode</tt> option is added for reference clock support, as described below. The <tt>prefer</tt> option can be useful to persuade the server to cherish a reference clock with somewhat more enthusiasm than other reference clocks or peers. Further information on this option can be found in the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. The <tt>minpoll</tt> and <tt>maxpoll</tt> options have meaning only for selected clock drivers. See the individual clock driver document pages for additional information.</p>
<p>The <tt>fudge</tt> command is used to provide additional information for individual clock drivers and normally follows immediately after the <tt>server</tt> command. The <i><tt>address</tt></i> argument specifies the clock address. The <tt>refid</tt> and <tt>stratum</tt> options control can be used to override the defaults for the device. There are two optional device-dependent time offsets and four flags that can be included in the <tt>fudge</tt> command as well.</p>
<p>The stratum number of a reference clock is by default zero. Since the <tt>ntpd</tt> daemon adds one to the stratum of each peer, a primary server ordinarily displays an external stratum of one. In order to provide engineered backups, it is often useful to specify the reference clock stratum as greater than zero. The <tt>stratum</tt> option is used for this purpose. Also, in cases involving both a reference clock and a pulse-per-second (PPS) discipline signal, it is useful to specify the reference clock identifier as other than the default, depending on the driver. The <tt>refid</tt> option is used for this purpose. Except where noted, these options apply to all clock drivers.</p>
<h4 id="cmd">Reference Clock Commands</h4>
<dl>
<dt id="server"><tt>server 127.127.<i>t.u</i> [prefer] [mode <i>int</i>] [minpoll <i>int</i>] [maxpoll <i>int</i>]</tt>
<dd>This command can be used to configure reference clocks in special ways. The options are interpreted as follows:
<dl>
<dt><tt>prefer</tt>
<dd>Marks the reference clock as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page for further information.
<dt><tt>mode <i>int</i></tt>
<dd>Specifies a mode number which is interpreted in a device-specific fashion. For instance, it selects a dialing protocol in the ACTS driver and a device subtype in the <tt>parse</tt> drivers.
<dt><tt>minpoll <i>int</i></tt>
<dt><tt>maxpoll <i>int</i></tt>
<dd>These options specify the minimum and maximum polling interval for reference clock messages in seconds, interpreted as dual logarithms (2 ^ x). For most directly connected reference clocks, both <tt>minpoll</tt> and <tt>maxpoll</tt> default to 6 (2^16 = 64 s). For modem reference clocks, <tt>minpoll</tt> defaults to 10 (2^10 = 1024 s = 17.1 m) and <tt>maxpoll</tt> defaults to 14 (2^14 = 16384 s = 4.5 h). The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
</dl>
<dt id="fudge"><tt>fudge 127.127.<i>t.u</i> [time1 <i>sec</i>] [time2 <i>sec</i>]
[stratum <i>int</i>] [refid <i>string</i>] [flag1 0|1]
[flag2 0|1] [flag3 0|1] [flag4 0|1]</tt>
<dd>This command can be used to configure reference clocks in special ways. It must immediately follow the <tt>server</tt> command which configures the driver. Note that the same capability is possible at run time using the <tt><a href="ntpdc.html">ntpdc</a></tt> program. The options are interpreted as follows:
<dl>
<dt><tt>time1 <i>sec</i></tt>
<dd>Specifies a constant to be added to the time offset produced by the driver, a fixed-point decimal number in seconds. This is used as a calibration constant to adjust the nominal time offset of a particular clock to agree with an external standard, such as a precision PPS signal. It also provides a way to correct a systematic error or bias due to serial port or operating system latencies, different cable lengths or receiver internal delay. The specified offset is in addition to the propagation delay provided by other means, such as internal DIPswitches. Where a calibration for an individual system and driver is available, an approximate correction is noted in the driver documentation pages.
<dd>Note: in order to facilitate calibration when more than one radio clock or PPS signal is supported, a special calibration feature is available. It takes the form of an argument to the <tt>enable</tt> command described in the <a href="miscopt.html">Miscellaneous Options</a> page and operates as described in the <a href="refclock.html">Reference Clock Drivers</a> page.
<dt><tt>time2 <i>secs</i></tt>
<dd>Specifies a fixed-point decimal number in seconds, which is interpreted in a driver-dependent way. See the descriptions of specific drivers in the <a href="refclock.html">reference clock drivers</a> page.
<dt><tt>stratum <i>int</i></tt>
<dd>Specifies the stratum number assigned to the driver, an integer between 0 and 15. This number overrides the default stratum number ordinarily assigned by the driver itself, usually zero.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies an ASCII string of from one to four characters which defines the reference identifier used by the driver. This string overrides the default identifier ordinarily assigned by the driver itself.
<dt><tt>flag1 flag2 flag3 flag4</tt>
<dd>These four flags are used for customizing the clock driver. The interpretation of these values, and whether they are used at all, is a function of the particular clock driver. However, by convention <tt>flag4</tt> is used to enable recording monitoring data to the <tt>clockstats</tt> file configured with the <tt>filegen</tt> command. Further information on the <tt>filegen</tt> command can be found in the <a href="monopt.html">Monitoring Options</a> page.
</dl>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/clockopt.txt"></script>
<hr>
<h4 id="addrs">Reference Clock Adddresses</h4>
<p>Unless noted otherwise, further information about these ccommands is on the <a href="refclock.html">Reference Clock Support</a> page.</p><p>Reference clocks are identified by a syntactically correct but invalid IP address, in order to distinguish them from ordinary NTP peers. These addresses are of the form 127.127.<em>t</em>.<em>u</em>, where <em>t</em> is an integer denoting the clock type and <em>u</em> indicates the unit number in the range 0-3. While it may seem overkill, it is in fact sometimes useful to configure multiple reference clocks of the same type, in which case the unit numbers must be unique.</p>
<h4 id="cmd"> Commands and Options</h4>
<dl>
<dt id="server"><tt>server 127.127.<i>t.u</i> [prefer] [mode <i>int</i>] [minpoll <i>int</i>] [maxpoll <i>int</i>]</tt></dt>
<dd>This command can be used to configure reference clocks in special ways. The options are interpreted as follows:
<dl>
<dt><tt>prefer</tt></dt>
<dd>Marks the reference clock as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page for further information.</dd>
<dt><tt>mode <i>int</i></tt></dt>
<dd>Specifies a mode number which is interpreted in a device-specific fashion. For instance, it selects a dialing protocol in the ACTS driver and a device subtype in the <tt>parse</tt> drivers.</dd>
<dt><tt>minpoll <i>int</i></tt><br>
<tt>maxpoll <i>int</i></tt></dt>
<dd>These options specify the minimum and maximum polling interval for reference clock messages in log<sub>2</sub> seconds. For most directly connected reference clocks, both <tt>minpoll</tt> and <tt>maxpoll</tt> default to 6 (64 s). For modem reference clocks, <tt>minpoll</tt> is ordinarily set to 10 (about 17 m) and <tt>maxpoll</tt> to 15 (about 9 h). The allowable range is 4 (16 s) to 17 (36 h) inclusive.</dd>
</dl>
</dd>
<dt id="fudge"><tt>fudge 127.127.<i>t.u</i> [time1 <i>sec</i>] [time2 <i>sec</i>]
[stratum <i>int</i>] [refid <i>string</i>] [flag1 0|1]
[flag2 0|1] [flag3 0|1] [flag4 0|1]</tt></dt>
<dd>This command can be used to configure reference clocks in special ways. It must immediately follow the <tt>server</tt> command which configures the driver. Note that the same capability is possible at run time using the <tt><a href="ntpdc.html">ntpdc</a></tt> program. The options are interpreted as follows:
<dl>
<dt><tt>time1 <i>sec</i></tt></dt>
<dd>Specifies a constant to be added to the time offset produced by the driver, a fixed-point decimal number in seconds. This is used as a calibration constant to adjust the nominal time offset of a particular clock to agree with an external standard, such as a precision PPS signal. It also provides a way to correct a systematic error or bias due to serial port or operating system latencies, different cable lengths or receiver internal delay. The specified offset is in addition to the propagation delay provided by other means, such as internal DIPswitches. Where a calibration for an individual system and driver is available, an approximate correction is noted in the driver documentation pages.</dd>
<dd>Note: in order to facilitate calibration when more than one radio clock or PPS signal is supported, a special calibration feature is available. It takes the form of an argument to the <tt>enable</tt> command described in the <a href="miscopt.html">Miscellaneous Options</a> page and operates as described in the <a href="refclock.html">Reference Clock Support</a> page.</dd>
<dt><tt>time2 <i>secs</i></tt></dt>
<dd>Specifies a fixed-point decimal number in seconds, which is interpreted in a driver-dependent way. See the descriptions of specific drivers in the <a href="refclock.html">Reference Clock Support</a> page.</dd>
<dt><tt>stratum <i>int</i></tt></dt>
<dd>Specifies the stratum number assigned to the driver in the range 0 to 15, inclusive. This number overrides the default stratum number ordinarily assigned by the driver itself, usually zero.</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies an ASCII string of from one to four characters which defines the reference identifier used by the driver. This string overrides the default identifier ordinarily assigned by the driver itself.</dd>
<dt><tt>flag1 flag2 flag3 flag4</tt></dt>
<dd>These four flags are used for customizing the clock driver. The interpretation of these values, and whether they are used at all, is a function of the particular driver. However, by convention <tt>flag4</tt> is used to enable recording monitoring data to the <tt>clockstats</tt> file configured with the <tt>filegen</tt> command. Additional information on the <tt>filegen</tt> command is on the <a href="monopt.html">Monitoring Options</a> page.</dd>
</dl>
</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

32
html/cluster.html Normal file
View File

@ -0,0 +1,32 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Clock Cluster Algorithm</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<em></em>
<h3>Clock Cluster Algorithm</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->15-Nov-2012 06:02<!-- #EndDate -->
UTC</p>
<hr>
<p>The clock cluster algorithm processes the truechimers produced by the clock select algorithm to produce a list of <em>survivors</em>. These survivors are used by the mitigation algorithms to discipline the system clock. The cluster algorithm operates in a series of rounds, where at each round the truechimer furthest from the offset centroid is pruned from the population. The rounds are continued until a specified termination condition is met. This page discusses the algorithm in detail.</p>
<p>First, the truechimer associations are saved on an unordered list with each candidate entry identified with index <em>i</em> (<em>i </em>= 1, ..., <em>n)</em>, where <em>n</em> is the number of candidates. Let &theta;(<em>i</em>), be the offset and &lambda;(<em>i</em>) be the root distance of the <em>i</em>th entry. Recall that the root distance is equal to the root dispersion plus half the root delay. For the <em>i</em>th candidate on the list, a statistic called the <em>select jitter</em> relative to the <em>i</em>th candidate is calculated as follows. Let</p>
<div align="center">
<p><em>d<sub>i</sub></em>(<em>j</em>) = |&theta;(<em>j</em>) &minus; &theta;(<em>i</em>)| &lambda;(<em>i</em>),</p>
</div>
<p> where &theta;(<em>i)</em> is the peer offset of the <em>i</em>th entry and &theta;(<em>j</em>) is the peer offset of the <em>j</em>th entry, both produced by the clock filter algorithm. The metric used by the cluster algorithm is the select jitter &phi;<sub>S</sub>(<em>i</em>) computed as the root mean square (RMS) of the <em>d<sub>i</sub></em>(<em>j</em>) as <em>j</em> ranges from 1 to <em>n</em>. <em> </em>For the purpose of notation in the example to follow, let &phi;<sub>R</sub>(<em>i</em>) be the peer jitter computed by the clock filter algorithm for the <em>i</em>th candidate.</p>
<p>The object at each round is to prune the entry with the largest metric until the termination condition is met. Note that the select jitter must be recomputed at each round, but the peer jitter does not change. At each round the remaining entries on the list represent the survivors of that round. If the candidate to be pruned is preemptable and the number of candidates is greater than the <em>maxclock threshold</em>, the association is demobilized. This is useful in the schemes described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. The maxclock threshold default is 10, but it can be changed using the <tt>maxclock</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. Further pruning is subject to the following termination conditions, but no associations will be automatically demobilized.</p>
<p>The termination condition has two parts. First, if the number of survivors is not greater than the<em> </em><em>minclock threshold</em> set by the <tt>minclock</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command, the pruning process terminates. The<tt> minclock</tt> default is 3, but can be changed to fit special conditions, as described on the <a href="prefer.html">Mitigation Rules and the prefer Keyword</a> page.</p>
<div align="center"><img src="pic/flt7.gif" alt="gif">
<p>Figure 1. Cluster Algorithm</p>
</div>
<p>The second termination condition is more intricate. Figure 1 shows a round where a candidate of (a) is pruned to yield the candidates of (b). Let &phi;<sub><em>max</em></sub> be the maximum select jitter and &phi;<sub><em>min</em></sub> be the minimum peer jitter over all candidates on the list. In (a), candidate 1 has the highest select jitter, so &phi;<sub><em>max</em></sub> = &phi;<sub>S</sub>(1). Candidate 4 has the lowest peer jitter, so &phi;<sub><em>min</em></sub> = &phi;<sub>R</sub>(4). Since &phi;<sub><em>max</em></sub> &gt; &phi;<sub><em>min</em></sub>, select jitter dominates peer jitter,the algorithm prunes candidate 1.&#13; In (b), &phi;<sub><em>max</em></sub> = &phi;<sub>S</sub>(3) and &phi;<sub><em>min </em></sub>=&phi;<sub>R</sub>(4). Since &phi;<sub><em>max</em></sub> &lt; &phi;<sub><em>min</em></sub>, pruning additional candidates does not reduce select jitter, the algorithm terminates with candidates 2, 3 and 4 as survivors.</p>
<p>The survivor list is passed on to the the mitigation algorithms, which combine the survivors, select a system peer, and compute the system statistics passed on to dependent clients. Note the use of root distance &lambda; as a weight factor at each round in the clock cluster algorithm. This is to favor the survivors with the lowest root distance and thus the smallest maximum error.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

55
html/comdex.html
View File

@ -1,32 +1,29 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Command Index</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Command Index</h3>
<img src="pic/alice38.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carrol</a>
<p>The Mad Hatter says &quot;Bring it on&quot;.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->08-Apr-2009 2:56<!-- #EndDate -->
UTC</p>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Command Index</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Command Index</h3>
<img src="pic/alice38.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carrol</a>
<p>The Mad Hatter says &quot;Bring it on&quot;.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->31-Jan-2014 06:54<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/accopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/clockopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/confopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/miscopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/monopt.txt"></script>
<hr>
<br>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/accopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/confopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/monopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/clockopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/miscopt.txt"></script>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<!-- <hr> -->
<!-- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> -->
</body>
</html>

7
html/config.html
View File

@ -13,8 +13,9 @@
<h3>Build Options</h3>
<img src="pic/pogo3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>Gnu autoconfigure tools are in the backpack.</p>
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">Monday,
December 15, 2008 20:54</csobj> UTC<csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="250"></csobj></p>
<p>Last update:
<!-- #BeginDate format:En2m -->10-Mar-2014 04:59<!-- #EndDate -->
UTC</p>
<br clear="left">
<hr>
<p>Most modern software distributions include an autoconfigure utility which
@ -36,4 +37,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

199
html/confopt.html
View File

@ -3,195 +3,100 @@
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Server Options</title>
<title>Server Commands and Options</title>
<!-- Changed by: Harlan &, 31-Jan-2014 -->
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Server Options</h3>
<h3>Server Commands and Options</h3>
<img src="pic/boom3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>,
Walt Kelly</a>
<p>The chicken is getting configuration advice.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->25-Nov-2009 4:46<!-- #EndDate -->
</p>
<!-- #BeginDate format:En2m -->10-Mar-2014 05:01<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/confopt.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#cfg">Configuration Commands</a></li>
<li class="inline"><a href="#opt">Command Options</a></li>
<li class="inline"><a href="#aux">Auxilliary Commands</a></li>
<li class="inline"><a href="#bug">Bugs</a></li>
<li class="inline"><a href="#address">Server and Peer Addresses</a></li>
<li class="inline"><a href="#command">Server Commands</a></li>
<li class="inline"><a href="#option">Server Command Options</a></li>
</ul>
<hr>
<p>Following is a description of the configuration commands in NTPv4. There are
two classes of commands, configuration commands that configure an association
with a remote server, peer or reference clock, and auxilliary commands that
specify environmental variables that control various related operations. </p>
<p>The various modes described on the <a href="assoc.html">Association Management</a> page
are determined by the command keyword and the DNS name or IP address. Addresses
are classed by type as (s) a remote server or peer (IPv4 class A, B and C),
(b) the IP broadcast address of a local interface, (m) a multicast address (IPv4
class D), or (r) a reference clock address (127.127.x.x). For type m addresses
the IANA has assigned the multicast group address IPv4 224.0.1.1 and IPv6 ff05::101
(site local) exclusively to NTP, but other nonconflicting addresses can be used. </p>
<h4 id="address">Server and Peer Addresses</h4>
<p>Following is a description of the server configuration commands in NTPv4. There are two classes of commands, configuration commands that configure an association with a remote server, peer or reference clock, and auxiliary commands that specify environment variables that control various related operations. </p>
<p>The various modes described on the <a href="assoc.html">Association Management</a> page are determined by the command keyword and the DNS name or IP address. Addresses are classed by type as (s) a remote server or peer (IPv4 class A, B and C or IPv6), (b) the IPv4 broadcast address of a local interface, (m) a multicast address (IPv4 class D or IPv6), or (r) a reference clock address (127.127.x.x). For type m addresses the IANA has assigned the multicast group address IPv4 224.0.1.1 and IPv6 ff05::101 (site local) exclusively to NTP, but other nonconflicting addresses can be used. </p>
<p>If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected,
support for the IPv6 address family is generated in addition to the default
IPv4 address family. IPv6 addresses can be identified by the presence of colons &quot;:&quot; in
the address field. IPv6 addresses can be used almost everywhere where IPv4 addresses
can be used, with the exception of reference clock addresses, which are always
IPv4. Note that in contexts where a host name is expected, a <tt>-4</tt> qualifier
preceding the host name forces DNS resolution to the IPv4 namespace, while a <tt>-6</tt> qualifier
forces DNS resolution to the IPv6 namespace.</p>
<h4 id="cfg">Configuration Commands</h4>
<dl>
support for the IPv6 address family is generated in addition to the default IPv4 address family. IPv6 addresses can be identified by the presence of colons &quot;:&quot; in the address field. IPv6 addresses can be used almost everywhere where IPv4 addresses can be used, with the exception of reference clock addresses, which are always IPv4. Note that in contexts where a host name is expected, a <tt>-4</tt> qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a <tt>-6</tt> qualifier forces DNS resolution to the IPv6 namespace.</p>
<h4 id="command">Server Commands</h4>
<p>Unless noted otherwise, further information about these commands is on the <a href="assoc.html">Association Management</a> page.</p><dl>
<dt id="server"><tt>server <i>address</i> [options ...]</tt><br>
<tt>peer <i>address</i> [options ...]</tt><br>
<tt>broadcast <i>address</i> [options ...]</tt><br>
<tt>manycastclient <i>address</i> [options ...]</tt><br>
<tt>pool <i>address</i> [options ...]</tt><br>
<tt>unpeer [<i>address</i> | <i>associd</i>]</tt></dt>
<dd>These commands specify the time server name or address to be used and the
mode in which to operate. The <i>address</i> can be either a DNS name or a
IPv4 or IPv6 address in standard notation. In general, multiple commands of
each type can be used for different server and peer addresses or multicast
groups.
<dd>These commands specify the remote server name or address to be used and the mode in which to operate. The <i>address</i> can be either a DNS name or a IPv4 or IPv6 address in standard notation. In general, multiple commands of each type can be used for different server and peer addresses or multicast groups.
<dl>
<dt><tt>server</tt></dt>
<dd>For type s and r addresses (only), this command mobilizes a persistent
client mode association with the specified remote server or local reference
clock. If the <tt>preempt</tt> flag is specified, a preemptable client mode
association is mobilized instead.</dd>
<dt><tt>peer</tt></dt>
<dd>For type s addresses (only), this command mobilizes a persistent symmetric-active
mode association with the specified remote peer.</dd>
<dt><tt>broadcast</tt></dt>
<dd>For type b and m addressees (only), this command mobilizes a persistent
broadcast or multicast server mode association. Note that type
b messages go only to the interface specified, but type m messages go to
all interfaces.</dd>
<dt><tt>manycastclient</tt></dt>
<dd>For type m addresses (only), this command mobilizes a manycast client
mode association for the multicast group address specified. In this mode
the address must match the address specified on the <tt>manycastserver</tt> command
of one or more designated manycast servers.</dd>
<dt><tt>pool</tt></dt>
<dd>For type s messages (only) this command mobilizes a client mode association
for servers implementing the pool automatic server discovery scheme described
on the <a href="assoc.html">Association Management</a> page. The address
is a DNS name in the form <tt><i>area</i>.pool.ntp.org</tt>, where <tt><i>area</i></tt> is
a qualifier designating the server geographic area such as <tt>us</tt> or <tt>europe</tt>.</dd>
<dt><tt>unpeer</tt></dt>
<dd>This command removes a previously configured association. An address or association ID can
be used to identify the association. Either an IP address or DNS name can be used. This
command is most useful when supplied via <tt><a href="ntpq.html">ntpq</a></tt> runtime
configuration commands <tt>:config</tt> and <tt>config-from-file</tt>.</dd>
<dd>For type s and r addresses (only), this command mobilizes a persistent client mode association with the specified remote server or local reference clock. If the <tt>preempt</tt> flag is specified, a preemptable client mode association is mobilized instead.</dd>
<dt id="peer"><tt>peer</tt></dt>
<dd>For type s addresses (only), this command mobilizes a persistent symmetric-active mode association with the specified remote peer.</dd>
<dt id="broadcast"><tt>broadcast</tt></dt>
<dd>For type b and m addressees (only), this command mobilizes a broadcast or multicast server mode association. Note that type b messages go only to the interface specified, but type m messages go to all interfaces.</dd>
<dt id="manycastclient"><tt>manycastclient</tt></dt>
<dd>For type m addresses (only), this command mobilizes a preemptable manycast client mode association for the multicast group address specified. In this mode the address must match the address specified on the <tt>manycastserver</tt> command of one or more designated manycast servers. Additional information about this command is on the <a href="discover.html#mcst">Automatic Server Discovery</a> page.</dd>
<dt id="pool"><tt>pool</tt></dt>
<dd>For type s addresses (only) this command mobilizes a preemptable pool client mode association for the DNS name specified. The DNS name must resolve to one or more IPv4 or IPv6 addresses. Additional information about this command is on the <a href="discover.html#pool">Automatic Server Discovery</a> page. The <a href="http://www.pool.ntp.org/">www.pool.ntp.org</a> page describes a compatible pool of public NTP servers.</dd>
<dt id="unpeer"><tt>unpeer</tt></dt>
<dd>This command removes a previously configured association. An address or association ID can be used to identify the association. Either an IP address or DNS name can be used. This command is most useful when supplied via <tt><a href="ntpq.html">ntpq</a></tt> runtime configuration commands <tt>:config</tt> and <tt>config-from-file</tt>.</dd>
</dl></dd>
</dl>
<h4 id="opt">Command Options</h4>
<h4 id="option">Server Command Options</h4>
<dl>
<dt><tt>autokey</tt></dt>
<dd>Send and receive packets authenticated by the Autokey scheme described
in the <a href="authopt.html">Authentication Options</a> page. This option
is mutually exclusive with the <tt>key</tt> option.</dd>
<dt><tt>burst</tt></dt>
<dd>When the server is reachable, send a burst of eight packets instead of the
usual one. The packet spacing is normally 2 s; however, the spacing between
the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command
to allow additional time for a modem or ISDN call to complete. This option
is valid only with the <tt>server</tt> command and type s addressesa.
It is a recommended option when the <tt>maxpoll</tt> option is greater than
10 (1024 s).</dd>
<dt><tt>iburst</tt></dt>
<dd>When the server is unreachable, send a burst of eight packets instead of
the usual one. The packet spacing is normally 2 s; however, the spacing between
the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command
to allow additional time for a modem or ISDN call to complete. This option
is valid only with the <tt>server</tt> command and type s addresses. It is
a recommended option with this command.</dd>
<dt><tt>key</tt> <i><tt>key</tt></i></dt>
<dd>Send and receive packets authenticated by the symmetric key scheme described
in the <a href="authopt.html">Authentication Options</a> page.
The <i><tt>key</tt></i> specifies the key identifier with values from 1 to
65534, inclusive. This option is mutually exclusive with the <tt>autokey</tt> option.</dd>
<dt><tt>minpoll <i>minpoll<br>
</i></tt><tt>maxpoll <i>maxpoll</i></tt></dt>
<dd>These options specify the minimum and maximum poll intervals for NTP messages,
in seconds as a power of two. The maximum poll interval defaults to 10
(1024 s), but can be increased by the <tt>maxpoll</tt> option to an upper limit
of 17 (36 h). The minimum poll interval defaults to 6 (64 s), but can
be decreased by the <tt>minpoll</tt> option to a lower limit of 3 (8 s).</dd>
on the <a href="autokey.html">Autokey Public Key Authentication</a> page. This option is mutually exclusive with the <tt>key</tt> option.</dd>
<dt id="burst"><tt>burst</tt></dt>
<dd>When the server is reachable, send a burst of packets instead of the usual one. This option is valid only with the <tt>server</tt> command and type s addresses. It is a recommended option when the <tt>maxpoll</tt> option is greater than 10 (1024 s). Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
<dt><tt>iburst</tt></dt>
<dd>When the server is unreachable, send a burst of packets instead of the usual one. This option is valid only with the <tt>server</tt> command and type <tt>s</tt> addresses. It is a recommended option with this command. Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
<dt><tt>ident</tt> <em><tt>group</tt></em></dt>
<dd>Specify the group name for the association. See the <a href="autokey.html">Autokey Public-Key Authentication</a> page for further information.</dd>
<dt><tt>key</tt> <i><tt>key</tt></i></dt>
<dd>Send and receive packets authenticated by the symmetric key scheme described in the <a href="authentic.html">Authentication Support</a> page. The <i><tt>key</tt></i> specifies the key identifier with values from 1 to 65534, inclusive. This option is mutually exclusive with the <tt>autokey</tt> option.</dd> <dt><tt>minpoll <i>minpoll<br>
</i></tt><tt>maxpoll <i>maxpoll</i></tt></dt>
<dd>These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two. The maximum poll interval defaults to 10 (1024 s), but can be increased by the <tt>maxpoll</tt> option to an upper limit of 17 (36 hr). The minimum poll interval defaults to 6 (64 s), but can be decreased by the <tt>minpoll</tt> option to a lower limit of 3 (8 s). Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
<dt><tt>mode <i>option</i></tt></dt>
<dd>Pass the <tt><i>option</i></tt> to a reference clock driver, where <tt><i>option</i></tt> is
an integer in the range from 0 to 255, inclusive. This option is valid
only with type r addresses.</dd>
<dd>Pass the <tt><i>option</i></tt> to a reference clock driver, where <tt><i>option</i></tt> is an integer in the range from 0 to 255, inclusive. This option is valid only with type r addresses.</dd>
<dt><tt>noselect</tt></dt>
<dd>Marks the server or peer to be ignored by the selection algorithm but visible
to the monitoring program. This option is ignored with the <tt>broadcast</tt> command.</dd>
<dd>Marks the server or peer to be ignored by the selection algorithm as unreachable, but visible to the monitoring program. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dt><tt>preempt</tt></dt>
<dd>Specifies the association as preemptable rather than the default persistent.
This option is ignored with the <tt>broadcast</tt> command and is most useful
with the <tt>manycastclient</tt> and <tt>pool</tt> commands.</dd>
<dd>Specifies the association as preemptable rather than the default persistent. This option is ignored with the <tt>broadcast</tt> command and is most useful with the <tt>manycastclient</tt> and <tt>pool</tt> commands.</dd>
<dt><tt>prefer</tt></dt>
<dd>Mark the server as preferred. All other things being equal, this host will
be chosen for synchronization among a set of correctly operating hosts. See
the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page
for further information. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dd>Mark the server as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page for further information. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dt><tt>true</tt></dt>
<dd>Mark the association to assume truechimer status; that is, always survive
the selection and clustering algorithms. This option can be used with any association,
but is most useful for reference clocks with large jitter on the serial port
and precision pulse-per-second (PPS) signals. Caution: this option defeats
the algorithms designed to cast out falsetickers and can allow these sources
to set the system clock. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dd>Mark the association to assume truechimer status; that is, always survive the selection and clustering algorithms. This option can be used with any association, but is most useful for reference clocks with large jitter on the serial port and precision pulse-per-second (PPS) signals. Caution: this option defeats the algorithms designed to cast out falsetickers and can allow these sources to set the system clock. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dt><tt>ttl <i>ttl</i></tt></dt>
<dd>This option specifies the time-to-live <i><tt>ttl</tt></i> for the <tt>broadcast</tt> command
and the maximum <i><tt>ttl</tt></i> for the expanding ring search used by the <tt>manycastclient</tt> command.
Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator. This option is invalid with type r addresses.</dd>
<dd>This option specifies the time-to-live <i><tt>ttl</tt></i> for the <tt>broadcast</tt> command and the maximum <i><tt>ttl</tt></i> for the expanding ring search used by the <tt>manycastclient</tt> command. Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator. This option is invalid with type r addresses.</dd>
<dt><tt>version <i>version</i></tt></dt>
<dd>Specifies the version number to be used f
or outgoing NTP packets. Versions
1-4 are the choices, with version 4 the default.</dd>
<dd>Specifies the version number to be used for
outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default.</dd>
<dt><tt>xleave</tt></dt>
<dd>Operate in interleaved mode (symmetric and broadcast modes only). (see <a href="xleave.html">NTP
Interleaved Modes</a>)</dd>
<dd>Operate in interleaved mode (symmetric and broadcast modes only). Further information is on the <a href="xleave.html">NTP Interleaved Modes</a> page.</dd>
</dl>
<h4 id="aux">Auxilliary Commands</h4>
<h4 id="aux">Auxiliary Commands</h4>
<dl>
<dt id="broadcastclient"><tt>broadcastclient</tt></dt>
<dd>Enable reception of broadcast server messages to any local interface (type
b address). Ordinarily, upon receiving a broadcast message for the first
time, the broadcast client measures the nominal server propagation delay using
a brief client/server exchange, after which it continues in listen-only mode.
If a nonzero value is specified in the <tt>broadcastdelay</tt> command, the
value becomes the delay and the volley is not executed. Note: the <tt>novolley</tt> option
has been deprecated for future enhancements. Note that, in order to avoid
accidental or malicious disruption in this mode, both the server and client
should operate using symmetric key or public key authentication as described
in the <a href="authopt.html">Authentication
Options</a> page. Note that the <tt>novolley</tt> keyword is incompatible with
public key authentication.</dd>
<dt id="manycastserver"><tt>manycastserver <i>address</i> [...]</tt></dt>
<dd>Enable reception of manycast client messages (type m)to the multicast group
address(es) (type m) specified. At least one address is required. Note that,
in order to avoid accidental or malicious disruption, both the server and client
should operate using symmetric key or public key authentication as described
in the <a href="authopt.html">Authentication Options</a> page.</dd>
<dd>Enable reception of broadcast server messages to any local interface (type b address). Ordinarily, upon receiving a broadcast message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange, after which it continues in listen-only mode. If a nonzero value is specified in the <tt>broadcastdelay</tt> command, the value becomes the delay and the volley is not executed. Note: the <tt>novolley</tt> option has been deprecated for future enhancements. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication Options</a> page. Note that the volley is required with public key authentication in order to run the Autokey protocol..</dd>
<dt id="manycastserver"><tt>manycastserver <i>address</i> [...]</tt></dt>
<dd>Enable reception of manycast client messages (type m) to the multicasts group address(es) (type m) specified. At least one address is required. Note that, in order to avoid accidental or malicious disruption, both the server and client should operate using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication Options</a> page.</dd>
<dt id="multicastclient"><tt>multicastclient <i>address</i> [...]</tt></dt>
<dd>Enable reception of multicast server messages to the multicast group address(es)
(type m) specified. Upon receiving a message for the first time, the multicast
client measures the nominal server propagation delay using a brief client/server
exchange with the server, then enters the broadcast client mode, in which it
synchronizes to succeeding multicast messages. Note that, in order to avoid
accidental or malicious disruption in this mode, both the server and client
should operate using symmetric key or public key authentication as described
in the <a href="authopt.html">Authentication Options</a> page.</dd>
<dd>Enable reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication Options</a> page.</dd>
</dl>
<h4 id="bug">Bugs</h4>
<p>The syntax checking is not picky; some combinations of ridiculous and even
hilarious options and modes may not be detected.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>

162
html/copyright.html
View File

@ -1,26 +1,25 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Copyright Notice</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Copyright Notice</h3>
<img src="pic/sheepb.jpg" alt="jpg" align="left"> &quot;Clone me,&quot; says Dolly sheepishly.
<p>Last update:
<!-- #BeginDate format:En2m -->1-Jan-2011 08:34<!-- #EndDate -->
UTC</csobj></p>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Copyright Notice</title>
<!-- Changed by: Harlan Stenn, 10-Mar-2014 -->
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Copyright Notice</h3>
<img src="pic/sheepb.jpg" alt="jpg" align="left"> "Clone me," says Dolly sheepishly.
<p>Last update:
<!-- #BeginDate format:En2m -->9-Aug-2014 07:56<!-- #EndDate -->
UTC</p>
<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>
<pre>
</p>
<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>
<pre>
***********************************************************************
* *
* Copyright (c) University of Delaware 1992-2011 *
* Copyright (c) University of Delaware 1992-2014 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *
@ -36,67 +35,68 @@
* *
***********************************************************************
</pre>
<p>The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.</p>
<ol>
<li class="inline"><a href="mailto:%20takao_abe@xurb.jp">Takao Abe &lt;takao_abe@xurb.jp&gt;</a> Clock driver for JJY receivers
<li class="inline"><a href="mailto:%20mark_andrews@isc.org">Mark Andrews &lt;mark_andrews@isc.org&gt;</a> Leitch atomic clock controller
<li class="inline"><a href="mailto:%20altmeier@atlsoft.de">Bernd Altmeier &lt;altmeier@atlsoft.de&gt;</a> hopf Elektronik serial line and PCI-bus devices
<li class="inline"><a href="mailto:%20vbais@mailman1.intel.co">Viraj Bais &lt;vbais@mailman1.intel.com&gt;</a> and <a href="mailto:%20kirkwood@striderfm.intel.com">Clayton Kirkwood &lt;kirkwood@striderfm.intel.com&gt;</a> port to WindowsNT 3.5
<li class="inline"><a href="mailto:%20michael.barone@lmco.com">Michael Barone &lt;michael,barone@lmco.com&gt;</a> GPSVME fixes
<li class="inline"><a href="mailto:%20karl@owl.HQ.ileaf.com">Karl Berry &lt;karl@owl.HQ.ileaf.com&gt;</a> syslog to file option
<li class="inline"><a href="mailto:%20greg.brackley@bigfoot.com">Greg Brackley &lt;greg.brackley@bigfoot.com&gt;</a> Major rework of WINNT port. Clean up recvbuf and iosignal code into separate modules.
<li class="inline"><a href="mailto:%20Marc.Brett@westgeo.com">Marc Brett &lt;Marc.Brett@westgeo.com&gt;</a> Magnavox GPS clock driver
<li class="inline"><a href="mailto:%20Piete.Brooks@cl.cam.ac.uk">Piete Brooks &lt;Piete.Brooks@cl.cam.ac.uk&gt;</a> MSF clock driver, Trimble PARSE support
<li class="inline"><a href="mailto:%20nelson@bolyard.me">Nelson B Bolyard &lt;nelson@bolyard.me&gt;</a> update and complete broadcast and crypto features in sntp
<li class="inline"><a href="mailto:%20Jean-Francois.Boudreault@viagenie.qc.ca">Jean-Francois Boudreault &lt;Jean-Francois.Boudreault@viagenie.qc.ca&gt;</a> IPv6 support
<li class="inline"><a href="mailto:%20reg@dwf.com">Reg Clemens &lt;reg@dwf.com&gt;</a> Oncore driver (Current maintainer)
<li class="inline"><a href="mailto:%20clift@ml.csiro.au">Steve Clift &lt;clift@ml.csiro.au&gt;</a> OMEGA clock driver
<li class="inline"><a href="mailto:casey@csc.co.za">Casey Crellin &lt;casey@csc.co.za&gt;</a> vxWorks (Tornado) port and help with target configuration
<li class="inline"><a href="mailto:%20Sven_Dietrich@trimble.COM">Sven Dietrich &lt;sven_dietrich@trimble.com&gt;</a> Palisade reference clock driver, NT adj. residuals, integrated Greg's Winnt port.
<li class="inline"><a href="mailto:%20dundas@salt.jpl.nasa.gov">John A. Dundas III &lt;dundas@salt.jpl.nasa.gov&gt;</a> Apple A/UX port
<li class="inline"><a href="mailto:%20duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe &lt;duwe@immd4.informatik.uni-erlangen.de&gt;</a> Linux port
<li class="inline"><a href="mailto:%20dennis@mrbill.canet.ca">Dennis Ferguson &lt;dennis@mrbill.canet.ca&gt;</a> foundation code for NTP Version 2 as specified in RFC-1119
<li class="inline"><a href="mailto:%20jhay@icomtek.csir.co.za">John Hay &lt;jhay@icomtek.csir.co.za&gt;</a> IPv6 support and testing
<li class="inline"><a href="mailto:%20davehart@davehart.com">Dave Hart &lt;davehart@davehart.com&gt;</a> General maintenance, Windows port interpolation rewrite
<li class="inline"><a href="mailto:%20neoclock4x@linum.com">Claas Hilbrecht &lt;neoclock4x@linum.com&gt;</a> NeoClock4X clock driver
<li class="inline"><a href="mailto:%20glenn@herald.usask.ca">Glenn Hollinger &lt;glenn@herald.usask.ca&gt;</a> GOES clock driver
<li class="inline"><a href="mailto:%20iglesias@uci.edu">Mike Iglesias &lt;iglesias@uci.edu&gt;</a> DEC Alpha port
<li class="inline"><a href="mailto:%20jagubox.gsfc.nasa.gov">Jim Jagielski &lt;jim@jagubox.gsfc.nasa.gov&gt;</a> A/UX port
<li class="inline"><a href="mailto:%20jbj@chatham.usdesign.com">Jeff Johnson &lt;jbj@chatham.usdesign.com&gt;</a> massive prototyping overhaul
<li class="inline"><a href="mailto:Hans.Lambermont@nl.origin-it.com">Hans Lambermont &lt;Hans.Lambermont@nl.origin-it.com&gt;</a> or <a href="mailto:H.Lambermont@chello.nl">&lt;H.Lambermont@chello.nl&gt;</a> ntpsweep
<li class="inline"><a href="mailto:%20phk@FreeBSD.ORG">Poul-Henning Kamp &lt;phk@FreeBSD.ORG&gt;</a> Oncore driver (Original author)
<li class="inline"><a href="http://www4.informatik.uni-erlangen.de/%7ekardel">Frank Kardel</a> <a href="mailto:%20kardel (at) ntp (dot) org">&lt;kardel (at) ntp (dot) org&gt;</a> PARSE &lt;GENERIC&gt; driver (>14 reference clocks), STREAMS modules for PARSE, support scripts, syslog cleanup, dynamic interface handling
<li class="inline"><a href="mailto:%20jones@hermes.chpc.utexas.edu">William L. Jones &lt;jones@hermes.chpc.utexas.edu&gt;</a> RS/6000 AIX modifications, HPUX modifications
<li class="inline"><a href="mailto:%20dkatz@cisco.com">Dave Katz &lt;dkatz@cisco.com&gt;</a> RS/6000 AIX port
<li class="inline"><a href="mailto:%20leres@ee.lbl.gov">Craig Leres &lt;leres@ee.lbl.gov&gt;</a> 4.4BSD port, ppsclock, Magnavox GPS clock driver
<li class="inline"><a href="mailto:%20lindholm@ucs.ubc.ca">George Lindholm &lt;lindholm@ucs.ubc.ca&gt;</a> SunOS 5.1 port
<li class="inline"><a href="mailto:%20louie@ni.umd.edu">Louis A. Mamakos &lt;louie@ni.umd.edu&gt;</a> MD5-based authentication
<li class="inline"><a href="mailto:%20thorinn@diku.dk">Lars H. Mathiesen &lt;thorinn@diku.dk&gt;</a> adaptation of foundation code for Version 3 as specified in RFC-1305
<li class="inline"><a href="mailto:%20mayer@ntp.org">Danny Mayer &lt;mayer@ntp.org&gt;</a>Network I/O, Windows Port, Code Maintenance
<li class="inline"><a href="mailto:%20mills@udel.edu">David L. Mills &lt;mills@udel.edu&gt;</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 class="inline"><a href="mailto:%20moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller &lt;moeller@gwdgv1.dnet.gwdg.de&gt;</a> VMS port
<li class="inline"><a href="mailto:%20mogul@pa.dec.com">Jeffrey Mogul &lt;mogul@pa.dec.com&gt;</a> ntptrace utility
<li class="inline"><a href="mailto:%20tmoore@fievel.daytonoh.ncr.com">Tom Moore &lt;tmoore@fievel.daytonoh.ncr.com&gt;</a> i386 svr4 port
<li class="inline"><a href="mailto:%20kamal@whence.com">Kamal A Mostafa &lt;kamal@whence.com&gt;</a> SCO OpenServer port
<li class="inline"><a href="mailto:%20derek@toybox.demon.co.uk">Derek Mulcahy &lt;derek@toybox.demon.co.uk&gt;</a> and <a href="mailto:%20d@hd.org">Damon Hart-Davis &lt;d@hd.org&gt;</a> ARCRON MSF clock driver
<li class="inline"><a href="mailto:%20neal@ntp.org">Rob Neal &lt;neal@ntp.org&gt;</a> Bancomm refclock and config/parse code maintenance
<li class="inline"><a href="mailto:%20Rainer.Pruy@informatik.uni-erlangen.de">Rainer Pruy &lt;Rainer.Pruy@informatik.uni-erlangen.de&gt;</a> monitoring/trap scripts, statistics file handling
<li class="inline"><a href="mailto:%20dirce@zk3.dec.com">Dirce Richards &lt;dirce@zk3.dec.com&gt;</a> Digital UNIX V4.0 port
<li class="inline"><a href="mailto:%20wsanchez@apple.com">Wilfredo S&aacute;nchez &lt;wsanchez@apple.com&gt;</a> added support for NetInfo
<li class="inline"><a href="mailto:%20mrapple@quack.kfu.com">Nick Sayer &lt;mrapple@quack.kfu.com&gt;</a> SunOS streams modules
<li class="inline"><a href="mailto:%20jack@innovativeinternet.com">Jack Sasportas &lt;jack@innovativeinternet.com&gt;</a> Saved a Lot of space on the stuff in the html/pic/ subdirectory
<li class="inline"><a href="mailto:%20schnitz@unipress.com">Ray Schnitzler &lt;schnitz@unipress.com&gt;</a> Unixware1 port
<li class="inline"><a href="mailto:%20shields@tembel.org">Michael Shields &lt;shields@tembel.org&gt;</a> USNO clock driver
<li class="inline"><a href="mailto:%20pebbles.jpl.nasa.gov">Jeff Steinman &lt;jss@pebbles.jpl.nasa.gov&gt;</a> Datum PTS clock driver
<li class="inline"><a href="mailto:%20harlan@pfcs.com">Harlan Stenn &lt;harlan@pfcs.com&gt;</a> GNU automake/autoconfigure makeover, various other bits (see the ChangeLog)
<li class="inline"><a href="mailto:%20ken@sdd.hp.com">Kenneth Stone &lt;ken@sdd.hp.com&gt;</a> HP-UX port
<li class="inline"><a href="mailto:%20ajit@ee.udel.edu">Ajit Thyagarajan &lt;ajit@ee.udel.edu&gt;</a>IP multicast/anycast support
<li class="inline"><a href="mailto:%20tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA &lt;tsuruoka@nc.fukuoka-u.ac.jp&gt;</a>TRAK clock driver
<li class="inline"><a href="mailto:%20vixie@vix.com">Paul A Vixie &lt;vixie@vix.com&gt;</a> TrueTime GPS driver, generic TrueTime clock driver
<li class="inline"><a href="mailto:%20Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl &lt;Ulrich.Windl@rz.uni-regensburg.de&gt;</a> corrected and validated HTML documents according to the HTML DTD
</ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<p>The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.</p>
<ol>
<li><a href="mailto:%20takao_abe@xurb.jp">Takao Abe &lt;takao_abe@xurb.jp&gt;</a> Clock driver for JJY receivers</li>
<li><a href="mailto:%20mark_andrews@isc.org">Mark Andrews &lt;mark_andrews@isc.org&gt;</a> Leitch atomic clock controller</li>
<li><a href="mailto:%20altmeier@atlsoft.de">Bernd Altmeier &lt;altmeier@atlsoft.de&gt;</a> hopf Elektronik serial line and PCI-bus devices</li>
<li><a href="mailto:%20vbais@mailman1.intel.co">Viraj Bais &lt;vbais@mailman1.intel.com&gt;</a> and <a href="mailto:%20kirkwood@striderfm.intel.com">Clayton Kirkwood &lt;kirkwood@striderfm.intel.com&gt;</a> port to WindowsNT 3.5</li>
<li><a href="mailto:%20michael.barone@lmco.com">Michael Barone &lt;michael,barone@lmco.com&gt;</a> GPSVME fixes</li>
<li><a href="mailto:%20karl@owl.HQ.ileaf.com">Karl Berry &lt;karl@owl.HQ.ileaf.com&gt;</a> syslog to file option</li>
<li><a href="mailto:%20greg.brackley@bigfoot.com">Greg Brackley &lt;greg.brackley@bigfoot.com&gt;</a> Major rework of WINNT port. Clean up recvbuf and iosignal code into separate modules.</li>
<li><a href="mailto:%20Marc.Brett@westgeo.com">Marc Brett &lt;Marc.Brett@westgeo.com&gt;</a> Magnavox GPS clock driver</li>
<li><a href="mailto:%20Piete.Brooks@cl.cam.ac.uk">Piete Brooks &lt;Piete.Brooks@cl.cam.ac.uk&gt;</a> MSF clock driver, Trimble PARSE support</li>
<li><a href="mailto:%20nelson@bolyard.me">Nelson B Bolyard &lt;nelson@bolyard.me&gt;</a> update and complete broadcast and crypto features in sntp</li>
<li><a href="mailto:%20Jean-Francois.Boudreault@viagenie.qc.ca">Jean-Francois Boudreault &lt;Jean-Francois.Boudreault@viagenie.qc.ca&gt;</a> IPv6 support</li>
<li><a href="mailto:%20reg@dwf.com">Reg Clemens &lt;reg@dwf.com&gt;</a> Oncore driver (Current maintainer)</li>
<li><a href="mailto:%20clift@ml.csiro.au">Steve Clift &lt;clift@ml.csiro.au&gt;</a> OMEGA clock driver</li>
<li><a href="mailto:%20casey@csc.co.za">Casey Crellin &lt;casey@csc.co.za&gt;</a> vxWorks (Tornado) port and help with target configuration</li>
<li><a href="mailto:%20Sven_Dietrich@trimble.COM">Sven Dietrich &lt;sven_dietrich@trimble.com&gt;</a> Palisade reference clock driver, NT adj. residuals, integrated Greg's Winnt port.</li>
<li><a href="mailto:%20dundas@salt.jpl.nasa.gov">John A. Dundas III &lt;dundas@salt.jpl.nasa.gov&gt;</a> Apple A/UX port</li>
<li><a href="mailto:%20duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe &lt;duwe@immd4.informatik.uni-erlangen.de&gt;</a> Linux port</li>
<li><a href="mailto:%20dennis@mrbill.canet.ca">Dennis Ferguson &lt;dennis@mrbill.canet.ca&gt;</a> foundation code for NTP Version 2 as specified in RFC-1119</li>
<li><a href="mailto:%20jhay@icomtek.csir.co.za">John Hay &lt;jhay@icomtek.csir.co.za&gt;</a> IPv6 support and testing</li>
<li><a href="mailto:%20davehart@davehart.com">Dave Hart &lt;davehart@davehart.com&gt;</a> General maintenance, Windows port interpolation rewrite</li>
<li><a href="mailto:%20neoclock4x@linum.com">Claas Hilbrecht &lt;neoclock4x@linum.com&gt;</a> NeoClock4X clock driver</li>
<li><a href="mailto:%20glenn@herald.usask.ca">Glenn Hollinger &lt;glenn@herald.usask.ca&gt;</a> GOES clock driver</li>
<li><a href="mailto:%20iglesias@uci.edu">Mike Iglesias &lt;iglesias@uci.edu&gt;</a> DEC Alpha port</li>
<li><a href="mailto:%20jagubox.gsfc.nasa.gov">Jim Jagielski &lt;jim@jagubox.gsfc.nasa.gov&gt;</a> A/UX port</li>
<li><a href="mailto:%20jbj@chatham.usdesign.com">Jeff Johnson &lt;jbj@chatham.usdesign.com&gt;</a> massive prototyping overhaul</li>
<li><a href="mailto:%20Hans.Lambermont@nl.origin-it.com">Hans Lambermont &lt;Hans.Lambermont@nl.origin-it.com&gt;</a> or <a href="mailto:H.Lambermont@chello.nl">&lt;H.Lambermont@chello.nl&gt;</a> ntpsweep</li>
<li><a href="mailto:%20phk@FreeBSD.ORG">Poul-Henning Kamp &lt;phk@FreeBSD.ORG&gt;</a> Oncore driver (Original author)</li>
<li><a href="http://www4.informatik.uni-erlangen.de/%7ekardel">Frank Kardel</a> <a href="mailto:%20kardel%20%28at%29%20ntp%20%28dot%29%20org">&lt;kardel (at) ntp (dot) org&gt;</a> PARSE &lt;GENERIC&gt; (driver 14 reference clocks), STREAMS modules for PARSE, support scripts, syslog cleanup, dynamic interface handling</li>
<li><a href="mailto:kuehn@ntp.org">Johannes Maximilian Kuehn &lt;kuehn@ntp.org&gt;</a> Rewrote <tt>sntp</tt> to comply with NTPv4 specification, <tt>ntpq saveconfig</tt></li>
<li><a href="mailto:%20jones@hermes.chpc.utexas.edu">William L. Jones &lt;jones@hermes.chpc.utexas.edu&gt;</a> RS/6000 AIX modifications, HPUX modifications</li>
<li><a href="mailto:%20dkatz@cisco.com">Dave Katz &lt;dkatz@cisco.com&gt;</a> RS/6000 AIX port</li>
<li><a href="mailto:%20leres@ee.lbl.gov">Craig Leres &lt;leres@ee.lbl.gov&gt;</a> 4.4BSD port, ppsclock, Magnavox GPS clock driver</li>
<li><a href="mailto:%20lindholm@ucs.ubc.ca">George Lindholm &lt;lindholm@ucs.ubc.ca&gt;</a> SunOS 5.1 port</li>
<li><a href="mailto:%20louie@ni.umd.edu">Louis A. Mamakos &lt;louie@ni.umd.edu&gt;</a> MD5-based authentication</li>
<li><a href="mailto:%20thorinn@diku.dk">Lars H. Mathiesen &lt;thorinn@diku.dk&gt;</a> adaptation of foundation code for Version 3 as specified in RFC-1305</li>
<li><a href="mailto:%20mayer@ntp.org">Danny Mayer &lt;mayer@ntp.org&gt;</a>Network I/O, Windows Port, Code Maintenance</li>
<li><a href="mailto:%20mills@udel.edu">David L. Mills &lt;mills@udel.edu&gt;</a> Version 4 foundation, precision kernel; clock drivers: 1, 3, 4, 6, 7, 11, 13, 18, 19, 22, 36</li>
<li><a href="mailto:%20moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller &lt;moeller@gwdgv1.dnet.gwdg.de&gt;</a> VMS port</li>
<li><a href="mailto:%20mogul@pa.dec.com">Jeffrey Mogul &lt;mogul@pa.dec.com&gt;</a> ntptrace utility</li>
<li><a href="mailto:%20tmoore@fievel.daytonoh.ncr.com">Tom Moore &lt;tmoore@fievel.daytonoh.ncr.com&gt;</a> i386 svr4 port</li>
<li><a href="mailto:%20kamal@whence.com">Kamal A Mostafa &lt;kamal@whence.com&gt;</a> SCO OpenServer port</li>
<li><a href="mailto:%20derek@toybox.demon.co.uk">Derek Mulcahy &lt;derek@toybox.demon.co.uk&gt;</a> and <a href="mailto:%20d@hd.org">Damon Hart-Davis &lt;d@hd.org&gt;</a> ARCRON MSF clock driver</li>
<li><a href="mailto:%20neal@ntp.org">Rob Neal &lt;neal@ntp.org&gt;</a> Bancomm refclock and config/parse code maintenance</li>
<li><a href="mailto:%20Rainer.Pruy@informatik.uni-erlangen.de">Rainer Pruy &lt;Rainer.Pruy@informatik.uni-erlangen.de&gt;</a> monitoring/trap scripts, statistics file handling</li>
<li><a href="mailto:%20dirce@zk3.dec.com">Dirce Richards &lt;dirce@zk3.dec.com&gt;</a> Digital UNIX V4.0 port</li>
<li><a href="mailto:%20wsanchez@apple.com">Wilfredo S&aacute;nchez &lt;wsanchez@apple.com&gt;</a> added support for NetInfo</li>
<li><a href="mailto:%20mrapple@quack.kfu.com">Nick Sayer &lt;mrapple@quack.kfu.com&gt;</a> SunOS streams modules</li>
<li><a href="mailto:%20jack@innovativeinternet.com">Jack Sasportas &lt;jack@innovativeinternet.com&gt;</a> Saved a Lot of space on the stuff in the html/pic/ subdirectory</li>
<li><a href="mailto:%20schnitz@unipress.com">Ray Schnitzler &lt;schnitz@unipress.com&gt;</a> Unixware1 port</li>
<li><a href="mailto:%20shields@tembel.org">Michael Shields &lt;shields@tembel.org&gt;</a> USNO clock driver</li>
<li><a href="mailto:%20pebbles.jpl.nasa.gov">Jeff Steinman &lt;jss@pebbles.jpl.nasa.gov&gt;</a> Datum PTS clock driver</li>
<li><a href="mailto:%20harlan@pfcs.com">Harlan Stenn &lt;harlan@pfcs.com&gt;</a> GNU automake/autoconfigure makeover, various other bits (see the ChangeLog)</li>
<li><a href="mailto:%20ken@sdd.hp.com">Kenneth Stone &lt;ken@sdd.hp.com&gt;</a> HP-UX port</li>
<li><a href="mailto:%20ajit@ee.udel.edu">Ajit Thyagarajan &lt;ajit@ee.udel.edu&gt;</a>IP multicast/anycast support</li>
<li><a href="mailto:%20tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA &lt;tsuruoka@nc.fukuoka-u.ac.jp&gt;</a>TRAK clock driver</li>
<li><a href="mailto:%20brian.utterback@oracle.com">Brian Utterback &lt;brian.utterback@oracle.com&gt;</a> General codebase, Solaris issues</li>
<li><a href="mailto:%20loganaden@gmail.com">Loganaden Velvindron &lt;loganaden@gmail.com&gt;</a> Sandboxing (libseccomp) support</li>
<li><a href="mailto:%20vixie@vix.com">Paul A Vixie &lt;vixie@vix.com&gt;</a> TrueTime GPS driver, generic TrueTime clock driver</li>
<li><a href="mailto:%20Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl &lt;Ulrich.Windl@rz.uni-regensburg.de&gt;</a> corrected and validated HTML documents according to the HTML DTD</li>
</ol>
<hr>
</body>
</html>

185
html/debug.html
View File

@ -1,96 +1,93 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>NTP Debugging Techniques</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>NTP Debugging Techniques</h3>
<img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We make house calls and bring our own bugs.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->16-Jul-2009 19:36<!-- #EndDate -->
UTC</p>
<h4>More Help</h4>
<script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
<hr>
<h4>Initial Startup</h4>
<p>This page discusses <tt>ntpd</tt> program monitoring and debugging techniques using the <a href="ntpq.html"><tt>ntpq</tt> - standard NTP query program</a>, either on the local server or from a remote machine. In special circumstances the <a href="ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a>, can be useful, but its use is not covered here. The <tt>ntpq</tt> program implements the management functions specified in the NTP specification <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.ps">RFC-1305, Appendix A</a>. It is used to read and write the variables defined in the NTP Version 4 specification now navigating the standards process. In addition, the program can be used to send remote configuration commands to the server.</p>
<p>The <tt>ntpd</tt> daemon can operate in two modes, depending on the presence of the <tt>-d</tt> command-line option. Without the option the daemon detaches from the controlling terminal and proceeds autonomously. With one or more <tt>-d</tt> options the daemon does not detach and generates special trace output useful for debugging. In general, interpretation of this output requires reference to the sources. However, a single <tt>-d</tt> does produce only mildly cryptic output and can be very useful in finding problems with configuration and network troubles.</p>
<p>Some problems are immediately apparent when the daemon first starts running. The most common of these are the lack of a UDP port for NTP (123) in the Unix <tt>/etc/services</tt> file (or equivalent in some systems). <b>Note that NTP does not use TCP in any form. Also note that NTP requires port 123 for both source and destination ports.</b> These facts should be pointed out to firewall administrators.</p>
<p>Other problems are apparent in the system log, which ordinarily shows the startup banner, some cryptic initialization data and the computed precision value. Event messages at startup and during regular operation are sent to the optional <tt>protostats</tt> monitor file, as described on the <a href="decode.html">Event Messages and Status Words</a> page. These and other error messages are sent to the system log, as described on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page. In real emergencies the daemon will sent a terminal error message to the system log and then cease operation.</p>
<p>The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the Unix <tt>ping</tt> command. The Unix <tt>traceroute</tt> or Windows <tt>tracert</tt> utility can be used to verify a partial or complete path exists. Most problems reported to the NTP newsgroup are not NTP problems, but problems with the network or firewall configuration.</p>
<h4>Verifying Correct Operation</h4>
<p>Unless using the <tt>iburst</tt> option, the client normally takes a few
minutes to synchronize to a server. If the client time at startup happens
to be more than 1000 s distant from NTP time, the daemon exits with a message
to the system log directing the operator to manually set the time within 1000
s and restart. If the time is less than 1000 s but more than 128 s distant,
a step correction occurs and the daemon restarts automatically.</p>
<p>When started for the first time and a frequency file is not present, the
daemon enters a special mode in order to calibrate the frequency. This takes
900 s during which the time is not disciplined. When calibration is complete,
the daemon creates the frequency file and enters normal mode to amortize whatever
residual offset remains.</p>
<p>The <tt>ntpq</tt> commands <tt>pe</tt>, <tt>as</tt> and <tt>rv</tt> are
normally sufficient to verify correct operation and assess nominal performance.
The <a href="ntpq.html#pe"><tt>pe</tt></a> command displays a list showing
the DNS name or IP address for each association along with selected status
and statistics variables. The first character in each line is the tally code,
which shows which associations are candidates to set the system clock and
of these which one is the system peer. The encoding is shown in the <tt>select</tt>
field of the <a href="decode.html#peer">peer status word</a>.</p>
<p>The <a href="ntpq.html#as"><tt>as</tt></a> command displays a list of associations and association identifiers. Note the <tt>condition</tt> column, which reflects the tally code. The <a href="ntpq.html#pe"><tt>rv</tt></a> command displays the <a href="ntpq.html#system">system variables</a> billboard, including the <a href="decode.html#sys">system status word</a>. The <a href="ntpq.html#rv"><tt>rv <i>assocID</i></tt></a> command, where <tt><i>assocID</i></tt> is the association ID, displays the <a href="ntpq.html#peer">peer variables</a> billboard, including the <a href="decode.html#peer">peer status word</a>. Note that, except for explicit calendar dates, times are in milliseconds and frequencies are in parts-per-million (PPM).</p>
<p>A detailed explanation of the system, peer and clock variables in the billboards is beyond the scope of this page; however, a comprehensive explanation for each one is in the NTPv4 protocol specification. The following observations will be useful in debugging and monitoring.</p>
<ol>
<li>The server has successfully synchronized to its sources if the <tt>leap</tt> peer
variable has value other than 3 (11b) The client has successfully synchronized
to the server when the <tt>leap</tt> system variable has value other than
3.
<li>The <tt>reach</tt> peer variable is an 8-bit shift register displayed in octal format. When a valid packet is received, the rightmost bit is lit. When a packet is sent, the register is shifted left one bit with 0 replacing the rightmost bit. If the <tt>reach</tt> value is nonzero, the server is reachable; otherwise, it is unreachable. Note that, even if all servers become unreachable, the system continues to show valid time to dependent applications.
<li>A useful indicator of miscellaneous problems is the <tt>flash</tt> peer variable, which shows the result of 13 sanity tests. It contains the <a href="decode.html#flash">flash status word</a> bits, commonly called flashers, which displays the current errors for the association. These bits should all be zero for a valid server.
<li>The three peer variables <tt>filtdelay</tt>, <tt>filtoffset</tt> and <tt>filtdisp</tt> show the delay, offset and jitter statistics for each of the last eight measurement rounds. These statistics and their trends are valuable performance indicators for the server, client and the network. For instance, large fluctuations in delay and jitter suggest network congestion. Missing clock filter stages suggest packet losses in the network.
<li>The synchronization distance, defined as one-half the delay plus the dispersion, represents the maximum error statistic. The jitter represents the expected error statistic. The maximum error and expected error calculated from the peer variables represents the quality metric for the server. The maximum error and expected error calculated from the system variables represents the quality metric for the client. If the root synchronization distance for any server exceeds 1.5 s, called the select threshold, the server is considered invalid.</ol>
<h4>Large Frequency Errors</h4>
<p>The frequency tolerance of computer clock oscillators varies widely, sometimes above 500 PPM. While the daemon can handle frequency errors up to 500 PPM, or 43 seconds per day, values much above 100 PPM reduce the headroom, especially at the lowest poll intervals. To determine the particular oscillator frequency, start <tt>ntpd</tt> using the <tt>noselect</tt> option with the <tt>server</tt> configuration command.</p>
<p>Record the time of day and offset displayed by the <tt>ntpq</tt> <a href="ntpq.html#pe"><tt>pe</tt></a> command. Wait for an hour or so and record the time of day and offset. Calculate the frequency as the offset difference divided by the time difference. If the frequency is much above 100 PPM, the <a href="tickadj.html">tickadj</a> program might be useful to adjust the kernel clock frequency below that value. For systems that do not support this program, this might be one using a command in the system startup file.</p>
<h4>Access Controls</h4>
<p>Provisions are included in <tt>ntpd</tt> for access controls which deflect unwanted traffic from selected hosts or networks. The controls described on the <a href="accopt.html">Access Control Options</a> include detailed packet filter operations based on source address and address mask. Normally, filtered packets are dropped without notice other than to increment tally counters. However, the server can be configured to send a &quot;kiss-o'-death&quot; (KOD) packet to the client either when explicitly configured or when cryptographic authentication fails for some reason. The client association is permanently disabled, the access denied bit (TEST4) is set in the flash variable and a message is sent to the system log.</p>
<p>The access control provisions include a limit on the packet rate from a
host or network. If an incoming packet exceeds the limit, it is dropped and
a KOD sent to the source. If this occurs after the client association has
synchronized, the association is not disabled, but a message is sent to the
system log. See the <a href="accopt.html">Access Control Options</a> page
for further information.</p>
<h4>Large Delay Variations</h4>
<p>In some reported scenarios an access line may show low to moderate network delays during some period of the day and moderate to high delays during other periods. Often the delay on one direction of transmission dominates, which can result in large time offset errors, sometimes in the range up to a few seconds. It is not usually convenient to run <tt>ntpd</tt> throughout the day in such scenarios, since this could result in several time steps, especially if the condition persists for greater than the stepout threshold.</p>
<p>Specific provisions have been built into <tt>ntpd</tt> to cope with these problems. The scheme is called &quot;huff-'n-puff and is described on the <a href="miscopt.html">Miscellaneous Options</a> page. An alternative approach in such scenarios is first to calibrate the local clock frequency error by running <tt>ntpd</tt> in continuous mode during the quiet interval and let it write the frequency to the <tt>ntp.drift</tt> file. Then, run <tt>ntpd -q</tt> from a cron job each day at some time in the quiet interval. In systems with the nanokernel or microkernel performance enhancements, including Solaris, Tru64, Linux and FreeBSD, the kernel continuously disciplines the frequency so that the residual correction produced by <tt>ntpd</tt> is usually less than a few milliseconds.</p>
<h4>Cryptographic Authentication</h4>
<p>Reliable source authentication requires the use of symmetric key or public key cryptography, as described on the <a href="authopt.html">Authentication Options</a> page. In symmetric key cryptography servers and clients share session keys contained in a secret key file In public key cryptography, which requires the OpenSSL software library, the server has a private key, never shared, and a public key with unrestricted distribution. The cryptographic media required are produced by the <a href="keygen.html"><tt>ntp-keygen</tt></a> program.</p>
<p>Problems with symmetric key authentication are usually due to mismatched keys or improper use of the <tt>trustedkey</tt> command. A simple way to check for problems is to use the trace facility, which is enabled using the <tt>ntpd -d</tt> command line. As each packet is received a trace line is displayed which shows the authentication status in the <tt>auth</tt> field. A status of 1 indicates the packet was successful authenticated; otherwise it has failed.</p>
<p>A common misconception is the implication of the <tt>auth</tt> bit in the <tt>enable</tt> and <tt>disable</tt> commands. <b>This bit does not affect authentication in any way other than to enable or disable mobilization of a new persistent association in broadcast/multicast client, manycast client or symmetric passive modes.</b> If enabled, which is the default, these associations require authentication; if not, an association is mobilized even if not authenticated. Users are cautioned that running with authentication disabled is very dangerous, since an intruder can easily strike up an association and inject false time values.</p>
<p>Public key cryptography is supported in NTPv4 using the Autokey protocol, which is described in briefings on the NTP Project page linked from www.ntp.org. Development of this protocol is mature and the <tt>ntpd</tt> implementation is basically complete. Autokey version 2, which is the latest and current version, includes provisions to hike certificate trails, operate as certificate authorities and verify identity using challenge/response identification schemes. Further details of the protocol are on the <a href="authopt.html">Authentication Options</a> page. Common problems with configuration and key generation are mismatched key files, broken links and missing or broken random seed file.</p>
<p>As in the symmetric key cryptography case, the trace facility is a good way to verify correct operation. A statistics file <tt>cryptostats</tt> records protocol transactions and error messages. The daemon requires a random seed file, public/private key file and a valid certificate file; otherwise it exits immediately with a message to the system log. As each file is loaded a trace message appears with its filestamp. There are a number of checks to insure that only consistent data are used and that the certificate is valid. When the protocol is in operation a number of checks are done to verify the server has the expected credentials and its filestamps and timestamps are consistent. Errors found are reported using NTP control and monitoring protocol traps with extended trap codes shown in the Authentication Options page.</p>
<p>To assist debugging every NTP extension field is displayed in the trace along with the Autokey operation code. Every extension field carrying a verified signature is identified and displayed along with filestamp and timestamp where meaningful. In all except broadcast/multicast client mode, correct operation of the protocol is confirmed by the absence of extension fields and an <tt>auth</tt> value of one. It is normal in broadcast/multicast client mode that the broadcast server use one extension field to show the host name, status word and association ID.</p>
<h4>Debugging Checklist</h4>
<p>If the <tt>ntpq</tt> or <tt>ntpdc</tt> programs do not show that messages are being received by the daemon or that received messages do not result in correct synchronization, verify the following:</p>
<ol>
<li>Verify the <tt>/etc/services</tt> file host machine is configured to accept UDP packets on the NTP port 123. NTP is specifically designed to use UDP and does not respond to TCP.
<li>Check the system log for <tt>ntpd</tt> messages about configuration errors, name-lookup failures or initialization problems. Common system log messages are summarized on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page. Check to be sure that only one copy of <tt>ntpd</tt> is running.
<li>Verify using <tt>ping</tt> or other utility that packets actually do make the round trip between the client and server. Verify using <tt>nslookup</tt> or other utility that the DNS server names do exist and resolve to valid Internet addresses.
<li>Check that the remote NTP server is up and running. The usual evidence that it is not is a <tt>Connection refused</tt> message.
<li>Using the <tt>ntpdc</tt> program, verify that the packets received and packets sent counters are incrementing. If the sent counter does not increment and the configuration file includes configured servers, something may be wrong in the host network or interface configuration. If this counter does increment, but the received counter does not increment, something may be wrong in the network or the server NTP daemon may not be running or the server itself may be down or not responding.
<li>If both the sent and received counters do increment, but the <tt>reach</tt> values in the <tt>pe</tt> billboard with <tt>ntpq</tt> continues to show zero, received packets are probably being discarded for some reason. If this is the case, the cause should be evident from the <tt>flash</tt> variable as discussed above and on the <tt>ntpq</tt> page. It could be that the server has disabled access for the client address, in which case the <tt>refid</tt> field in the <tt>ntpq pe</tt> billboard will show a kiss code. See earlier on this page for a list of kiss codes and their meaning.
<li>If the <tt>reach</tt> values in the <tt>pe</tt> billboard show the servers are alive and responding, note the tattletale symbols at the left margin, which indicate the status of each server resulting from the various grooming and mitigation algorithms. The interpretation of these symbols is discussed on the <tt>ntpq</tt> page. After a few minutes of operation, one or another of the reachable server candidates should show a * tattletale symbol. If this doesn't happen, the intersection algorithm, which classifies the servers as truechimers or falsetickers, may be unable to find a majority of truechimers among the server population.
<li>If all else fails, see the FAQ and/or the discussion and briefings at the NTP Project page.
</ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>NTP Debugging Techniques</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>NTP Debugging Techniques</h3>
<img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We make house calls and bring our own bugs.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->16-Jul-2014 08:38<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>More Help</h4>
<script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
<hr>
<h4>Initial Startup</h4>
<p>This page discusses <tt>ntpd</tt> program monitoring and debugging techniques using the <a href="ntpq.html"><tt>ntpq</tt> - standard NTP query program</a>, either on the local server or from a remote machine. In special circumstances the <a href="ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a>, can be useful, but its use is not covered here. The <tt>ntpq</tt> program implements the management functions specified in the NTP specification <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.ps">RFC-1305, Appendix A</a>. It is used to read and write the variables defined in the NTP Version 4 specification now navigating the standards process. In addition, the program can be used to send remote configuration commands to the server.</p>
<p>The <tt>ntpd</tt> daemon can operate in two modes, depending on the presence of the <tt>-d</tt> command-line option. Without the option the daemon detaches from the controlling terminal and proceeds autonomously. With one or more <tt>-d</tt> options the daemon does not detach and generates special trace output useful for debugging. In general, interpretation of this output requires reference to the sources. However, a single <tt>-d</tt> does produce only mildly cryptic output and can be very useful in finding problems with configuration and network troubles.</p>
<p>Some problems are immediately apparent when the daemon first starts running. The most common of these are the lack of a UDP port for NTP (123) in the Unix <tt>/etc/services</tt> file (or equivalent in some systems). <b>Note that NTP does not use TCP in any form. Also note that NTP requires port 123 for both source and destination ports.</b> These facts should be pointed out to firewall administrators.</p>
<p>Other problems are apparent in the system log, which ordinarily shows the startup banner, some cryptic initialization data and the computed precision value. Event messages at startup and during regular operation are sent to the optional <tt>protostats</tt> monitor file, as described on the <a href="decode.html">Event Messages and Status Words</a> page. These and other error messages are sent to the system log, as described on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page. In real emergencies the daemon will sent a terminal error message to the system log and then cease operation.</p>
<p>The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the Unix <tt>ping</tt> command. The Unix <tt>traceroute</tt> or Windows <tt>tracert</tt> utility can be used to verify a partial or complete path exists. Most problems reported to the NTP newsgroup are not NTP problems, but problems with the network or firewall configuration.</p>
<h4>Verifying Correct Operation</h4>
<p>Unless using the <tt>iburst</tt> option, the client normally takes a few
minutes to synchronize to a server. If the client time at startup happens
to be more than 1000 s distant from NTP time, the daemon exits with a message
to the system log directing the operator to manually set the time within 1000
s and restart. If the time is less than 1000 s but more than 128 s distant,
a step correction occurs and the daemon restarts automatically.</p>
<p>When started for the first time and a frequency file is not present, the
daemon enters a special mode in order to calibrate the frequency. This takes
900 s during which the time is not disciplined. When calibration is complete,
the daemon creates the frequency file and enters normal mode to amortize whatever
residual offset remains.</p>
<p>The <tt>ntpq</tt> commands <tt>pe</tt>, <tt>as</tt> and <tt>rv</tt> are
normally sufficient to verify correct operation and assess nominal performance.
The <a href="ntpq.html#pe"><tt>pe</tt></a> command displays a list showing
the DNS name or IP address for each association along with selected status
and statistics variables. The first character in each line is the tally code,
which shows which associations are candidates to set the system clock and
of these which one is the system peer. The encoding is shown in the <tt>select</tt> field of the <a href="decode.html#peer">peer status word</a>.</p>
<p>The <a href="ntpq.html#as"><tt>as</tt></a> command displays a list of associations and association identifiers. Note the <tt>condition</tt> column, which reflects the tally code. The <a href="ntpq.html#pe"><tt>rv</tt></a> command displays the <a href="ntpq.html#system">system variables</a> billboard, including the <a href="decode.html#sys">system status word</a>. The <a href="ntpq.html#rv"><tt>rv <i>assocID</i></tt></a> command, where <tt><i>assocID</i></tt> is the association ID, displays the <a href="ntpq.html#peer">peer variables</a> billboard, including the <a href="decode.html#peer">peer status word</a>. Note that, except for explicit calendar dates, times are in milliseconds and frequencies are in parts-per-million (PPM).</p>
<p>A detailed explanation of the system, peer and clock variables in the billboards is beyond the scope of this page; however, a comprehensive explanation for each one is in the NTPv4 protocol specification. The following observations will be useful in debugging and monitoring.</p>
<ol>
<li>The server has successfully synchronized to its sources if the <tt>leap</tt> peer
variable has value other than 3 (11b) The client has successfully synchronized
to the server when the <tt>leap</tt> system variable has value other than
3.</li>
<li>The <tt>reach</tt> peer variable is an 8-bit shift register displayed in octal format. When a valid packet is received, the rightmost bit is lit. When a packet is sent, the register is shifted left one bit with 0 replacing the rightmost bit. If the <tt>reach</tt> value is nonzero, the server is reachable; otherwise, it is unreachable. Note that, even if all servers become unreachable, the system continues to show valid time to dependent applications.</li>
<li>A useful indicator of miscellaneous problems is the <tt>flash</tt> peer variable, which shows the result of 13 sanity tests. It contains the <a href="decode.html#flash">flash status word</a> bits, commonly called flashers, which displays the current errors for the association. These bits should all be zero for a valid server.</li>
<li>The three peer variables <tt>filtdelay</tt>, <tt>filtoffset</tt> and <tt>filtdisp</tt> show the delay, offset and jitter statistics for each of the last eight measurement rounds. These statistics and their trends are valuable performance indicators for the server, client and the network. For instance, large fluctuations in delay and jitter suggest network congestion. Missing clock filter stages suggest packet losses in the network.</li>
<li>The synchronization distance, defined as one-half the delay plus the dispersion, represents the maximum error statistic. The jitter represents the expected error statistic. The maximum error and expected error calculated from the peer variables represents the quality metric for the server. The maximum error and expected error calculated from the system variables represents the quality metric for the client. If the root synchronization distance for any server exceeds 1.5 s, called the select threshold, the server is considered invalid.</li>
</ol>
<h4>Large Frequency Errors</h4>
<p>The frequency tolerance of computer clock oscillators varies widely, sometimes above 500 PPM. While the daemon can handle frequency errors up to 500 PPM, or 43 seconds per day, values much above 100 PPM reduce the headroom, especially at the lowest poll intervals. To determine the particular oscillator frequency, start <tt>ntpd</tt> using the <tt>noselect</tt> option with the <tt>server</tt> configuration command.</p>
<p>Record the time of day and offset displayed by the <tt>ntpq</tt> <a href="ntpq.html#pe"><tt>pe</tt></a> command. Wait for an hour or so and record the time of day and offset. Calculate the frequency as the offset difference divided by the time difference. If the frequency is much above 100 PPM, the <a href="tickadj.html">tickadj</a> program might be useful to adjust the kernel clock frequency below that value. For systems that do not support this program, this might be one using a command in the system startup file.</p>
<h4>Access Controls</h4>
<p>Provisions are included in <tt>ntpd</tt> for access controls which deflect unwanted traffic from selected hosts or networks. The controls described on the <a href="accopt.html">Access Control Options</a> include detailed packet filter operations based on source address and address mask. Normally, filtered packets are dropped without notice other than to increment tally counters. However, the server can be configured to send a &quot;kiss-o'-death&quot; (KoD) packet to the client either when explicitly configured or when cryptographic authentication fails for some reason. The client association is permanently disabled, the access denied bit (TEST4) is set in the flash variable and a message is sent to the system log.</p>
<p>The access control provisions include a limit on the packet rate from a
host or network. If an incoming packet exceeds the limit, it is dropped and
a KoD sent to the source. If this occurs after the client association has
synchronized, the association is not disabled, but a message is sent to the
system log. See the <a href="accopt.html">Access Control Options</a> page
for further information.</p>
<h4>Large Delay Variations</h4>
<p>In some reported scenarios an access line may show low to moderate network delays during some period of the day and moderate to high delays during other periods. Often the delay on one direction of transmission dominates, which can result in large time offset errors, sometimes in the range up to a few seconds. It is not usually convenient to run <tt>ntpd</tt> throughout the day in such scenarios, since this could result in several time steps, especially if the condition persists for greater than the stepout threshold.</p>
<p>Specific provisions have been built into <tt>ntpd</tt> to cope with these problems. The scheme is called &quot;huff-'n-puff and is described on the <a href="miscopt.html">Miscellaneous Options</a> page. An alternative approach in such scenarios is first to calibrate the local clock frequency error by running <tt>ntpd</tt> in continuous mode during the quiet interval and let it write the frequency to the <tt>ntp.drift</tt> file. Then, run <tt>ntpd -q</tt> from a cron job each day at some time in the quiet interval. In systems with the nanokernel or microkernel performance enhancements, including Solaris, Tru64, Linux and FreeBSD, the kernel continuously disciplines the frequency so that the residual correction produced by <tt>ntpd</tt> is usually less than a few milliseconds.</p>
<h4>Cryptographic Authentication</h4>
<p>Reliable source authentication requires the use of symmetric key or public key cryptography, as described on the <a href="authopt.html">Authentication Options</a> page. In symmetric key cryptography servers and clients share session keys contained in a secret key file In public key cryptography, which requires the OpenSSL software library, the server has a private key, never shared, and a public key with unrestricted distribution. The cryptographic media required are produced by the <a href="keygen.html"><tt>ntp-keygen</tt></a> program.</p>
<p>Problems with symmetric key authentication are usually due to mismatched keys or improper use of the <tt>trustedkey</tt> command. A simple way to check for problems is to use the trace facility, which is enabled using the <tt>ntpd -d</tt> command line. As each packet is received a trace line is displayed which shows the authentication status in the <tt>auth</tt> field. A status of 1 indicates the packet was successful authenticated; otherwise it has failed.</p>
<p>A common misconception is the implication of the <tt>auth</tt> bit in the <tt>enable</tt> and <tt>disable</tt> commands. <b>This bit does not affect authentication in any way other than to enable or disable mobilization of a new persistent association in broadcast/multicast client, manycast client or symmetric passive modes.</b> If enabled, which is the default, these associations require authentication; if not, an association is mobilized even if not authenticated. Users are cautioned that running with authentication disabled is very dangerous, since an intruder can easily strike up an association and inject false time values.</p>
<p>Public key cryptography is supported in NTPv4 using the Autokey protocol, which is described in briefings on the NTP Project page linked from www.ntp.org. Development of this protocol is mature and the <tt>ntpd</tt> implementation is basically complete. Autokey version 2, which is the latest and current version, includes provisions to hike certificate trails, operate as certificate authorities and verify identity using challenge/response identification schemes. Further details of the protocol are on the <a href="authopt.html">Authentication Options</a> page. Common problems with configuration and key generation are mismatched key files, broken links and missing or broken random seed file.</p>
<p>As in the symmetric key cryptography case, the trace facility is a good way to verify correct operation. A statistics file <tt>cryptostats</tt> records protocol transactions and error messages. The daemon requires a random seed file, public/private key file and a valid certificate file; otherwise it exits immediately with a message to the system log. As each file is loaded a trace message appears with its filestamp. There are a number of checks to insure that only consistent data are used and that the certificate is valid. When the protocol is in operation a number of checks are done to verify the server has the expected credentials and its filestamps and timestamps are consistent. Errors found are reported using NTP control and monitoring protocol traps with extended trap codes shown in the Authentication Options page.</p>
<p>To assist debugging every NTP extension field is displayed in the trace along with the Autokey operation code. Every extension field carrying a verified signature is identified and displayed along with filestamp and timestamp where meaningful. In all except broadcast/multicast client mode, correct operation of the protocol is confirmed by the absence of extension fields and an <tt>auth</tt> value of one. It is normal in broadcast/multicast client mode that the broadcast server use one extension field to show the host name, status word and association ID.</p>
<h4>Debugging Checklist</h4>
<p>If the <tt>ntpq</tt> or <tt>ntpdc</tt> programs do not show that messages are being received by the daemon or that received messages do not result in correct synchronization, verify the following:</p>
<ol>
<li>Verify the <tt>/etc/services</tt> file host machine is configured to accept UDP packets on the NTP port 123. NTP is specifically designed to use UDP and does not respond to TCP.</li>
<li>Check the system log for <tt>ntpd</tt> messages about configuration errors, name-lookup failures or initialization problems. Common system log messages are summarized on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page. Check to be sure that only one copy of <tt>ntpd</tt> is running.</li>
<li>Verify using <tt>ping</tt> or other utility that packets actually do make the round trip between the client and server. Verify using <tt>nslookup</tt> or other utility that the DNS server names do exist and resolve to valid Internet addresses.</li>
<li>Check that the remote NTP server is up and running. The usual evidence that it is not is a <tt>Connection refused</tt> message.</li>
<li>Using the <tt>ntpdc</tt> program, verify that the packets received and packets sent counters are incrementing. If the sent counter does not increment and the configuration file includes configured servers, something may be wrong in the host network or interface configuration. If this counter does increment, but the received counter does not increment, something may be wrong in the network or the server NTP daemon may not be running or the server itself may be down or not responding.</li>
<li>If both the sent and received counters do increment, but the <tt>reach</tt> values in the <tt>pe</tt> billboard with <tt>ntpq</tt> continues to show zero, received packets are probably being discarded for some reason. If this is the case, the cause should be evident from the <tt>flash</tt> variable as discussed above and on the <tt>ntpq</tt> page. It could be that the server has disabled access for the client address, in which case the <tt>refid</tt> field in the <tt>ntpq pe</tt> billboard will show a kiss code. See earlier on this page for a list of kiss codes and their meaning.</li>
<li>If the <tt>reach</tt> values in the <tt>pe</tt> billboard show the servers are alive and responding, note the tattletale symbols at the left margin, which indicate the status of each server resulting from the various grooming and mitigation algorithms. The interpretation of these symbols is discussed on the <tt>ntpq</tt> page. After a few minutes of operation, one or another of the reachable server candidates should show a * tattletale symbol. If this doesn't happen, the intersection algorithm, which classifies the servers as truechimers or falsetickers, may be unable to find a majority of truechimers among the server population.</li>
<li>If all else fails, see the FAQ and/or the discussion and briefings at the NTP Project page.</li>
</ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

1433
html/decode.html
View File

File diff suppressed because it is too large Load Diff

49
html/discipline.html Normal file
View File

@ -0,0 +1,49 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Clock Discipline Algorithm</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Clock Discipline Algorithm</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->10-Mar-2014 05:03<!-- #EndDate -->
UTC</p>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">General Overview</a></li>
<li class="inline"><a href="#pll">Phase-Lock Loop Operations</a></li>
<li class="inline"><a href="#loop">Loop Dynamics</a></li>
<li class="inline"><a href="#house">Clock Initialization and Management</a></li>
</ul>
<hr>
<h4 id="intro">General Overview</h4>
<p>At the heart of the NTP specification and reference implementation is the clock discipline algorithm, which is best described as an adaptive parameter, hybrid phase/frequency-lock feedback loop. It is an intricately crafted algorithm that automatically adapts for optimum performance while minimizing network overhead. Operation is in two modes, phase-lock loop (PLL), which is used at poll intervals below the Allan intercept, by default 2048 s, and frequency-lock loop (FLL), which is used above that.</p>
<div align="center"> <img src="pic/discipline.gif" alt="gif">
<p>Figure 1. Clock Discipline Algorithm</p>
</div>
<h4 id="pll">Clock Discipline Operations</h4>
<p>A block diagram of the clock discipline is shown in Figure 1. The timestamp of a reference clock or remote server is compared with the timestamp of the system clock, represented as a variable frequency oscillator (VFO), to produce a raw offset sample <em>V<sub>d</sub></em>. Offset samples are processed by the clock filter to produce a filtered update <em>V<sub>s</sub></em>. The loop filter implements a type-2 proportional-integrator controller (PIC). The PIC can minimize errors in both time and frequency using predictors <em>x</em> and <em>y</em>, respectively. The clock adjust process samples these predictors once each second for the daemon discipline or once each tick interrupt for the kernel discipline to produce the system clock update <em>V<sub>c</sub></em>.</p>
<p>In PLL mode the frequency predictor is an integral of the offset over past updates, while the phase predictor is the offset amortized over time in order to avoid setting the clock backward. In FLL mode the phase predictor is not used, while the frequency predictor is similar to the NIST <em>lockclock</em> algorithm. In this algorithm, the frequency predictor is computed as a fraction of the current offset divided by the time since the last update in order to minimize the offset at the next update.</p>
<p>The discipline response in PLL mode is determined by the <em>time constant</em>, which results in a &quot;stiffness&quot; depending on the jitter of the available sources and the wander of the system clock oscillator. The scaled time constant is also used as the poll interval described on the <a href="poll.html">Poll Program</a> page. However, in NTP symmetric mode, each peer manages its own poll interval and the two might not be the same. In such cases either peer uses the minimum of its own poll interval and that of the other peer, which is included in the NTP packet header.</p>
<h4 id="loop">Loop Dynamics</h4>
<p> It is necessary to verify that the clock discipline algorithm is stable and satisfies the Nyquist criterion, which requires that the sampling rate be at least twice the bandwidth. In this case the bandwidth can be approximated by the reciprocal of the time constant. In the NTP specification and reference implementation, time constants and poll intervals are expressed as exponents of 2. By construction, the time constant exponent is five times the poll interval exponent. Thus, the default poll exponent of 6 corresponds to a poll interval of 64 s and a time constant of 2048 s. A change in the poll interval changes the time constant by a corresponding amount.. The Nyquist criterion requires the sample interval to be not more than half the time constant or 1024 s. The clock filter guarantees at least one sample in eight poll intervals, so the sample interval is not more than 512 s. This would be described as oversampling by a factor of two. Finally, the PLL parameters have been chosen for a damping factor of 2, which results in a much faster risetime than with critical damping, but results in modest overshoot of 6 percent.</p>
<p> It is important to understand how the dynamics of the PLL are affected by the time constant and poll interval. At the default poll interval of 64 s and a step offset change of 100 ms, the time response crosses zero in about 50 min and overshoots about 6 ms, as per design. Ordinarily, a step correction would causes a temporary frequency surge of about 5 PPM, which along with the overshoot slowly dissipates over a few hours.</p>
<p>However, the clock state machine used with the discipline algorithm avoids this transient at startup. It does this using a previously saved frequency file, if present, or by measuring the oscillator frequency, if not. It then quickly amortizes the residual offset at startup without affecting the oscillator frequency. In this way the offset error is less than 0.5 ms within 5 min, if the file is present, and within 10 min if not. See the <a href="clock.html">Clock State Machine</a> page for further details.</p>
<p>Since the PLL is linear, the response with different offset step amplitudes and poll intervals has the same characteristic shape, but scaled differently in amplitude and time. The response scales exactly with step amplitude, so that the response to a 10-ms step has the same shape as at 64 s, but with amplitude compressed by one-tenth. The response scales exactly with poll interval, so that response at a poll interval of 8 s has the same shape as at 64 s, but with time compressed by one-eighth.</p>
<p>The optimum time constant, and thus the poll interval, depends on the network time jitter and the oscillator frequency wander. Errors due to jitter decrease as the time constant increases, while errors due to wander decrease as the time constant decreases. For typical Internet paths, the two error characteristics intersect at a point called the <em>Allan intercept</em>, which represents the optimum time constant. With a compromise Allan intercept of 2048 s, the optimum poll interval is about 64 s, which corresponds to a compromise poll exponent of 6. For fast LANs with modern computers, the Allan intercept is somewhat lower at around 512 s, so a compromise poll exponent of 4 (16 s) is appropriate. An intricate, heuristic algorithm is used to manage the actual poll interval within a specified range. Details are on the <a href="poll.html">Poll Program</a> page.</p>
<p>In the NTPv4 specification and reference implementation a state machine is used to manage the system clock under exceptional conditions, as when the daemon is first started or when encountering severe network congestion. In extreme cases not likely to be encountered in normal operation, the system time can be stepped forward or backward more than 128 ms. Further details are on the <a href="clock.html">Clock State Machine</a> page.</p>
<h4 id="house">Clock Initialization and Management</h4>
<p>If left running continuously, an NTP client on a fast LAN in a home or office environment can maintain synchronization nominally within one millisecond. When the ambient temperature variations are less than a degree Celsius, the clock oscillator frequency is disciplined to within one part per million (PPM), even when the clock oscillator native frequency offset is 100 PPM or more.</p>
<p> For laptops and portable devices when the power is turned off, the battery backup clock offset error can increase as much as one second per day. When power is restored after several hours or days, the clock offset and oscillator frequency errors must be resolved by the clock discipline algorithm, but this can take several hours without specific provisions.</p>
<p> The provisions described in this section insure that, in all but pathological situations, the startup transient is suppressed to within nominal levels in no more than five minutes after a warm start or ten minutes after a cold start. Following is a summary of these provisions. A detailed discussion of these provisions is on the <a href="clock.html">Clock State Machine</a> page.</p>
<p> The reference implementation measures the clock oscillator frequency and updates a frequency file at intervals of one hour or more, depending on the measured frequency wander. This design is intended to minimize write cycles in NVRAM that might be used in a laptop or portable device. In a warm start, the frequency is initialized from this file, which avoids a possibly lengthy convergence time. In a cold start when no frequency file is available, the reference implementation first measures the oscillator frequency over a five-min interval. This generally results in a residual frequency error less than 1 PPM. The measurement interval can be changed using the <tt>stepout</tt> option of the <a href="miscopt.html#tinker"><tt>tinker</tt></a> command.</p>
<p>In order to reduce the clock offset error at restart, the reference implementation mext disables oscillator frequency discipline and enables clock offset discipline with a small time constant. This is designed to quickly reduce the clock offset error without causing a frequency surge. This configuration is continued for an interval of five-min, after which the clock offset error is usually no more than a millisecond. The measurement interval can be changed using the <tt>stepout</tt> option of the <a href="miscopt.html#tinker"><tt>tinker</tt></a> command.</p>
<p>Another concern at restart is the time necessary for the select and cluster algorithms to refine and validate the initial clock offset estimate. Normally, this takes several updates before setting the system clock. As the default minimum poll interval in most configurations is about one minute, it can take several minutes before setting the system clock. The <tt>iburst</tt> option of the <a href="confopt.html#burst"><tt>server</tt></a> command changes the behavior at restart and is recommended for client/server configurations. When this option is enabled, the client sends a volley of six requests at intervals of two seconds. This usually insures a reliable estimate is available in about ten seconds before setting the clock. Once this initial volley is complete, the procedures described above are executed.</p>
<p>As a result of the above considerations, when a backup source, such as the local clock driver, ACTS modem driver or orphan mode is included in the system configuration, it may happen that one or more of them are selectable before one or more of the regular sources are selectable. When backup sources are included in the configuration, the reference implementation waits an interval of several minutes without regular sources before switching to backup sources. This is generally enough to avoid startup transients due to premature switching to backup sources. The interval can be changed using the <tt>orphanwait</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

75
html/discover.html Normal file
View File

@ -0,0 +1,75 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Automatic Server Discoveryschemes</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Automatic Server Discovery Schemes</h3>
<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->10-Mar-2014 05:04<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#assoc">Association Management</a></li>
<li class="inline"><a href="#bcst">Broadcast/Multicast Scheme</a></li>
<li class="inline"><a href="#mcst">Manycast Scheme</a></li>
<li class="inline"><a href="#pool">Server Pool Scheme</a></li>
</ul>
<hr>
<h4 id="modes">Introduction</h4>
<p>This page describes the automatic server discovery schemes provided in NTPv4. There are three automatic server discovery schemes: broadcast/multicast, many cast, and server pool, which are described on this page. The broadcast/multicast and many cast schemes utilize the ubiquitous broadcast or one-to-many paradigm native to IPv4 and IPv6. The server pool scheme uses DNS to resolve addresses of multiple volunteer servers scattered throughout the world.</p>
<p> All three schemes work in much the same way and might be described as <i>grab-n'-prune.</i> Through one means or another they grab a number of associations either directly or indirectly from the configuration file, order them from best to worst according to the NTP mitigation algorithms, and prune the surplus associations.</p>
<h4 id="assoc">Association Management</h4>
<p>All schemes use an iterated process to discover new preemptable client associations as long as the total number of client associations is less than the <tt>maxclock</tt> option of the <tt>tos</tt> command. The <tt>maxclock</tt> default is 10, but it should be changed in typical configuration to some lower number, usually two greater than the <tt>minclock</tt> option of the same command. </p>
<p>All schemes use a stratum filter to select just those servers with stratum considered useful. This can avoid large numbers of clients ganging up on a small number of low-stratum servers and avoid servers below or above specified stratum levels. By default, servers of all strata are acceptable; however, the <tt>tos</tt> command can be used to restrict the acceptable range from the <tt>floor</tt> option, inclusive, to the <tt>ceiling</tt> option, exclusive. Potential servers operating at the same stratum as the client will be avoided, unless the <tt>cohort</tt> option is present. Additional filters can be supplied using the methods described on the <a href="authentic.html">Authentication Support</a> page.</p>
<p>The pruning process uses a set of unreach counters, one for each association created by the configuration or discovery processes. At each poll interval, the counter is increased by one. If an acceptable packet arrives for a persistent (configured) or ephemeral (broadcast/multicast) association, the counter is set to zero. If an acceptable packet arrives for a preemptable (manycast, pool) association and survives the selection and clustering algorithms, the counter is set to zero. If the the counter reaches an arbitrary threshold of 10, the association becomes a candidate for pruning.</p>
<p>The pruning algorithm is very simple. If an ephemeral or preemptable association becomes a candidate for pruning, it is immediately demobilized. If a persistent association becomes a candidate for pruning, it is not demobilized, but its poll interval is set at the maximum. The pruning algorithm design avoids needless discovery/prune cycles for associations that wander in and out of the survivor list, but otherwise have similar characteristics. </p>
<p>Following is a summary of each scheme. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
<h4 id="bcst">Broadcast/Multicast Scheme</h4>
<p>A broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overridden by the <tt>minpoll</tt> and <tt>ttl</tt> options, respectively. Not all kernels support the <tt>ttl</tt> option. A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. It then polls the server in client/server mode using the <tt>iburst</tt> option in order to quickly authenticate the server, calibrate the propagation delay and set the client clock. This normally results in a volley of six client/server exchanges at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently.</p>
<p>Following the volley, the server continues in listen-only mode and sends no further messages. If for some reason the broadcast server does not respond to these messages, the client will cease transmission and continue in listen-only mode with a default propagation delay. The volley can be avoided by using the <tt>broadcastdelay</tt> command with nonzero argument.</p>
<p>A server is configured in broadcast mode using the <tt>broadcast</tt> command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a <tt>broadcast</tt> command is needed for each address. This provides a way to limit exposure in a firewall, for example. A broadcast client is configured using the <tt>broadcastclient</tt> command. </p>
<p>NTP multicast mode can be used to extend the scope using IPv4 multicast or IPv6 broadcast with defined span. The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6 address FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
<p>A multicast server is configured using the <tt>broadcast</tt> command, but specifying a multicast address instead of a broadcast address. A multicast client is configured using the <tt>multicastclient</tt> command specifying a list of one or more multicast addresses. Note that there is a subtle distinction between the IPv4 and IPv6 address families. The IPv4 broadcast or mulitcast mode is determined by the IPv4 class. For IPv6 the same distinction can be made using the link-local prefix FF02 for each interface and site-local prefix FF05 for all interfaces.</p>
<p>It is possible and frequently useful to configure a host as both broadcast client and broadcast server. A number of hosts configured this way and sharing a common broadcast address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.</p>
<p>Since an intruder can impersonate a broadcast server and inject false time values, broadcast mode should always be cryptographically authenticated. By default, a broadcast association will not be mobilized unless cryptographically authenticated. If necessary, the <tt>auth</tt> option of the <tt>disable</tt> command will disable this feature. The feature can be selectively enabled using the <tt>notrust</tt> option of the <tt>restrict</tt> command.</p>
<p>With symmetric key cryptography each broadcast server can use the same or different keys. In one scenario on a broadcast LAN,&nbsp;a set of broadcast clients and servers share the same key along with another set that share a different key. Only the clients with matching key will respond to a server broadcast. Further information is on the <a href="authentic.html">Authentication Support</a> page.</p>
<p>Public key cryptography can be used with some restrictions. If multiple servers belonging to different secure groups share the same broadcast LAN, the clients on that LAN&nbsp;must have the client keys for all of them. This scenario is illustrated in the example on the <a href="autokey.html">Autokey Public Key Authentication</a> page.</p>
<h4 id="mcst">Manycast Scheme</h4>
<p>Manycast is an automatic server discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. It uses the grab-n'-drop paradigm with the additional feature that active means are used to grab additional servers should the number of associations fall below the <tt>maxclock</tt> option of the <tt>tos</tt> command.</p>
<p>The manycast paradigm is not the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p>
<p>A manycast client is configured using the <tt>manycastclient</tt> configuration command, which is similar to the <tt>server</tt> configuration command. It sends ordinary client mode messages, but with a broadcast address rather than a unicast address and sends only if less than <tt>maxclock</tt> associations remain and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. There can be as many manycast client associations as different addresses, each one serving as a template for future unicast client/server associations.</p>
<p>A manycast server is configured using the <tt>manycastserver</tt> command, which listens on the specified broadcast address for manycast client messages. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies with an ordinary unicast server message.</p>
<p>The manycast client receiving this message mobilizes a preemptable client association according to the matching manycast client template. This requires the server to be cryptographically authenticated and the server stratum to be less than or equal to the client stratum. </p>
<p>It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common multicast group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.</p>
<p>The use of cryptograpic authentication is always a good idea in any server discovery scheme. Both symmetric key and public key cryptography can be used in the same scenarios as described above for the broadast/multicast scheme.</p>
<h4 id="pool">Server Pool Scheme</h4>
<p>The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several thousand operators around the globe have volunteered their servers for public access. In general, NTP&nbsp;is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers using the NTP&nbsp;mitigation algorithms.</p>
<p>To support this service, custom DNS software is used by pool.ntp.org and its subdomains
to discover a random selection of participating servers in response to a DNS query.
The client receiving this list mobilizes some or all of them, similar to the
manycast discovery scheme, and prunes the excess. Unlike <tt>manycastclient</tt>,
cryptographic authentication is not required. The pool scheme solicits a single
server at a time, compared to <tt>manycastclient</tt> which solicits all servers
within a multicast TTL range simultaneously. Otherwise, the pool server discovery
scheme operates as manycast does.</p>
<p>The pool scheme is configured using one or more <tt>pool</tt> commands with DNS names
indicating the pool from which to draw. The <tt>pool</tt> command can be used more
than once; duplicate servers are detected and discarded. In principle, it is
possible to use a configuration file containing a single line <tt>pool
pool.ntp.org</tt>. The <a href="http://www.pool.ntp.org/en/use.html">NTP Pool
Project</a> offers instructions on using the pool with the <tt>server</tt> command, which is suboptimal but works with older versions of <tt>ntpd</tt> predating the <tt>pool</tt> command. With recent ntpd, consider replacing the
multiple <tt>server</tt> commands in their example with a single <tt>pool</tt> command.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

96
html/drivers/driver1.html
View File

@ -1,50 +1,50 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Undisciplined Local Clock</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Undisciplined Local Clock</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.1.<i>u</i><br>
Reference ID: <tt>LCL</tt><br>
Driver ID: <tt>LOCAL</tt></p>
<h4>Description</h4>
<p>Not: This driver is not recommended for new installations. A much more flexible replacement is available in the form of orphan mode described on the <a href="../assoc.html">Association Management page</a>.</p>
<p>This driver is intended for use in an isolated network where no external source of synchronization such as a radio clock or modem is available. It allows a designated time server to act as a primary server to provide synchronization to other clients on the network. Pick a machine that has a good clock oscillator (Digital machines are good, Sun machines are not) and configure it with this driver. Set the clock using the best means available, like eyeball-and-wristwatch. Then, point all the other machines at this one or use broadcast mode to distribute time.</p>
<p>Another application for this driver is if a particular server clock is to be used as the clock of last resort when all other normal synchronization sources have gone away. This is especially useful if that server has an ovenized oscillator. For this you would usually, but not necessarily, configure this driver at a stratum greater than any other likely sources of time, such as the default 5 for this driver, to prevent this driver taking over when legitimate sources elsewher in the network are available. To further protect the Internet infrastructure from accidental or malicious exposure to this driver, the driver is desabled if another source is available and operating.</p>
<h4>Monitor Data</h4>
<p>No <tt>filegen clockstats</tt> monitor data are produced by this driver.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Specifies the frequency offset calibration factor, in parts per million, with default 0.0.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 3.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>LCL</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Undisciplined Local Clock</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Undisciplined Local Clock</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->9-May-2014 08:34<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.1.<i>u</i><br>
Reference ID: <tt>LOCL</tt><br>
Driver ID: <tt>LOCAL</tt></p>
<h4>Description</h4>
<p>Note: <strong>We recommend against using this driver.</strong> A much more flexible replacement is described on the <a href="../orphan.html">Orphan Mode</a> page.</p>
<p>This driver was intended for use in an isolated network where no external source of synchronization such as a radio clock or modem is available. It allows a designated time server to act as a primary server to provide synchronization to other clients on the network. Pick a machine that has a good clock oscillator and configure it with this driver. Set the clock using the best means available, like eyeball-and-wristwatch. Then, point all the other machines at this one or use broadcast mode to distribute time.</p>
<p>Another application for this driver is if a particular server clock is to be used as the clock of last resort when all other normal synchronization sources have gone away. This is especially useful if that server has an ovenized oscillator. For this you would usually, but not necessarily, configure this driver at a stratum greater than any other likely sources of time, such as the default 5 for this driver, to prevent this driver taking over when legitimate sources elsewhere in the network are available. To further protect the Internet infrastructure from accidental or malicious exposure to this driver, the driver is disabled if another source is available and operating.</p>
<h4>Monitor Data</h4>
<p>No <tt>filegen clockstats</tt> monitor data are produced by this driver.</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>Specifies the frequency offset calibration factor, in parts per million, 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 5.</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>LOCL</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>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

102
html/drivers/driver10.html
View File

@ -1,53 +1,53 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>Austron 2200A/2201A GPS Receivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Austron 2200A/2201A GPS Receivers</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.10.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS_AS2201</tt><br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock and Timing Receiver connected via a serial port. It supports several special features of the clock, including the Input Buffer Module, Output Buffer Module, IRIG-B Interface Module and LORAN Assist Module. It requires the RS232 Buffered Serial Interface module for communication with the driver.</p>
<p>For use with a single computer, the receiver can be connected directly to the receiver. For use with multiple computers, one of them is connected directly to the receiver and generates the polling messages. The other computers just listen to the receiver output directly or through a buffer amplifier. For computers that just listen, <tt>fudge flag2</tt> must be set and the <tt>ppsclock </tt>streams module configured on each of them.</p>
<p>This receiver is capable of a comprehensive and large volume of statistics and operational data. The specific data collection commands and attributes are embedded in the driver source code; however, the collection process can be enabled or disabled using the flag4 flag. If set, collection is enabled; if not, which is the default, it is disabled. A comprehensive suite of data reduction and summary scripts is in the ./scripts/stats directory</p>
of the ntp3 distribution.
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Set for computers that listen-only.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</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>Austron 2200A/2201A GPS Receivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Austron 2200A/2201A GPS Receivers</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.10.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS_AS2201</tt><br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock and Timing Receiver connected via a serial port. It supports several special features of the clock, including the Input Buffer Module, Output Buffer Module, IRIG-B Interface Module and LORAN Assist Module. It requires the RS232 Buffered Serial Interface module for communication with the driver.</p>
<p>For use with a single computer, the receiver can be connected directly to the receiver. For use with multiple computers, one of them is connected directly to the receiver and generates the polling messages. The other computers just listen to the receiver output directly or through a buffer amplifier. For computers that just listen, <tt>fudge flag2</tt> must be set and the <tt>ppsclock </tt>streams module configured on each of them.</p>
<p>This receiver is capable of a comprehensive and large volume of statistics and operational data. The specific data collection commands and attributes are embedded in the driver source code; however, the collection process can be enabled or disabled using the flag4 flag. If set, collection is enabled; if not, which is the default, it is disabled. A comprehensive suite of data reduction and summary scripts is in the ./scripts/stats directory</p>
of the ntp3 distribution.
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</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>GPS</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Set for computers that listen-only.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

120
html/drivers/driver11.html
View File

@ -1,29 +1,30 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>Arbiter 1088A/B GPS Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Arbiter 1088A/B GPS Receiver</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.11.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS_ARBITER</tt><br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The claimed accuracy of this clock is 100 ns relative to the PPS output when receiving four or more satellites.</p>
<p>The receiver should be configured before starting the NTP daemon, in order to establish reliable position and operating conditions. It does not initiate surveying or hold mode. For use with NTP, the daylight savings time feature should be disables (<tt>D0</tt> command) and the broadcast mode set to operate in UTC (<tt>BU</tt> command).</p>
<p>The timecode format supported by this driver is selected by the poll sequence <tt>B5</tt>, which initiates a line in the following format to be repeated once per second until turned off by the <tt>B0</tt> command.</p>
<p>Format <tt>B5</tt> (24 ASCII printing characters):</p>
<pre>&lt;cr&gt;&lt;lf&gt;i yy ddd hh:mm:ss.000bbb
<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>Arbiter 1088A/B GPS Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Arbiter 1088A/B GPS Receiver</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.11.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS_ARBITER</tt><br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The claimed accuracy of this clock is 100 ns relative to the PPS output when receiving four or more satellites.</p>
<p>The receiver should be configured before starting the NTP daemon, in order to establish reliable position and operating conditions. It does not initiate surveying or hold mode. For use with NTP, the daylight savings time feature should be disables (<tt>D0</tt> command) and the broadcast mode set to operate in UTC (<tt>BU</tt> command).</p>
<p>The timecode format supported by this driver is selected by the poll sequence <tt>B5</tt>, which initiates a line in the following format to be repeated once per second until turned off by the <tt>B0</tt> command.</p>
<p>Format <tt>B5</tt> (24 ASCII printing characters):</p>
<pre>&lt;cr&gt;&lt;lf&gt;i yy ddd hh:mm:ss.000bbb
on-time = &lt;cr&gt;
i = synchronization flag (' ' = locked, '?' = unlocked)
@ -32,10 +33,10 @@ ddd = day of year
hh:mm:ss = hours, minutes, seconds
.000 = fraction of second (not used)
bbb = tailing spaces for fill</pre>
<p>The alarm condition is indicated by a '?' at i, which indicates the receiver is not synchronized. In normal operation, a line consisting of the timecode followed by the time quality character (TQ) followed by the receiver status string (SR) is written to the clockstats file.</p>
<p>The time quality character is encoded in IEEE P1344 standard:</p>
<p>Format <tt>TQ</tt> (IEEE P1344 estimated worst-case time quality)</p>
<pre>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock locked, maximum accuracy
<p>The alarm condition is indicated by a '?' at i, which indicates the receiver is not synchronized. In normal operation, a line consisting of the timecode followed by the time quality character (TQ) followed by the receiver status string (SR) is written to the clockstats file.</p>
<p>The time quality character is encoded in IEEE P1344 standard:</p>
<p>Format <tt>TQ</tt> (IEEE P1344 estimated worst-case time quality)</p>
<pre>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock locked, maximum accuracy
F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock failure, time not reliable
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 1 us
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 10 us
@ -45,41 +46,40 @@ F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock failure, time not reliable
9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 100 ms
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 1 s
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 10 s</pre>
<p>The status string is encoded as follows:</p>
<p>Format <tt>SR</tt> (25 ASCII printing characters)</p>
<pre>V=vv S=ss T=t P=pdop E=ee
<p>The status string is encoded as follows:</p>
<p>Format <tt>SR</tt> (25 ASCII printing characters)</p>
<pre>V=vv S=ss T=t P=pdop E=ee
vv = satellites visible
ss = relative signal strength
t = satellites tracked
pdop = position dilution of precision (meters)
ee = hardware errors</pre>
<p>A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself.</p>
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, an additional line containing the latitude, longitude, elevation and optional deviation data is written to the <tt>clockstats</tt> file. The deviation data operates with an external pulse-per-second (PPS) input, such as a cesium oscillator or another radio clock. The PPS input should be connected to the B event channel and the radio initialized for deviation data on that channel. The deviation data consists of the mean offset and standard deviation of the external PPS signal relative the GPS signal, both in microseconds over the last 16 seconds.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<p>A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself.</p>
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, an additional line containing the latitude, longitude, elevation and optional deviation data is written to the <tt>clockstats</tt> file. The deviation data operates with an external pulse-per-second (PPS) input, such as a cesium oscillator or another radio clock. The PPS input should be connected to the B event channel and the radio initialized for deviation data on that channel. The deviation data consists of the mean offset and standard deviation of the external PPS signal relative the GPS signal, both in microseconds over the last 16 seconds.</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>GPS</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>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

94
html/drivers/driver12.html
View File

@ -1,49 +1,49 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>KSI/Odetics TPRO/S IRIG Interface</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>KSI/Odetics TPRO/S IRIG Interface</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.12.<i>u</i><br>
Reference ID: <tt>IRIG</tt><br>
Driver ID: <tt>IRIG_TPRO</tt><br>
TPRO Device: <tt>/dev/tpro<i>u</i></tt><br>
Requires: KSI/Odetics device driver, <tt>/usr/include/sys/tpro.h</tt> header file</p>
<h4>Description</h4>
<p>This driver supports the KSI/Odetics TPRO and TPRO-SAT IRIG-B Decoder, which is a module connected directly to the SBus of a Sun workstation. The module works with the IRIG-B signal generated by several radio clocks, including those made by Arbiter, Austron, Odetics, Spectracom and TrueTime, among others, although it is generally an add- on option. In the case of the TPRO-SAT, the module is an integral part of a GPS receiver, which serves as the primary timing source.</p>
<p>Using the TPRO interface as a NTP reference clock provides precision time only to ntpd and its clients. With suitable kernel modifications, it is possible to use the TPRO as the CPU system clock, avoiding errors introduced by the CPU clock oscillator wander. See the <a href="../kern.html">A Kernel Model for Precision Timekeeping </a>page for further details.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>IRIG</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</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>KSI/Odetics TPRO/S IRIG Interface</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>KSI/Odetics TPRO/S IRIG Interface</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.12.<i>u</i><br>
Reference ID: <tt>IRIG</tt><br>
Driver ID: <tt>IRIG_TPRO</tt><br>
TPRO Device: <tt>/dev/tpro<i>u</i></tt><br>
Requires: KSI/Odetics device driver, <tt>/usr/include/sys/tpro.h</tt> header file</p>
<h4>Description</h4>
<p>This driver supports the KSI/Odetics TPRO and TPRO-SAT IRIG-B Decoder, which is a module connected directly to the SBus of a Sun workstation. The module works with the IRIG-B signal generated by several radio clocks, including those made by Arbiter, Austron, Odetics, Spectracom and TrueTime, among others, although it is generally an add- on option. In the case of the TPRO-SAT, the module is an integral part of a GPS receiver, which serves as the primary timing source.</p>
<p>Using the TPRO interface as a NTP reference clock provides precision time only to ntpd and its clients. With suitable kernel modifications, it is possible to use the TPRO as the CPU system clock, avoiding errors introduced by the CPU clock oscillator wander. See the <a href="../kern.html">A Kernel Model for Precision Timekeeping </a>page for further details.</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>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>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>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

53
html/drivers/driver16.html
View File

@ -2,30 +2,33 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.6 [en] (Win95; U) [Netscape]">
<meta name="Author" content="Ganesh Ramasivan">
<title>Bancomm bc635VME Time and Frequency Processor</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.6 [en] (Win95; U) [Netscape]">
<meta name="Author" content="Ganesh Ramasivan">
<title>Bancomm bc635VME Time and Frequency Processor</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>bc635VME/bc350VXI Time and Frequency Processor</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.16.<i>u</i><br>
Reference ID: BTFP<br>
Driver ID: GPS_BANCOMM<br>
Bancomm Device <tt>/dev/btfp0</tt><br>
Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x</p>
<h4>Description</h4>
<p>This is the clock driver for the Bancomm bc635VME Time and Frequency Processor. It requires the BANCOMM bc635VME bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS 5.x UNIX Systems.</p>
<p>Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.</p>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<body>
<h3>bc635VME/bc350VXI Time and Frequency Processor</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.16.<i>u</i><br>
Reference ID: BTFP<br>
Driver ID: GPS_BANCOMM<br>
Bancomm Device <tt>/dev/btfp0</tt><br>
Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x</p>
<h4>Description</h4>
<p>This is the clock driver for the Bancomm bc635VME Time and Frequency Processor. It requires the BANCOMM bc635VME bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS 5.x UNIX Systems.</p>
<p>Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.</p>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

160
html/drivers/driver18.html
View File

@ -1,82 +1,82 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>NIST/USNO/PTB Modem Time Services</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>NIST/USNO/PTB Modem Time Services</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.18.<i>u</i><br>
Reference ID: <tt>NIST | USNO | PTB | WWVB</tt><br>
Driver ID: <tt>ACTS_MODEM</tt><br>
Serial Port: <tt>/dev/acts<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt><br>
Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control and a dial-out (cua)&nbsp;device.</p>
<h4>Description</h4>
<p>This driver supports the US (NIST and USNO) and European (PTB (Germany), NPL (UK), etc.) modem time services, as well as Spectracom GPS&nbsp;and WWVB receivers connected via a modem. The driver periodically dials a number from a telephone list, receives the timecode data and calculates the local clock correction. It is designed primarily for backup when neither a radio clock nor connectivity to Internet time servers are available. It can also be configured to operate full period.</p>
<p>For best results the indicated time must be corrected for the modem and telephone circuit propagation delays, which can reach 200 ms or more. For the NIST service, corrections are determined automatically by measuring the roundtrip delay of echoed characters. With this service the absolute accuracy is typically a millisecond or two. Corrections for the other services must be determined by other means. With these services variations from call to call and between messages during a call are typically a few milliseconds, occasionally higher.</p>
<p>This driver requires a 9600-bps modem with a Hayes-compatible command set and control over the modem data terminal ready (DTR) control line. The actual line speed ranges from 1200 bps with USNO&nbsp;to 14,400 bps with NIST. The modem setup string is hard-coded in the driver and may require changes for nonstandard modems or special circumstances.</p>
<p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done manually using <tt>ntpdc</tt>, or by a cron job. In auto mode (0) <tt>flag1</tt> is set at each poll event. In backup mode (1) <tt>flag1</tt> is set at each poll event, but only if no other synchronization sources are available.</p>
<p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The phone number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpdc</tt>.</p>
<p>The driver automatically recognizes the message format of each modem time service. It selects the parsing algorithm depending on the message length. There is some hazard should the message be corrupted. However, the data format is checked carefully and only if all checks succeed is the message accepted. Corrupted lines are discarded without complaint. Once the service is known, the reference identifier for the driver is set to NIST, USNO, PTB or WWVB as appropriate.</p>
<p>Ordinarily, the serial port is connected to a modem; however, if fudge <tt>flag3</tt> is set, it can be connected directly to a Spectracom WWV or GPS radio for testing or calibration. The Spectracom radio can be connected via a modem if the radio is connfigured to send time codes continuoulsly at 1-s intervals. In principle, fudge <tt>flag2</tt> enables port locking, allowing the modem to be shared when not in use by this driver. At least on Solaris with the current NTP I/O routines, this results in lots of ugly error messages.</p>
<p>The <tt>minpoll</tt> and <tt>maxpoll</tt> keywords of the server configuration command can be used to limit the intervals between calls. The recommended settings are 12 (1.1 hours) for <tt>minpoll</tt> and 17 (36 hours) for <tt>maxpoll</tt>. Ordinarily, the poll interval will start at <tt>minpoll</tt> and ramp up to <tt>maxpoll</tt> in a day or two.</p>
<h4>US Phone Numbers and Formats</h4>
<p>Note: Phone numbers include the entire Hayes modem command, including the <tt>ATDT</tt> and other control codes as may be necessary. For most cases only the <tt>ATDT</tt> may be necessary.</p>
<p><a href="http://www.boulder.nist.gov/timefreq">National Institute of Science and Technology (NIST)</a></p>
<p>Phone: (303) 494-4774 (Boulder, CO); (808) 335-4721 (Hawaii)</p>
<p><a href="http://www.boulder.nist.gov/timefreq/service/acts.htm">Data Format</a></p>
<p><tt>National Institute of Standards and Technology<br>
Telephone Time Service, Generator 3B<br>
Enter question mark &quot;?&quot; for HELP<br>
MJD YR MO DA H M S ST S UT1 msADV &lt;OTM&gt;<br>
47999 90-04-18 21:39:15 50 0 +.1 045.0 UTC(NIST) *<br>
47999 90-04-18 21:39:16 50 0 +.1 045.0 UTC(NIST) #<br>
...</tt></p>
<p><tt>MJD</tt>, <tt>YR</tt>, <tt>ST</tt>, <tt>UT1</tt> and <tt>UTC(NIST)</tt> are not used by this driver. The <tt>&lt;OTM&gt;</tt> on-time character &quot;<tt>*</tt>&quot; changes to &quot;<tt>#</tt>&quot;&nbsp;when the delay correction is valid.</p>
<p><a href="http://tycho.usno.navy.mil">US Naval Observatory (USNO)</a></p>
<p>Phone: (202) 762-1594 (Washington, DC); (719) 567-6742 (Boulder, CO)</p>
<p><a href="http://tycho.usno.navy.mil/modem_time.html">Data Format</a> (two lines, repeating at one-second intervals)</p>
<p><tt>jjjjj nnn hhmmss UTC</tt></p>
<p>* on-time character for previous timecode message<br>
jjjjj modified Julian day number (not used)<br>
nnn day of year<br>
hhmmss second of day</p>
<p><a href="tf582_4.html">European Phone Numbers and Formats</a></p>
<p><a href="http://www.spectracomcorp.com">Spectracom GPS and WWVB Receivers</a></p>
<p>If a modem is connected to a Spectracom receiver, this driver will call it and retrieve the time in one of two formats, 0 and 2. Ordinarily, the receiver requires a <tt>T</tt> in order to return the timecode. As this driver does not send data via the modem, it must either be configured in continuous mode or be polled by another local driver.</p>
<h4>Monitor Data</h4>
<p>The received timecode is written as-is to the <tt>clockstats</tt> file along with the Hayes connection and hangup commands and result codes.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Set by the driver to (one of) <tt>NIST</tt>, <tt>USNO</tt>, <tt>PTB</tt> or <tt>WWVB</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Initiate a call if 1. Automatically reset by program.
<dt><tt>flag2 0 | 1</tt>
<dd>Enables port locking if 1, disables if 0 (default).
<dt><tt>flag3 0 | 1</tt>
<dd>Enables direct connection if 1, or modem if 0 (default). If set, the driver will send a single character 'T' at every poll event.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a>&nbsp;</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</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>NIST/USNO/PTB Modem Time Services</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>NIST/USNO/PTB Modem Time Services</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->1-Dec-2012 10:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.18.<i>u</i><br>
Reference ID: <tt>NIST | USNO | PTB | WWVB</tt><br>
Driver ID: <tt>ACTS_MODEM</tt><br>
Serial Port: <tt>/dev/acts<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt><br>
Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control and a dial-out (cua)&nbsp;device.</p>
<h4>Description</h4>
<p>This driver supports the US (NIST and USNO) and European (PTB (Germany), NPL (UK), etc.) modem time services, as well as Spectracom GPS&nbsp;and WWVB receivers connected via a modem. The driver periodically dials a number from a telephone list, receives the timecode data and calculates the local clock correction. It is designed primarily for backup when neither a radio clock nor connectivity to Internet time servers are available. It can also be configured to operate full period.</p>
<p>For best results the indicated time must be corrected for the modem and telephone circuit propagation delays, which can reach 200 ms or more. For the NIST service, corrections are determined automatically by measuring the roundtrip delay of echoed characters. With this service the absolute accuracy is typically a millisecond or two. Corrections for the other services must be determined by other means. With these services variations from call to call and between messages during a call are typically a few milliseconds, occasionally higher.</p>
<p>This driver requires a 9600-bps modem with a Hayes-compatible command set and control over the modem data terminal ready (DTR) control line. The actual line speed ranges from 1200 bps with USNO&nbsp;to 14,400 bps with NIST. The modem setup string is hard-coded in the driver and may require changes for nonstandard modems or special circumstances.</p>
<p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done manually using <tt>ntpq</tt>, or by a cron job. In auto mode (0) <tt>flag1</tt> is set at each poll event. In backup mode (1) <tt>flag1</tt> is set at each poll event, but only if no other synchronization sources are available.</p>
<p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The phone number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpq</tt>.</p>
<p>The driver automatically recognizes the message format of each modem time service. It selects the parsing algorithm depending on the message length. There is some hazard should the message be corrupted. However, the data format is checked carefully and only if all checks succeed is the message accepted. Corrupted lines are discarded without complaint. Once the service is known, the reference identifier for the driver is set to NIST, USNO, PTB or WWVB as appropriate.</p>
<p>The Spectracom radio can be connected via a modem if the radio is configured to send time codes continuously at 1-s intervals. In principle, fudge <tt>flag2</tt> enables port locking, allowing the modem to be shared when not in use by this driver. At least on Solaris with the current NTP I/O routines, this results in lots of ugly error messages.</p>
<p>The <tt>minpoll</tt> and <tt>maxpoll</tt> keywords of the server configuration command can be used to limit the intervals between calls. The recommended settings are 12 (1.1 hours) for <tt>minpoll</tt> and 17 (36 hours) for <tt>maxpoll</tt>. Ordinarily, the poll interval will start at <tt>minpoll</tt> and ramp up to <tt>maxpoll</tt> in a day or two.</p>
<h4>US Phone Numbers and Formats</h4>
<p>Note: Phone numbers include the entire Hayes modem command, including the <tt>ATDT</tt> and other control codes as may be necessary. For most cases only the <tt>ATDT</tt> may be necessary.</p>
<p><a href="http://www.boulder.nist.gov/timefreq">National Institute of Science and Technology (NIST)</a></p>
<p>Phone: (303) 494-4774 (Boulder, CO); (808) 335-4721 (Hawaii)</p>
<p><a href="http://www.boulder.nist.gov/timefreq/service/acts.htm">Data Format</a></p>
<p><tt>National Institute of Standards and Technology<br>
Telephone Time Service, Generator 3B<br>
Enter question mark &quot;?&quot; for HELP<br>
MJD YR MO DA H M S ST S UT1 msADV &lt;OTM&gt;<br>
47999 90-04-18 21:39:15 50 0 +.1 045.0 UTC(NIST) *<br>
47999 90-04-18 21:39:16 50 0 +.1 045.0 UTC(NIST) #<br>
...</tt></p>
<p><tt>MJD</tt>, <tt>YR</tt>, <tt>ST</tt>, <tt>UT1</tt> and <tt>UTC(NIST)</tt> are not used by this driver. The <tt>&lt;OTM&gt;</tt> on-time character &quot;<tt>*</tt>&quot; changes to &quot;<tt>#</tt>&quot;&nbsp;when the delay correction is valid.</p>
<p><a href="http://tycho.usno.navy.mil">US Naval Observatory (USNO)</a></p>
<p>Phone: (202) 762-1594 (Washington, DC); (719) 567-6742 (Boulder, CO)</p>
<p><a href="http://tycho.usno.navy.mil/modem_time.html">Data Format</a> (two lines, repeating at one-second intervals)</p>
<p><tt>jjjjj nnn hhmmss UTC</tt></p>
<p>* on-time character for previous timecode message<br>
jjjjj modified Julian day number (not used)<br>
nnn day of year<br>
hhmmss second of day</p>
<p><a href="tf582_4.html">European Phone Numbers and Formats</a></p>
<p><a href="http://www.spectracomcorp.com">Spectracom GPS and WWVB Receivers</a></p>
<p>If a modem is connected to a Spectracom receiver, this driver will call it and retrieve the time in one of two formats, 0 and 2. Ordinarily, the receiver requires a <tt>T</tt> in order to return the timecode. As this driver does not send data via the modem, it must either be configured in continuous mode or be polled by another local driver.</p>
<h4>Monitor Data</h4>
<p>The received timecode is written as-is to the <tt>clockstats</tt> file along with the Hayes connection and hang-up commands and result codes.</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>Set by the driver to (one of) <tt>NIST</tt>, <tt>USNO</tt>, <tt>PTB</tt> or <tt>WWVB</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Initiate a call if 1. Automatically reset by program.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Enables port locking if 1, disables if 0 (default).</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>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a>&nbsp;</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

106
html/drivers/driver19.html
View File

@ -1,59 +1,59 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>Heath WWV/WWVH Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Heath WWV/WWVH Receiver</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.19.<i>u</i><br>
Reference ID: <tt>WWV</tt><br>
Driver ID: <tt>WWV_HEATH</tt><br>
Serial Port: <tt>/dev/heath<i>u</i></tt>; 1200 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt><br>
Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control</p>
<h4>Description</h4>
<p>This driver supports the Heath GC-1000 Most Accurate Clock, with RS232C Output Accessory. This is a WWV/WWVH receiver somewhat less robust than other supported receivers. It's claimed accuracy is 100 ms when actually synchronized to the broadcast signal, but this doesn't happen even most of the time, due to propagation conditions, ambient noise sources, etc. When not synchronized, the accuracy is at the whim of the internal clock oscillator, which can wander into the sunset without warning. Since the indicated precision is 100 ms, expect a host synchronized only to this thing to wander to and fro, occasionally being rudely stepped when the offset exceeds the default CLOCK_MAX of 128 ms.</p>
<p>The internal DIPswitches should be set to operate at 1200 baud in MANUAL mode and the current year. The external DIPswitches should be set to GMT and 24-hour format. It is very important that the year be set correctly in the DIPswitches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year.</p>
<p>In MANUAL mode the clock responds to a rising edge of the request to send (RTS) modem control line by sending the timecode. Therefore, it is necessary that the operating system implement the <tt>TIOCMBIC</tt> and <tt>TIOCMBIS</tt> ioctl system calls and <tt>TIOCM_RTS</tt> control bit. Present restrictions require the use of a POSIX-compatible programming interface, although other interfaces may work as well.</p>
<p>The clock message consists of 23 ASCII printing characters in the following format:</p>
<pre>hh:mm:ss.f&nbsp;&nbsp;&nbsp;&nbsp; dd/mm/yr&lt;cr&gt;
<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>Heath WWV/WWVH Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Heath WWV/WWVH Receiver</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.19.<i>u</i><br>
Reference ID: <tt>WWV</tt><br>
Driver ID: <tt>WWV_HEATH</tt><br>
Serial Port: <tt>/dev/heath<i>u</i></tt>; 1200 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt><br>
Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control</p>
<h4>Description</h4>
<p>This driver supports the Heath GC-1000 Most Accurate Clock, with RS232C Output Accessory. This is a WWV/WWVH receiver somewhat less robust than other supported receivers. It's claimed accuracy is 100 ms when actually synchronized to the broadcast signal, but this doesn't happen even most of the time, due to propagation conditions, ambient noise sources, etc. When not synchronized, the accuracy is at the whim of the internal clock oscillator, which can wander into the sunset without warning. Since the indicated precision is 100 ms, expect a host synchronized only to this thing to wander to and fro, occasionally being rudely stepped when the offset exceeds the default CLOCK_MAX of 128 ms.</p>
<p>The internal DIPswitches should be set to operate at 1200 baud in MANUAL mode and the current year. The external DIPswitches should be set to GMT and 24-hour format. It is very important that the year be set correctly in the DIPswitches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year.</p>
<p>In MANUAL mode the clock responds to a rising edge of the request to send (RTS) modem control line by sending the timecode. Therefore, it is necessary that the operating system implement the <tt>TIOCMBIC</tt> and <tt>TIOCMBIS</tt> ioctl system calls and <tt>TIOCM_RTS</tt> control bit. Present restrictions require the use of a POSIX-compatible programming interface, although other interfaces may work as well.</p>
<p>The clock message consists of 23 ASCII printing characters in the following format:</p>
<pre>hh:mm:ss.f&nbsp;&nbsp;&nbsp;&nbsp; dd/mm/yr&lt;cr&gt;
hh:mm:ss.f = hours, minutes, seconds
f = deciseconds ('?' when out of spec)
dd/mm/yr = day, month, year</pre>
<p>The alarm condition is indicated by '?', rather than a digit, at A. Note that 0?:??:??.? is displayed before synchronization is first established and hh:mm:ss.? once synchronization is established and then lost again for about a day.</p>
<p>A fudge time1 value of .07 s appears to center the clock offset residuals.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver
</dl>
Additional Information
<p><a href="../refclock.html">Reference Clock Drivers</a>&nbsp;</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<p>The alarm condition is indicated by '?', rather than a digit, at A. Note that 0?:??:??.? is displayed before synchronization is first established and hh:mm:ss.? once synchronization is established and then lost again for about a day.</p>
<p>A fudge time1 value of .07 s appears to center the clock offset residuals.</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>WWV</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>
Additional Information
<p><a href="../refclock.html">Reference Clock Drivers</a>&nbsp;</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

67
html/drivers/driver2.html
View File

@ -1,67 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>Trak 8820 GPS Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Trak 8820 GPS Receiver</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.2.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS_TRAK</tt><br>
Serial Port: <tt>/dev/trak<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports the Trak 8820 GPS Station Clock. The claimed accuracy at the 1-PPS output is 200-300 ns relative to the broadcast signal; however, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p>
<p>For best accuracy, this radio requires the <tt>tty_clk</tt> line discipline, which captures a timestamp at the <tt>*</tt> on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the <tt>\r</tt> ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines.</p>
<p>Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning.</p>
<p>In operation, this driver sends a <tt>RQTS\r</tt> request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second:</p>
<pre>*RQTS U,ddd:hh:mm:ss.0,q&lt;cr&gt;&lt;lf&gt;
on-time = '*'
ddd = day of year
hh:mm:ss = hours, minutes, seconds
q = quality indicator (phase error), 0-6:
&nbsp;&nbsp;&nbsp;&nbsp; 0 &gt; 20 us
&nbsp;&nbsp;&nbsp;&nbsp; 6 &gt; 10 us
&nbsp;&nbsp;&nbsp;&nbsp; 5 &gt; 1 us
&nbsp;&nbsp;&nbsp;&nbsp; 4 &gt; 100 ns
&nbsp;&nbsp;&nbsp;&nbsp; 3 &gt; 10 ns
&nbsp;&nbsp;&nbsp;&nbsp; 2 &lt; 10 ns</pre>
The alarm condition is indicated by <tt>0</tt> at <tt>Q</tt>, which means the radio has a phase error greater than 20 us relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarmed.
<p>The continuous time mode is disabled using the <tt>RQTX\r</tt> request, following which the radio sends a <tt>RQTX DONE&lt;cr&gt;&lt;lf&gt;</tt> response. In the normal mode, other control and status requests are effective, including the leap-second status request <tt>RQLS&lt;cr&gt;</tt>. The radio responds with <tt>RQLS yy,mm,dd&lt;cr&gt;&lt;lf&gt;</tt>, where <tt>yy,mm,dd</tt> are the year, month and day. Presumably, this gives the epoch of the next leap second, <tt>RQLS 00,00,00</tt> if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver.</p>
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
<h4>Fudge Factors</h4>
<p></p>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver.
<p>Additional Information</p>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

523
html/drivers/driver20.html
View File

@ -1,105 +1,432 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"><title>Generic NMEA GPS Receiver</title>
<!-- Changed by: Harlan &, 31-Mar-2014 -->
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
table.dlstable { font-size:85%; }
td.ttf{ font-family:Courier; font-weight:bold; }
</style></head>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<title>Generic NMEA GPS Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Generic NMEA GPS Receiver</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.20.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS_NMEA</tt><br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 - 115200 bps, 8-bits, no parity<br>
Serial Port: <tt>/dev/gpspps<i>u</i></tt>; for just the PPS signal (this is tried first for PPS, before <tt>/dev/gps<i>u</i></tt>)<br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; symlink to server:port (for nmead) Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports GPS receivers with the <tt>$GPRMC, $GPGLL, $GPGGA, $GPZDA, and $GPZDG</tt> NMEA sentences by default.&nbsp; Note that Accord's custom NMEA sentence <tt>$GPZDG</tt> reports using the GPS timescale, while the rest of the sentences report UTC.&nbsp; The difference between the two is a whole number of seconds which increases with each leap second insertion in UTC.&nbsp; To avoid problems mixing UTC and GPS timescales, the driver disables processing of UTC sentences once <tt>$GPZDG</tt> is received.</p>
<p>The driver expects the receiver to be set up to transmit at least one supported sentence every second.</p>
<p>The accuracy depends on the receiver used. Inexpensive GPS models are available with a claimed PPS signal accuracy of 1 <font face="Symbol">m</font>s or better relative to the broadcast signal. However, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p>
<p>If the Operating System supports PPSAPI (<a href="http://www.ietf.org/rfc/rfc2783.txt">RFC 2783</a>), fudge flag1 1 enables its use.<br>&nbsp;</p>
<p>The various GPS sentences that this driver recognises look like this:<br>
(others quietly ignored)</p>
<pre><tt>$GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS&lt;cr&gt;&lt;lf&gt;
$GPGLL,LAT,LAT_REF,LONG,LONG_REF,UTC,POS_STAT*CS&lt;cr&gt;&lt;lf&gt;
$GPGGA,UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CS&lt;cr&gt;&lt;lf&gt;
$GPZDA,UTC,DD,MM,YYYY,TH,TM,*CS&lt;cr&gt;&lt;lf&gt;
$GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS&lt;cr&gt;&lt;lf&gt;
<body>
<h3>Generic NMEA GPS Receiver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->31-Mar-2014 03:55<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
&nbsp; UTC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Time of day on UTC timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.fff])
&nbsp; POS_STAT - Position status. (A = Data valid, V = Data invalid)
&nbsp; LAT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Latitude (llll.ll)
&nbsp; LAT_REF&nbsp; - Latitude direction. (N = North, S = South)
&nbsp; LON&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Longitude (yyyyy.yy)
&nbsp; LON_REF&nbsp; - Longitude direction (E = East, W = West)
&nbsp; SPD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Speed over ground. (knots) (x.x)
&nbsp; HDG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Heading/track made good (degrees True) (x.x)
&nbsp; DATE&nbsp;&nbsp;&nbsp;&nbsp; - Date (ddmmyy)
&nbsp; MAG_VAR&nbsp; - Magnetic variation (degrees) (x.x)
&nbsp; MAG_REF&nbsp; - Magnetic variation (E = East, W = West)
&nbsp; FIX_MODE - Position Fix Mode (0 = Invalid, &gt;0 = Valid)
&nbsp; SAT_USED - Number Satellites used in solution
&nbsp; HDOP&nbsp;&nbsp;&nbsp;&nbsp; - Horizontal Dilution of Precision
&nbsp; ALT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Antenna Altitude
&nbsp; ALT_UNIT - Altitude Units (Metres/Feet)
&nbsp; GEO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Geoid/Elipsoid separation
&nbsp; G_UNIT&nbsp;&nbsp; - Geoid units (M/F)
&nbsp; D_AGE&nbsp;&nbsp;&nbsp; - Age of last DGPS Fix
&nbsp; D_REF&nbsp;&nbsp;&nbsp; - Reference ID of DGPS station
&nbsp; GPSTIME&nbsp; - Time of day on GPS timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.f])
&nbsp; DD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Day of the month (1-31)
&nbsp; MM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Month of the year (1-12)
&nbsp; YYYY&nbsp;&nbsp;&nbsp;&nbsp; - Year
&nbsp; AA.BB&nbsp;&nbsp;&nbsp; - Denotes the signal strength (should be &lt 05.00)
&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - GPS sync status
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '0' =&gt INVALID time,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '1' =&gt accuracy of +/- 20ms,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '2' =&gt accuracy of +/- 100ns
&nbsp; CS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Checksum
&nbsp; &lt;cr&gt;&lt;lf&gt; - Sentence terminator.</tt></pre>
<p>
Address: 127.127.20.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS_NMEA</tt><br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 - 115200 bps, 8-bits, no parity<br>
Serial Port: <tt>/dev/gpspps<i>u</i></tt>; for just the PPS signal (this
is tried first for PPS, before <tt>/dev/gps<i>u</i></tt>)<br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; symlink to server:port (for nmead)<br>
Features: <tt>tty_clk</tt>
</p>
<p>Specific GPS sentences and bitrates may be selected by setting bits of the 'mode' in the server configuration line:<br>
&nbsp;&nbsp;<tt>server 127.127.20.x mode X</tt><br>&nbsp;&nbsp;&nbsp; bit 0 - process <tt>$GPMRC</tt>&nbsp;&nbsp;&nbsp; (value = 1)<br>&nbsp;&nbsp;&nbsp; bit 1 - process <tt>$GPGGA</tt>&nbsp;&nbsp;&nbsp; (value = 2)<br>&nbsp;&nbsp;&nbsp; bit 2 - process <tt>$GPGLL</tt>&nbsp;&nbsp;&nbsp; (value = 4)<br>&nbsp;&nbsp;&nbsp; bit 4 - process <tt>$GPZDA</tt> or <tt>$GPZDG</tt>&nbsp;&nbsp;&nbsp; (value = 8)<br>
<p>The default (mode 0) is to process all supported sentences, which results in the last received each cycle being used.&nbsp; Multiple sentences may be selected by adding their mode bit values.&nbsp; The driver uses 4800 bits per second by default.&nbsp; Faster bitrates can be selected using bits 4, 5, and 6 of the mode field:<br><br>
&nbsp;&nbsp;&nbsp; bits 4/5/6 - select serial bitrate&nbsp;&nbsp; (0 for 4800 - the default, 16 for 9600, 32 for 19200, 48 for 38400, 64 for 57600, 80 for 115200)<br></p>
<p>The driver will send a <tt>$PMOTG,RMC,0000*1D&lt;cr&gt;&lt;lf&gt;</tt> command each poll interval.&nbsp; This is not needed on most GPS receivers because they automatically send <tt>$GPRMC</tt> every second, but helps a Motorola GPS receiver that is otherwise silent.&nbsp; NMEA devices ignore commands they do not understand.</p>
<h4>Setting up the Garmin GPS-25XL</h4>
Switch off all output with by sending it the following string.
<pre>&quot;$PGRMO,,2&lt;cr&gt;&lt;lf&gt;&quot;</pre>
<p>Now switch only $GPRMC on by sending it the following string.</p>
<pre>&quot;$PGRMO,GPRMC,1&lt;cr&gt;&lt;lf&gt;&quot;</pre>
<p>On some systems the PPS signal isn't switched on by default. It can be switched on by sending the following string.</p>
<pre>&quot;$PGRMC,,,,,,,,,,,,2&lt;cr&gt;&lt;lf&gt;&quot;</pre>
<h4>Monitor Data</h4>
<p>The GPS sentence that is used is written to the clockstats file and available with ntpq -c clockvar.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Specifies the serial end of line time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.
<dt><tt>flag2 0 | 1</tt>
<dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1.
<dt><tt>flag3 0 | 1</tt>
<dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel discipline if 1.
<dt><tt>flag4 0 | 1</tt>
<dd>Obscures location in timecode: 0 for disable (default), 1 for enable.
</dl>
<p>Additional Information</p>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<h4>Description</h4>
</html>
<p>
This driver supports GPS receivers with
the <tt>$GPRMC</tt>, <tt>$GPGLL</tt>, <tt>$GPGGA</tt>, <tt>$GPZDA</tt>
and <tt>$GPZDG</tt> NMEA sentences by default.&nbsp; Note that Accord's
custom NMEA sentence <tt>$GPZDG</tt> reports using the GPS timescale,
while the rest of the sentences report UTC.&nbsp; The difference between
the two is a whole number of seconds which increases with each leap
second insertion in UTC.&nbsp; To avoid problems mixing UTC and GPS
timescales, the driver disables processing of UTC sentences
once <tt>$GPZDG</tt> is received.
</p>
<p>
The driver expects the receiver to be set up to transmit at least one
supported sentence every second.
</p>
<p>
The accuracy depends on the receiver used. Inexpensive GPS models are
available with a claimed PPS signal accuracy of
1 &mu;s or better relative to the broadcast
signal. However, in most cases the actual accuracy is limited by the
precision of the timecode and the latencies of the serial interface and
operating system.
</p>
<p>
If the Operating System supports PPSAPI
(<a href="http://www.ietf.org/rfc/rfc2783.txt">RFC 2783</a>), fudge flag1
1 enables its use.
</p>
<p>
The various GPS sentences that this driver recognises look like this:<br>
(others quietly ignored)
</p>
<p><table class="dlstable" border="1">
<caption>Accepted NMEA sentences</caption>
<tbody><tr>
<th>Sentence</th>
<th>Vendor</th>
</tr><tr>
<td class="ttf">$GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS&lt;cr&gt;&lt;lf&gt;</td>
</tr><tr>
<td class="ttf">$GPGLL,LAT,LAT_REF,LON,LON_REF,UTC,POS_STAT*CS&lt;cr&gt;&lt;lf&gt;</td>
</tr><tr>
<td class="ttf">$GPGGA,UTC,LAT,LAT_REF,LON,LON_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CS&lt;cr&gt;&lt;lf&gt;</td>
</tr><tr>
<td class="ttf">$GPZDA,UTC,DD,MM,YYYY,TH,TM,*CS&lt;cr&gt;&lt;lf&gt;</td>
</tr><tr>
<td class="ttf">$GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS&lt;cr&gt;&lt;lf&gt;</td>
<td>Accord</td>
</tr>
</tbody></table></p>
<p><table class="dlstable" border="1">
<caption>NMEA data items</caption>
<tbody><tr>
<th>Symbol</th>
<th>Meaning and Format</th>
</tr>
<tr>
<td class="ttf">UTC</td>
<td>Time of day on UTC timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.fff])</td>
</tr><tr>
<td class="ttf">POS_STAT</td>
<td>Position status. (A = Data valid, V = Data invalid)</td>
</tr><tr>
<td class="ttf">LAT</td>
<td>Latitude (llll.ll)</td>
</tr><tr>
<td class="ttf">LAT_REF</td>
<td>Latitude direction. (N = North, S = South)</td>
</tr><tr>
<td class="ttf">LON</td>
<td>Longitude (yyyyy.yy)</td>
</tr><tr>
<td class="ttf">LON_REF</td>
<td>Longitude direction (E = East, W = West)</td>
</tr><tr>
<td class="ttf">SPD</td>
<td>Speed over ground. (knots) (x.x)</td>
</tr><tr>
<td class="ttf">HDG</td>
<td>Heading/track made good (degrees True) (x.x)</td>
</tr><tr>
<td class="ttf">DATE</td>
<td>Date (ddmmyy)</td>
</tr><tr>
<td class="ttf">MAG_VAR</td>
<td>Magnetic variation (degrees) (x.x)</td>
</tr><tr>
<td class="ttf">MAG_REF</td>
<td>Magnetic variation (E = East, W = West)</td>
</tr><tr>
<td class="ttf">FIX_MODE</td>
<td>Position Fix Mode (0 = Invalid, &gt;0 = Valid)</td>
</tr><tr>
<td class="ttf">SAT_USED</td>
<td>Number of Satellites used in solution</td>
</tr><tr>
<td class="ttf">HDOP</td>
<td>Horizontal Dilution of Precision</td>
</tr><tr>
<td class="ttf">ALT</td>
<td>Antenna Altitude</td>
</tr><tr>
<td class="ttf">ALT_UNIT</td>
<td>Altitude Units (Metres/Feet)</td>
</tr><tr>
<td class="ttf">GEO</td>
<td>Geoid/Elipsoid separation</td>
</tr><tr>
<td class="ttf">G_UNIT</td>
<td>Geoid units (M/F)</td>
</tr><tr>
<td class="ttf">D_AGE</td>
<td>Age of last DGPS Fix</td>
</tr><tr>
<td class="ttf">D_REF</td>
<td>Reference ID of DGPS station</td>
</tr><tr>
<td class="ttf">GPSTIME</td>
<td>Time of day on GPS timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.f])</td>
</tr><tr>
<td class="ttf">DD</td>
<td>Day of the month (1-31)</td>
</tr><tr>
<td class="ttf">MM</td>
<td>Month of the year (1-12)</td>
</tr><tr>
<td class="ttf">YYYY</td>
<td>Year</td>
</tr><tr>
<td class="ttf">AA.BB</td>
<td>Denotes the signal strength (should be &lt; 05.00)</td>
</tr><tr>
<td class="ttf">V</td>
<td>GPS sync status<br>
&nbsp;&nbsp;&nbsp;'0' =&gt; INVALID time,<br>
&nbsp;&nbsp;&nbsp;'1' =&gt; accuracy of +/- 20ms,<br>
&nbsp;&nbsp;&nbsp;'2' =&gt; accuracy of +/- 100ns</td>
</tr><tr>
<td class="ttf">CS</td>
<td> Checksum</td>
</tr><tr>
<td class="ttf">&lt;cr&gt;&lt;lf&gt;</td>
<td>Sentence terminator.</td>
</tr>
</tbody></table></p>
<h4>The 'mode' byte</h4>
<p>
Specific GPS sentences and bitrates may be selected by setting bits of
the 'mode' in the server configuration line:<br> &nbsp;&nbsp;<tt>server
127.127.20.x mode X</tt>
</p>
<table border="1">
<caption>mode byte bits and bit groups</caption>
<tbody><tr>
<th align="center">Bit</th>
<th align="center">Decimal</th>
<th align="center">Hex</th>
<th align="left">Meaning</th>
</tr>
<tr>
<td align="center">0</td>
<td align="center">1</td>
<td align="center">1</td>
<td>process <tt>$GPMRC</tt></td>
</tr><tr>
<td align="center">1</td>
<td align="center">2</td>
<td align="center">2</td>
<td>process <tt>$GPGGA</tt></td>
</tr><tr>
<td align="center">2</td>
<td align="center">4</td>
<td align="center">4</td>
<td>process <tt>$GPGLL</tt></td>
</tr><tr>
<td align="center">3</td>
<td align="center">8</td>
<td align="center">8</td>
<td>process <tt>$GPZDA</tt> or <tt>$GPZDG</tt></td>
</tr><tr>
<td rowspan="6" align="center">4-6</td>
<td align="center">0</td>
<td align="center">0</td>
<td>linespeed 4800 bps</td>
</tr><tr>
<td align="center">16</td>
<td align="center">0x10</td>
<td>linespeed 9600 bps</td>
</tr><tr>
<td align="center">32</td>
<td align="center">0x20</td>
<td>linespeed 19200 bps</td>
</tr><tr>
<td align="center">48</td>
<td align="center">0x30</td>
<td>linespeed 38400 bps</td>
</tr><tr>
<td align="center">64</td>
<td align="center">0x40</td>
<td>linespeed 57600 bps</td>
</tr><tr>
<td align="center">80</td>
<td align="center">0x50</td>
<td>linespeed 115200 bps</td>
</tr><tr>
<td align="center">7</td>
<td align="center">128</td>
<td align="center">0x80</td>
<td>Write the sub-second fraction of the receive time stamp to the
clockstat file for all recognised NMEA sentences. This can be used to
get a useful value for fudge time2.<br><strong>Caveat:</strong> This
will fill your clockstat file rather fast. Use it only temporarily to
get the numbers for the NMEA sentence of your choice.</td>
</tr>
</tr><tr>
<td align="center">8</td>
<td align="center">256</td>
<td align="center">0x100</td>
<td>process <tt>$PGRMF</tt></td>
</tr><tr>
<td align="center">9-15</td>
<td align="center"></td>
<td align="center">0xFE00</td>
<td>reserved - leave 0</td>
</tr><tr>
<td align="center">16</td>
<td align="center">65536</td>
<td align="center">0x10000</td>
<td>Append extra statistics to the clockstats line.
Details below.</td>
</tr>
</tbody></table>
<p>
The default (mode 0) is to process all supported sentences at a linespeed
of 4800 bps, which results in the first one received and recognised in
each cycle being used.&nbsp; If only specific sentences should be
recognised, then the mode byte must be chosen to enable only the selected
ones.&nbsp; Multiple sentences may be selected by adding their mode bit
values, but of those enabled still only the first received sentence in a
cycle will be used.&nbsp; Using more than one sentence per cycle is
impossible, because
</p><ul>
<li>there is only <a href="#fudgetime2">fudge time2</a> available to
compensate for transmission delays but every sentence would need a
different one and
</li><li>using more than one sentence per cycle overstuffs the internal data
filters.
</li></ul>
The driver uses 4800 bits per second by default, but faster bitrates can
be selected using bits 4 to 6 of the mode field.
<p></p>
<p>
<strong>Caveat:</strong> Using higher line speeds does not necessarily
increase the precision of the timing device.&nbsp; Higher line speeds are
not necessarily helpful for the NMEA driver, either.&nbsp; They can be
used to accomodate for an amount of data that does not fit into a
1-second cycle at 4800 bps, but high-speed high-volume NMEA data is likely
to cause trouble with the serial line driver since NMEA supports no
protocol handshake.&nbsp; Any device that is exclusively used for time
synchronisation purposes should be configured to transmit the relevant
data only, e.g. one <tt>$GPRMC</tt> or <tt>$GPZDA</tt> per second, at a
linespeed of 4800 bps or 9600 bps.
</p>
<h4>Monitor Data</h4>
<p>The last GPS sentence that is accepted or rejected is written to the
clockstats file and available with <code>ntpq -c clockvar</code>.
(Logging the rejected sentences lets you see/debug why they were rejected.)
Filtered sentences are not logged.</p>
<p>
If the 0x10000 mode bit is on and clockstats is enabled, several extra
counters will be appended to the NMEA sentence that gets logged.
For example:
<pre>
56299 76876.691 127.127.20.20 $GPGGA,212116.000,3726.0785,N,12212.2605,W,1,05,2.0,17.0,M,-25.7,M,,0000*5C 228 64 0 0 64 0
</pre>
</p>
<table border="1">
<caption>Clockstats</caption>
<tbody><tr>
<th align="center">Column</th>
<th align="center">Sample</th>
<th align="left">Meaning</th>
</tr>
<tr>
<td align="center">1</td>
<td align="center">56299</td>
<td>MJD</td>
</tr><tr>
<td align="center">2</td>
<td align="center">76876.691</td>
<td>Time of day in seconds</td>
</tr><tr>
<td align="center">3</td>
<td align="center">127.127.20.20</td>
<td>IP Address from server config line</td>
</tr><tr>
<td align="center">4</td>
<td align="center">$GPGGA,...0*5C</td>
<td>NMEA Sentence</td>
</tr><tr>
<td align="center">5</td>
<td align="center">228</td>
<td>Number of sentences received</td>
</tr><tr>
<td align="center">6</td>
<td align="center">64</td>
<td>Number of sentences accepted and used for timekeeping</td>
</tr><tr>
<td align="center">7</td>
<td align="center">0</td>
<td>Number of sentences rejected because they were marked invalid (poor signal)</td>
</tr><tr>
<td align="center">8</td>
<td align="center">0</td>
<td>Number of sentences rejected because of bad checksum or invalid date/time</td>
</tr><tr>
<td align="center">9</td>
<td align="center">64</td>
<td>Number of sentences filtered by mode bits or same second</td>
</tr><tr>
<td align="center">10</td>
<td align="center">0</td>
<td>Number of PPS pulses used, overrides NMEA sentences</td>
</tr>
</tbody></table>
Sentences like $GPGSV that don't contain the time will get
counted in the total but otherwise ignored.
<p>
<a href="https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks">Configuring
NMEA Refclocks</a> might give further useful hints for specific hardware
devices that exhibit strange or curious behaviour.
</p>
<p>
To make a specific setting, select the corresponding decimal values from
the mode byte table, add them all together and enter the resulting
decimal value into the clock configuration line.
</p>
<h4>Setting up the Garmin GPS-25XL</h4>
Switch off all output with by sending it the following string.
<pre>"$PGRMO,,2&lt;cr&gt;&lt;lf&gt;"</pre>
<p>Now switch only $GPRMC on by sending it the following string.</p>
<pre>"$PGRMO,GPRMC,1&lt;cr&gt;&lt;lf&gt;"</pre>
<p>On some systems the PPS signal isn't switched on by default. It can be
switched on by sending the following string.</p>
<pre>"$PGRMC,,,,,,,,,,,,2&lt;cr&gt;&lt;lf&gt;"</pre>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0.</dd>
<dt><a name="fudgetime2"><tt>time2 <i>time</i></tt></a></dt>
<dd>Specifies the serial end of line time offset calibration factor, 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>Specifies the driver reference identifier, an ASCII string from one to four characters, with
default <tt>GPS</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the
falling edge if 1.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel
discipline if 1.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Obscures location in timecode: 0 for disable (default), 1 for enable.</dd>
</dl>
<p>Additional Information</p>
<p><tt>flag1</tt>, <tt>flag2</tt>, and <tt>flag3</tt> are ignored under Windows.</p>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body></html>

175
html/drivers/driver22.html
View File

@ -1,109 +1,98 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>PPS Clock Discipline</title>
<!-- Changed by: Harlan &, 31-Mar-2014 -->
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>PPS Clock Discipline</h3>
<hr>
<p>Last change:
<!-- #BeginDate format:En2m -->22-Apr-2009 15:02<!-- #EndDate -->
UTC</p>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last change:
<!-- #BeginDate format:En2m -->31-Mar-2014 07:46<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.22.<i>u</i><br>
Reference ID: <tt>PPS</tt><br>
Driver ID: <tt>PPS</tt><br>
Serial or Parallel Port: <tt>/dev/pps<i>u</i></tt><br>
Requires: PPSAPI signal interface for PPS signal processing.</p>
Reference ID: <tt>PPS</tt><br>
Driver ID: <tt>PPS</tt><br>
Serial or Parallel Port: <tt>/dev/pps<i>u</i></tt><br>
Requires: PPSAPI signal interface for PPS signal processing.</p>
<p>Note: This driver supersedes an older one of the same name. The older driver operated with several somewhat archaic signal interface devices, required intricate configuration and was poorly documented. This driver requires the Pulse per Second API (PPSAPI)<sup>1</sup>. Note also that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p>
<h4>Description</h4>
<p>This driver furnishes an interface for the pulse-per-second (PPS) signal produced by a cesium clock, radio clock or related devices. It can be used to augment the serial timecode generated by a GPS receiver, for example. It can be used to remove accumulated jitter and re-time a secondary server when synchronized to a primary server over a congested, wide-area network and before redistributing the time to local clients. The driver includes extensive signal sanity checks and grooming algorithms. A range gate and frequency discriminator reject noise and signals with incorrect frequency. A multiple-stage median filter rejects jitter due to hardware interrupt and operating system latencies. A trimmed-mean algorithm determines the best time samples. With typical workstations and processing loads, the incidental jitter can be reduced to a few microseconds.</p>
<p>While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required, ordinarily a radio clock operated as a primary reference (stratum 1) source; however, another NTP time server can be used as well. For this purpose, the auxiliary source should be specified as the prefer peer, as described in the <a href="../prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page.</p>
<p>The driver requires the PPSAPI interface<sup>1</sup>, which is a proposed IETF standard. The interface consists of the <tt>timepps.h</tt> header file and associated kernel support. Support for this interface is included in current versions of Solaris, FreeBSD and Linux and proprietary versions of Tru64 (Alpha) and SunOS. See the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page for further information.</p>
<p>The PPS source can be connected via a serial or parallel port, depending on the hardware and operating system. A serial port can be dedicated to the PPS source or shared with another device; however, if dedicated the data leads should not be connected, as noise or unexpected signals can cause <tt>ntpd</tt> to exit.</p>
<p>A radio clock is usually connected via a serial port and the PPS source
connected via a level converter to the data carrier detect (DCD)
pin (DB-9 pin 1, DB-25 pin 8) of the same connector. In some systems
where a parallel port and driver are available, the PPS signal can
be connected directly to the ACK pin (DB25 pin 10) of the connector.
Whether the PPS signal is connected via a dedicated port or shared with another
device, the driver opens the device <tt>/dev/pps%d</tt>,
where <tt>%d</tt> is the unit number. As with other drivers, links can be
used to redirect the logical name to the actual physical device.</p>
<p>The driver normally operates like any other driver and uses the same mitigation
algorithms and PLL/FLL clock discipline incorporated in the daemon.
If kernel PLL/FLL support is available, the kernel PLL/FLL clock
discipline can be used instead. The default behavior is not to use
the kernel PPS clock discipline, even if present. This driver incorporates
a good deal of signal processing to reduce jitter using the median
filter algorithm in the driver. As the result, performance
with <tt>minpoll</tt> configured at 4 (16s) is generally
better than the kernel PPS discipline. However, fudge flag 3 can
be used to enable the kernel PPS discipline if necessary.</p>
<p>This driver
is enabled only under one of two conditions (a) a prefer peer other than
this driver is among the survivors of the mitigation algorithms or (b)
there are no survivors and the <tt>minsane</tt> option
of the <tt>tos</tt> command is 0. The prefer peer designates another source
that can reliably number the seconds when available . However, if no
sources are available, the system clock continues to be disciplined by
the PPS driver on an indefinite basis.</p>
<p>A scenario where the latter behavior can be most useful is a planetary orbiter
fleet, for instance in the vicinity of Mars, where contact between orbiters
and Earth only one or two times per Sol (Mars day). These orbiters have a
precise timing reference based on an Ultra Stable Oscillator (USO) with accuracy
in the order of a Cesium oscillator. A PPS signal is derived from the USO
and can be disciplined from Earth on rare occasion or from another orbiter
via NTP. In the above scenario the PPS signal disciplines the spacecraft clock
between NTP updates.</p>
<p>In a similar scenario a PPS signal can be used to discipline the clock between
updates produced by the modem driver. This would provide precise synchronization
without needing the Internet at all.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>PPS</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Specifies PPS capture on the rising (assert) pulse edge if 0; falling
(clear) edge if 1. (default),
1 for clear.
<dt><tt>flag3 0 | 1</tt>
<dd>Controls the kernel PPS discipline: 0 for disable (default), 1 for enable.
<dt><tt>flag4 0 | 1</tt>
<dd>Record a timestamp once for each second if 1. Useful for constructing
Allan deviation plots..
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<p>Reference</p>
<ol>
<li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp.
</ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<p>The driver requires the PPSAPI interface<sup>1</sup>, which is a proposed IETF standard. The interface consists of the <tt>timepps.h</tt> header file and associated kernel support. Support for this interface is included in current versions of Solaris, FreeBSD and Linux and proprietary versions of Tru64 (Alpha) and SunOS. See the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page for further information.</p>
<p>The PPS source can be connected via a serial or parallel port, depending on the hardware and operating system. A serial port can be dedicated to the PPS source or shared with another device; however, if dedicated the data leads should not be connected, as noise or unexpected signals can cause <tt>ntpd</tt> to exit.</p>
<p>A radio clock is usually connected via a serial port and the PPS source
connected via a level converter to the data carrier detect (DCD)
pin (DB-9 pin 1, DB-25 pin 8) of the same connector. In some systems
where a parallel port and driver are available, the PPS signal can
be connected directly to the ACK pin (DB25 pin 10) of the connector.
Whether the PPS signal is connected via a dedicated port or shared with another
device, the driver opens the device <tt>/dev/pps%d</tt>,
where <tt>%d</tt> is the unit number. As with other drivers, links can be
used to redirect the logical name to the actual physical device.</p>
<p>The driver normally operates like any other driver and uses the same mitigation
algorithms and PLL/FLL clock discipline incorporated in the daemon.
If kernel PLL/FLL support is available, the kernel PLL/FLL clock
discipline can be used instead. The default behavior is not to use
the kernel PPS clock discipline, even if present. This driver incorporates
a good deal of signal processing to reduce jitter using the median
filter algorithm in the driver. As the result, performance
with <tt>minpoll</tt> configured at 4 (16s) is generally
better than the kernel PPS discipline. However, fudge flag 3 can
be used to enable the kernel PPS discipline if necessary.</p>
<p>This driver
is enabled only under one of two conditions (a) a prefer peer other than
this driver is among the survivors of the mitigation algorithms or (b)
there are no survivors and the <tt>minsane</tt> option
of the <tt>tos</tt> command is 0. The prefer peer designates another source
that can reliably number the seconds when available . However, if no
sources are available, the system clock continues to be disciplined by
the PPS driver on an indefinite basis.</p>
<p>A scenario where the latter behavior can be most useful is a planetary orbiter
fleet, for instance in the vicinity of Mars, where contact between orbiters
and Earth only one or two times per Sol (Mars day). These orbiters have a
precise timing reference based on an Ultra Stable Oscillator (USO) with accuracy
in the order of a Cesium oscillator. A PPS signal is derived from the USO
and can be disciplined from Earth on rare occasion or from another orbiter
via NTP. In the above scenario the PPS signal disciplines the spacecraft clock
between NTP updates.</p>
<p>In a similar scenario a PPS signal can be used to discipline the clock between
updates produced by the modem driver. This would provide precise synchronization
without needing the Internet at all.</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>PPS</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 PPS capture on the rising (assert) pulse edge if 0 (default) or falling
(clear) pulse edge if 1. Not used under Windows - if the special <tt>serialpps.sys</tt> serial port driver is installed then the leading edge will <i>always</i> be used.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Controls the kernel PPS discipline: 0 for disable (default), 1 for enable. Not used under Windows - if the special <tt>serialpps.sys<\tt> serial port driver is used then kernel PPS will be available and used.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Record a timestamp once for each second if 1. Useful for constructing
Allan deviation plots.</dd>
.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<p>Reference</p>
<ol>
<li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp.</li>
</ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

3
html/drivers/driver26.html
View File

@ -11,6 +11,9 @@
<body>
<h3>Hewlett Packard 58503A GPS Receiver and HP Z3801A</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->5-Oct-2005 04:37<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.26.<i>u</i><br>

5
html/drivers/driver27.html
View File

@ -11,6 +11,9 @@
<body>
<h3>Arcron MSF Receiver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.27.<i>u</i><br>
@ -242,4 +245,4 @@ May 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, w
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

84
html/drivers/driver28.html
View File

@ -5,12 +5,15 @@
<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>Shared memoy Driver</title>
<title>Shared Memory Driver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Shared Memory Driver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->8-Aug-2014 19:17<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.28.<i>u</i><br>
@ -22,49 +25,64 @@
<h4>Structure of shared memory-segment</h4>
<pre>struct shmTime {
&nbsp; int&nbsp;&nbsp;&nbsp; mode; /* 0 - if valid set
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use values,&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clear valid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * 1 - if valid set&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if count before and after read of&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; values is equal,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use values&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clear valid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */
&nbsp; int&nbsp;&nbsp;&nbsp; count;
&nbsp; time_t clockTimeStampSec;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* external clock */
&nbsp; int&nbsp;&nbsp;&nbsp; clockTimeStampUSec;&nbsp;&nbsp;&nbsp;&nbsp; /* external clock */
&nbsp; time_t receiveTimeStampSec;&nbsp;&nbsp;&nbsp; /* internal clock, when external value was received */
&nbsp; int&nbsp;&nbsp;&nbsp; receiveTimeStampUSec;&nbsp;&nbsp; /* internal clock, when external value was received */
&nbsp; int&nbsp;&nbsp;&nbsp; leap;
&nbsp; int&nbsp;&nbsp;&nbsp; precision;
&nbsp; int&nbsp;&nbsp;&nbsp; nsamples;
&nbsp; int&nbsp;&nbsp;&nbsp; valid;
&nbsp; int&nbsp;&nbsp;&nbsp; dummy[10];&nbsp;
int mode; /* 0 - if valid is set:
* use values,
* clear valid
* 1 - if valid is set:
* if count before and after read of data is equal:
* use values
* clear valid
*/
volatile int count;
time_t clockTimeStampSec;
int clockTimeStampUSec;
time_t receiveTimeStampSec;
int receiveTimeStampUSec;
int leap;
int precision;
int nsamples;
volatile int valid;
unsigned clockTimeStampNSec; /* Unsigned ns timestamps */
unsigned receiveTimeStampNSec; /* Unsigned ns timestamps */
int dummy[8];
};</pre>
<h4>Operation mode=0</h4>
<p>Each second, the valid-flag of the shared memory-segment is checked:</p>
<p>If set, the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are passed to ntp, and the valid-flag is cleared and a counter is bumped.</p>
<p>If not set, a counter is bumped</p>
<p>Each second, the value of <code>valid</code> of the shared memory-segment is checked:</p>
<p>If set, the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are passed to ntp, and <code>valid</code> is cleared and <code>count</code> is bumped.</p>
<p>If not set, <code>count</code> is bumped.</p>
<h4>Operation mode=1</h4>
<p>Each second, the valid-flag of the shared memory-segment is checked:</p>
<p>If set, the count-field of the record is remembered, and the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are read. Then, the remembered count is compared to the count now in the record. If both are equal, the values read from the record are passed to ntp. If they differ, another process has modified the record while it was read out (was not able to produce this case), and failure is reported to ntp. The valid flag is cleared and a counter is bumped.</p>
<p>If not set, a counter is bumped</p>
<p>Each second, <code>valid</code> in the shared memory-segment is checked:</p>
<p>If set, the <code>count</code> field of the record is remembered, and the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are read. Then, the remembered <code>count</code> is compared to current value of <code>count</code> now in the record. If both are equal, the values read from the record are passed to ntp. If they differ, another process has modified the record while it was read out (was not able to produce this case), and failure is reported to ntp. The <code>valid</code> flag is cleared and <code>count</code> is bumped.</p>
<p>If not set, <code>count</code> is bumped</p>
<h4>Mode-independent postprocessing</h4>
After the time stamps have been successfully plucked from the SHM
segment, some sanity checks take place:
<ul>
<li>The receive time stamp of the SHM data must be in the last 5
seconds before the time the data is processed. This helps in weeding
out stale data.
<li>If the absolute difference between remote and local clock
exceeds the limit (either <i>time2</i> or the default of 4hrs), then
the sample is discarded. This check is disabled when <i>flag1</i> is
set to 1.
</ul>
<h4>gpsd</h4>
<a href="http://gpsd.berlios.de/"><i>gpsd</i></a>
knows how to talk to many GPS devices.
It works with <i>ntpd</i> through the SHM driver.
It can work with <i>ntpd</i> through the SHM driver.
<P>
The <i>gpsd</i> man page suggests setting minpoll and maxpoll to 4.
That was an attempt to reduce jitter.
The SHM driver was fixed (ntp-4.2.5p138) to collect data each second rather than
once per polling interval so that suggestion is no longer reasonable.
<P>
<b>Note:</b> The GPSD client driver (type 46) uses the <i>gpsd</i>
client protocol to connect and talk to <i>gpsd</i>, but using the
SHM driver is the ancient way to have <i>gpsd</i> talk to <i>ntpd</i>.
<h4>Clockstats</h4>
If flag4 is set when the driver is polled, a clockstats record is written.
@ -99,13 +117,19 @@ Here is a sample showing the GPS reception fading out:
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dd>Maximum allowed difference between remote and local
clock, in seconds. Values <1.0 or >86400.0 are ignored, and the
default value of 4hrs (14400s) is used instead. See also flag 1.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>SHM</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dd><i>Skip</i> the difference limit check if set. Useful
for systems where the RTC backup cannot keep the time over
long periods without power and the SHM clock must be able
to force long-distance initial jumps. <i>Check</i> the
difference limit if cleared (default).
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>

5
html/drivers/driver29.html
View File

@ -10,6 +10,9 @@
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<h1><font size="+2">Trimble Palisade and Thunderbolt Receivers</font>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
</h1>
<table>
@ -1087,4 +1090,4 @@ Here is a link explaining the situation:<p>
;
</body>
</html>
</html>

104
html/drivers/driver3.html
View File

@ -1,28 +1,29 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<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>PSTI/Traconex 1020 WWV/WWVH Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>PSTI/Traconex 1020 WWV/WWVH Receiver</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.3.<i>u</i><br>
Reference ID: <tt>WWV</tt><br>
Driver ID: <tt>WWV_PST</tt><br>
Serial Port: <tt>/dev/wwv<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports the PSTI 1010 and Traconex 1020 WWV/WWVH Receivers. No specific claim of accuracy is made for these receiver, but actual experience suggests that 10 ms would be a conservative assumption.</p>
<p>The dipswitches should be set for 9600 bps line speed, 24-hour day-of-year format and UTC time zone. Automatic correction for DST should be disabled. It is very important that the year be set correctly in the DIP-switches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year. As the there are only four dipswitches to set the year and the base value of zero correspondes to 1986, years beyond 2001 recycle with the value of zero corresponding to 2002. The propagation delay DIP-switches should be set according to the distance from the transmitter for both WWV and WWVH, as described in the instructions. While the delay can be set only to within 11 ms, the fudge time1 parameter can be used for vernier corrections.</p>
<p>Using the poll sequence <tt>QTQDQM</tt>, the response timecode is in three sections totalling 50 ASCII printing characters, as concatenated by the driver, in the following format:</p>
<pre>
<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>PSTI/Traconex 1020 WWV/WWVH Receiver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>PSTI/Traconex 1020 WWV/WWVH Receiver</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.3.<i>u</i><br>
Reference ID: <tt>WWV</tt><br>
Driver ID: <tt>WWV_PST</tt><br>
Serial Port: <tt>/dev/wwv<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt></p>
<h4>Description</h4>
<p>This driver supports the PSTI 1010 and Traconex 1020 WWV/WWVH Receivers. No specific claim of accuracy is made for these receiver, but actual experience suggests that 10 ms would be a conservative assumption.</p>
<p>The dipswitches should be set for 9600 bps line speed, 24-hour day-of-year format and UTC time zone. Automatic correction for DST should be disabled. It is very important that the year be set correctly in the DIP-switches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year. As the there are only four dipswitches to set the year and the base value of zero correspondes to 1986, years beyond 2001 recycle with the value of zero corresponding to 2002. The propagation delay DIP-switches should be set according to the distance from the transmitter for both WWV and WWVH, as described in the instructions. While the delay can be set only to within 11 ms, the fudge time1 parameter can be used for vernier corrections.</p>
<p>Using the poll sequence <tt>QTQDQM</tt>, the response timecode is in three sections totalling 50 ASCII printing characters, as concatenated by the driver, in the following format:</p>
<pre>
ahh:mm:ss.fffs&lt;cr&gt; yy/dd/mm/ddd&lt;cr&gt;
frdzycchhSSFTttttuuxx&lt;cr&gt;
@ -45,32 +46,31 @@ T = transmitter (C = WWV, H = WWVH)
tttt = time since last update (0000 = minutes)
uu = flush character (03 = ^c)
xx = 94 (unknown)</pre>
<p>The alarm condition is indicated by other than <tt>8</tt> at <tt>a</tt>, which occurs during initial synchronization and when received signal is lost for an extended period; unlock condition is indicated by other than <tt>0000</tt> in the <tt>tttt</tt> subfield.</p>
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<p>The alarm condition is indicated by other than <tt>8</tt> at <tt>a</tt>, which occurs during initial synchronization and when received signal is lost for an extended period; unlock condition is indicated by other than <tt>0000</tt> in the <tt>tttt</tt> subfield.</p>
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

5
html/drivers/driver30.html
View File

@ -11,6 +11,9 @@
<body>
<h3>Motorola Oncore GPS receiver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.30.<i>u</i><br>
@ -80,4 +83,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

5
html/drivers/driver31.html
View File

@ -11,6 +11,9 @@
<body>
<h3>Rockwell Jupiter GPS receiver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.31.<i>u</i><br>
@ -55,4 +58,4 @@
</html>
=
=

6
html/drivers/driver32.html
View File

@ -10,6 +10,9 @@
<body>
<h3>Chrono-log K-series WWVB receiver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.32.<i>u</i><br>
@ -30,9 +33,8 @@ L - \n (newline)
Z - timestamp indicator
hh:mm:ss - local time
</pre>
<!-- hhmts start -->Last modified: Sun Feb 14 11:57:27 EST 1999 <!-- hhmts end -->
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

7
html/drivers/driver33.html
View File

@ -10,6 +10,9 @@
<body>
<h3>Dumb Clock</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.33.<i>u</i><br>
@ -26,10 +29,8 @@ hh:mm:ss - local time
C - \r (carriage return)
L - \n (newline)
</pre>
<hr>
<!-- hhmts start -->Last modified: Sun Feb 14 12:07:01 EST 1999 <!-- hhmts end -->
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

3
html/drivers/driver34.html
View File

@ -10,6 +10,9 @@
<body>
<h3>Ultralink Clock</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->31-Dec-2007 19:43<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.34.<i>u</i><br>

5
html/drivers/driver35.html
View File

@ -10,6 +10,9 @@
<body>
<h3>Conrad parallel port radio clock</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.35.<i>u</i><br>
@ -45,4 +48,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

293
html/drivers/driver36.html
View File

@ -1,147 +1,150 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Radio WWV/H Audio Demodulator/Decoder</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</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>WV<i>f</i></tt> or <tt>WH<i>f</i></tt><br>
Driver ID: <tt>WWV_AUDIO</tt><br>
Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no parity<br>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>This driver synchronizes the computer time using shortwave radio transmissions from NIST time/frequency stations <a href="http://www.bldrdoc.gov/timefreq/stations/wwv.html">WWV</a> in Ft. Collins, CO, and <a href="http://www.bldrdoc.gov/timefreq/stations/wwvh.htm">WWVH</a> in Kauai, HI. Transmissions are made continuously on 2.5, 5, 10 and 15 MHz from both stations and on 20 MHz from WWV. 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 season. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC.
<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 187 PPM (.0187 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
<p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 2479 km from the transmitter, the predicted two-hop propagation delay varies from 9.3 ms in sunlight to 9.0 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p>
<p>After calibration relative to the PPS&nbsp;signal from a GPS&nbsp;receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.1 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver6.html">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.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
<p>The driver processes 8-kHz <font face="symbol">m</font>-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in the broadcast signal. The WWV signal format is described in NIST Special Publication 432 (Revised 1990) and also available on the <a href="http://tf.nist.gov/stations/wwvtimecode.htm">WWV/H web site</a>. 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.</p>
<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 for 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/%7emills/reports.html">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 to improve performance, especially under weak signal conditions and to provide an automatic frequency and station selection feature.</p>
<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 with 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 using a communications receiver.</p>
<h4>Baseband Signal Processing</h4>
<p>The 1000/1200-Hz pulses and 100-Hz subcarrier are first separated using a 600-Hz bandpass filter centered on 1100 Hz and a 150-Hz lowpass filter. The minute pulse is extracted using an 800-ms synchronous matched filter and pulse grooming logic which discriminates between WWV and WWVH signals and noise. The second pulse is extracted using a 5-ms FIR matched filter for each station and a single 8000-stage comb filter.</p>
<p>The phase of the 100-Hz subcarrier relative to the second pulse is fixed at the transmitter; however, the audio stage in many 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 type-1 phase-lock loop (PLL) to discipline the demodulator phase.</p>
<p>A bipolar data signal is determined from the matched filter subcarrier envelope using a pulse-width discriminator. The discriminator samples the I channel at 15 ms (<i>n</i>), 200 ms (<i>s</i><sub>0</sub>) and 500 ms (<i>s</i><sub>1</sub>), and the envelope (RMS I and Q channels) at 200 ms (<i>e</i><sub>1</sub>) and the end of the second (<i>e</i><sub>0</sub>). The bipolar data signal is expressed 2<i>s</i><sub>1</sub> - <i>s</i><sub>0</sub> - <i>n</i>, where positive values correspond to data 1 and negative values correspond to data 0. Note that, since the signals <i>s</i><sub>0</sub> and <i>s</i><sub>1</sub> include the noise <i>n</i>, the noise component cancels out. The data bit SNR is calculated as 20 log<sub>10</sub>(<i>e</i><sub>1</sub> / <i>e</i><sub>0</sub>). If the driver has not synchronized to the minute pulse, or if the data bit amplitude <i>e</i><sub>1</sub> or SNR are below thresholds, the bit is considered invalid and the bipolar signal is forced to zero.</p>
<p>The bipolar signal 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 a data average value larger than a positive threshold is interpreted as +1 (hit) and a value smaller than a negative threshold as a -1 (miss). Values between the two thresholds, which can occur due to signal fades, are interpreted as an erasure and result in no change of indication.</p>
<h4>Maximum-Likelihood Decoder</h4>
<p>The BCD digit in each digit position of the timecode is represented as four data bits. The bits are correlated with the bits corresponding to each of the valid decimal digits in this position. If any of the four bits are 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 averaged values then becomes the maximum-likelihood candidate for this position and the ratio of the maximum over the next lower value represents the digit SNR.</p>
<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>
<p>Each row of the decoding matrix also includes a compare counter and the most recently determined maximum-likelihood digit. If a digit likelihood exceeds the decision level and compares with previous digits 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>
<h4>Master Clock Discipline</h4>
<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. The maximum value of the 5-ms pulse after the comb filter represents the on-time epoch of the second. At averaging intervals determined by the measured jitter, the frequency error is calculated as the difference between the epoches over the interval divided by the interval itself. The sample clock frequency is then corrected by this amount divided by a time constant of 8.</p>
<p>When first started, the frequency averaging interval is 8 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 1024 s, which results in an ultimate frequency resolution of 0.125 PPM, or about 11 ms/day.</p>
<p>The data demodulation functions operate using the subcarrier clock, which is independent of the epoch. However, the data decoding functions are driven by the epoch. The decoder is phase-locked to the epoch in such a way that, when the clock state machine has reliably decoded the broadcast time to the second, the epoch timestamp of that second becomes a candidate to set the system clock.</p>
<p>The comb filter can have a long memory and is vulnerable to noise and stale data, especially when coming up after a long fade. Therefore, a candidate is considered valid only if the 5-ms signal amplitude and SNR&nbsp;are above thresholds. In addition, the system clock is not set until after one complete averaging interval has passed with valid candidates.</p>
<h4>Station Identification</h4>
<p>It is important that the logical clock frequency is stable and accurately determined, since in many 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>
<p>Reliable station identification requires accurate discrimination between very weak signals in noise and noise alone. The driver very aggressively soaks up every scrap of signal information, but has to be careful to avoid making pseudo-sense of noise alone. The signal quality metric depends on the minute pulse amplitude and SNR measured in second 0 of the minute, together with the data subcarrier amplitude and SNR measured in second 1. If all four values are above defined thresholds a hit is declared, otherwise a miss. In principle, the data pulse in second 58 is usable, but the AGC in most radios is not fast enough for a reliable measurement.</p>
<p>The number of hits declared in the last 6 minutes for each station represents the high order bits of the metric, while the current minute pulse amplitude represents the low order bits. Only if the metric is above a defined threshold is the station signal considered acceptable. The metric is also used by the autotune function described below and reported in the timecode string.</p>
<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 ionospheric propagation medium. Conventional wisdom is that manual synchronization via oscilloscope and HF medium is good only to a millisecond under the best propagation conditions. The performance of the NTP daemon disciplined by this driver is clearly better than this, even under marginal conditions.</p>
<p>The figure below shows the measured offsets over a typical day near the bottom of the sunspot cycle ending in October, 2006. Variations up to &plusmn;0.4 ms can be expected due to changing ionospheric layer height and ray geometry over the day and night.</p>
<div align="center">
<img src="../pic/offset1211.gif" alt="gif"></div>
<p>The figure was constructed using a 2.4-GHz P4 running FreeBSD 6.1. For these measurements the computer clock was disciplined within a few microseconds of UTC using a PPS signal and GPS receiver and the measured offsets determined from the filegen peerstats data.</p>
<p>The predicted propagation delay from the WWV transmitter at Boulder, CO, to the receiver at Newark, DE, varies over 9.0-9.3 ms. In addition, the receiver contributes 4.7 ms and the 600-Hz bandpass filter 0.9 ms. With these values, the mean error is less than 0.1 ms and varies &plusmn;0.3 ms over the day as the result of changing ionospheric height and ray geometry.</p>
<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 synch. This may take some fits and starts, as the driver expects to see several 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 finding a station and frequency with acceptable metric.
<p>While this is going on the the driver acquires second synch, which can take up to several minutes, depending on signal quality. When minute synch has been acquired, the driver accumulates likelihood values for the unit (seconds) digit of the nine timecode digits, plus the seven miscellaneous bits included in the WWV/H transmission format. When a good unit digit has been found, the driver accumulated likelihood values for the remaining eight digits of the timecode. When three repetitions of all nine digits have decoded correctly, which normally takes 15 minutes with good signals, and up to 40 minutes when buried in noise, and the second synch has been acquired, the clock is set (or verified) and is selectable to discipline the system clock.</p>
<p>Once the clock is set, it continues to provide correct timecodes as long as the signal metric is above threshold, as described in the previous section. As long as the clock is correctly set or verified, the system clock offsets are provided once each minute to the reference clock interface, where they are processed using the same algorithms as with other reference clocks and remote servers.</p>
<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 has mitigated which station and frequency is best, it sets the reference identifier to the string WV<i>f</i> for WWV and WH<i>f</i> for WWVH, where <i>f</i> is the frequency in megahertz. If the propagation delays have 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 is seamless.</p>
<p>Operation continues as long as the signal metric from at least one station on at least one frequency is acceptable. A consequence of this design is that, once the clock is set, the time and frequency are disciplined only by the second synch pulse and the clock digits themselves are driven by the clock state machine. If for some reason the state machine drifts to the wrong second, it would never resynchronize. To protect against this most unlikely situation, if after two days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.</p>
<p>Once the system clock been set correctly it will continue to read correctly even during the holdover interval, but with increasing dispersion. Assuming the system clock frequency can be disciplined within 1 PPM, it can coast without signals for several days without exceeding the NTP step threshold of 128 ms. During such periods the root distance increases at 15 <font face="Symbol">m</font>s per second, which makes the driver appear less likely for selection as time goes on. Eventually, when the distance due all causes exceeds 1 s, it is no longer suitable for synchronization. Ordinarily, this happens after about 18 hours with no signals. The <tt>tinker maxdist</tt> configuration command can be used to change this value.</p>
<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. Further details are on the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>If specified, 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 synch 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 is inoperative, the driver quietly gives up with no harm done.</p>
<p>Once acquiring minute synch, 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 signal metric as described above. 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 probe 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>
<p>The mitigation procedure selects the frequency and station with the highest valid metric, ties going first to the highest frequency and then to WWV in order. A station is considered valid only if the metric is above a specified threshold; if no station is above the metric, the rotating probes continue until a valid station is found.</p>
<p>The behavior of the autotune function over a typical day is shown in the figure below.</p>
<div align="center">
<img src="../pic/freq1211.gif" alt="gif"></div>
<p>As expected, the lower frequencies prevail when the ray path is in moonlight (0100-1300 UTC) and the higher frequencies when the path is in sunlight (1300-0100 UTC). Note three periods in the figure show zero frequency when signals are below the minimum for all frequencies and stations.</p>
<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 disciplining 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>wwv</tt> for convenient filtering with the Unix <tt>grep</tt> command.</p>
<p>The autotune process produces diagnostic information along with the timecode. This is very useful for evaluating the performance of the algorithms, as well as radio propagation conditions in general. The message is produced once each minute for each frequency in turn after minute synch has been acquired.</p>
<p><tt>wwv5 status agc epoch secamp/secsnr datamp/datsnr wwv wwvh</tt></p>
<p>where the fields after the <tt>wwv5</tt> identifier are: <tt>status</tt> contains status bits, <tt>agc</tt> audio gain, <tt>epoch </tt>second epoch, <tt>secamp/secsnr </tt>second pulse amplitude/SNR, 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>
<p><tt>ident score metric minamp/minsnr</tt></p>
<p>where <tt>ident </tt>encodes the station (<tt>WV</tt> for WWV, <tt>WH</tt> for WWVH) and frequency (2, 5, 10, 15 or 20), <tt>score</tt> 32-bit shift register recording the hits (1) and misses (0) of the last 32 probes (hits and misses enter from the right), <tt>metric</tt> is described above, and <tt>minamp/minsnr</tt> is the minute pulse ampliture/SNR. An example is:</p>
<pre><tt>wwv5 000d 111 5753 3967/20.1 3523/10.2 WV20 bdeff 100 8348/30.0 WH20 0000 1 22/-12.4</tt></pre>
<p>There are several other messages that can occur; these are documented in the source listing.</p>
<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:
<p><tt>sq yyyy ddd hh:mm:ss l d du lset agc ident metric errs freq avg<br>
</tt></p>
The fields beginning with <tt>yyyy</tt> and extending through <tt>du</tt> are decoded from the received data and are in fixed-length format. The remaining fields are in variable-length format. The fields are as follows:
<dl>
<dt><tt>s</tt>
<dd>The synch indicator is initially <tt>?</tt> before the clock is set, but turns to space when all nine digits of the timecode are correctly set and the decoder is synchronized to the station within 125 <font face="Symbol">m</font>s.
<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>synch alarm. The decoder is not synchronized to the station within 125 <font face="Symbol">m</font>s.
<dt><tt>0x4</tt>
<dd>Digit error alarm. Less than nine decimal digits were found in the last minute.<dt><tt>0x2</tt>
<dd>Error alarm. More than 40 data bit errors were found in the last minute.<dt><tt>0x1</tt>
<dd>Compare alarm. A maximum-likelihood digit failed to agree with the current associated clock digit in the last minute.</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 marginal condition.<dt><tt>yyyy ddd hh:mm:ss</tt>
<dd>The timecode format itself is self explanatory. Since the driver latches the on-time epoch directly from the second synch pulse, the seconds fraction is always zero. Although the transmitted timecode includes only the year of century, the Gregorian year is augmented by 2000.
<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.
<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.
<dt><tt>du</tt>
<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds.
<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 decoder was last synchronized to the station within 125 <font face="Symbol">m</font>s.
<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 should be set for a value midway in this range.
<dt><tt>ident</tt>
<dd>The station identifier shows the station, <tt>WV<i>f</i></tt> for WWV or <tt>WH<i>f</i></tt> for WWVH, and frequency <i><tt>f</tt></i> being tracked. If neither station is heard on any frequency, the reference identifier shows <tt>NONE</tt>.
<dt><tt>metric</tt>
<dd>The signal metric described above from 0 (no signal) to 100 (best).
<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 even 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 metric drops below threshold and the decoder switches to a different frequency.<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.
<dt><tt>avg</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.
</dl>
<p>An example timecode is:</p>
<p><tt>0 2000 006 22:36:00 S +3 1 115 WV20 86 5 66.4 1024</tt></p>
<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. Good receiving conditions prevail, as indicated by the metric 86 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.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the propagation delay for WWV (40:40:49.0N 105:02:27.0W), in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Specifies the propagation delay for WWVH (21:59:26.0N 159:46:00.0W), in seconds and fraction, with default 0.0.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<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>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<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.
<dt><tt>flag3 0 | 1</tt>
<dd>Enables audio monitoring of the input signal. For this purpose, the speaker volume must be set before the driver is started.
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Radio WWV/H Audio Demodulator/Decoder</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Radio WWV/H Audio Demodulator/Decoder</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last updage:
<!-- #BeginDate format:En2m -->15-Nov-2012 06:42<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
Address: 127.127.36.<i>u</i><br>
Reference ID: <tt>WV<i>f</i></tt> or <tt>WH<i>f</i></tt><br>
Driver ID: <tt>WWV_AUDIO</tt><br>
Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no parity<br>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
This driver synchronizes the computer time using shortwave radio transmissions from NIST time/frequency stations <a href="http://www.bldrdoc.gov/timefreq/stations/wwv.html">WWV</a> in Ft. Collins, CO, and <a href="http://www.bldrdoc.gov/timefreq/stations/wwvh.htm">WWVH</a> in Kauai, HI. Transmissions are made continuously on 2.5, 5, 10 and 15 MHz from both stations and on 20 MHz from WWV. 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 season. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC.
<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and &mu;-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 187 PPM (.0187 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
<p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 2479 km from the transmitter, the predicted two-hop propagation delay varies from 9.3 ms in sunlight to 9.0 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p>
<p>After calibration relative to the PPS&nbsp;signal from a GPS&nbsp;receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.1 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver6.html">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.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
<p>The driver processes 8-kHz &mu;-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in the broadcast signal. The WWV signal format is described in NIST Special Publication 432 (Revised 1990) and also available on the <a href="http://tf.nist.gov/stations/wwvtimecode.htm">WWV/H web site</a>. 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.</p>
<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 for 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/%7emills/reports.html">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 to improve performance, especially under weak signal conditions and to provide an automatic frequency and station selection feature.</p>
<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 with 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 using a communications receiver.</p>
<h4>Baseband Signal Processing</h4>
<p>The 1000/1200-Hz pulses and 100-Hz subcarrier are first separated using a 600-Hz bandpass filter centered on 1100 Hz and a 150-Hz lowpass filter. The minute pulse is extracted using an 800-ms synchronous matched filter and pulse grooming logic which discriminates between WWV and WWVH signals and noise. The second pulse is extracted using a 5-ms FIR matched filter for each station and a single 8000-stage comb filter.</p>
<p>The phase of the 100-Hz subcarrier relative to the second pulse is fixed at the transmitter; however, the audio stage in many 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 type-1 phase-lock loop (PLL) to discipline the demodulator phase.</p>
<p>A bipolar data signal is determined from the matched filter subcarrier envelope using a pulse-width discriminator. The discriminator samples the I channel at 15 ms (<i>n</i>), 200 ms (<i>s</i><sub>0</sub>) and 500 ms (<i>s</i><sub>1</sub>), and the envelope (RMS I and Q channels) at 200 ms (<i>e</i><sub>1</sub>) and the end of the second (<i>e</i><sub>0</sub>). The bipolar data signal is expressed 2<i>s</i><sub>1</sub> - <i>s</i><sub>0</sub> - <i>n</i>, where positive values correspond to data 1 and negative values correspond to data 0. Note that, since the signals <i>s</i><sub>0</sub> and <i>s</i><sub>1</sub> include the noise <i>n</i>, the noise component cancels out. The data bit SNR is calculated as 20 log<sub>10</sub>(<i>e</i><sub>1</sub> / <i>e</i><sub>0</sub>). If the driver has not synchronized to the minute pulse, or if the data bit amplitude <i>e</i><sub>1</sub> or SNR are below thresholds, the bit is considered invalid and the bipolar signal is forced to zero.</p>
<p>The bipolar signal 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 a data average value larger than a positive threshold is interpreted as +1 (hit) and a value smaller than a negative threshold as a -1 (miss). Values between the two thresholds, which can occur due to signal fades, are interpreted as an erasure and result in no change of indication.</p>
<h4>Maximum-Likelihood Decoder</h4>
<p>The BCD digit in each digit position of the timecode is represented as four data bits. The bits are correlated with the bits corresponding to each of the valid decimal digits in this position. If any of the four bits are 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 averaged values then becomes the maximum-likelihood candidate for this position and the ratio of the maximum over the next lower value represents the digit SNR.</p>
<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>
<p>Each row of the decoding matrix also includes a compare counter and the most recently determined maximum-likelihood digit. If a digit likelihood exceeds the decision level and compares with previous digits 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>
<h4>Master Clock Discipline</h4>
<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. The maximum value of the 5-ms pulse after the comb filter represents the on-time epoch of the second. At averaging intervals determined by the measured jitter, the frequency error is calculated as the difference between the epoches over the interval divided by the interval itself. The sample clock frequency is then corrected by this amount divided by a time constant of 8.</p>
<p>When first started, the frequency averaging interval is 8 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 1024 s, which results in an ultimate frequency resolution of 0.125 PPM, or about 11 ms/day.</p>
<p>The data demodulation functions operate using the subcarrier clock, which is independent of the epoch. However, the data decoding functions are driven by the epoch. The decoder is phase-locked to the epoch in such a way that, when the clock state machine has reliably decoded the broadcast time to the second, the epoch timestamp of that second becomes a candidate to set the system clock.</p>
<p>The comb filter can have a long memory and is vulnerable to noise and stale data, especially when coming up after a long fade. Therefore, a candidate is considered valid only if the 5-ms signal amplitude and SNR&nbsp;are above thresholds. In addition, the system clock is not set until after one complete averaging interval has passed with valid candidates.</p>
<h4>Station Identification</h4>
<p>It is important that the logical clock frequency is stable and accurately determined, since in many 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>
<p>Reliable station identification requires accurate discrimination between very weak signals in noise and noise alone. The driver very aggressively soaks up every scrap of signal information, but has to be careful to avoid making pseudo-sense of noise alone. The signal quality metric depends on the minute pulse amplitude and SNR measured in second 0 of the minute, together with the data subcarrier amplitude and SNR measured in second 1. If all four values are above defined thresholds a hit is declared, otherwise a miss. In principle, the data pulse in second 58 is usable, but the AGC in most radios is not fast enough for a reliable measurement.</p>
<p>The number of hits declared in the last 6 minutes for each station represents the high order bits of the metric, while the current minute pulse amplitude represents the low order bits. Only if the metric is above a defined threshold is the station signal considered acceptable. The metric is also used by the autotune function described below and reported in the timecode string.</p>
<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 ionospheric propagation medium. Conventional wisdom is that manual synchronization via oscilloscope and HF medium is good only to a millisecond under the best propagation conditions. The performance of the NTP daemon disciplined by this driver is clearly better than this, even under marginal conditions.</p>
<p>The figure below shows the measured offsets over a typical day near the bottom of the sunspot cycle ending in October, 2006. Variations up to &plusmn;0.4 ms can be expected due to changing ionospheric layer height and ray geometry over the day and night.</p>
<div align="center"> <img src="../pic/offset1211.gif" alt="gif"></div>
<p>The figure was constructed using a 2.4-GHz P4 running FreeBSD 6.1. For these measurements the computer clock was disciplined within a few microseconds of UTC using a PPS signal and GPS receiver and the measured offsets determined from the filegen peerstats data.</p>
<p>The predicted propagation delay from the WWV transmitter at Boulder, CO, to the receiver at Newark, DE, varies over 9.0-9.3 ms. In addition, the receiver contributes 4.7 ms and the 600-Hz bandpass filter 0.9 ms. With these values, the mean error is less than 0.1 ms and varies &plusmn;0.3 ms over the day as the result of changing ionospheric height and ray geometry.</p>
<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 synch. This may take some fits and starts, as the driver expects to see several 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 finding a station and frequency with acceptable metric.
<p>While this is going on the the driver acquires second synch, which can take up to several minutes, depending on signal quality. When minute synch has been acquired, the driver accumulates likelihood values for the unit (seconds) digit of the nine timecode digits, plus the seven miscellaneous bits included in the WWV/H transmission format. When a good unit digit has been found, the driver accumulated likelihood values for the remaining eight digits of the timecode. When three repetitions of all nine digits have decoded correctly, which normally takes 15 minutes with good signals, and up to 40 minutes when buried in noise, and the second synch has been acquired, the clock is set (or verified) and is selectable to discipline the system clock.</p>
<p>Once the clock is set, it continues to provide correct timecodes as long as the signal metric is above threshold, as described in the previous section. As long as the clock is correctly set or verified, the system clock offsets are provided once each minute to the reference clock interface, where they are processed using the same algorithms as with other reference clocks and remote servers.</p>
<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 has mitigated which station and frequency is best, it sets the reference identifier to the string WV<i>f</i> for WWV and WH<i>f</i> for WWVH, where <i>f</i> is the frequency in megahertz. If the propagation delays have 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 is seamless.</p>
<p>Operation continues as long as the signal metric from at least one station on at least one frequency is acceptable. A consequence of this design is that, once the clock is set, the time and frequency are disciplined only by the second synch pulse and the clock digits themselves are driven by the clock state machine. If for some reason the state machine drifts to the wrong second, it would never resynchronize. To protect against this most unlikely situation, if after two days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.</p>
<p>Once the system clock been set correctly it will continue to read correctly even during the holdover interval, but with increasing dispersion. Assuming the system clock frequency can be disciplined within 1 PPM, it can coast without signals for several days without exceeding the NTP step threshold of 128 ms. During such periods the root distance increases at 15 &mu;s per second, which makes the driver appear less likely for selection as time goes on. Eventually, when the distance due all causes exceeds 1 s, it is no longer suitable for synchronization. Ordinarily, this happens after about 18 hours with no signals. The <tt>tinker maxdist</tt> configuration command can be used to change this value.</p>
<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. Further details are on the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>If specified, 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 synch 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 is inoperative, the driver quietly gives up with no harm done.</p>
<p>Once acquiring minute synch, 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 signal metric as described above. 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 probe 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>
<p>The mitigation procedure selects the frequency and station with the highest valid metric, ties going first to the highest frequency and then to WWV in order. A station is considered valid only if the metric is above a specified threshold; if no station is above the metric, the rotating probes continue until a valid station is found.</p>
<p>The behavior of the autotune function over a typical day is shown in the figure below.</p>
<div align="center"> <img src="../pic/freq1211.gif" alt="gif"></div>
<p>As expected, the lower frequencies prevail when the ray path is in moonlight (0100-1300 UTC) and the higher frequencies when the path is in sunlight (1300-0100 UTC). Note three periods in the figure show zero frequency when signals are below the minimum for all frequencies and stations.</p>
<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 disciplining 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>wwv</tt> for convenient filtering with the Unix <tt>grep</tt> command.</p>
<p>The autotune process produces diagnostic information along with the timecode. This is very useful for evaluating the performance of the algorithms, as well as radio propagation conditions in general. The message is produced once each minute for each frequency in turn after minute synch has been acquired.</p>
<p><tt>wwv5 status agc epoch secamp/secsnr datamp/datsnr wwv wwvh</tt></p>
<p>where the fields after the <tt>wwv5</tt> identifier are: <tt>status</tt> contains status bits, <tt>agc</tt> audio gain, <tt>epoch </tt>second epoch, <tt>secamp/secsnr </tt>second pulse amplitude/SNR, 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>
<p><tt>ident score metric minamp/minsnr</tt></p>
<p>where <tt>ident </tt>encodes the station (<tt>WV</tt> for WWV, <tt>WH</tt> for WWVH) and frequency (2, 5, 10, 15 or 20), <tt>score</tt> 32-bit shift register recording the hits (1) and misses (0) of the last 32 probes (hits and misses enter from the right), <tt>metric</tt> is described above, and <tt>minamp/minsnr</tt> is the minute pulse ampliture/SNR. An example is:</p>
<pre><tt>wwv5 000d 111 5753 3967/20.1 3523/10.2 WV20 bdeff 100 8348/30.0 WH20 0000 1 22/-12.4</tt></pre>
<p>There are several other messages that can occur; these are documented in the source listing.</p>
<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:
<p><tt>sq yyyy ddd hh:mm:ss l d du lset agc ident metric errs freq avg<br>
</tt></p>
The fields beginning with <tt>yyyy</tt> and extending through <tt>du</tt> are decoded from the received data and are in fixed-length format. The remaining fields are in variable-length format. The fields are as follows:
<dl>
<dt><tt>s</tt></dt>
<dd>The synch indicator is initially <tt>?</tt> before the clock is set, but turns to space when all nine digits of the timecode are correctly set and the decoder is synchronized to the station within 125 &mu;s.</dd>
<dt><tt>q</tt></dt>
<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></dt>
<dd>synch alarm. The decoder is not synchronized to the station within 125 &mu;s.</dd>
<dt><tt>0x4</tt></dt>
<dd>Digit error alarm. Less than nine decimal digits were found in the last minute.</dd>
<dt><tt>0x2</tt></dt>
<dd>Error alarm. More than 40 data bit errors were found in the last minute.</dd>
<dt><tt>0x1</tt></dt>
<dd>Compare alarm. A maximum-likelihood digit failed to agree with the current associated clock digit in the last 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 marginal condition.</dd>
<dt><tt>yyyy ddd hh:mm:ss</tt></dt>
<dd>The timecode format itself is self explanatory. Since the driver latches the on-time epoch directly from the second synch pulse, the seconds fraction is always zero. Although the transmitted timecode includes only the year of century, the Gregorian year is augmented by 2000.</dd>
<dt><tt>l</tt></dt>
<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.</dd>
<dt><tt>d</tt></dt>
<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>du</tt></dt>
<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds.</dd>
<dt><tt>lset</tt></dt>
<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 decoder was last synchronized to the station within 125 &mu;s.</dd>
<dt><tt>agc</tt></dt>
<dd>The audio gain shows the current codec gain setting in the range 0 to 255. Ordinarily, the receiver audio gain control should be set for a value midway in this range.</dd>
<dt><tt>ident</tt></dt>
<dd>The station identifier shows the station, <tt>WV<i>f</i></tt> for WWV or <tt>WH<i>f</i></tt> for WWVH, and frequency <i><tt>f</tt></i> being tracked. If neither station is heard on any frequency, the reference identifier shows <tt>NONE</tt>.</dd>
<dt><tt>metric</tt></dt>
<dd>The signal metric described above from 0 (no signal) to 100 (best).</dd>
<dt><tt>errs</tt></dt>
<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 even 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 metric drops below threshold and the decoder switches to a different frequency.</dd>
<dt><tt>freq</tt></dt>
<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>avg</tt></dt>
<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>
<p><tt>0 2000 006 22:36:00 S +3 1 115 WV20 86 5 66.4 1024</tt></p>
<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. Good receiving conditions prevail, as indicated by the metric 86 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.</p>
<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.</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>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

5
html/drivers/driver37.html
View File

@ -10,6 +10,9 @@
<body>
<h3>Forum Graphic GPS Dating station</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.37.<i>u</i><br>
@ -48,4 +51,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

8
html/drivers/driver38.html
View File

@ -10,6 +10,9 @@
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<h1><font face="Arial"><i><blink><font size="5">hopf</font></blink></i><font size="+2"> </font><font size="3">Serial Line Receivers (6021 and&nbsp; kompatible)</font></font></h1>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h2><font size="+1">Synopsis</font></h2>
<table width="100%">
@ -110,7 +113,7 @@
<hr>
<h2><font size="+1">Fudge Factors</font></h2>
<dl>
<dt><b><a name="time1"></a><tt><font size="+1"><a href="#Configuration">time1 <i>time</i></a></font></tt></b>
<dt><b><tt><font size="+1">time1 <i>time</i></font></tt></b>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. Should be set to 20 milliseconds to correct serial line and operating system delays incurred in capturing time stamps from the synchronous packets.
<dt><tt><font size="+1"><a href="#REFID"><b>refid <i>string</i></b></a></font></tt>
<dd>Specifies the driver reference identifier, <b>GPS </b><i>or</i> <b>DCF</b>.
@ -123,9 +126,8 @@
<hr>
<h3>Questions or Comments:</h3>
<p><a href="mailto:altmeier@atlsoft.de">Bernd Altmeier</a><a href="http://www.ATLSoft.de"><br>Ing.-B&uuml;ro f&uuml;r Software www.ATLSoft.de</a></p>
<p>(last updated 02/28/2001)<br>&nbsp;</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

6
html/drivers/driver39.html
View File

@ -10,6 +10,9 @@
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<h1><font face="Arial"><i><blink><font size="5">hopf</font></blink></i><font size="+2"> </font><font size="3">PCI-Bus Receiver (6039 GPS/DCF77)</font></font></h1>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<div align="center">
<center>
@ -105,9 +108,8 @@
<hr>
<h3>Questions or Comments:</h3>
<p><a href="mailto:altmeier@atlsoft.de">Bernd Altmeier</a><a href="http://www.ATLSoft.de"><br>Ing.-B&uuml;ro f&uuml;r Software www.ATLSoft.de</a></p>
<p>(last updated 03/02/2001)<br>&nbsp;</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

110
html/drivers/driver4.html
View File

@ -1,108 +1,76 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Spectracom WWVB/GPS Receivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
<!--
.style1 {font-family: Symbol}
.style1 {
font-family: Symbol
}
-->
</style>
</head>
<body>
<h3>Spectracom WWVB/GPS Receivers</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate -->
UTC</p>
<hr>
Last update:
<!-- #BeginDate format:En2m -->22-Apr-2009 15:00<!-- #EndDate -->
UTC</p>
<h4>Synopsis</h4>
<p>Address: 127.127.4.<i>u</i><br>
Reference ID: <tt>WWVB</tt><br>
Driver ID: <tt>WWVB_SPEC</tt><br>
Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: Optional PPS signal processing, <tt>tty_clk</tt><br>
Requires: Optional PPS signal processing requires the PPSAPI signal interface.</p>
Reference ID: <tt>WWVB</tt><br>
Driver ID: <tt>WWVB_SPEC</tt><br>
Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: Optional PPS signal processing, <tt>tty_clk</tt><br>
Requires: Optional PPS signal processing requires the PPSAPI signal interface.</p>
<h4>Description</h4>
<p>This driver supports all known Spectracom radio and satellite clocks, including the Model 8170 and Netclock/2 WWVB Synchronized Clocks and the Netclock/GPS GPS Master Clock. The claimed accuracy of the WWVB clocks is 100 <span class="style1">m</span>s relative to the broadcast signal. These clocks have proven a reliable source of time, except in some parts of the country with high levels of conducted RF interference. WIth the GPS clock the claimed accuracy is 130 ns. However, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p>
<p>The DIPswitches on these clocks should be set to 24-hour display, AUTO DST off, data format 0 or 2 (see below) and baud rate 9600. If this clock is used as the source for the IRIG Audio Decoder (<tt>refclock_irig.c</tt> in this distribution), set the DIPswitches for AM IRIG output and IRIG format 1 (IRIG B with signature control).</p>
<p>There are two timecode formats used by these clocks. Format 0, which is available with all clocks, and format 2, which is available with all clocks except the original (unmodified) Model 8170.</p>
<p>Format 0 (22 ASCII printing characters):<br>
&lt;cr&gt;&lt;lf&gt;i ddd hh:mm:ss TZ=zz&lt;cr&gt;&lt;lf&gt;</p>
&lt;cr&gt;&lt;lf&gt;i ddd hh:mm:ss TZ=zz&lt;cr&gt;&lt;lf&gt;</p>
<p>on-time = first &lt;cr&gt;<br>
i = synchronization flag (' ' = in synch, '?' = out synch)<br>
hh:mm:ss = hours, minutes, seconds</p>
i = synchronization flag (' ' = in synch, '?' = out synch)<br>
hh:mm:ss = hours, minutes, seconds</p>
<p>The alarm condition is indicated by other than ' ' at <tt>i</tt>, which occurs during initial synchronization and when received signal is lost for about ten hours.</p>
<p>Format 2 (24 ASCII printing characters):<br>
lt;cr&gt;lf&gt;iqyy ddd hh:mm:ss.fff ld</p>
lt;cr&gt;lf&gt;iqyy ddd hh:mm:ss.fff ld</p>
<p>on-time = &lt;cr&gt;<br>
i = synchronization flag (' ' = in synch, '?' = out synch)<br>
q = quality indicator (' ' = locked, 'A'...'D' = unlocked)<br>
yy = year (as broadcast)<br>
ddd = day of year<br>
hh:mm:ss.fff = hours, minutes, seconds, milliseconds</p>
i = synchronization flag (' ' = in synch, '?' = out synch)<br>
q = quality indicator (' ' = locked, 'A'...'D' = unlocked)<br>
yy = year (as broadcast)<br>
ddd = day of year<br>
hh:mm:ss.fff = hours, minutes, seconds, milliseconds</p>
<p>The alarm condition is indicated by other than ' ' at <tt>i</tt>, which occurs during initial synchronization and when received signal is lost for about ten hours. The unlock condition is indicated by other than ' ' at <tt>q</tt>.</p>
<p>The <tt>q</tt> is normally ' ' when the time error is less than 1 ms and a character in the set <tt>A...D</tt> when the time error is less than 10, 100, 500 and greater than 500 ms respectively. The <tt>l</tt> is normally ' ', but is set to <tt>L</tt> early in the month of an upcoming UTC leap second and reset to ' ' on the first day of the following month. The <tt>d</tt> is set to <tt>S</tt> for standard time <tt>S</tt>, <tt>I</tt> on the day preceding a switch to daylight time, <tt>D</tt> for daylight time and <tt>O</tt> on the day preceding a switch to standard time. The start bit of the first &lt;cr&gt; is synchronized to the indicated time as returned.</p>
<p>This driver does not need to be told which format is in use - it figures out which one from the length of the message. A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself, which is a known problem with the older radios.</p>
<h4<PPS Signal Processing</h4>
<h4>PPS Signal Processing</h4>
<p>When PPS signal processing is enabled, and when the system clock has been set by this or another driver and the PPS signal offset is within 0.4 s of the system clock offset, the PPS signal replaces the timecode for as long as the PPS signal is active. If for some reason the PPS signal fails for one or more poll intervals, the driver reverts to the timecode. If the timecode fails for one or more poll intervals, the PPS signal is disconnected.</p>
<h4>Monitor Data</h4>
<p>The driver writes each timecode as received to the <tt>clockstats</tt> file. When enabled by the <tt>flag4</tt> fudge flag, a table of quality data maintained internally by the Netclock/2 is retrieved and written to the <tt>clockstats</tt> file when the first timecode message of a new day is received.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Specifies the serial time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWVB</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.
<dt><tt>flag2 0 | 1</tt>
<dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1.
<dt><tt>flag3 0 | 1</tt>
<dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel discipline if 1.
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Specifies the serial time offset calibration factor, 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>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWVB</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel discipline if 1.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

121
html/drivers/driver40.html
View File

@ -14,25 +14,40 @@
<body>
<h3>JJY Receivers</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->3-May-2011 00:20<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
Address: 127.127.40.<em>u</em><br>
Reference ID: <code>JJY</code><br>
Driver ID: <code>JJY</code><br>
Serial Port: <code>/dev/jjy<em>u</em></code>; 9600|4800(See corresponding receiver) baud, 8-bits, no parity, 1 stop bit
Serial Port: <code>/dev/jjy<em>u</em></code>; See corresponding receiver
<h4>Description</h4>
<p>This driver supports the following JJY receivers sold in Japan.</p>
<ul>
<li>Tristate Ltd. JJY01 <a href="http://www.tristate.ne.jp/">http://www.tristate.ne.jp/</a> (Japanese only)<br>
<li>
<p>Tristate Ltd. JJY01, JJY02 <a href="http://www.tristate.ne.jp/">http://www.tristate.ne.jp/</a> (Japanese only)</p><br>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 1</p>
<dl>
<dt>fudge &nbsp; 127.127.40.X &nbsp; flag1 0|1</dt>
<dd>
<p>Flag1 has no effect for time synchronization. When a flag1 is set to 1, status commands are issued before DATE and STIM commands, and write a response text into a clockstats file.</p>
<table border="1" summary="fudge flag1">
<tr><td>0 (Default)</td><td>DCST and STUS commands are not issued</td></tr>
<tr><td>1</td><td>DCST and STUS commands are issued</td></tr>
</table>
</dd>
</dl>
<br>
</dd>
<dt>RS-232C</dt>
<dt>Interface</dt>
<dd>
<p>9600 Baud</p>
<p>RS-232C, 9600 baud, 8-bits, no parity, 1 stop bit</p>
<br>
</dd>
<dt>Time code format</dt>
@ -44,29 +59,32 @@
<td>Reply</td>
</tr>
<tr>
<td><code>date&lt;CR&gt;&lt;LF&gt;</code></td>
<td><code>date{CR}{LF}</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>YYYY/MM/DD WWW&lt;CR&gt;&lt;LF&gt;</code></td>
<td><code>YYYY/MM/DD WWW{CR}{LF}</code></td>
</tr>
<tr>
<td><code>stim&lt;CR&gt;&lt;LF&gt;</code></td>
<td><code>stim{CR}{LF}</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>HH:MM:SS&lt;CR&gt;&lt;LF&gt;</code></td>
<td><code>HH:MM:SS{CR}{LF}</code></td>
</tr>
</table>
<br>
</dd>
</dl>
<li>C-DEX Co.,Ltd. JST2000 <a href="http://www.c-dex.co.jp/">http://www.c-dex.co.jp/</a> (Japanese only)<br>
</li>
<li>
<p>C-DEX Co.,Ltd. JST2000 <a href="http://www.c-dex.co.jp/">http://www.c-dex.co.jp/</a> (Japanese only)</p><br>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 2</p>
<br>
</dd>
<dt>RS-232C</dt>
<dt>Interface</dt>
<dd>
<p>9600 Baud</p>
<p>RS-232C, 9600 baud, 8-bits, no parity, 1 stop bit</p>
<br>
</dd>
<dt>Time code format</dt>
@ -78,25 +96,27 @@
<td>Reply</td>
</tr>
<tr>
<td><code>&lt;ENQ&gt;1J&lt;ETX&gt;</code></td>
<td><code>{ENQ}1J{ETX}</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>&lt;STX&gt;JYYMMDD HHMMSSS&lt;ETX&gt;</code></td>
<td><code>{STX}JYYMMDD HHMMSSS{ETX}</code></td>
</tr>
</table>
<br>
</dd>
</dl>
</li>
<li>
<p>Echo Keisokuki Co.,Ltd. LT-2000 <a href="http://www.clock.co.jp/">http://www.clock.co.jp/</a> (Japanese only)</p>
<p>Echo Keisokuki Co.,Ltd. LT-2000 <a href="http://www.clock.co.jp/">http://www.clock.co.jp/</a> (Japanese only)</p><br>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 3</p>
<br>
</dd>
<dt>RS-232C</dt>
<dt>Interface</dt>
<dd>
<p>9600 Baud</p>
<p>RS-232C, 9600 baud, 8-bits, no parity, 1 stop bit</p>
<br>
</dd>
<dt>Time code format</dt>
@ -115,7 +135,7 @@
<tr>
<td>( Every second before 0.5 second )</td>
<td></td>
<td><code>YYMMDDWHHMMSS&lt;ST1&gt;&lt;ST2&gt;&lt;ST3&gt;&lt;ST4&gt;&lt;CR&gt;</code></td>
<td><code>YYMMDDWHHMMSS{ST1}{ST2}{ST3}{ST4}{CR}</code></td>
</tr>
<tr>
<td><code>#</code></td>
@ -126,17 +146,19 @@
<br>
</dd>
</dl>
</li>
<li>
<p>CITIZEN T.I.C. CO.,LTD. JJY-200 <a href="http://www.tic-citizen.co.jp/">http://www.tic-citizen.co.jp/</a> (Japanese only)</p>
<p>CITIZEN T.I.C. CO.,LTD. JJY-200 <a href="http://www.tic-citizen.co.jp/">http://www.tic-citizen.co.jp/</a> (Japanese only)</p><br>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 4</p>
<br>
</dd>
<dt>RS-232C</dt>
<dt>Interface</dt>
<dd>
<p>4800 Baud</p>
<p>RS-232C, 4800 baud, 8-bits, no parity, 1 stop bit</p>
<br>
</dd>
<dt>Time code format</dt>
@ -150,16 +172,69 @@
<tr>
<td>( Every second )</td>
<td></td>
<td><code>'XX YY/MM/DD W HH:MM:SS&lt;CR&gt;</code></td>
<td><code>'XX YY/MM/DD W HH:MM:SS{CR}</code></td>
</tr>
</table>
<br>
</dd>
</dl>
</li>
<li>
<p>Tristate Ltd. TS-GPSclock-01 <a href="http://www.tristate.ne.jp/">http://www.tristate.ne.jp/</a> (Japanese only)</p>
<p>This driver supports the Tristate TS-GPSclock-01 in command/response mode, though it is a GPS clock, not JJY radio clock. Using the menus and the onboard switches, the TS-GPSclock-01 should be set to command/response mode and JST time zone.<br>
Besides this driver ( Type 40 ), <a href="driver20.html">the generic NMEA GPS driver ( Type 20 )</a> supports the TS-GPSclock-01 in NMEA mode.</p>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 5</p>
<dl>
<dt>fudge &nbsp; 127.127.40.X &nbsp; flag1 0|1</dt>
<dd>
<p>Flag1 has no effect for time synchronization. When a flag1 is set to 1, status command is issued before DATE and TIME commands, and write a response text into a clockstats file.</p>
<table border="1" summary="fudge flag1">
<tr><td>0 (Default)</td><td>STUS command is not issued</td></tr>
<tr><td>1</td><td>STUS command is issued</td></tr>
</table>
</dd>
</dl>
<br>
</dd>
<dt>Interface</dt>
<dd>
<p>USB ( /dev/ttyACM<em>0</em> )</p>
<br>
</dd>
<dt>Time code format</dt>
<dd><br>
<table summary="CommandAndReply">
<tr>
<td>Command</td>
<td>&nbsp;--&gt;&nbsp;</td>
<td>Reply</td>
</tr>
<tr>
<td><code>date{CR}{LF}</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>YYYY/MM/DD{CR}{LF}</code></td>
</tr>
<tr>
<td><code>time{CR}{LF}</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>HH:MM:SS{CR}{LF}</code></td>
</tr>
</table>
<br>
</dd>
</dl>
</li>
</ul>
<p>JJY is the radio station which transmites the JST (Japan Standard Time) in long wave radio. The station JJY is operated by the National Institute of Information and Communications Technology. An operating announcement and some information are avaiable from <a href="http://www.nict.go.jp/">http://www.nict.go.jp/</a> (English and Japanese) and <a href="http://jjy.nict.go.jp/">http://jjy.nict.go.jp/</a> (English and Japanese)</p>
<p>The user is expected to provide a symbolic link to an available serial port device. This is typically performed by a command such as:</p>
<p>The user is expected to provide a symbolic link to an available serial port device. This is typically performed by a command such as;</p>
<p><code>ln -s /dev/ttyS0 /dev/jjy0</code></p>
<p>Using RS232C to USB converter cable, the clock can be connected to an USB port instead of a serial port. In this case, typical symbolic link command is as follows;
<p><code>ln -s /dev/ttyUSB0 /dev/jjy0</code></p>
<p>Windows NT does not support symbolic links to device files. COM<em>X</em>: is the unit used by the driver, based on the refclock unit number, where unit 1 corresponds to COM1: and unit 3 corresponds to COM3:</p>
<h4>Monitor Data</h4>
<p>The driver writes each timecode as received to the <code>clockstats</code> file.</p>
@ -174,7 +249,7 @@
<dt><code>refid <em>string</em></code>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <code>JJY</code>.
<dt><code>flag1 0 | 1</code>
<dd>Not used by this driver.
<dd>See corresponding receiver.
<dt><code>flag2 0 | 1</code>
<dd>Not used by this driver.
<dt><code>flag3 0 | 1</code>

5
html/drivers/driver42.html
View File

@ -10,6 +10,9 @@
<body>
<h3>Zyfer GPStarplus Receiver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
Address: 127.127.42.<i>u</i><br>
@ -27,4 +30,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

5
html/drivers/driver43.html
View File

@ -10,6 +10,9 @@
<body>
<h3>RIPE NCC interface for Trimble Palisade</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<img src="../pic/driver43_2.jpg" alt="Trimble Acutime 2000" align="right">
<h4>Synopsis</h4>
@ -62,4 +65,4 @@ S1 [prn] [channel] [aqflag] [ephstat] [snr] [azinuth] [elevation]
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

5
html/drivers/driver44.html
View File

@ -11,6 +11,9 @@
<body>
<h1>NeoClock4X - DCF77 / TDF serial line receiver<br>
</h1>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr size="2" width="100%">
<h2>Synopsis</h2>
<table width="100%">
@ -85,4 +88,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

32
html/drivers/driver45.html Normal file
View File

@ -0,0 +1,32 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Spectracom TSYNC PCI</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Spectracom TSYNC PCI</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->26-Mar-2012 05:10<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
Address: 127.127.45.<i>u</i><br>
Reference ID: one of <tt>GPS</tt>, <tt>IRIG</tt>, <tt>HVQ</tt>, <tt>FREQ</tt>, <tt>ACTS</tt>, <tt>PPS</tt>, <tt>PTP</tt>, <tt>ACT</tt>, <tt>USR</tt>, <tt>LOCL</tt><br>
Driver ID: <tt>Spectracom TSYNC PCI</tt><br>
Driver Port: <tt>/dev/tsyncpci<i>u</i></tt>
Features: <tt>(none)</tt>
<h4>Description</h4>
<p>This driver supports the <a
href="http://www.spectracomcorp.com/ProductsServices/TimingSynchronization/BuslevelTiming">Spectracom TSYNC PCI</a> receiver.</p>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

184
html/drivers/driver46.html Normal file
View File

@ -0,0 +1,184 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="Content-Type"
content="text/html;charset=iso-8859-1"><title>GPSD-NG client driver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
<style type="text/css">
table.dlstable { font-size:85%; }
td.ttf{ font-family:Courier; font-weight:bold; }
</style></head>
<body>
<h3>GPSD NG client driver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->1-Mar-2014 03:48<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>
Address: 127.127.46.<i>u</i><br>
Reference ID: <tt>GPSD</tt><br>
Driver ID: <tt>GPSD_JSON</tt><br>
Serial Port: <tt>/dev/gps<i>u</i></tt> as symlink to the true
device (not used directly; see below)<br>
Features: <tt></tt>
</p>
<h4>Description</h4>
<p>
This driver is a client driver to the <i>GPSD</i> daemon, which
over the time became increasingly popular for UN*Xish
platforms. <i>GPSD</i> can manage several devices in parallel,
aggregate information, and acts as a data hub for client
applications. <i>GPSD</i> can also auto-detect and handle PPS
hardware signals on serial ports. Have a look
at <a href="http://www.catb.org/gpsd/">the
<i>GPSD</i> project page</a>.
</p>
<p>
<b>It is important to understand that this driver works best
using a GPS device with PPS support.</b>
</p>
<p>
The GPSD-NG protocol is text based, using JSON notation to
transfer records in form of JSON objects. The driver uses a
TCP/IP connection to <tt>localhost:gpsd</tt> to connect to the
daemon and then requests the GPS
device <tt>/dev/gps<i>u</i></tt> to be watched. (Different clock
units use different devices, and
<i>GPSD</i> is able to give only the relevant information to a clock
instance.)
</p>
<p>
This driver does not expect <i>GPSD</i> to be running or the
clock device to be present <i>a priori</i>; it will try to
re-establish a lost or hitherto unsuccessful connection and will
wait for device to come up in <i>GPSD.</i> There is an initial
10 seconds delay between a connection loss or failed attempt and
the next reconnect attempt; this makes sure that there is no
thrashing on the network layer. If the connection fails again,
an exponential back off is used with an upper limit of
approximately 10 minutes.
</p>
<p>
The overall accuracy depends on the receiver used. The driver
uses the error estimations (95% probability limits) provided by
<i>GPSD</i> to set the clock precision dynamically according to these
readings.
</p>
<p>
The driver needs the VERSION, TPV, PPS and WATCH objects of
the <i>GPSD</i> protocol. (Others are quietly ignored.)
</p>
<h4>Naming a Device</h4>
<p>
The <i>GPSD</i> driver uses the same name as the NMEA driver,
namely <tt>/dev/gps<i>u</i></tt>. There is a simple reason for
that: While the NMEA driver and the <i>GPSD</i> driver can be
active at the same time <b>for different devices</b>,
they cannot access the same device at a time. Having the same
name helps on that. It also eases migration from using NMEA
directly to using <i>GPSD</i>, as no new links etc need to be
created.
</p>
<p>
<i>GPSD</i> is normally started with the device name to access;
it can also be instructed by hot-plug scripts to add or remove
devices from its device pool. Luckily, the symlinks used by the
NMEA driver are happily accepted and used by <i>GPSD</i>; this
makes it possible to use the symlink names as device
identification. This makes the migration from the built-in NMEA
driver a bit easier.
</p>
<p><b>Note:</b> <i>GPSD</i> (as of version 3.10) cannot
use kernel mode PPS on devices that are hot-plugged. This would
require to attach the PPS line discipline to the file, which is
not possible when running with root privileges dropped. This is
not likely to change in the future.
</p>
<h4>The 'mode' byte</h4>
<p>
A few operation modes can be selected with the mode word.
</p>
<p>
<table border="1" frame="box" rules="all">
<th colspan="3">The Mode Word</th>
<tr> <td>Bits</td><td>Value</td><td>Description</td>
</tr>
<tr> <td rowspan="4"align="center">0..1</td><td align="center">0</td>
<td>Uses TPV to get absolute time stamps for full
synchronization. If PPS is available , it is used to improve
the precision, but the clock can work without it.</td>
</tr>
<tr><td align="center">1</td>
<td>Require TPV <b>and</b> PPS to work.</td>
</tr>
<tr><td align="center">2</td>
<td>Ignore PPS data, run on TPV only. This is not a
recommended mode unless the serial timing is very stable
and GPSD provides an information element in TPV that
indicates the receive time of the fix data.</td>
</tr>
<tr><td align="center">3</td>
<td>PPS-only mode. Ignores TPV and does only the PPS phase
correction. This means that some other source must get NTPD
close to synchronisation; only after that happened and the
phase shift between the system clock and the PPS pulse is
less than 125msec the PPS lock will be engaged.</td>
</tr>
<tf colspan="3"><b>IMPORTANT: work in progress, mode
word ignored right now. Fixed mode '0' operation.</b></tf>
</table>
</p>
<h4>Syslog flood throttle</h4>
<p>This driver can create a lot of syslog messages when things go
wrong, and cluttering the log files is frowned upon. So we attempt
to log persistent or recurring errors only once per hour. On the
other hand, when tracking a problem the syslog flood throttle can
get into the way.</p>
<p>Therefore, fudge <i>flag3</i> can be used to <i>disable</i> the
flood throttle at any time; the throttle is engaged by
default. Running with the syslog flood throttle disabled for
lengthy time is not recommended unless the log files are closely
monitored.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the PPS time offset calibration factor, in seconds
and fraction, with default 0.0.</dd>
<dt><a name="fudgetime2"><tt>time2 <i>time</i></tt></a></dt>
<dd>Specifies the TPV time offset calibration factor, 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>Specifies the driver reference identifier, an ASCII string
from one to four characters, with default <tt>GPSD</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt><dd><i>(not used)</i></dd>
<dt><tt>flag2 0 | 1</tt></dt><dd><i>(not used)</i></dd>
<dt><tt>flag3 0 | 1</tt></dt><dd>If set, <i>disable</i> the
log throttle. Useful when tracking problems in the interaction
between <i>GPSD</i> and <i>NTPD</i>, since now all error
events are logged. Persistent/recurrent errors can easily fill
up the log, so this should only be enabled during bug
hunts.</dd>
<dt><tt>flag4 0 | 1</tt></dt><dd>If set, write a clock stats
line on every poll cycle.</dd>
</dl>
<p>Additional Information</p>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body></html>

143
html/drivers/driver5.html
View File

@ -2,71 +2,82 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>TrueTime GPS/GOES/OMEGA Receivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<title>TrueTime GPS/GOES/OMEGA/WWV Receivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>TrueTime GPS/GOES/OMEGA Receivers</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.5.<i>u</i><br>
Reference ID: <tt>GPS, OMEGA, GOES</tt><br>
Driver ID: <tt>TRUETIME</tt><br>
Serial Port: <tt>/dev/true<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt>
<h4>Description</h4>
<p>This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, and very likely others in the same model family that use the same timecode formats.</p>
<p>Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.</p>
<p>Timcode format: <tt>ADDD:HH:MM:SSQCL</tt> A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed Quality codes indicate possible error of</p>
<dl>
<dt>468-DC GOES Receiver<br>
GPS-TM/TMD Receiver
<dd>? +/- 500 milliseconds # +/- 50 milliseconds<br>
* +/- 5 milliseconds . +/- 1 millisecond<br>
space less than 1 millisecond
<dt>OM-DC OMEGA Receiver:
<dd>&gt; +/- 5 seconds<br>
? +/- 500 milliseconds # +/- 50 milliseconds<br>
* +/- 5 milliseconds . +/- 1 millisecond<br>
A-H less than 1 millisecond. Character indicates which station is being received as follows<br>
A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan<br>
The carriage return start bit begins on 0 seconds and extends to 1 bit time.
</dl>
<h4>Notes on 468-DC and OMEGA receiver:</h4>
<p>Send the clock a <tt>R</tt> or <tt>C</tt> and once per second a timestamp will appear. Send a <tt>R</tt> to get the satellite position once (GOES only).</p>
<h4>Notes on the 468-DC receiver:</h4>
<p>Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line</p>
<p><tt>fudge 127.127.5.0 time1 +0.008 time2 -0.004</tt></p>
<p>This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.</p>
<p>The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)</p>
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, to be used for the West satellite, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, with default 0.0.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>TRUE</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Silence the clock side of ntpd, just reading the clock without trying to write to it.
<dt><tt>flag2 0 | 1</tt>
<dd>Generate a debug file /tmp/true%d.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Not used by this driver.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<body>
<h3>TrueTime GPS/GOES/OMEGA/WWV Receivers</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.5.<i>u</i><br>
Reference ID: <tt>GPS, OMEGA, GOES, WWV</tt><br>
Driver ID: <tt>TRUETIME</tt><br>
Serial Port: <tt>/dev/true<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt>
<h4>Description</h4>
<p>This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, the TL-3 WWV receiver, and very likely others in the same model families that use the same timecode formats.</p>
<p>Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.</p>
<p>Timcode format: <tt>ADDD:HH:MM:SSQCL</tt><br>
A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed</p><br>
Quality codes indicate possible error of:
<dl>
<dt>468-DC GOES Receiver<br>
GPS-TM/TMD Receiver
<dd>? +/- 500 milliseconds # +/- 50 milliseconds<br>
* +/- 5 milliseconds . +/- 1 millisecond<br>
space less than 1 millisecond
<dt>OM-DC OMEGA Receiver:
<dd>&gt; +/- 5 seconds<br>
? +/- 500 milliseconds # +/- 50 milliseconds<br>
* +/- 5 milliseconds . +/- 1 millisecond<br>
A-H less than 1 millisecond. Character indicates which station is being received as follows<br>
A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan<br>
The carriage return start bit begins on 0 seconds and extends to 1 bit time.
<dt>TL-3 WWV Receiver:
<dd>? receiver is unlocked<br>
<dd>space +/- 5 milliseconds<br>
</dl>
<h4>Notes on 468-DC and OMEGA receiver:</h4>
<p>Send the clock a <tt>R</tt> or <tt>C</tt> and once per second a timestamp will appear. Send a <tt>R</tt> to get the satellite position once (GOES only).</p>
<h4>Notes on the 468-DC receiver:</h4>
<p>Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line</p>
<p><tt>fudge 127.127.5.0 time1 +0.008 time2 -0.004</tt></p>
<p>This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.</p>
<p>The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)</p>
<h4>Notes on the TL-3 receiver:</h4>
<p>The mini-DIN RS-232 port uses the Apple pinout.<br>
Send the clock ST1 to turn on continuous (1/sec) timecodes.
You can also enable "mode C" via the front panel. ST0 turns off this mode.<br>
QV will return the firmware revision (and is useful in identifying this clock.)<br>
QW will return its weekly signal log, useful if you're testing antennas. You may wish to turn the loss interval down from 4h (04) to 1h (01), so the receiver declares itself unlocked sooner. When in holdover, drift can be on the order of 10 ms/hr since there is no high quality reference oscillator.</p>
<h4>Monitor Data</h4>
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, to be used for the West satellite, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, with default 0.0.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>TRUE</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Silence the clock side of ntpd, just reading the clock without trying to write to it.
<dt><tt>flag2 0 | 1</tt>
<dd>Generate a debug file /tmp/true%d.
<dt><tt>flag3 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
<h4>Additional Information</h4>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

152
html/drivers/driver6.html
View File

@ -1,76 +1,80 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>IRIG Audio Decoder</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</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>
<h4>Description</h4>
<p>This driver synchronizes the computer time using the Inter-Range Instrumentation Group (IRIG) standard time distribution signal. This signal is generated by several radio clocks, including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom, Symmetricom and TrueTime, among others, although it is often an add-on option. The signal is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC.</p>
<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation, only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 250 PPM (.025 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
<p>For proper operation the IRIG signal source should be configured for analog signal levels, not digital TTL levels. In most radios the IRIG signal is driven &plusmn;10 V behind 50 Ohms. In such cases the cable should be terminated at the line-in port with a 50-Ohm resistor to avoid overloading the codec. 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 automatically rejects the data and declares itself unsynchronized in this case. Some devices, in particular Spectracom radio/satellite clocks, provide additional year and status indication; other devices may not.</p>
<p>In general and without calibration, the driver is accurate within 500 <font face="symbol">m</font>s relative to the IRIG time. After calibrating relative to the PPS&nbsp;signal from a GPS&nbsp;receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is less than 20 <font face="symbol">m</font>s with standard deviation 10 <font face="symbol">m</font>s. Most of this is due to residuals after filtering and averaging the raw codec samples, which have an inherent jitter of 125 <font face="symbol">m</font>s. The processor load due to the driver is 0.6 percent on the P4.</p>
<p>However, be acutely aware that the accuracy with Solaris 2.8 and beyond has been seriously degraded to the order of several milliseconds. The Sun kernel driver has a sawtooth modulation with amplitude over 5 ms P-P and period 5.5 s. This distortion is especially prevalent with Sun Blade 1000 and possibly other systems.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver36.html">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.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
<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 processor load with older workstations. Generally, the accuracy with IRIG-E is about ten times worse than IRIG-B, but the processor load is somewhat less. Technical details about the IRIG&nbsp;formats can be found in <a href="http://handle.dtic.mil/100.2/ADA346250">IRIG Standard 200-98</a>.</p>
<p>The driver processes 8000-Hz <font face="symbol">m</font>-law companded samples using separate signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector and automatic threshold corrector. An infinite impulse response (IIR) 1000-Hz bandpass filter is used for IRIG-B and an IIR 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.</p>
<p>Cycle crossings relative to the corrected slice level determine the width of each pulse and its value - zero, one or position identifier (PI). The data encode ten characters (20 BCD digits) which determine the second, minute, hour and day of the year and with some IRIG&nbsp;generators 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.</p>
<p>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 median filter and used to update the system clock.</p>
<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. The driver produces one line for each timecode in the following format:
<p><tt>00 00 98 23 19:26:52 2782 143 0.694 10 0.3 66.5 3094572411.00027</tt></p>
<p>If clockstats is enabled, the most recent line is written to the clockstats file every 64 s. If verbose recording is enabled (fudge flag 4) each line is written as generated.</p>
<p>The first field containes the error flags in hex, where the hex bits are interpreted as below. This is followed by the year of century, day of year and time of day. Note that the time of day is for the previous minute, not the current time. The status indicator and year are not produced by some IRIG devices and appear as zeros. Following these fields are the carrier amplitude (0-3000), codec gain (0-255), modulation index (0-1), time constant (4-10), carrier phase error (0&plusmn;0.5) and carrier frequency error (PPM). The last field is the on-time timestamp in NTP format.</p>
<p>The error flags are defined as follows in hex:</p>
<dl>
<dt><tt>x01</tt>
<dd>Low signal. The carrier amplitude is less than 100 units. This is usually the result of no signal or wrong input port.
<dt><tt>x02</tt>
<dd>Frequency error. The codec frequency error is greater than 250 PPM. This may be due to wrong signal format or (rarely) defective codec.
<dt><tt>x04</tt>
<dd>Modulation error. The IRIG modulation index is less than 0.5. This is usually the result of an overdriven codec, wrong signal format or wrong input port.
<dt><tt>x08</tt>
<dd>Frame synch error. The decoder frame does not match the IRIG frame. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal. It may also be the result of an IRIG signature check which indicates a failure of the IRIG signal synchronization source.
<dt><tt>x10</tt>
<dd>Data bit error. The data bit length is out of tolerance. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal.
<dt><tt>x20</tt>
<dd>Seconds numbering discrepancy. The decoder second does not match the IRIG second. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal.
<dt><tt>x40</tt>
<dd>Codec error (overrun). The machine is not fast enough to keep up with the codec.
<dt><tt>x80</tt>
<dd>Device status error (Spectracom).
</dl>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>IRIG</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<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.
<dt><tt>flag3 0 | 1</tt>
<dd>Enables audio monitoring of the input signal. For this purpose, the speaker volume must be set before the driver is started.
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>IRIG Audio Decoder</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>IRIG Audio Decoder</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->17-Jul-2014 02:17<!-- #EndDate -->
UTC</p>
<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>
<h4>Description</h4>
<p>This driver synchronizes the computer time using the Inter-Range Instrumentation Group (IRIG) standard time distribution signal. This signal is generated by several radio clocks, including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom, Symmetricom and TrueTime, among others, although it is often an add-on option. The signal is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC.</p>
<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and &mu;-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation, only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 250 PPM (.025 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
<p>For proper operation the IRIG signal source should be configured for analog signal levels, not digital TTL levels. In most radios the IRIG signal is driven &plusmn;10 V behind 50 Ohms. In such cases the cable should be terminated at the line-in port with a 50-Ohm resistor to avoid overloading the codec. 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 automatically rejects the data and declares itself unsynchronized in this case. Some devices, in particular Spectracom radio/satellite clocks, provide additional year and status indication; other devices may not.</p>
<p>In general and without calibration, the driver is accurate within 500 &mu;s relative to the IRIG time. After calibrating relative to the PPS&nbsp;signal from a GPS&nbsp;receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is less than 20 &mu;s with standard deviation 10 &mu;s. Most of this is due to residuals after filtering and averaging the raw codec samples, which have an inherent jitter of 125 &mu;s. The processor load due to the driver is 0.6 percent on the P4.</p>
<p>However, be acutely aware that the accuracy with Solaris 2.8 and beyond has been seriously degraded to the order of several milliseconds. The Sun kernel driver has a sawtooth modulation with amplitude over 5 ms P-P and period 5.5 s. This distortion is especially prevalent with Sun Blade 1000 and possibly other systems.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver36.html">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.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
<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 processor load with older workstations. Generally, the accuracy with IRIG-E is about ten times worse than IRIG-B, but the processor load is somewhat less. Technical details about the IRIG&nbsp;formats can be found in <a href="http://handle.dtic.mil/100.2/ADA346250">IRIG Standard 200-98</a>.</p>
<p>The driver 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. An infinite impulse response (IIR) 1000-Hz bandpass filter is used for IRIG-B and an IIR 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.</p>
<p>Cycle crossings relative to the corrected slice level determine the width of each pulse and its value - zero, one or position identifier (PI). The data encode ten characters (20 BCD digits) which determine the second, minute, hour and day of the year and with some IRIG&nbsp;generators 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.</p>
<p>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 median filter and used to update the system clock.</p>
<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. The driver produces one line for each timecode in the following format:
<p><tt>00 00 98 23 19:26:52 2782 143 0.694 10 0.3 66.5 3094572411.00027</tt></p>
<p>If clockstats is enabled, the most recent line is written to the clockstats file every 64 s. If verbose recording is enabled (fudge flag 4) each line is written as generated.</p>
<p>The first field containes the error flags in hex, where the hex bits are interpreted as below. This is followed by the year of century, day of year and time of day. Note that the time of day is for the previous minute, not the current time. The status indicator and year are not produced by some IRIG devices and appear as zeros. Following these fields are the carrier amplitude (0-3000), codec gain (0-255), modulation index (0-1), time constant (4-10), carrier phase error (0&plusmn;0.5) and carrier frequency error (PPM). The last field is the on-time timestamp in NTP format.</p>
<p>The error flags are defined as follows in hex:</p>
<dl>
<dt><tt>x01</tt></dt>
<dd>Low signal. The carrier amplitude is less than 100 units. This is usually the result of no signal or wrong input port.</dd>
<dt><tt>x02</tt></dt>
<dd>Frequency error. The codec frequency error is greater than 250 PPM. This may be due to wrong signal format or (rarely) defective codec.</dd>
<dt><tt>x04</tt></dt>
<dd>Modulation error. The IRIG modulation index is less than 0.5. This is usually the result of an overdriven codec, wrong signal format or wrong input port.</dd>
<dt><tt>x08</tt></dt>
<dd>Frame synch error. The decoder frame does not match the IRIG frame. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal. It may also be the result of an IRIG signature check which indicates a failure of the IRIG signal synchronization source.</dd>
<dt><tt>x10</tt></dt>
<dd>Data bit error. The data bit length is out of tolerance. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal.</dd>
<dt><tt>x20</tt></dt>
<dd>Seconds numbering discrepancy. The decoder second does not match the IRIG second. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal.</dd>
<dt><tt>x40</tt></dt>
<dd>Codec error (overrun). The machine is not fast enough to keep up with the codec.</dd>
<dt><tt>x80</tt></dt>
<dd>Device status error (Spectracom).</dd>
</dl>
<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>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>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

253
html/drivers/driver7.html
View File

@ -1,65 +1,67 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Radio CHU Audio Demodulator/Decoder</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</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>
Modem Port: <tt>/dev/chu<i>u</i></tt>; 300 baud, 8-bits, no parity<br>
Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no parity<br>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
<p>This driver synchronizes the computer time using shortwave radio transmissions
from Canadian time/frequency station <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/shortwave_broadcasts_e.html">CHU</a> in
Ottawa, Ontario. CHU transmissions are made continuously on 3.330,
7.850 and 14.670 MHz 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 season.</p>
<p>The driver can be compiled to use either an audio codec or soundcard, or a Bell 103-compatible, 300-b/s modem or modem chip, as described on the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. If compiled for a modem, the driver uses it to receive the radio signal and demodulate the data. If compiled for the audio codec, it requires a sampling rate of 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC. In this implementation, only one audio driver and codec can be supported on a single machine.</p>
<p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 625 km from the transmitter, the predicted one-hop propagation delay varies from 2.8 ms in sunlight to 2.6 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p>
<p>After calibration relative to the PPS&nbsp;signal from a GPS&nbsp;receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.2 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.html">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.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
<p>The driver processes 8-kHz <font face="symbol">m</font>-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. The single format B burst is considered correct only if every character matches its repetition in the burst. For the eight format A bursts, a majority decoder requires more than half of the 16 repetitions for each digit decode to the same value. Every character in every burst provides an independent timestamp upon arrival with a potential total of 60 timestamps for each minute.</p>
<p>The CHU timecode format is described on the <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/chu_e.html">CHU website</a>. A timecode is assembled when all bursts have been received in each minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the majority decoder declares success. Once the driver has synchronized for the first time, it will appear reachable and selectable to discipline the system clock. It is normal on occasion to miss a minute or two due to signal fades or noise. If eight successive minutes are missed, the driver is considered unreachable and the system clock will free-wheel at the latest determined frequency offset. 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 with long intervals between updates, it is unlikely that the system clock will drift more than a few milliseconds during periods of signal loss.</p>
<h4>Baseband Signal Processing</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). It consists of a 500-Hz bandpass filter centered on 2125 Hz followed by a limiter/discriminator and raised-cosine lowpass filter optimized for the 300-b/s data rate. </p>
<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 from the DSP modem is shifted into the corresponding register and the maximum and minimum over all 11 samples computed. This establishes a span (difference) and slice level (average) over all 11 stages. For each stage, a signal level above the slice is a mark (1) and below that 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 start bit (space), eight arbitrary information bits and two stop bits (mark).</p>
<p>The shift registers are processed in round-robin order as the phases of each bit arrive. At the end of each bit all eight phases are searched for valid framing bits, sufficient span and best metric. The best candidate found in this way represents the maximum-likelihood character. The process then continues for all ten characters in the burst.</p>
<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>
<p>A valid burst consists of ten characters in two replicated five-character blocks, each block representing ten 4-bit BCD digits. The format B blocks sent in second 31 contain the year and other information in ten digits. The eight format A blocks sent in seconds 32-39 contain the timecode in ten 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 codes to correct the discrepancy, either one character early or one character late.</p>
<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 burst 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>
<h4>Majority Decoder</h4>
<p>Each minute of transmission includes eight format A bursts containing two timecodes for each second from 32 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 burst must match and the value must be in the range 2-9 and greater than in the previous burst.</p>
<p>As each 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 the minute, each row of the decoding matrix encodes the number of occurrences of each code found at the corresponding position.</p>
<p>The maximum over all occurrences at each digit position is the distance for that position and the corresponding code is the maximum-likelihood digit. If the distance is not more than half the total number of occurrences, the decoder assumes a soft error and discards all information collected during the minute. The decoding distance is defined as the sum of the distances over the first nine digits; the tenth digit varies over the seconds and is uncounted.</p>
<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>
<p>If the timecode is valid, it is passed to the reference clock interface along with the backdated timestamps accumulated over the minute. A perfect set of eight bursts could generate as many as 80 timestamps, but the maximum the interface can handle is 60. These are processed using a median filter and trimmed-mean average, so the resulting system clock correction is usually much better than would otherwise be the case with radio noise, UART jitter and occasional burst errors.</p>
<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. Further details are on the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will tune the radio to 3.331 MHz. The 1-kHz offset is useful with a narrowband SSB&nbsp;filter where the passband includes the carrier and modem signals. 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 is inoperative, the driver continues in single-frequency mode.</p>
<p>As long as no bursts are received, the driver cycles over the three frequencies in turn, one minute for each station. When bursts are received from one or more stations, the driver operates in a five-minute cycle. During the first four minutes it tunes to the station with the highest metric. During the last minute it alternates between the other two stations in turn in order to measure the metric.</p>
<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>
<p>With debugging enabled the driver produces messages in the following formats: A single message beginning with <tt>chuB</tt> is produced for each format B burst received in second 31, while eight messages beginning with <tt>chuA</tt> are produced for each format A burst received in seconds 32 through 39 of the minute. The first four fields are</p>
<p><tt>stat sig n b</tt></p>
<p>where <tt>stat</tt> is the status code, <tt>sig</tt> the character span, <tt>n</tt> the number of characters in the burst (9-11) and <tt>b</tt> the burst distance (0-40). Good bursts will have spans of a 800 or more and the other numbers near the top of the range specified. See the source for the interpretation of the remaining data in the burst. Note that each character of the burst is encoded as two digits in nibble-swapped order.</p>
<p>If the CI-V interface for ICOM radios is active, a debug level greater than 1 will produce a trace of the CI-V command and response messages. Interpretation of these messages requires knowledge of the CI-V protocol, which is beyond the scope of this document.</p>
<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>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Radio CHU Audio Demodulator/Decoder</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Radio CHU Audio Demodulator/Decoder</h3>
<p>Author: David L. Mills (mills@udel.edu)<br>
Last update:
<!-- #BeginDate format:En2m -->17-Jul-2014 02:17<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
Address: 127.127.7.<i>u</i><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>; 1200/9600 baud, 8-bits, no parity<br>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
<p>This driver synchronizes the computer time using shortwave radio transmissions
from Canadian time/frequency station <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/shortwave_broadcasts_e.html">CHU</a> in
Ottawa, Ontario. CHU transmissions are made continuously on 3.330,
7.850 and 14.670 MHz 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 season.</p>
<p>The driver can be compiled to use either an audio codec or soundcard, or a Bell 103-compatible, 300-b/s modem or modem chip, as described on the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. If compiled for a modem, the driver uses it to receive the radio signal and demodulate the data. If compiled for the audio codec, it requires a sampling rate of 8 kHz and &mu;-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC. In this implementation, only one audio driver and codec can be supported on a single machine.</p>
<p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 625 km from the transmitter, the predicted one-hop propagation delay varies from 2.8 ms in sunlight to 2.6 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p>
<p>After calibration relative to the PPS&nbsp;signal from a GPS&nbsp;receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.2 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.html">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.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
<p>The driver processes 8-kHz &mu;-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. The single format B burst is considered correct only if every character matches its repetition in the burst. For the eight format A bursts, a majority decoder requires more than half of the 16 repetitions for each digit decode to the same value. Every character in every burst provides an independent timestamp upon arrival with a potential total of 60 timestamps for each minute.</p>
<p>The CHU timecode format is described on the <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/chu_e.html">CHU website</a>. A timecode is assembled when all bursts have been received in each minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the majority decoder declares success. Once the driver has synchronized for the first time, it will appear reachable and selectable to discipline the system clock. It is normal on occasion to miss a minute or two due to signal fades or noise. If eight successive minutes are missed, the driver is considered unreachable and the system clock will free-wheel at the latest determined frequency offset. 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 with long intervals between updates, it is unlikely that the system clock will drift more than a few milliseconds during periods of signal loss.</p>
<h4>Baseband Signal Processing</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). It consists of a 500-Hz bandpass filter centered on 2125 Hz followed by a limiter/discriminator and raised-cosine lowpass filter optimized for the 300-b/s data rate. </p>
<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 from the DSP modem is shifted into the corresponding register and the maximum and minimum over all 11 samples computed. This establishes a span (difference) and slice level (average) over all 11 stages. For each stage, a signal level above the slice is a mark (1) and below that 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 start bit (space), eight arbitrary information bits and two stop bits (mark).</p>
<p>The shift registers are processed in round-robin order as the phases of each bit arrive. At the end of each bit all eight phases are searched for valid framing bits, sufficient span and best metric. The best candidate found in this way represents the maximum-likelihood character. The process then continues for all ten characters in the burst.</p>
<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>
<p>A valid burst consists of ten characters in two replicated five-character blocks, each block representing ten 4-bit BCD digits. The format B blocks sent in second 31 contain the year and other information in ten digits. The eight format A blocks sent in seconds 32-39 contain the timecode in ten 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 codes to correct the discrepancy, either one character early or one character late.</p>
<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 burst 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>
<h4>Majority Decoder</h4>
<p>Each minute of transmission includes eight format A bursts containing two timecodes for each second from 32 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 burst must match and the value must be in the range 2-9 and greater than in the previous burst.</p>
<p>As each 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 the minute, each row of the decoding matrix encodes the number of occurrences of each code found at the corresponding position.</p>
<p>The maximum over all occurrences at each digit position is the distance for that position and the corresponding code is the maximum-likelihood digit. If the distance is not more than half the total number of occurrences, the decoder assumes a soft error and discards all information collected during the minute. The decoding distance is defined as the sum of the distances over the first nine digits; the tenth digit varies over the seconds and is uncounted.</p>
<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>
<p>If the timecode is valid, it is passed to the reference clock interface along with the backdated timestamps accumulated over the minute. A perfect set of eight bursts could generate as many as 80 timestamps, but the maximum the interface can handle is 60. These are processed using a median filter and trimmed-mean average, so the resulting system clock correction is usually much better than would otherwise be the case with radio noise, UART jitter and occasional burst errors.</p>
<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. Further details are on the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will tune the radio to 3.331 MHz. The 1-kHz offset is useful with a narrowband SSB&nbsp;filter where the passband includes the carrier and modem signals. 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 is inoperative, the driver continues in single-frequency mode.</p>
<p>As long as no bursts are received, the driver cycles over the three frequencies in turn, one minute for each station. When bursts are received from one or more stations, the driver operates in a five-minute cycle. During the first four minutes it tunes to the station with the highest metric. During the last minute it alternates between the other two stations in turn in order to measure the metric.</p>
<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>
<p>With debugging enabled the driver produces messages in the following formats: A single message beginning with <tt>chuB</tt> is produced for each format B burst received in second 31, while eight messages beginning with <tt>chuA</tt> are produced for each format A burst received in seconds 32 through 39 of the minute. The first four fields are</p>
<p><tt>stat sig n b</tt></p>
<p>where <tt>stat</tt> is the status code, <tt>sig</tt> the character span, <tt>n</tt> the number of characters in the burst (9-11) and <tt>b</tt> the burst distance (0-40). Good bursts will have spans of a 800 or more and the other numbers near the top of the range specified. See the source for the interpretation of the remaining data in the burst. Note that each character of the burst is encoded as two digits in nibble-swapped order.</p>
<p>If the CI-V interface for ICOM radios is active, a debug level greater than 1 will produce a trace of the CI-V command and response messages. Interpretation of these messages requires knowledge of the CI-V protocol, which is beyond the scope of this document.</p>
<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 yyyy ddd hh:mm:ss lw dst du lset agc rfrq bcnt dist tsmp
s sync indicator
@ -78,72 +80,65 @@
dist decoder 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 has been correctly set.
<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>Timestamp alarm. Fewer than 20 timestamps have been determined.
<dt><tt>4</tt>
<dd>Decoder alarm. A majority of repetitions for at least one digit of the timecode fails to agree.
<dt><tt>2</tt>
<dd>Format alarm. One or more bursts contained invalid data or was improperly formatted.<dt><tt>1</tt>
<dd>Frame alarm. One or more bursts was improperly framed or contained too many repetition errors.</dl>
<p>The timestamp and decoder alarms are fatal; the data accumulated during the minute are not used to set the clock. The format and fram alarm are nonfatal; only the data in the burst are discarded.</p>
<dt><tt>yyyy ddd hh:mm:ss</tt>
<dd>The timecode format itself is self explanatory. Note that the Gregorian year is decoded directly from the transmitted timecode.
<dt><tt>lw</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.<dt><tt>dst</tt>
<dd>The DST code for Canada encodes the state for all provinces. It is encoded as two hex characters.
<dt><tt>dut</tt>
<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds. It is encoded as one digit preceeded by sign.
<dt><tt>lset</tt>
<dd>Before the clock is set, this is the number of minutes since the program was started; after the clock is set, this is the number of minutes since the time was last verified relative to the broadcast signal.<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 should be set for a value midway in this range.
<dt><tt>ident</tt>
<dd>The CHU&nbsp;identifier <tt>CHU </tt>followed by the current radio frequency
code, if the CI-V interface is active, or <tt>CHU</tt> if not. The radio
frequncy is encoded as 0 for 3.330 MHz, 1 for 7.850 MHz and 2
for 14.670 MHz.<dt><tt>dist</tt>
<dd>The decoding distance determined during the most recent minute bursts were received. The values range from 0 to 160, with the higher values indicating better signals. The decoding algorithms require the distance at least 50; otherwise all data in the minute are discarded.<dt><tt>tsmp</tt>
<dd>The number of timestamps determined during the most recent minute bursts were received. The values range from 0 to 60, with the higher values indicating better signals. The decoding algoriths require at least 20 timestamps in the minute; otherwise all data in the minute are discarded.
</dl>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the propagation delay for CHU (45:18N 75:45N), in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>CHU</tt>.
<dt><tt>flag1 0 | 1</tt>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<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.
<dt><tt>flag3 0 | 1</tt>
<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.
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
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></dt>
<dd>The sync indicator is initially <tt>?</tt> before the clock is set, but turns to space when the clock has been correctly set.</dd>
<dt><tt>q</tt></dt>
<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></dt>
<dd>Timestamp alarm. Fewer than 20 timestamps have been determined.</dd>
<dt><tt>4</tt></dt>
<dd>Decoder alarm. A majority of repetitions for at least one digit of the timecode fails to agree.</dd>
<dt><tt>2</tt></dt>
<dd>Format alarm. One or more bursts contained invalid data or was improperly formatted.</dd>
<dt><tt>1</tt></dt>
<dd>Frame alarm. One or more bursts was improperly framed or contained too many repetition errors.</dd>
</dl>
The timestamp and decoder alarms are fatal; the data accumulated during the minute are not used to set the clock. The format and fram alarm are nonfatal; only the data in the burst are discarded.</dd>
<dt><tt>yyyy ddd hh:mm:ss</tt></dt>
<dd>The timecode format itself is self explanatory. Note that the Gregorian year is decoded directly from the transmitted timecode.</dd>
<dt><tt>lw</tt></dt>
<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.</dd>
<dt><tt>dst</tt></dt>
<dd>The DST code for Canada encodes the state for all provinces. It is encoded as two hex characters.</dd>
<dt><tt>dut</tt></dt>
<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds. It is encoded as one digit preceeded by sign.</dd>
<dt><tt>lset</tt></dt>
<dd>Before the clock is set, this is the number of minutes since the program was started; after the clock is set, this is the number of minutes since the time was last verified relative to the broadcast signal.</dd>
<dt><tt>agc</tt></dt>
<dd>The audio gain shows the current codec gain setting in the range 0 to 255. Ordinarily, the receiver audio gain control should be set for a value midway in this range.</dd>
<dt><tt>ident</tt></dt>
<dd>The CHU&nbsp;identifier <tt>CHU </tt>followed by the current radio frequency
code, if the CI-V interface is active, or <tt>CHU</tt> if not. The radio
frequncy is encoded as 0 for 3.330 MHz, 1 for 7.850 MHz and 2
for 14.670 MHz.</dd>
<dt><tt>dist</tt></dt>
<dd>The decoding distance determined during the most recent minute bursts were received. The values range from 0 to 160, with the higher values indicating better signals. The decoding algorithms require the distance at least 50; otherwise all data in the minute are discarded.</dd>
<dt><tt>tsmp</tt></dt>
<dd>The number of timestamps determined during the most recent minute bursts were received. The values range from 0 to 60, with the higher values indicating better signals. The decoding algoriths require at least 20 timestamps in the minute; otherwise all data in the minute are discarded.</dd>
</dl>
<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>
<dd>When the audio driver is compiled, this flag enables audio monitoring of the input signal. For this purpose, the speaker volume must be set before the driver is started.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

566
html/drivers/driver8.html
View File

@ -2,299 +2,277 @@
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Generic Reference Driver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Generic Reference Driver</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.8.<i>u</i><br>
Reference ID: <tt>PARSE</tt><br>
Driver ID: <tt>GENERIC</tt><br>
Serial Port: <tt>/dev/refclock-<i>u</i></tt>; TTY mode according to clock type<br>
PPS device: <tt>/dev/refclockpps-<i>u</i></tt>; alternate PPS device (if not available via the serial port)
<h4>Description</h4>
The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br>
<br>
<p>The actual receiver status is mapped into various synchronization states generally used by receivers. The driver is configured to interpret the time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see <a href="#clocklist">list below</a>).</p>
<p>The reference clock support in NTP contains the necessary configuration tables for those receivers. In addition to supporting several different clock types and up to 4 devices, the processing of a PPS signal is also provided as a configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.</p>
<p>CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way ntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.</p>
<p>The use of the PPS option requires receivers with an accuracy of better than 1ms.</p>
<h4>Timecode variables listed by ntpq (8)</h4>
<p>The ntpq program can read and display several clock variables. These hold the following information:</p>
<dl>
<dt><tt>refclock_format</tt></dt>
<dd>A qualification of the decoded time code format.</dd>
<dt><tt>refclock_states</tt></dt>
<dd>The overall running time and the accumulated times for the clock event states.</dd>
<dt><tt>refclock_status</tt></dt>
<dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd>
<dt><tt>refclock_time</tt></dt>
<dd>The local time with the offset to UTC (format HHMM).</dd>
<dt><tt>timecode</tt></dt>
<dd>The actual time code.</dd>
</dl>
<p>If PPS information is present, additional variables are available:</p>
<dl>
<dt><tt>refclock_ppsskew</tt></dt>
<dd>The difference between the RS-232-derived timestamp and the PPS timestamp.</dd>
<dt><tt>refclock_ppstime</tt></dt>
<dd>The PPS timestamp.</dd>
</dl>
<h4>Supported Devices</h4>
<p>Currently, nineteen clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported by the PARSE driver.<br>
A note on the implementations:</p>
<ul>
<li>These implementations were mainly done without actual access to the hardware, thus not all implementations provide full support. The development was done with the help of many kind souls who had the hardware and kindly lent me their time and patience during the development and debugging cycle. Thus for continued support and quality, direct access to the receivers is a big help. Nevertheless I am not prepared to buy these reference clocks - donations to (<a href="mailto:kardel <AT> ntp.org">kardel &lt;AT&gt; ntp.org</a>) are welcome as long as they work within Europe 8-).
<p>Verified implementations are:</p>
<ul>
<li>RAWDCF variants
<p>These variants have been tested for correct decoding with my own homegrown receivers. Interfacing with specific commercial products may involve some fiddling with cables. In particular, commercial RAWDCF receivers have a seemingly unlimited number of ways to draw power from the RS-232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.</p>
<li><a href="http://www.meinberg.de">Meinberg clocks</a>
<p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p>
</ul>
</ul>
<p>The pictures below have been taken from and are linked to the vendors' web pages.</p>
<a name="clocklist"></a>
<ul>
<li><b><tt>server 127.127.8.0-3 mode 0</tt></b>
<p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50&mu;s)</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 1</tt></b>
<p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50&mu;s)</tt></b><br>
<a href="http://www.meinberg.de/english/products/pzf-eurocard.htm"><img src="../pic/pzf511.jpg" alt="Image PZF511" height="300" width="260" align="top" border="0"></a><br>
<br></p>
<li><a name="mode2"></a><b><tt>server 127.127.8.0-3 mode 2</tt></b>
<p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</tt></b><br>
<a href="http://www.meinberg.de/english/products/c51.htm"><img src="../pic/c51.jpg" alt="Image C51" height="239" width="330" align="top" border="0"></a><br>
</p>
<p>This mode expects the Meinberg standard time string format with 9600/7E2.</p>
<p><b>Note:</b> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to allow ntpd to access those cards. For details, please refer to the README file that comes with the Meinberg driver package.<br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 3</tt></b>
<p><b><tt><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 4</tt></b>
<p><b><tt>Walter Schmid DCF receiver Kit (AM demodulation / 1ms)</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 5</tt></b>
<p><b><tt>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 6</tt></b>
<p><b><tt>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</tt></b><br>
<br></p>
<li><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/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / &lt;&lt;1&mu;s)</tt></b><br>
<a href="http://www.meinberg.de/english/products/gps-eurocard.htm"><img src="../pic/gps167.jpg" alt="Image GPS167" height="300" width="280" align="top" border="0"></a><br>
</p>
<p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p>
<p>The University of Erlangen format is preferred. Newer Meinberg GPS receivers can be configured to transmit that format; for older devices, a special firmware version may be available.</p>
<p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p>
<p><b>Note:</b> mode 7 must not be used with Meinberg PCI cards; use <a href="#mode2">mode 2</a> instead.<br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 8</tt></b>
<p><b><tt><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></tt></b><br>
<a href="http://www.igel.de/eigelmn.html"><img src="../pic/igclock.gif" alt="Image IGEL clock" height="174" width="200" border="0"></a><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 9</tt></b>
<p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / &lt;&lt;1&mu;s)</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 10</tt></b>
<p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / &lt;&lt;1&mu;s) (no kernel support yet)</tt></b><br>
<a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html"><img src="../pic/pd_om011.gif" alt="Image SVeeSix-CM3" height="100" width="420" align="top" border="0"></a><br>
<a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.html"><img src="../pic/pd_om006.gif" alt="Image Lassen-SK8" height="100" width="420" border="0"></a><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 11</tt></b>
<p><b><tt>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 12</tt></b>
<p><b><tt><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></tt></b><br>
<a href="http://www.hopf-time.com/engl/kart6021.html"><img src="../pic/fg6021.gif" alt="Image DCF77 Interface Board" height="207" width="238" align="top" border="0"></a><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 13</tt></b>
<p><b><tt>Diem's Computime Radio Clock</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 14</tt></b>
<p><b><tt>RAWDCF receiver (DTR=high/RTS=low)</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 15</tt></b>
<p><b><tt>WHARTON 400A Series Clocks with a 404.2 Serial Interface</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 16</tt></b>
<p><b><tt>RAWDCF receiver (DTR=low/RTS=high) </tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 17</tt></b>
<p><b><tt>VARITEXT Receiver (MSF) </tt></b><br>
<br></p>
<li><a name="mode18"></a><b><tt>server 127.127.8.0-3 mode 18</tt></b>
<p><b><tt><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / &lt;&lt;1&mu;s)</tt></b><br>
</p>
<p>This mode works without additional data communication (version, GPS status etc.) and thus should be used with multidrop, heterogeneous multiclient operation.</p>
<p><b>Note:</b> mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.<br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 19</tt></b>
<p><b><tt>Gude Analog- und Digitalsystem GmbH 'Expert mouseCLOCK USB v2.0'</tt></b><br>
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 20</tt></b>
<p><b><tt>RAWDCF receiver similar to mode 14, but operating @ 75 baud (DTR=high/RTS=low)</tt></b><br>
</p>
<p>Driving the DCF clocks at 75 baud may help to get them to work with a bunch of common USB serial converters, that do 75 but cannot do 50 baud at all, e.g. those based on Prolific PL2303.
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 21</tt></b>
<p><b><tt>RAWDCF receiver similar to mode 16, but operating @ 75 baud (DTR=low/RTS=high) </tt></b><br>
</p>
<p>See comment from mode 20 clock.
<br></p>
<li><b><tt>server 127.127.8.0-3 mode 22</tt></b>
<p><b><tt>MEINBERG, mode 2 but with POWERUP trust </tt></b><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 23</tt></b>
<p><b><tt>MEINBERG, mode 7 but with POWERUP trust </tt></b><br>
</p>
</ul>
<p>Actual data formats and setup requirements of the various clocks can be found in <a href="../parsedata.html">NTP PARSE clock data formats</a>.</p>
<h4>Operation</h4>
<p>The reference clock support software carefully monitors the state transitions of the receiver. All state changes and exceptional events (such as loss of time code transmission) are logged via the syslog facility. Every hour a summary of the accumulated times for the clock states is listed via syslog.</p>
<p>PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronization, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus is a function of clock type.</p>
<p>Raw DCF77 pulses can be fed via a level converter to the RXD pin of an RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin connector). The telegrams are decoded and used for synchronization. DCF77 AM receivers can be bought for as little as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) and 10ms (cheap). Synchronization ceases when reception of the DCF77 signal deteriorates, since no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. During transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.</p>
<p>In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually fed via a level converter to the DCD pin of an RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin connector). To select PPS support, the mode parameter is the mode value as above plus 128. If 128 is not added to the mode value, PPS will be detected to be available but will not be used.
</p>
<h4>Hardware PPS support<br>
</h4>
<p>For PPS to be used, add 128 to the mode parameter.</p>
<p>If the PPS signal is fed in from a device different from the device providing the serial communication (/dev/refclock-{0..3}), this device is configured as /dev/refclockpps-{0..3}. This allows the PPS information to be fed in e.g. via the parallel port (if supported by the underlying operation system) and the date/time telegrams to be handled via the serial port.</p>
<h4>Monitor Data</h4>
<p>Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the <code>ntpq cv</code> command.<br>
Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data
and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on
a specific clock association as shown below.
</p>
<p>First let <code>ntpq</code> display the table of associations:</p>
<pre>
ntpq&gt; as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 19556 9154 yes yes none falsetick reachable 5
2 19557 9435 yes yes none candidat clock expt 3
3 19558 9714 yes yes none pps.peer reachable 1
</pre>
<p>Then switch to raw output. This may be required because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.</p>
<pre>
ntpq&gt; raw
Output set to raw
</pre>
<p>Use the cv command to read the list of clock variables of a selected association:</p>
<pre>
ntpq&gt; cv 19557 clock_var_list
</pre>
<p>The long output of the command above looks similar to:</p>
<pre>
assID=19557 status=0x0000,
clock_var_list=&quot;type,timecode,poll,noreply,badformat,baddata,fudgetime1,
fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status,
refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version,
meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51,
gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],
gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]&quot;
</pre>
<p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p>
<pre>
ntpq&gt; cv 19557 refclock_status,refclock_format,refclock_states,refclock_id,
refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction,
gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1],
gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4],
gps_health[4],gps_cfg[5]
</pre>
<p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p>
<pre>
status=0x0003,
refclock_status=&quot;UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION;
PPS SIGNAL; POSITION)&quot;,
refclock_format=&quot;Meinberg GPS Extended&quot;,
refclock_states=&quot;*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%);
running time: 21:21:39&quot;,
refclock_id=&quot;GPS&quot;, refclock_iomode=&quot;normal&quot;,
refclock_driver_version=&quot;refclock_parse.c,v 4.77 2006/08/05 07:44:49
kardel RELEASE_20060805_A&quot;,
meinberg_gps_status=&quot;[0x0000] &lt;OK&gt;&quot;,
gps_utc_correction=&quot;current correction 14 sec, last correction
on c7619a00.00000000 Sun, Jan 1 2006 0:00:00.000&quot;,
gps_message=&quot;/PFU3SOP-4WG14EPU0V1KA&quot;,
meinberg_antenna_status=&quot;RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000)
UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s,
disconnect time 0000-00-00 00:00:00.0000000 (+0000) &quot;,
gps_tot_51=&quot;week 1400 + 3 days + 42300.0000000 sec&quot;,
gps_tot_63=&quot;week 1400 + 3 days + 42294.0000000 sec&quot;,
gps_t0a=&quot;week 1400 + 5 days + 71808.0000000 sec&quot;,
gps_cfg[1]=&quot;[0x9] BLOCK II&quot;, gps_health[1]=&quot;[0x0] OK;SIGNAL OK&quot;,
gps_cfg[2]=&quot;[0x0] BLOCK I&quot;, gps_health[2]=&quot;[0x3f] PARITY;MULTIPLE ERRS&quot;,
gps_cfg[3]=&quot;[0x9] BLOCK II&quot;, gps_health[3]=&quot;[0x0] OK;SIGNAL OK&quot;,
gps_cfg[4]=&quot;[0x9] BLOCK II&quot;, gps_health[6]=&quot;[0x0] OK;SIGNAL OK&quot;,
gps_cfg[5]=&quot;[0x9] BLOCK II&quot;
</pre>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type.
<dt><tt>time2 <i>time</i></tt>
<dd>
If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning).
<dd>
If flag1 is 1, time2 specifies the number of seconds a receiver with a premium local oscillator can be trusted after losing synchronisation.
<dt><tt>stratum <i>stratum</i></tt>
<dd>The stratum for this reference clock.
<dt><tt>refid <i>refid</i></tt>
<dd>The refid for this reference clock.
</dl>
<dl>
<dt><tt>flag1 { 0 | 1 }</tt>
<dd>If 0, the fudge factor <tt>time2</tt> refers to the PPS offset.
<dd>If 1, <tt>time2</tt> refers to the TRUST TIME.
<dt><tt>flag2 { 0 | 1 }</tt>
<dd>If <tt>flag2</tt> is 1, sample PPS on CLEAR instead of on ASSERT.
<dt><tt>flag3 { 0 | 1 }</tt>
<dd>If <tt>flag3</tt> is 1, link kernel PPS tracking to this refclock instance.
<dt><tt>flag4 { 0 | 1 }</tt>
<dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-)
</dl>
<span style="font-weight: bold;">Note about auxiliary Sun STREAMS modules (SunOS and Solaris):</span><br>
<dl>
<dt>The timecode of these receivers can be sampled via a STREAMS module in the kernel. (The STREAMS module has been designed for use with Sun systems under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into the kernel or loaded via the loadable driver mechanism.) This STREAMS module can be adapted to convert different time code formats. Nowadays the PPSAPI mechanism is usually used.
</dl>
<h4>Making your own PARSE clocks</h4>
<p>The parse clock mechanism deviates from the way other NTP reference clocks work. For a short description of how to build parse reference clocks, see <a href="../parsenew.html">making PARSE clocks</a>.</p>
<p>Additional Information</p>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Generic Reference Driver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Generic Reference Driver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->27-Jan-2014 05:31<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
Address: 127.127.8.<em>u</em><br>
Reference ID: PARSE<br>
Driver ID: GENERIC<br>
Serial Port: /dev/refclock-<em>u</em>; TTY mode according to clock type<br>
PPS device: /dev/refclockpps-<em>u</em>; alternate PPS device (if not available via the serial port)
<h4>Description</h4>
The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br>
<br>
<p>The actual receiver status is mapped into various synchronization states generally used by receivers. The driver is configured to interpret the time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#clocklist">list below</a>).</p>
<p>The reference clock support in NTP contains the necessary configuration tables for those receivers. In addition to supporting several different clock types and up to 4 devices, the processing of a PPS signal is also provided as a configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.</p>
<p>CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way ntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.</p>
<p>The use of the PPS option requires receivers with an accuracy of better than 1ms.</p>
<h4>Timecode variables listed by ntpq (8)</h4>
<p>The ntpq program can read and display several clock variables. These hold the following information:</p>
<dl>
<dt>refclock_format</dt>
<dd>A qualification of the decoded time code format.</dd>
<dt>refclock_states</dt>
<dd>The overall running time and the accumulated times for the clock event states.</dd>
<dt>refclock_status</dt>
<dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd>
<dt>refclock_time</dt>
<dd>The local time with the offset to UTC (format HHMM).</dd>
<dt>timecode</dt>
<dd>The actual time code.</dd>
</dl>
<p>If PPS information is present, additional variables are available:</p>
<dl>
<dt>refclock_ppsskew</dt>
<dd>The difference between the RS-232-derived timestamp and the PPS timestamp.</dd>
<dt>refclock_ppstime</dt>
<dd>The PPS timestamp.</dd>
</dl>
<h4>Supported Devices</h4>
<p>Currently, twenty-four clock types are supported by the PARSE driver and up to four (devices /dev/refclock-0 - /dev/refclock-3) of these clocks may be operational at any one time.<br>
A note on the implementations:</p>
<ul>
<li>These implementations were mainly done without actual access to the hardware, thus not all implementations provide full support. The development was done with the help of many kind souls who had the hardware and kindly lent me their time and patience during the development and debugging cycle. Thus for continued support and quality, direct access to the receivers is a big help. Nevertheless I am not prepared to buy these reference clocks - donations to (<a href="mailto:kardel%20%3CAT%3E%20ntp.org">kardel &lt;AT&gt; ntp.org</a>) are welcome as long as they work within Europe 8-).
<p>Verified implementations are:</p>
<ul>
<li>RAWDCF variants
<p>These variants have been tested for correct decoding with my own homegrown receivers. Interfacing with specific commercial products may involve some fiddling with cables. In particular, commercial RAWDCF receivers have a seemingly unlimited number of ways to draw power from the RS-232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.</p>
</li>
<li><a href="http://www.meinberg.de">Meinberg clocks</a>
<p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p>
</li>
<li><a href="http://www.selinc.com">Schweitzer Engineering
Laboratories SEL-240x clocks</a>
<p>This implementation was provided and verified by SEL and <a
href="http://networktimefoundation.org">Network Time Foundation</a>
has an SEL-2407 in one of its development labs.</p>
</li>
</ul>
</li>
</ul>
<p>The pictures below have been taken from and are linked to the vendors' web pages.</p>
<a name="clocklist"></a>
<ul>
<li><strong>server 127.127.8.0-3 mode 0</strong>
<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50&mu;s)</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 1</strong>
<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50&mu;s)</strong><br>
<a href="http://www.meinberg.de/english/products/pzf-eurocard.htm"><img src="../pic/pzf511.jpg" alt="Image PZF511" align="top" border="0" height="300" width="260"></a><br>
<br>
</p>
</li>
<li><a name="mode2"></a><strong>server 127.127.8.0-3 mode 2</strong>
<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</strong><br>
<a href="http://www.meinberg.de/english/products/c51.htm"><img src="../pic/c51.jpg" alt="Image C51" align="top" border="0" height="239" width="330"></a><br>
</p>
<p>This mode expects the Meinberg standard time string format with 9600/7E2.</p>
<p><strong>Note:</strong> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to allow ntpd to access those cards. For details, please refer to the README file that comes with the Meinberg driver package.<br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 3</strong>
<p><strong><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 4</strong>
<p><strong>Walter Schmid DCF receiver Kit (AM demodulation / 1ms)</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 5</strong>
<p><strong>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 6</strong>
<p><strong>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 7</strong>
<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / &lt;&lt;1&mu;s)</strong><br>
<a href="http://www.meinberg.de/english/products/gps-eurocard.htm"><img src="../pic/gps167.jpg" alt="Image GPS167" align="top" border="0" height="300" width="280"></a><br>
</p>
<p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p>
<p>The University of Erlangen format is preferred. Newer Meinberg GPS receivers can be configured to transmit that format; for older devices, a special firmware version may be available.</p>
<p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p>
<p><strong>Note:</strong> mode 7 must not be used with Meinberg PCI cards; use <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode2">mode 2</a> instead.<br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 8</strong>
<p><strong><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></strong><br>
<a href="http://www.igel.de/eigelmn.html"><img src="../pic/igclock.gif" alt="Image IGEL clock" border="0" height="174" width="200"></a><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 9</strong>
<p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / &lt;&lt;1&mu;s)</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 10</strong>
<p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / &lt;&lt;1&mu;s) (no kernel support yet)</strong><br>
<a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html"><img src="../pic/pd_om011.gif" alt="Image SVeeSix-CM3" align="top" border="0" height="100" width="420"></a><br>
<a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.html"><img src="../pic/pd_om006.gif" alt="Image Lassen-SK8" border="0" height="100" width="420"></a><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 11</strong>
<p><strong>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 12</strong>
<p><strong><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></strong><br>
<a href="http://www.hopf-time.com/engl/kart6021.html"><img src="../pic/fg6021.gif" alt="Image DCF77 Interface Board" align="top" border="0" height="207" width="238"></a><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 13</strong>
<p><strong>Diem's Computime Radio Clock</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 14</strong>
<p><strong>RAWDCF receiver (DTR=high/RTS=low)</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 15</strong>
<p><strong>WHARTON 400A Series Clocks with a 404.2 Serial Interface</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 16</strong>
<p><strong>RAWDCF receiver (DTR=low/RTS=high) </strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 17</strong>
<p><strong>VARITEXT Receiver (MSF) </strong><br>
<br>
</p>
</li>
<li><a name="mode18"></a><strong>server 127.127.8.0-3 mode 18</strong>
<p><strong><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / &lt;&lt;1&mu;s)</strong><br>
</p>
<p>This mode works without additional data communication (version, GPS status etc.) and thus should be used with multidrop, heterogeneous multiclient operation.</p>
<p><strong>Note:</strong> mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.<br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 19</strong>
<p><strong>Gude Analog- und Digitalsystem GmbH 'Expert mouseCLOCK USB v2.0'</strong><br>
<br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 20</strong>
<p><strong>RAWDCF receiver similar to mode 14, but operating @ 75 baud (DTR=high/RTS=low)</strong><br>
</p>
<p>Driving the DCF clocks at 75 baud may help to get them to work with a bunch of common USB serial converters, that do 75 but cannot do 50 baud at all, e.g. those based on Prolific PL2303. <br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 21</strong>
<p><strong>RAWDCF receiver similar to mode 16, but operating @ 75 baud (DTR=low/RTS=high) </strong><br>
</p>
<p>See comment from mode 20 clock. <br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 22</strong>
<p><strong>MEINBERG, mode 2 but with POWERUP trust </strong><br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 23</strong>
<p><strong>MEINBERG, mode 7 but with POWERUP trust </strong><br>
</p>
</li>
<li><strong>server 127.127.8.0-3 mode 24</strong>
<p><strong><a href="http://www.selinc.com/">Schweitzer Engineering Laboratories</a></strong><br>
</p>
</li>
</ul>
<p>Actual data formats and setup requirements of the various clocks can be found in <a href="../parsedata.html">NTP PARSE clock data formats</a>.</p>
<h4>Operation</h4>
<p>The reference clock support software carefully monitors the state transitions of the receiver. All state changes and exceptional events (such as loss of time code transmission) are logged via the syslog facility. Every hour a summary of the accumulated times for the clock states is listed via syslog.</p>
<p>PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronization, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus is a function of clock type.</p>
<p>Raw DCF77 pulses can be fed via a level converter to the RXD pin of an RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin connector). The telegrams are decoded and used for synchronization. DCF77 AM receivers can be bought for as little as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) and 10ms (cheap). Synchronization ceases when reception of the DCF77 signal deteriorates, since no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. During transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.</p>
<p>In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually fed via a level converter to the DCD pin of an RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin connector). To select PPS support, the mode parameter is the mode value as above plus 128. If 128 is not added to the mode value, PPS will be detected to be available but will not be used. </p>
<h4>Hardware PPS support<br>
</h4>
<p>For PPS to be used, add 128 to the mode parameter.</p>
<p>If the PPS signal is fed in from a device different from the device providing the serial communication (/dev/refclock-{0..3}), this device is configured as /dev/refclockpps-{0..3}. This allows the PPS information to be fed in e.g. via the parallel port (if supported by the underlying operation system) and the date/time telegrams to be handled via the serial port.</p>
<h4>Monitor Data</h4>
<p>Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the ntpq cv command.<br>
Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on a specific clock association as shown below. </p>
<p>First let ntpq display the table of associations:</p>
<pre> ntpq&gt; as ind assID status conf reach auth condition last_event cnt =========================================================== 1 19556 9154 yes yes none falsetick reachable 5 2 19557 9435 yes yes none candidat clock expt 3 3 19558 9714 yes yes none pps.peer reachable 1 </pre>
<p>Then switch to raw output. This may be required because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.</p>
<pre> ntpq&gt; raw Output set to raw </pre>
<p>Use the cv command to read the list of clock variables of a selected association:</p>
<pre> ntpq&gt; cv 19557 clock_var_list </pre>
<p>The long output of the command above looks similar to:</p>
<pre> assID=19557 status=0x0000, clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1, fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status, refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version, meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51, gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3], gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]" </pre>
<p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p>
<pre> ntpq&gt; cv 19557 refclock_status,refclock_format,refclock_states,refclock_id, refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction, gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1], gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4], gps_health[4],gps_cfg[5] </pre>
<p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p>
<pre> status=0x0003, refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION)", refclock_format="Meinberg GPS Extended", refclock_states="*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%); running time: 21:21:39", refclock_id="GPS", refclock_iomode="normal", refclock_driver_version="refclock_parse.c,v 4.77 2006/08/05 07:44:49 kardel RELEASE_20060805_A", meinberg_gps_status="[0x0000] &lt;OK&gt;", gps_utc_correction="current correction 14 sec, last correction on c7619a00.00000000 Sun, Jan 1 2006 0:00:00.000", gps_message="/PFU3SOP-4WG14EPU0V1KA", meinberg_antenna_status="RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000) UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s, disconnect time 0000-00-00 00:00:00.0000000 (+0000) ", gps_tot_51="week 1400 + 3 days + 42300.0000000 sec", gps_tot_63="week 1400 + 3 days + 42294.0000000 sec", gps_t0a="week 1400 + 5 days + 71808.0000000 sec", gps_cfg[1]="[0x9] BLOCK II", gps_health[1]="[0x0] OK;SIGNAL OK", gps_cfg[2]="[0x0] BLOCK I", gps_health[2]="[0x3f] PARITY;MULTIPLE ERRS", gps_cfg[3]="[0x9] BLOCK II", gps_health[3]="[0x0] OK;SIGNAL OK", gps_cfg[4]="[0x9] BLOCK II", gps_health[6]="[0x0] OK;SIGNAL OK", gps_cfg[5]="[0x9] BLOCK II" </pre>
<h4>Fudge Factors</h4>
<dl>
<dt>time1 <em>time</em> </dt>
<dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type. </dd>
<dt>time2 <em>time</em> </dt>
<dd> If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning). </dd>
<dd> If flag1 is 1, time2 specifies the number of seconds a receiver with a premium local oscillator can be trusted after losing synchronisation. </dd>
<dt>stratum <em>stratum</em> </dt>
<dd>The stratum for this reference clock. </dd>
<dt>refid <em>refid</em> </dt>
<dd>The refid for this reference clock. </dd>
</dl>
<dl>
<dt>flag1 { 0 | 1 } </dt>
<dd>If 0, the fudge factor time2 refers to the PPS offset. </dd>
<dd>If 1, time2 refers to the TRUST TIME. </dd>
<dt>flag2 { 0 | 1 } </dt>
<dd>If flag2 is 1, sample PPS on CLEAR instead of on ASSERT. </dd>
<dt>flag3 { 0 | 1 } </dt>
<dd>If flag3 is 1, link kernel PPS tracking to this refclock instance. </dd>
<dt>flag4 { 0 | 1 } </dt>
<dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-) </dd>
</dl>
Note about auxiliary Sun STREAMS modules (SunOS and Solaris):<br>
<dl>
<dt>The timecode of these receivers can be sampled via a STREAMS module in the kernel. (The STREAMS module has been designed for use with Sun systems under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into the kernel or loaded via the loadable driver mechanism.) This STREAMS module can be adapted to convert different time code formats. Nowadays the PPSAPI mechanism is usually used. </dt>
</dl>
<h4>Making your own PARSE clocks</h4>
<p>The parse clock mechanism deviates from the way other NTP reference clocks work. For a short description of how to build parse reference clocks, see <a href="../parsenew.html">making PARSE clocks</a>.</p>
<p>Additional Information</p>
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

5
html/drivers/driver9.html
View File

@ -11,6 +11,9 @@
<body>
<h3>Magnavox MX4200 GPS Receiver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
Address: 127.127.9.<i>u</i><br>
@ -54,4 +57,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

5
html/drivers/mx4200data.html
View File

@ -8,6 +8,9 @@
<body>
<h1>MX4200 Receiver Data Format</h1>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h2>Table of Contents</h2>
<ul>
@ -1071,4 +1074,4 @@
<script type="text/javascript" language="javascript" src="../scripts/footer.txt"></script>
</body>
</html>
</html>

5
html/drivers/oncore-shmem.html
View File

@ -10,6 +10,9 @@
<body>
<h3>Motorola ONCORE - The Shared Memory Interface</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<h4>Introduction</h4>
<p>In NMEA mode, the Oncore GPS receiver provides the user with the same information as other GPS receivers. In BINARY mode, it can provide a lot of additional information.</p>
@ -158,4 +161,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

10
html/drivers/scripts/footer.txt
View File

@ -1,7 +1,9 @@
document.write("\
<table><tr>\
<td width='50%' ><img src='../icons/home.gif' align='middle' alt='gif'>\
<td width='33%' align='center'><img src='../icons/home.gif' align='middle'>\
<a href='../index.html'>Home Page</a></td>\
<td width='50%' ><img src='../icons/mail2.gif' align='middle' alt='gif'>\
<a href='http://www.ntp.org/contact.html'>Contacts</a></i></td>\
</tr></table>")
<td width='33%' ><img src='../icons/sitemap.png' align='middle'>\
<a href='../sitemap.html'>Site Map</a></td>\
<td width='33%' ><img src='../icons/mail2.gif' align='middle'>\
<a href='http://www.ntp.org/contact'>Contacts</a></td>\
</tr></table>")

2
html/drivers/scripts/style.css
View File

@ -61,4 +61,4 @@ th {background: #FFFFCC;
th.caption {background: #EEEEEE;
color: #006600;
text-align: center;}
text-align: center;}

5
html/drivers/tf582_4.html
View File

@ -11,6 +11,9 @@
<body>
<h3>European Automated Computer Time Services</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<hr>
<p>Several European countries use the following message data format:</p>
<p><font size="-1" face="Courier New">Data format<br>
@ -68,4 +71,4 @@
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

94
html/extern.html
View File

@ -1,50 +1,48 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>External Clock Discipline and the Local Clock Driver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>External Clock Discipline and the Local Clock Driver</h3>
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:38</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
<hr>
<p>The NTPv4 implementation includes provisions for an external clock, where
the system clock is implemented by some external hardware device.
One implementation might take the form of a bus peripheral with a high resolution
counter disciplined by a GPS receiver, for example. Another implementation
might involve another synchronization protocol, such as the Digital Time Synchronization
Service (DTSS), where the system time is disciplined to this protocol and
NTP clients of the server obtain synchronization indirectly via the server.
A third implementation might be a completely separate clock discipline algorithm
and synchronization protocol, such as the <tt>Lockclock</tt> algorithm used
with NIST Automated Computer Time Service (ACTS) modem synchronized time.</p>
<p>When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon <tt>ntpd</tt> to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail and synchronization service fall back to other means, such as a local reference clock or another NTP server. In addition, when the external clock and driver are in control, some means needs to be provided for the clock driver to pass on status information and error statistics to the NTP daemon.</p>
<p>Control and monitoring functions for the external clock and driver are implemented using the <a href="drivers/driver1.html">Local Clock (type 1) driver</a> and the <tt>ntp_adjtime()</tt> system call. This system call is implemented by special kernel provisions included in the kernel of several operating systems, including Solaris, Tru64, FreeBSD and Linux, and possibly others. When the external clock is disabled or not implemented, the system call is used to pass time and frequency information, as well as error statistics, to the kernel. Besides disciplining the system time, the same interface can be used by other applications to determine the operating parameters of the discipline.</p>
<p>When the external clock is enabled, <tt>ntpd</tt> does not discipline the system clock, nor does it maintain the error statistics. In this case, the external clock and driver do this using mechanisms unknown to <tt>ntpd</tt>; however, in this case the kernel state variables are retrieved at 64-s intervals by the Local Clock driver and used by the clock selection and mitigation algorithms to determine the system variables presented to other NTP clients and peers. In this way, downstream clients and servers in the NTP subnet can make an intelligent choice when more than one server is available.</p>
<p>In order to implement a reliable mitigation between ordinary NTP sources and the external clock source, a protocol is necessary between the local clock driver and the external clock driver. This is implemented using Boolean variables and certain bits in the kernel clock status word. The Boolean variables include the following:</p>
<p><tt>ntp_enable</tt>. set/reset by the <tt>enable</tt> command. enables ntpd
clock discipline</p>
<p><tt>ntp_contro</tt>l. set during initial configuration if kernel support is available</p>
<p><tt>kern_enable</tt> Set/reset by the <tt>enable</tt> command</p>
<p>If the <tt>kern_enable</tt> switch is set, the daemon computes the offset,
frequency, maximum error, estimated error, time constant and status bits,
then provides them to the kernel via <tt>ntp_adjtime()</tt>. If this switch
is not set, these values are not passed to the kernel; however, the daemon
retrieves their present values and uses them in place of the values computed
by the daemon.</p>
<p>The <tt>pps_update</tt> bit set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.</p>
<p>The <tt>PPS control</tt> Updated to the current time by kernel support if
the PPS signal is enabled and working correctly. Set to zero in the adjust
routine if the interval since the last update exceeds 120 s.</p>
<p>The <tt>ntp_enable</tt> and <tt>kern_enable</tt> are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The <tt>pps_update</tt> switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The <tt>ntp_control</tt> switch is set during configuration by interrogating the kernel. If both the <tt>kern_enable</tt> and <tt>ntp_control</tt> switches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.</p>
<p>The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the <tt>ntp_adjtime()</tt> system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>External Clock Discipline and the Local Clock Driver</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>External Clock Discipline and the Local Clock Driver</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->9-May-2014 04:46<!-- #EndDate -->
UTC</p>
<hr>
<p>The NTPv4 implementation includes provisions for an external clock, where
the system clock is implemented by some external hardware device.
One implementation might take the form of a bus peripheral with a high resolution
counter disciplined by a GPS receiver, for example. Another implementation
might involve another synchronization protocol, such as the Digital Time Synchronization
Service (DTSS), where the system time is disciplined to this protocol and
NTP clients of the server obtain synchronization indirectly via the server.
A third implementation might be a completely separate clock discipline algorithm
and synchronization protocol, such as the <tt>Lockclock</tt> algorithm used
with NIST Automated Computer Time Service (ACTS) modem synchronized time.</p>
<p>When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon <tt>ntpd</tt> to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail and synchronization service fall back to other means, such as a local reference clock or another NTP server. In addition, when the external clock and driver are in control, some means needs to be provided for the clock driver to pass on status information and error statistics to the NTP daemon.</p>
<p>Control and monitoring functions for the external clock and driver are implemented using the <a href="drivers/driver1.html">Local Clock (type 1) driver</a> and the <tt>ntp_adjtime()</tt> system call. This system call is implemented by special kernel provisions included in the kernel of several operating systems, including Solaris, Tru64, FreeBSD and Linux, and possibly others. When the external clock is disabled or not implemented, the system call is used to pass time and frequency information, as well as error statistics, to the kernel. Besides disciplining the system time, the same interface can be used by other applications to determine the operating parameters of the discipline.</p>
<p>When the external clock is enabled, <tt>ntpd</tt> does not discipline the system clock, nor does it maintain the error statistics. In this case, the external clock and driver do this using mechanisms unknown to <tt>ntpd</tt>; however, in this case the kernel state variables are retrieved at 64-s intervals by the Local Clock driver and used by the clock selection and mitigation algorithms to determine the system variables presented to other NTP clients and peers. In this way, downstream clients and servers in the NTP subnet can make an intelligent choice when more than one server is available.</p>
<p>In order to implement a reliable mitigation between ordinary NTP sources and the external clock source, a protocol is necessary between the local clock driver and the external clock driver. This is implemented using Boolean variables and certain bits in the kernel clock status word. The Boolean variables include the following:</p>
<p><tt>ntp_enable</tt>. set/reset by the <tt>enable</tt> command. enables ntpd
clock discipline</p>
<p><tt>ntp_contro</tt>l. set during initial configuration if kernel support is available</p>
<p><tt>kern_enable</tt> Set/reset by the <tt>enable</tt> command</p>
<p>If the <tt>kern_enable</tt> switch is set, the daemon computes the offset,
frequency, maximum error, estimated error, time constant and status bits,
then provides them to the kernel via <tt>ntp_adjtime()</tt>. If this switch
is not set, these values are not passed to the kernel; however, the daemon
retrieves their present values and uses them in place of the values computed
by the daemon.</p>
<p>The <tt>pps_update</tt> bit set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.</p>
<p>The <tt>PPS control</tt> Updated to the current time by kernel support if
the PPS signal is enabled and working correctly. Set to zero in the adjust
routine if the interval since the last update exceeds 120 s.</p>
<p>The <tt>ntp_enable</tt> and <tt>kern_enable</tt> are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The <tt>pps_update</tt> switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The <tt>ntp_control</tt> switch is set during configuration by interrogating the kernel. If both the <tt>kern_enable</tt> and <tt>ntp_control</tt> switches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.</p>
<p>The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the <tt>ntp_adjtime()</tt> system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

34
html/filter.html Normal file
View File

@ -0,0 +1,34 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Clock Filter Algorithm</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Clock Filter Algorithm</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->10-Mar-2014 05:05<!-- #EndDate -->
UTC</p>
<hr>
<p>The clock filter algorithm processes the offset and delay samples produced by the on-wire protocol for each peer process separately. It uses a sliding window of eight samples and picks out the sample with the least expected error. This page describes the algorithm design principles along with an example of typical performance.</p>
<div align="center"><img src="pic/flt5.gif" alt="gif">
<p>Figure 1. Wedge Scattergram</p>
</div>
<p>Figure 1 shows a typical <em>wedge scattergram</em> plotting sample points of offset versus delay collected over a 24-hr period. As the delay increases, the offset variation increases, so the best samples are those at the lowest delay. There are two limb lines at slope &plusmn;0.5, representing the limits of sample variation. However, it is apparent that, if a way could be found to find the sample of lowest delay, it would have the least offset variation and would be the best candidate to synchronize the system clock.</p>
<p>The clock filter algorithm works best when the delays are statistically identical in the reciprocal directions between the server and client. This is apparent in Figure 1, where the scattergram is symmetric about the x axis through the apex sample. In configurations where the delays are not reciprocal, or where the transmission delays on the two directions are traffic dependent, this may not be the case. A common case with DSL links is when downloading or uploading a large file. During the download or upload process, the delays may be significantly different resulting in large errrors. However, these errors can be largely eliminated using samples near the limb lines, as described on the <a href="huffpuff.html">Huff-n'-Puff Filter</a> page.</p>
<p>In the clock filter algorithm the offset and delay samples from the on-wire protocol are inserted as the youngest stage of an eight-stage shift register, thus discarding the oldest stage. Each time an NTP packet is received from a source, a dispersion sample is initialized as the sum of the precisions of the server and client. Precision is defined by the latency to read the system clock and varies from 1000 ns to 100 ns in modern machines. The dispersion sample is inserted in the shift register along with the associated offset and delay samples. Subsequently, the dispersion sample in each stage is increased at a fixed rate of 15 &mu;s/s, representing the worst case error due to skew between the server and client clock frequencies.</p>
<p>In each peer process the clock filter algorithm selects the stage with the smallest delay, which generally represents the most accurate data, and it and the associated offset sample become the peer variables of the same name. The peer jitter statistic is computed as the root mean square (RMS) differences between the offset samples and the offset of the selected stage.</p>
<p> The peer dispersion statistic is determined as a weighted sum of the dispersion samples in the shift register. Initially, the dispersion of all shift register stages is set to a large number &quot;infinity&quot; equal to 16 s. The weight factor for each stage, starting from the youngest numbered <em>i</em> = 1, is 2<sup>-<em>i</em></sup>, which means the peer dispersion is approximately 16 s.</p>
<p> As samples enter the register, the peer dispersion drops from 16 s to 8 s, 4 s, 2 s, and so forth. In practice, the synchronization distance, which is equal to one-half the delay plus the dispersion, falls below the select threshold of 1.5 s in about four updates. This gives some time for meaningful comparison between sources, if more than one are available. The dispersion continues to grow at the same rate as the sample dispersion. For additional information on statistacl principles and performance metrics, see the <a href="stats.html">Performance Metrics</a> page.</p>
<p> As explained elsewhere, when a source becomes unreachable, the poll process inserts a dummy infinity sample in the shift register for each poll sent. After eight polls, the register returns to its original state.</p>
<div align="center"><img src="pic/flt1.gif" alt="gif"> &nbsp; <img src="pic/flt2.gif" alt="gif">
<p>Figure 2. Raw (left) and Filtered (right) Offsets</p>
</div>
<p>Figure 2 shows the performance of the algorithm for a typical Internet path over a 24-hr period. The graph on the left shows the raw offsets produced by the on-wired protocol, while the figure on the right shows the filtered offsets produced by the clock filter algorithm. If we consider the series formed as the absolute value of the offset samples, the mean error is defined as the mean of this series. Thus, the mean error of the raw samples is 0.724 ms, while the mean error of the filtered series is 0.192 ms. Radio engineers would interpret this as a processing gain of 11.5 dB.</p>
<p>The reader might notice the somewhat boxy characteristic of the filtered offsets. Once a sample is selected, it remains selected until a newer sample with lower delay is available. This commonly occurs when an older selected sample is discarded from the shift register. The reason for this is to preserve causality; that is, time always moves forward, never backward. The result can be the loss of up to seven samples in the shift register, or more to the point, the output sample rate can never be less than one in eight input samples. The clock discipline algorithm is specifically designed to operate at this rate.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

42
html/gadget.html
View File

@ -1,42 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Gadget Box PPS Level Converter and CHU Modem</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Gadget Box PPS Level Converter and CHU Modem</h3>
<img src="pic/gadget.jpg" alt="gif" align="left">A Gadget Box built by Chuck Hanavin
<br clear="left">
<h4>Related Links</h4>
<p>
<script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
<br clear="left">
</p>
<h4>table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a></li>
<li class="inline"><a href="#ckt">Circuit Description</a></li>
<li class="inline"><a href="#file">Files</a></li>
</ul>
<hr>
<h4 id="intro">Introduction</h4>
<p>Many radio clocks used as a primary reference source for NTP servers produce
a pulse-per-second (PPS) signal that can be used to improve accuracy to a
high degree. However, the signals produced are usually incompatible with the
modem interface signals on the serial ports used to connect the signal to
the host. The gadget box consists of a handful of electronic components assembled
in a small aluminum box. It includes level converters and a optional radio
modem designed to decode the radio timecode signals transmitted by the Canadian
time and frequency station CHU. A complete set of schematics, PCB artwork,
drill templates can be obtained via the web from ftp.udel.edu as <a href="ftp://ftp.udel.edu/pub/ntp/hardware/gadget.tar.Z">gadget.tar.Z</a>.</p>
<p>The gadget box is assembled in a 5&quot;x3&quot;x2&quot; aluminum minibox containing the level converter and modem circuitry. It includes two subcircuits. One of these converts a TTL positive edge into a fixed-width pulse at EIA levels and is for use with a timecode receiver or oscillator including a TTL PPS output. The other converts the timecode modulation broadcast by Canadian time/frequency standard station CHU into a 300-bps serial character stream at EIA levels and is for use with the <a href="drivers/driver7.html">Radio CHU Audio Demodulator/Decoder</a> driver.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

42
html/hints.html
View File

@ -1,24 +1,22 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=windows-1252">
<title>Hints and Kinks</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Hints and Kinks</h3>
<img src="pic/alice35.gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Mother in law has all the answers.</p>
<p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:27</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
<br clear="left">
<hr>
<p>This is an index for a set of troubleshooting notes contained in individual text files in the <tt>./hints</tt> directory. They were supplied by various volunteers in the form of mail messages, patches or just plain word of mouth. Each note applies to a specific computer and operating system and gives information found useful in setting up the NTP distribution or site configuration. The notes are very informal and subject to errors; no attempt has been made to verify the accuracy of the information contained in them.</p>
<p>Additions or corrections to this list or the information contained in the notes is solicited. The most useful submissions include the name of the computer manufacturer (and model numbers where appropriate), operating system (specific version(s) where appropriate), problem description, problem solution and submitter's name and electric address. If the submitter is willing to continue debate on the problem, please so advise. See the <a href="hints/">directory listing</a>.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=windows-1252">
<title>Hints and Kinks</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Hints and Kinks</h3>
<img src="pic/alice35.gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Mother in law has all the answers.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->10-Mar-2014 05:06<!-- #EndDate -->
UTC</p>
<br clear="left">
<hr>
<p>This is an index for a set of troubleshooting notes contained in individual text files in the <tt>./hints</tt> directory. They were supplied by various volunteers in the form of mail messages, patches or just plain word of mouth. Each note applies to a specific computer and operating system and gives information found useful in setting up the NTP distribution or site configuration. The notes are very informal and subject to errors; no attempt has been made to verify the accuracy of the information contained in them.</p>
<p>Additions or corrections to this list or the information contained in the notes is solicited. The most useful submissions include the name of the computer manufacturer (and model numbers where appropriate), operating system (specific version(s) where appropriate), problem description, problem solution and submitter's name and electric address. If the submitter is willing to continue debate on the problem, please so advise. See the <a href="hints/">directory listing</a>.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>

5
html/hints/sco.html
View File

@ -11,6 +11,9 @@
<body>
<h3>SCO Unix hints</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<h4>Older SCO Unix versions</h4>
<p>NTP 4.0.x does not run on SCO Unix prior to version 3.2.5.0.0. If you need NTP on an older SCO Unix system and don't mind to modify your kernel, use 3.5.91 which has patches for SCO Unix 3.2.4.x. Apply the kernel modifications as described in <a href="http://www.echelon.nl/en/ntp/sco3-recipe.html">XNTP on SCO 3.2.4.2</a>.</p>
<h4>Compiling NTP</h4>
@ -23,4 +26,4 @@
<p>Kees Hendrikse, January 1999</p>
</body>
</html>
</html>

96
html/hints/solaris.html
View File

@ -6,9 +6,12 @@
<BODY>
Information on compiling and executing ntpd under Solaris.
<BR>
Last Updated: Sun Jun 21 01:32:18 EDT 1998,
<p>Last update:
<!-- #BeginDate format:En2m -->27-Jan-2014 05:31<!-- #EndDate -->
UTC,
John Hawkinson,
<! -- This is deliberately not a mailto -- > &lt;jhawk@MIT.EDU&gt;
</p>
<P>
If you're not running Solaris 2.5.1 or later, it is likely
that you will have problems; upgrading would be a really good plan.
@ -38,7 +41,7 @@ set dosynctodr = 0
<P>
Instead of the <I>tick</I> kernel variable, which many operating
systems use to control microseconds added to the system time every
clock tick (c.f. <A HREF="../notes.html#frequency_tolerance">Dealing
clock tick (c.f. <A HREF="#frequency_tolerance">Dealing
with Frequency Tolerance Violations</A>), Solaris has the variables
<I>nsec_per_tick</I> and <I>usec_per_tick</I>.
<P>
@ -63,6 +66,95 @@ HREF="solaris.xtra.S99ntpd">this one</A>, installed in
<CODE>/etc/init.d/ntpd</CODE> with a symbol link from
<CODE>/etc/rc2.d/S99ntpd</CODE>.
<a id="frequency_tolerance" />
<h4>Dealing with Frequency Tolerance Violations (<tt>tickadj</tt> and
Friends)</h4>
The NTP Version 3 specification RFC-1305 calls for a maximum
oscillator frequency tolerance of +-100 parts-per-million (PPM), which is
representative of those components suitable for use in relatively
inexpensive workstation platforms. For those platforms meeting this
tolerance, NTP will automatically compensate for the frequency errors of the
individual oscillator and no further adjustments are required, either to the
configuration file or to various kernel variables. For the NTP Version 4
release, this tolerance has been increased to +-500 PPM. <p>However, in the
case of certain notorious platforms, in particular Sun 4.1.1 systems, the
performance can be improved by adjusting the values of certain kernel
variables; in particular, <tt>tick</tt> and <tt>tickadj</tt>. The variable
<tt>tick</tt> is the increment in microseconds added to the system time on
each interval- timer interrupt, while the variable <tt>tickadj</tt> is used
by the time adjustment code as a slew rate, in microseconds per tick. When
the time is being adjusted via a call to the system routine
<tt>adjtime()</tt>, the kernel increases or reduces tick by <tt>tickadj</tt>
microseconds per tick until the specified adjustment has been
completed. Unfortunately, in most Unix implementations the tick increment
must be either zero or plus/minus exactly <tt>tickadj</tt> microseconds,
meaning that adjustments are truncated to be an integral multiple of
<tt>tickadj</tt> (this latter behaviour is a misfeature, and is the only
reason the <tt>tickadj</tt> code needs to concern itself with the internal
implementation of <tt>tickadj</tt> at all). In addition, the stock Unix
implementation considers it an error to request another adjustment before a
prior one has completed.</p> <p>Thus, to make very sure it avoids problems
related to the roundoff, the <tt>tickadj</tt> program can be used to adjust
the values of <tt>tick</tt> and <tt>tickadj</tt>. This ensures that all
adjustments given to <tt>adjtime()</tt> are an even multiple of
<tt>tickadj</tt> microseconds and computes the largest adjustment that can
be completed in the adjustment interval (using both the value of
<tt>tick</tt> and the value of <tt>tickadj</tt>) so it can avoid exceeding
this limit. It is important to note that not all systems will allow
inspection or modification of kernel variables other than at system build
time. It is also important to know that, with the current NTP tolerances, it
is rarely necessary to make these changes, but in many cases they will
substantially improve the general accuracy of the time service.</p>
<p>Unfortunately, the value of <tt>tickadj</tt> set by default is almost
always too large for <tt>ntpd</tt>. NTP operates by continuously making
small adjustments to the clock, usually at one-second intervals. If
<tt>tickaj</tt> is set too large, the adjustments will disappear in the
roundoff; while, if <tt>tickadj</tt> is too small, NTP will have difficulty
if it needs to make an occasional large adjustment. While the daemon itself
will read the kernel's values of these variables, it will not change the
values, even if they are unsuitable. You must do this yourself before the
daemon is started using the <tt>tickadj</tt> program included in the
<tt>./util</tt> directory of the distribution. Note that the latter program
will also compute an optimal value of <tt>tickadj</tt> for NTP use based on
the kernel's value of <tt>tick</tt>.</p> <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.</p>
<p>We have a report that says starting with Solaris 2.6 we should leave
<i>dosynctodr</i> alone.</p> <p>In order to maintain reasonable correctness
bounds, as well as reasonably good accuracy with acceptable polling
intervals, <tt>ntpd</tt> will complain if the frequency error is greater
than 500 PPM. For machines with a value of <tt>tick</tt> in the 10-ms range,
a change of one in the value of <tt>tick</tt> will change the frequency by
about 100 PPM. In order to determine the value of <tt>tick</tt> for a
particular CPU, disconnect the machine from all source s of time
(<tt>dosynctodr</tt> = 0) and record its actual time compared to an outside
source (eyeball-and-wristwatch will do) over a day or more. Multiply the
time change over the day by 0.116 and add or subtract the result to tick,
depending on whether the CPU is fast or slow. An example call to
<tt>tickadj</tt> useful on SunOS 4.1.1 is:</p>
<pre>
<tt>tickadj</tt> -t 9999 -a 5 -s
</pre>
which sets tick 100 PPM fast, <tt>tickadj</tt> to 5 microseconds and turns
off the clock/calendar chip fiddle. This line can be added to the <tt
>rc.local</tt> configuration file to automatically set the kernel variables
at boot time. <p>All this stuff about diddling kernel variables so the NTP
daemon will work is really silly. If vendors would ship machines with clocks
that kept reasonable time and would make their <tt>adjtime()</tt> system
call apply the slew it is given exactly, independent of the value of
<tt>tickadj</tt>, all this could go away. This is in fact the case on many
current Unix systems.</p>
<H3>Solaris 2.6</H3>
<P>
Solaris 2.6 adds support for kernel PLL timekeeping, but breaks this

5
html/hints/vxworks.html
View File

@ -12,6 +12,9 @@
<body link="#00008B" vlink="#8B0000">
<h4>VxWorks port of NTP</h4>
<p>Last update:
<!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate -->
UTC</p>
<p>Creating a port for vxWorks posed some problems. This port may help as a starting point for similar ports to real-time OS's and other embeddable kernels, particularly where <tt>main()</tt> is not allowed, and where the configure scripts need to be altered.</p>
<h4>Configuration issues</h4>
<p>I decided to do as little invasive surgery as possible on the NTP code, so I brought the vxWorks header tree in line with the standard Unix tree. The following changes were needed, as a side effect these changes will allow for easy porting of other autoconfigure enabled code.</p>
@ -82,4 +85,4 @@
<p>Casey Crellin, casey@csc.co.za</p>
</body>
</html>
</html>

125
html/hints/winnt.html
View File

@ -9,10 +9,10 @@
<link href="../scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>NTP 4.x for Windows NT</h3>
<h3>NTP 4.x for Windows</h3>
<h4>Introduction</h4>
<p>The NTP 4 distribution runs as service on Windows Vista, Windows NT 4.0, Windows 2000, Windows XP, Windows .NET Server 2003. It will NOT run on Windows 95, 98, ME, etc. The binaries work on multi-processor systems. This port has not been tested on the Alpha platform. This release now uses OpenSSL for authentication. IPv6 is not implemented yet for Win32 platforms. A ready-to-run install distribution is available from Meinberg at <a href="http://www.meinberg.de/english/sw/ntp.htm">http://www.meinberg.de/english/sw/ntp.htm.</a></p>
<p>The NTP 4 distribution runs as service on Windows 2000 and later. It will NOT run on Windows 95, 98, ME, etc. Lately it has been run the most on Windows-7 and later. The binaries work on multi-processor systems. This port has not been tested on the Alpha platform. This release now uses OpenSSL for authentication. IPv6 is not implemented yet for Win32 platforms. A ready-to-run install distribution is available from Meinberg at <a href="http://www.meinberg.de/english/sw/ntp.htm">http://www.meinberg.de/english/sw/ntp.htm.</a></p>
<p>Users should note that the stock Windows client sends requests as mode-1 packets, which can have unintended consequences and create a security risk. The client should send requests as mode-3 (client) packets, which conform to the protocol specification. The issues and resolution are described in Microsoft KB 875424. A less desirable alternative that avoids changing registry keys is to use the <tt>--with-wintime</tt> option when building the executable.</p>
<h4>Authentication Keys</h4>
<p>With this release ntp-keygen is supported. See the <a href="../keygen.html"> ntp keygen documentation</a> for details on how to use ntp-keygen.</p>
@ -36,17 +36,15 @@
<h4 id="ToDo">ToDo</h4>
<p>These tasks are in no particular order of priority.</p>
<ul>
<li>Create a proper install/uninstall program
<li>Add sntp to the list of supported programs
<li>Add support for Visual C++ 7.0 or later (.NET)
<li>Add IPv6 support
<li>See if precision can be improved by using CPU cycle counter for tick interpolation.
<li>Make precision time available to applications using NTP_GETTIME API
</ul>
<h4>Compiling Requirements</h4>
<ul>
<li>Windows NT 4.0 Windows 2000, Windows XP,Windows Vista or Windows.NET Server 2003
<li>Microsoft Visual C++ 2008 EE or Visual C++ 2010 EE
<li>Windows 7 or Windows.NET Server 2003, or later.
<li>Windows NT 4.0 Windows 2000, Windows XP or Windows Vista <i>may</i> still work.
<li>Microsoft Visual C++ 2008, 2010, or 2013 EE
<li>Some way of uncompressing and untarring the gzipped tar file.
<li>OpenSSL must be built on the box before building NTP. Additional steps would
be required to not use OpenSSL.
@ -58,15 +56,15 @@
<ul><li> OPENSSL_INC=C:\OpenSSL\include
<li> OPENSSL_LIB=C:\OpenSSL\lib</ul>
<li>Unpack the NTP-4.x.tar.gz using utilities such as WinZip or WinRar.
<li>Run Microsoft Visual C++ 2008 EE. On Windows Vista and later, Run as Administrator.
<li>Run Microsoft Visual C++ 2008 EE.
<li>Open the ports\winnt\vs2008\ntp.sln solution file
<li>Batch build all projects (Build menu, Batch Build..., select all, build).
<li>The built binaries can be found in the ports\winnt\v2008\bin\ directory.
<li>The built binaries can be found in the <tt>ports\winnt\v2008\Win32-bin\Release</tt> directory.
<li>If you are shipping binaries in a kit it is strongly recommended that you ship this file (winnt.html) along with the binaries.
</ol>
<h4>Configuration File</h4>
<p>The default NTP configuration file path is %SystemRoot%<tt>\system32\drivers\etc\. </tt>(%SystemRoot% is an environmental variable that can be determined by typing &quot;set&quot; at the &quot;Command Prompt&quot; or from the &quot;System&quot; icon in the &quot;Control Panel&quot;).</p>
<p>Refer to your system environment and <tt>c</tt>reate your<tt> ntp.conf</tt> file in the directory corresponding to your system&nbsp; installation. The older <tt>&lt;WINDIR&gt;\ntp.conf</tt> is still supported but you will get a log entry reporting that the first file wasn't found.
<p>Refer to your system environment and create your<tt> ntp.conf</tt> file in the directory corresponding to your system&nbsp; installation. The older <tt>&lt;WINDIR&gt;\ntp.conf</tt> is still supported but you will get a log entry reporting that the first file wasn't found.
<h4>Installation Instructions</h4>
<p>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.</p>
<ol>
@ -83,105 +81,10 @@
<p>Use the registry editor to edit the value for the ntpd executable under LocalMachine\System\CurrentControlSet\Services\NTP.</p>
<p>Add the -g option to the ImagePath key, behind &quot;%INSTALLDIR&gt;\ntpd.exe&quot;. This will force NTP to accept large time errors (including 1.1.1980 00:00)</p>
<h4>Bug Reports</h4>
<p>Send questions and bug reports to <a href="../bugs.html">NTP Bug Reporting Procedures</a>.</p>
<h4>Change Log</h4>
<h3>Last revision 2 July 2003&nbsp; Version 4.2.0</h3>
<p>by Danny Mayer (mayer@ntp.org>)</p>
<h4>Significant Changes:</h4>
<p>This latest release of NTP constitutes a major upgrade to its ability to build and run on Windows platforms and should now build and run cleanly. More importantly it is now able to support all authentication in the same way as Unix boxes. This does require the usage of OpenSSL which is now a prerequisite for build on Windows. <tt>ntp-keygen</tt> is now supported and builds on Win32 platforms.
<h4>Last revision 16 February 1999 Version 4.0.99e.</h4>
<p>by Sven Dietrich (sven_dietrich@trimble.com)</p>
<p>pSignificant Changes:</p>
<ul>
<li>Perl 5 is no longer needed to compile NTP. The configuration script which creates version.c with the current date and time was modified by Frederick Czajka [w2k@austin.rr.com] so that Perl is no longer required.
</ul>
<h4>Last revision 15 November 1999&nbsp; Version 4.0.98f.</h4>
<p>by Sven Dietrich (sven_dietrich@trimble.com)</b>
<p>ignificant Changes:</p>
<ul>
<li>Fixed I/O problem delaying packet responses which resulted in no-replys to NTPQ and others.
<li>The default configuration file path is <tt>&lt;WINDIR&gt;\system32\drivers\etc\ntp.conf. The old &lt;WINDIR&gt;\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.
</ul>
<h4>Known Problems / TODO:</h4>
<ul>
<li>MD5 and name resolution do not yet get along. If you define MD5, you cannot use DNS names, only IP numbers.
</ul>
<h4>Last revision 27 July 1999&nbsp; Version 4.0.95.</h4>
<p>This version compiled under WINNT with Visual C 6.0 by Greg Brackley and Sven Dietrich. Significant changes:</p>
<ul>
<li>Visual Studio v6.0 support
<li>Winsock 2.0 support
<li>Use of I/O completion ports for sockets and comm port I/O
<li>Removed the use of multimedia timers (from ntpd, others need removing)
<li>Use of waitable timers (with user mode APC) and performance counters to fake getting a better time
<li>Trimble Palisade NTP Reference Clock support
<li>General cleanup, prototyping of functions
<li>Moved receiver buffer code to a separate module (removed unused members from the recvbuff struct)
<li>Moved io signal code to a separate module
</ul>
<h4>Last revision:&nbsp; 20-Oct-1996</h4>
<p>This version corrects problems with building the XNTPversion 3.5-86 distribution under Windows NT. The following files were modified:</p>
<ul>
<li><tt>blddbg.bat</tt>
<li><tt>bldrel.bat</tt>
<li><tt>include\ntp_machine.h</tt>
<li><tt>xntpd\ntp_unixclock.c</tt>
<li><tt>xntpd\ntp_refclock.c</tt>
<li><tt>scripts\wininstall\build.bat</tt>
<li><tt>scripts\wininstall\setup.rul</tt>
<li><tt>scripts\wininstall\readme.nt</tt>
<li><tt>scripts\wininstall\distrib\ntpog.wri</tt>
<li><tt>html\hints\winnt</tt> (this file)
</ul>
<p>In order to build the entire Windows NT distribution you need to modify the file scripts\wininstall\build.bat with the installation directory of the InstallShield software.&nbsp; Then, simply type &quot;bldrel&quot; for non-debug or &quot;blddbg&quot; for debug executables.</p>
<p>Greg Schueman,
schueman@acm.org&gt;</p>
<h4>Last revision: 07-May-1996</h4>
<p>This set of changes fixes all known bugs, and it includes<br>
several major enhancements. Many changes have been made both to the build environment as well as the code.&nbsp; There is no longer an ntp.mak file, instead there is a buildntall.bat file that will build the entire release in one shot. The batch file requires Perl.&nbsp; Perl is easily available from the NT Resource Kit or on the Net.</p>
<p>The multiple interface support was adapted from Larry Kahn's work on the BIND NT port.&nbsp; I have not been able to test it, adequately as I only have NT servers with one network interfaces on which to test.</p>
<p>Enhancements:</p>
<ul>
<li>Event Logging now works correctly.
<li>Version numbers now work (requires Perl during build)
<li>Support for multiple network interface cards (untested)
<li>NTP.CONF now default, but supports ntp.ini if not found
<li>Installation procedure automated.
<li>All paths now allow environment variables such as %windir%
</ul>
<p>Bug fixes</p>
<ul>
<li>INSTSRV replaced, works correctly
<li>Cleaned up many warnings
<li>Corrected use of an uninitialized variable in XNTPD
<li>Fixed ntpdate -b option
<li>Fixed ntpdate to accept names as well as IP addresses
(Winsock WSAStartup was called after a gethostbyname())
<li>Fixed problem with &quot;longjmp&quot; in xntpdc/ntpdc.c that caused a software exception on doing a Control-C in xntpdc. A Cntrl-C now terminates the program.
</ul>
<p>See below for more detail</p>
<p>Note: SIGINT is not supported for any Win32 application including; Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior.</p>
<p>Possible enhancements and things left to do:</p>
<ul>
<li>Reference clock drivers for NT (at least Local Clock support)
<li>Control Panel Applet
<li>InstallShield based installation, like NT BIND has
<li>Integration with NT Performance Monitor
<li>SNMP integration
<li>Fully test multiple interface support
</ul>
<h4>Known problems:</h4>
<ul>
<li>bug in ntptrace - if no Stratum 1 servers are available, such as on an IntraNet, the application crashes.
</ul>
<h4>Last revision: 12-Apr-1995</h4>
<p>This NTPv3 distribution includes a sample configuration file and the project makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0 compiler. Also included is a small routine to install the NTP daemon as a &quot;service&quot; on a WindowsNT box. Besides xntpd, the utilities that have been ported are ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using a Bancomm TimeServe2000 GPS receiver clock that acts as a stratum 1 NTP server with no authentication (it has not been tested with any refclock drivers compiled in).
<p>Following are the known flaws in this port</p>
<ul>
<li>Currently, I do not know of a way in NT to get information about multiple network interface cards. The current port uses just one socket bound to INADDR_ANY address. Therefore when dealing with a multihomed NT time server, clients should point to the default address on the server (otherwise the reply is not guaranteed to come from the same interface to which the request was sent). Working with Microsoft to get this resolved.
<li>There is some problem with &quot;longjmp&quot; in xntpdc/ntpdc.c that causes a software exception on doing a Control-C in xntpdc. Be patient!&gt; 3) The error messages logged by xntpd currently contain only the numerical error code. Corresponding error message string has to be looked up in &quot;Books Online&quot; on Visual C++ 2.0 under the topic &quot;Numerical List of Error Codes&quot;.</ul>
<h4>Last HTML Update: November 17, 1999</h4>
<p>by Sven_Dietrich@Trimble.COM</p>
</body>
<p>Please follow the <a href="../bugs.html">NTP Bug Reporting Procedures</a> to report bugs or request enhancements.</p>
<p>Last update:
<!-- #BeginDate format:En2m -->6-Apr-2014 23:27<!-- #EndDate -->
</p>
</body>
</html>

74
html/history.html Normal file
View File

@ -0,0 +1,74 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Historical Notes</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h3>Historical Notes</h3>
<p>Last update:
<!-- #BeginDate format:En2m -->10-Mar-2014 05:07<!-- #EndDate -->
UTC</p>
<hr>
<h4>Historical Notes on NTP Upgrades</h4>
<p>This is an interim report on recent upgrades to the NTPv4 reference implementation code base and documentation. This report documents the upgrade program, which began in June 2007 and continued until March 2008. It is very important to recognize that this historic document describes the upgrade status as of 2008. Additional upgrades have been implemented since then. As of mid 2011, the additional upgrades are documented on the <a href="release.html">NTP Version 4 Release Notes</a> page.</p>
<p>The motivation for this project was the overhaul and refinement of the code, some of which dates back twenty years. Some four dozen sets of fingers have introduced sometimes incompatible &quot;improvements&quot; that to some degree enhance or burden the product. There has been a continuing effort over the years to maintain the briar patch and pluck the more flagrant weeds, but it now requires a more systematic and thorough examination of purpose, design and implementation. The project is not complete, but far enough along to present a status report and review of significant changes.</p>
<p>Please note THE CHANGES DO NOT AFFECT THE PROTOCOL SPECIFICATION AND DO NOT AFFECT INTEROPERABILITY WITH PREVIOUS VERSIONS.</p>
<h4>1. Transparent Design</h4>
<p>During the project a number of minor inconsistencies in various algorithms were found and resolved. In most cases this did not result in any changes in behavior, just a more simplified, transparent and easier to maintain design. In a few cases behavior has been modified to correct deficiencies and to avoid hostile attacks, as described below.</p>
<h4>2. Documentation</h4>
<p>The documentation required a major upgrade. Many pages have been overhauled, some completely rewritten and new ones added. A site map has been added and sorted by page category. A comprehensive command index has been added and sorted by page category. The command index includes a brief gloss for each command. A page has been added to show the various status word and event decodes used for monitoring and event reporting. The decodes show the internal code, ASCII report and short function gloss.</p>
<p>New pages have been added on association management, automatic server discovery and rate management. Much of the overburden on the program manual and configuration pages has been moved to these pages with the intent of the original pages to contain primarily a functional description for the commands and command line options. This is still an ongoing process.</p>
<h4>3. Bulletproofing</h4>
<p>In a continuing mission the code flow has been carefully adjusted to decrease vulnerability to configuration errors and possibly hostile attack. The order of restriction processing was adjusted to deflect access denials as early as possible and without consuming useless processor cycles. This is especially important in rate defense, as the MRU list should only be used for clients that could be legitimately served. In addition, the Autokey protocol was adjusted to avoid some potentially nasty disruption attacks.</p>
<h4>4. Rate Management</h4>
<p>Strict rate controls have been refined in both outbound and inbound traffic for both minimum headway (guard time) and minimum average headway. This is a major improvement over the original limitreject design of 1992 and upgrade circa 2003. Headway violations result in an optional <em>kiss-o'-death</em> (KoD) packet. To avoid a clogging vulnerability, the KoD packets are themselves rate controlled for each source address separately.</p>
<p>The main feature of the revised design is that it is responsive to the server minimum headway and avoids guessing. This is done by setting the ppoll field in the server packet to the maximum of (a) the ppoll field in the client packet and (b) the server headway. The client sets the ppoll field in the association to the maximum of (a) the ppoll field in the server packet and (b) the minpoll field in the association. If this is a KoD and this value is greater than minpoll, minpoll is set to this value. The result is that the client continues sending, but only at headway at least as large as the server.</p>
<p>The revised design makes possible a decrease in the minimum time constant/poll interval to 3 (8 s), which reduces the risetime to 250 s. This may be useful for rapid convergence when a client is first started, but should not be used for links with moderate to large jitter. This is done using the average option of the discard command, which sets the minimum poll interval and headway from the default 4 (16 s) to a value in the range 3 (8 s) to 6 (64 s). Larger values than 4 might be appropriate for very busy public servers.</p>
<p>Rate management applies also to Autokey messages. This fixes a problem when iburst and autokey are both in play and when for some reason an association with iburst is repeatedly restarted. This may appear spooky to some folks that frequently restart a client for testing. The server remembers. Further information is in the current web documentation.</p>
<h4>5. Frequency File</h4>
<p>Initial frequency training has always been a problem, as it can take a very long time to trim the frequency estimate to nominal values. Once this happens and the frequency file is written, subsequent reboots will restore the frequency and frequency training is avoided. The problem is exacerbated using toll modem services such as ACTS which make a call at each poll interval. Until the training is complete the poll interval is held below the desired maximum as toll charges accrue.</p>
<p>The problem was solved by changing the clock state machine so that, if no frequency file is available, an initial training interval of 300 s occurs, after which the frequency is directly calculated and the discipline then turned over to the feedback loop. The choice of 300 s is based on the assumption that time can be estimated within 1 ms and the resulting frequency estimate within nominal 1 PPM.</p>
<p>Note that once the initial time offset is either stepped or slewed, no further time offsets are amortized during the training period. If the frequency error is large, the time offset at the end of the period can be moderately large, which then must be amortized by the feedback loop. While this may take up to an hour and result in a minor frequency tweak, the behavior is very much better than without the initial training. The remedy would require intricate and fragile code revisions.</p>
<p>In the original design the frequency file was written at one-hour intervals. This apparently makes embedded systems folks nervous, since this can tire the flash NVRAM after several years. The interval between writes now depends on the ambient clock stability and normally maxes out at something over one day unless the frequency takes an unusual twitch. </p>
<h4>6. Leapseconds</h4>
<p>The leapsecond processing has been overhauled once again. The problem is to avoid fake leap warnings displayed by an errant server and to insure correct response in case of large time changes which might validate or invalidate arming for a subsequent leap. No leap information is used unless the client is synchronized to a proventic source. The values obtained from an Autokey server or peer are updated if newer than the current values. Server leap warning bits are disregarded if these values are available. If not, and if either a majority of the servers show leap warning bits or if one or more of the survivors are a reference clock with leap warning bit, the leap is armed. If armed by server leap warning bits and these provisions no longer prevail, the leap is disarmed. The NTPv4 protocol specifically does not speak to this issue.</p>
<p>The leap armed condition is displayed in the host status word. Transitions between warnings and no warnings are reported to the protostats file, system log and traps.</p>
<h4>7. Orphan Mode and Local Clock Driver</h4>
<p>The orphan mode code has been overhauled to correct some minor bugs and to clarify operation under normal and recovery conditions. The requirement that all subnet hosts have orphan configuration has been removed. The only requirement is that the orphan clients on the DMZ network sharing the root server(s) be so configured The scheme now works if the root servers are configured with each other, either in symmetric or broadcast modes. Orphan mode is not considered in the NTPv4 protocol specification.</p>
<p>The local clock driver can be very dangerous when used as a fallback when connectivity to Internet time servers is interrupted. Orphan mode was designed to reduce the need for the local clock driver, as it is active only if no server is available. The local clock driver has been modified to have the same characteristics, regardless of stratum. Only if the host running the local clock driver loses all servers, regardless of stratum, is the driver activated. Thus, it is possible, but not recommended, to run the driver at any stratum, including zero.</p>
<h4>8. Poll Rate Control</h4>
<p>One of the most persistent problems is when after long operation and then a failure and then subsequently recovery, a client can take a long time to refresh the clock filter and resynchronize. Once the client has backed off the poll interval after a lengthy outage, it sends polls at that interval until receiving a response. At that time it temporarily retries at the minimum poll interval to fill up the clock filter. If iburst is configured, this will happen after 10 seconds or so and the client then resumes its poll interval required by the discipline time constant. This avoids needless network traffic while the poll interval increases gradually to the maximum. Further information is in the current web documentation.</p>
<p>The same thing happens on initial startup or when an association is restarted. The intent is to avoid a blast of <tt>iburst</tt> packets unless the server actually responds to the first one and to retry only while responding to the the rate controls.</p>
<p>In order to speed response to initial startup when a reference clock is available, the clock is set on the first message received from the driver. This exposed an interesting bug, now fixed, with the ACTS modem driver, which began prematurely to ramp up the poll interval.</p>
<h4>9. Autokey</h4>
<p>The management of host and group names with respect to Autokey configuration and key generation has been removed and simplified. On host certificates, the subject and issuer fields carry the group name, while other certificates carry the host name, which can be an arbitrary string having nothing to do with the DNS name. This opens up a possible future plan to use the Autokey name rather than the IP address when constructing the session key. It also allows a client to easily switch from one group to another without regenerating the certificate. Further information is in the current web documentation and in the latest Autokey ID.</p>
<p>Various protocol refinements have been done in the Autokey state machine. A bug was found in symmetric modes where the peer cookies were not EXORed. A bug was found in processing the certificate cache when a participant was a client of two or more server in the same group which themselves had certificate trails to different trusted hosts.</p>
<p>The protocol machine is now restarted every several days in order to update certificates and leapseconds values when they are changed.</p>
<h4> 10. Report, Log and Event Codes </h4>
<p>The status, selection, source, event and log decodes have been adjusted for consistency. Some of the decodes were missing, some with errors and a few new ones added. Old versions of ntpq continue to work without change, but display a new code as space. Except for the new codes, this behavior is consistent with RFC 1305 and proposed for the NTPv4 protocol specification.</p>
<p>The ntpq as command has been changed to fix some very old bugs. The display is now consistent with the system and peer billboards. The authentication state is correctly displayed for broadcast server associations.</p>
<p>The event reporting has been cleaned up for more straightforward interpretation by a remote agent. All significant state transitions are reported, including clock state machine changes, mobilization, /demobilization, system and peer restart, system peer change, panic stop and so forth.</p>
<p>A new protostats monitoring file facility has been added. It works just like the other monitor files. All events are recorded to this file as reported and optionally to the system log. Many reports that sometimes clog up the system log are more usefully directed to this file. The reports also trigger a trap packet that can be sent via an agent to page an administrator.</p>
<p>When the current mode-6 monitoring protocol was designed circa 1988 the considered intent was that monitoring functions rely only on the NTP packet itself and the system, peer and clock status words provided in the mode-6 packet. While the strongly felt advice at that time was to avoid reformatting the plain ASCII text sent by the server, at various times folks have cheated and reformatted the text. In some places this is good, like displaying the filter shift register; in some places this is bad, like reformatting the timestamps. There is nothing much that can be done about this now without angry mobs rioting when forced to upgrade to a new ntpq. I will not rule this out in future.</p>
<p>A more serious comment has to do with using other than the NTP packet, status words and events for monitoring purposes. Emphasis added: monitors should not parse such things as the flash codes, clock state or anything else not called out in the NTPv4 specification. The clock state machine is defined in the specification, but no specific numbers are assigned to the states.</p>
<p>When the numbers were changed to align for reporting purposes, some scripts no longer worked. The scripts should be changed to use only the leap and select fields of the system status word. If the leap field is other than 0, the client has synchronized at least once; if the select field is other than 0, the client is currently synchronized to the source indicated in the decode.</p>
<h4>11. Two-step and timestamp capture</h4>
<p>A number of interesting ideas were found in the IEEE 1588 Precision Time Protocol specification. One of them was the two-step protocol in which the transmit timestamp is sent in a following message. However, the PTP design operates only in a master-slave configuration and is not directly usable in NTP. The protocol was adapted to the NTP symmetric design, which requires four state variables rather than two. It is described on <a href="http://www.eecis.udel.edu/~mills/stamp.html">Timestamp Capture Principles</a>. This might be an interesting project for future research.</p>
<p>A detailed study of the timestamp capture opportunities for both hardware and software timestamping revealed that the most accurate and interoperable design involves the transmit timestamp at the beginning of the packet and then receive timestamp at the end. This makes it possible to accurately measure the offset and delay even if the ends of the synchronization path operate at different rates. It is described on the Timestamp Capture Principles page.</p>
<h4>12. Windows client bug</h4>
<p>The Windows XP and Vista clients send the NTP request in symmetric active mode rather than client mode. An unsuspecting server could mobilize a symmetric passive association, which is a serious security vulnerability. The NTPv4 servers, including those at NIST and USNO, discard symmetric active requests unless cryptographically authenticated, so Windows clients do not work. The Microsoft KB 875424 discusses the preferred workaround; however, an optional workaround is now available so that, if the request is not authenticated, the server responds with symmetric passive mode, but without mobilize an association. The workaround is enabled with the WINTIME build option.</p>
<p>The spec assumes that either peer in symmetric modes can synchronize the other should a peer lose all sources. The workaround violates that assumption and some legitimate configuration might be badly misused. It should be used only with this understanding.</p>
<h4>13. Autonomous configuration</h4>
<p>The autonomous configuration (pool and manycast) code was refined to more reliably prune excess servers. If a truechimer is discarded by the clustering algorithm and the total number of survivors is greater than the maxclock option of the tos command, it is considered excess and shows a &quot;#&quot; tally code. If the association is ephemeral and survives the clustering algorithm, the watchdog counter is reset. If the watchdog timer expires and the total number of associations is greater than the maxclock option of the tos command, it is demobilized. This behavior is not considered in the NTPv4 protocol specification.</p>
<h4>14. Code ornamentation</h4>
<p>When auditing the code and figuring out its historic origin and evolution, additional commentary has been added so future generations can figure it out, too. </p>
<p>David L. Mills<br>
17 March 2008<br>
</p>
<hr>
<p><script type="text/javascript" language="javascript" src="scripts/footer.txt"></script></p>
</body>
</html>

Some files were not shown because too many files have changed in this diff Show More