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

Virgin import of ntpd 4.1.0

Browse Source
This commit is contained in:
Ollivier Robert 2001-08-29 14:35:15 +00:00
parent 1c80946020
commit 224ba2bd37
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/vendor/ntp/dist/; revision=82498
266 changed files with 43925 additions and 22952 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

242
contrib/ntp/COPYRIGHT
View File

@ -2,162 +2,172 @@ This file is automatically generated from html/copyright.htm
Copyright Notice
[INLINE] "Clone me," says Dolly sheepishly
[sheepb.jpg] "Clone me," says Dolly sheepishly
_________________________________________________________________
The following copyright notice applies to all files collectively
called the Network Time Protocol Version 4 Distribution. Unless
specifically declared otherwise in an individual file, this notice
applies as if the text was explicitly included in the file.
/***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2000 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission *
* notice appear in supporting documentation, and that the name *
* University of Delaware not be used in advertising or publicity *
* pertaining to distribution of the software without specific, *
* written prior permission. The University of Delaware makes no *
* representations about the suitability this software for any *
* purpose. It is provided "as is" without express or implied *
* warranty. *
* *
***********************************************************************
*/
***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2001 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission *
* notice appear in supporting documentation, and that the name *
* University of Delaware not be used in advertising or publicity *
* pertaining to distribution of the software without specific, *
* written prior permission. The University of Delaware makes no *
* representations about the suitability this software for any *
* purpose. It is provided "as is" without express or implied *
* warranty. *
* *
***********************************************************************
The following individuals contributed in part to the Network Time
Protocol Distribution Version 4 and are acknowledged as authors of
this work.
1. [1]Mark Andrews <marka@syd.dms.csiro.au> Leitch atomic clock
controller
2. [2]Viraj Bais <vbais@mailman1.intel.com> and [3]Clayton Kirkwood
2. [2]Bernd Altmeier <altmeier@atlsoft.de> hopf Elektronik serial
line and PCI-bus devices
3. [3]Viraj Bais <vbais@mailman1.intel.com> and [4]Clayton Kirkwood
<kirkwood@striderfm.intel.com> port to WindowsNT 3.5
3. [4]Michael Barone <michael,barone@lmco.com> GPSVME fixes
4. [5]Karl Berry <karl@owl.HQ.ileaf.com> syslog to file option
5. [6]Greg Brackley <greg.brackley@bigfoot.com> Major rework of WINNT
4. [5]Michael Barone <michael,barone@lmco.com> GPSVME fixes
5. [6]Karl Berry <karl@owl.HQ.ileaf.com> syslog to file option
6. [7]Greg Brackley <greg.brackley@bigfoot.com> Major rework of WINNT
port. Clean up recvbuf and iosignal code into separate modules.
6. [7]Piete Brooks <Piete.Brooks@cl.cam.ac.uk> MSF clock driver,
7. [8]Marc Brett <Marc.Brett@westgeo.com> Magnavox GPS clock driver
8. [9]Piete Brooks <Piete.Brooks@cl.cam.ac.uk> MSF clock driver,
Trimble PARSE support
7. [8]Steve Clift <clift@ml.csiro.au> OMEGA clock driver
8. [9]Casey Crellin <casey@csc.co.za> vxWorks (Tornado) port and help
with target configuration
9. [10]Sven Dietrich <sven_dietrich@trimble.com> Palisade reference
9. [10]Reg Clemens <reg@dwf.com> Oncore driver (Current maintainer)
10. [11]Steve Clift <clift@ml.csiro.au> OMEGA clock driver
11. [12]Casey Crellin <casey@csc.co.za> vxWorks (Tornado) port and
help with target configuration
12. [13]Sven Dietrich <sven_dietrich@trimble.com> Palisade reference
clock driver, NT adj. residuals, integrated Greg's Winnt port.
10. [11]John A. Dundas III <dundas@salt.jpl.nasa.gov> Apple A/UX port
11. [12]Torsten Duwe <duwe@immd4.informatik.uni-erlangen.de> Linux
13. [14]John A. Dundas III <dundas@salt.jpl.nasa.gov> Apple A/UX port
14. [15]Torsten Duwe <duwe@immd4.informatik.uni-erlangen.de> Linux
port
12. [13]Dennis Ferguson <dennis@mrbill.canet.ca> foundation code for
15. [16]Dennis Ferguson <dennis@mrbill.canet.ca> foundation code for
NTP Version 2 as specified in RFC-1119
13. [14]Glenn Hollinger <glenn@herald.usask.ca> GOES clock driver
14. [15]Mike Iglesias <iglesias@uci.edu> DEC Alpha port
15. [16]Jim Jagielski <jim@jagubox.gsfc.nasa.gov> A/UX port
16. [17]Jeff Johnson <jbj@chatham.usdesign.com> massive prototyping
16. [17]Glenn Hollinger <glenn@herald.usask.ca> GOES clock driver
17. [18]Mike Iglesias <iglesias@uci.edu> DEC Alpha port
18. [19]Jim Jagielski <jim@jagubox.gsfc.nasa.gov> A/UX port
19. [20]Jeff Johnson <jbj@chatham.usdesign.com> massive prototyping
overhaul
17. [18]William L. Jones <jones@hermes.chpc.utexas.edu> RS/6000 AIX
modifications, HPUX modifications
18. [19]Hans Lambermont <Hans.Lambermont@nl.origin-it.com> or
[20]<H.Lambermont@chello.nl> ntpsweep
19. [21]Frank Kardel [22]<Frank.Kardel@informatik.uni-erlangen.de>
20. [21]Hans Lambermont <Hans.Lambermont@nl.origin-it.com> or
[22]<H.Lambermont@chello.nl> ntpsweep
21. [23]Poul-Henning Kamp <phk@FreeBSD.ORG> Oncore driver (Original
author)
22. [24]Frank Kardel [25]<Frank.Kardel@informatik.uni-erlangen.de>
PARSE <GENERIC> driver (14 reference clocks), STREAMS modules for
PARSE, support scripts, syslog cleanup
20. [23]Dave Katz <dkatz@cisco.com> RS/6000 AIX port
21. [24]Craig Leres <leres@ee.lbl.gov> 4.4BSD port, ppsclock,
Maganavox GPS clock driver
22. [25]George Lindholm <lindholm@ucs.ubc.ca> SunOS 5.1 port
23. [26]Louis A. Mamakos <louie@ni.umd.edu> MD5-based authentication
24. [27]Lars H. Mathiesen <thorinn@diku.dk> adaptation of foundation
23. [26]William L. Jones <jones@hermes.chpc.utexas.edu> RS/6000 AIX
modifications, HPUX modifications
24. [27]Dave Katz <dkatz@cisco.com> RS/6000 AIX port
25. [28]Craig Leres <leres@ee.lbl.gov> 4.4BSD port, ppsclock, Magnavox
GPS clock driver
26. [29]George Lindholm <lindholm@ucs.ubc.ca> SunOS 5.1 port
27. [30]Louis A. Mamakos <louie@ni.umd.edu> MD5-based authentication
28. [31]Lars H. Mathiesen <thorinn@diku.dk> adaptation of foundation
code for Version 3 as specified in RFC-1305
25. [28]David L. Mills <mills@udel.edu> Version 4 foundation: clock
29. [32]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
26. [29]Wolfgang Moeller <moeller@gwdgv1.dnet.gwdg.de> VMS port
27. [30]Jeffrey Mogul <mogul@pa.dec.com> ntptrace utility
28. [31]Tom Moore <tmoore@fievel.daytonoh.ncr.com> i386 svr4 port
29. [32]Derek Mulcahy <derek@toybox.demon.co.uk> and [33]Damon
30. [33]Wolfgang Moeller <moeller@gwdgv1.dnet.gwdg.de> VMS port
31. [34]Jeffrey Mogul <mogul@pa.dec.com> ntptrace utility
32. [35]Tom Moore <tmoore@fievel.daytonoh.ncr.com> i386 svr4 port
33. [36]Kamal A Mostafa <kamal@whence.com> SCO OpenServer port
34. [37]Derek Mulcahy <derek@toybox.demon.co.uk> and [38]Damon
Hart-Davis <d@hd.org> ARCRON MSF clock driver
30. [34]Rainer Pruy <Rainer.Pruy@informatik.uni-erlangen.de>
35. [39]Rainer Pruy <Rainer.Pruy@informatik.uni-erlangen.de>
monitoring/trap scripts, statistics file handling
31. [35]Dirce Richards <dirce@zk3.dec.com> Digital UNIX V4.0 port
32. [36]Wilfredo Sánchez <wsanchez@apple.com> added support for
36. [40]Dirce Richards <dirce@zk3.dec.com> Digital UNIX V4.0 port
37. [41]Wilfredo Sánchez <wsanchez@apple.com> added support for
NetInfo
33. [37]Nick Sayer <mrapple@quack.kfu.com> SunOS streams modules
34. [38]Jack Sasportas <jack@innovativeinternet.com> Saved a Lot of
38. [42]Nick Sayer <mrapple@quack.kfu.com> SunOS streams modules
39. [43]Jack Sasportas <jack@innovativeinternet.com> Saved a Lot of
space on the stuff in the html/pic/ subdirectory
35. [39]Ray Schnitzler <schnitz@unipress.com> Unixware1 port
36. [40]Michael Shields <shields@tembel.org> USNO clock driver
37. [41]Jeff Steinman <jss@pebbles.jpl.nasa.gov> Datum PTS clock
40. [44]Ray Schnitzler <schnitz@unipress.com> Unixware1 port
41. [45]Michael Shields <shields@tembel.org> USNO clock driver
42. [46]Jeff Steinman <jss@pebbles.jpl.nasa.gov> Datum PTS clock
driver
38. [42]Harlan Stenn <harlan@pfcs.com> GNU automake/autoconfigure
43. [47]Harlan Stenn <harlan@pfcs.com> GNU automake/autoconfigure
makeover, various other bits (see the ChangeLog)
39. [43]Kenneth Stone <ken@sdd.hp.com> HP-UX port
40. [44]Ajit Thyagarajan <ajit@ee.udel.edu>IP multicast/anycast
44. [48]Kenneth Stone <ken@sdd.hp.com> HP-UX port
45. [49]Ajit Thyagarajan <ajit@ee.udel.edu>IP multicast/anycast
support
41. [45]Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp>TRAK clock
46. [50]Tomoaki TSURUOKA <tsuruoka@nc.fukuoka-u.ac.jp>TRAK clock
driver
42. [46]Paul A Vixie <vixie@vix.com> TrueTime GPS driver, generic
47. [51]Paul A Vixie <vixie@vix.com> TrueTime GPS driver, generic
TrueTime clock driver
43. [47]Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> corrected and
48. [52]Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> corrected and
validated HTML documents according to the HTML DTD
_________________________________________________________________
[48][LINK]
[53]gif
[49]David L. Mills <mills@udel.edu>
[54]David L. Mills <mills@udel.edu>
References
1. mailto:marka@syd.dms.csiro.au
2. mailto:vbais@mailman1.intel.co
3. mailto:kirkwood@striderfm.intel.com
4. mailto:michael.barone@lmco.com
5. mailto:karl@owl.HQ.ileaf.com
6. mailto:greg.brackley@bigfoot.com
7. mailto:Piete.Brooks@cl.cam.ac.uk
8. mailto:clift@ml.csiro.au
9. mailto:casey@csc.co.za
10. mailto:Sven_Dietrich@trimble.COM
11. mailto:dundas@salt.jpl.nasa.gov
12. mailto:duwe@immd4.informatik.uni-erlangen.de
13. mailto:dennis@mrbill.canet.ca
14. mailto:glenn@herald.usask.ca
15. mailto:iglesias@uci.edu
16. mailto:jagubox.gsfc.nasa.gov
17. mailto:jbj@chatham.usdesign.com
18. mailto:jones@hermes.chpc.utexas.edu
19. mailto:Hans.Lambermont@nl.origin-it.com
20. mailto:H.Lambermont@chello.nl
21. http://www4.informatik.uni-erlangen.de/~kardel
22. mailto:Frank.Kardel@informatik.uni-erlangen.de
23. mailto:dkatz@cisco.com
24. mailto:leres@ee.lbl.gov
25. mailto:lindholm@ucs.ubc.ca
26. mailto:louie@ni.umd.edu
27. mailto:thorinn@diku.dk
28. mailto:mills@udel.edu
29. mailto:moeller@gwdgv1.dnet.gwdg.de
30. mailto:mogul@pa.dec.com
31. mailto:tmoore@fievel.daytonoh.ncr.com
32. mailto:derek@toybox.demon.co.uk
33. mailto:d@hd.org
34. mailto:Rainer.Pruy@informatik.uni-erlangen.de
35. mailto:dirce@zk3.dec.com
36. mailto:wsanchez@apple.com
37. mailto:mrapple@quack.kfu.com
38. mailto:jack@innovativeinternet.com
39. mailto:schnitz@unipress.com
40. mailto:shields@tembel.org
41. mailto:pebbles.jpl.nasa.gov
42. mailto:harlan@pfcs.com
43. mailto:ken@sdd.hp.com
44. mailto:ajit@ee.udel.edu
45. mailto:tsuruoka@nc.fukuoka-u.ac.jp
46. mailto:vixie@vix.com
47. mailto:Ulrich.Windl@rz.uni-regensburg.de
48. file://localhost/backroom/ntp4+/html/index.htm
49. mailto:mills@udel.edu
2. mailto:altmeier@atlsoft.de
3. mailto:vbais@mailman1.intel.co
4. mailto:kirkwood@striderfm.intel.com
5. mailto:michael.barone@lmco.com
6. mailto:karl@owl.HQ.ileaf.com
7. mailto:greg.brackley@bigfoot.com
8. mailto:Marc.Brett@westgeo.com
9. mailto:Piete.Brooks@cl.cam.ac.uk
10. mailto:reg@dwf.com
11. mailto:clift@ml.csiro.au
12. mailto:casey@csc.co.za
13. mailto:Sven_Dietrich@trimble.COM
14. mailto:dundas@salt.jpl.nasa.gov
15. mailto:duwe@immd4.informatik.uni-erlangen.de
16. mailto:dennis@mrbill.canet.ca
17. mailto:glenn@herald.usask.ca
18. mailto:iglesias@uci.edu
19. mailto:jagubox.gsfc.nasa.gov
20. mailto:jbj@chatham.usdesign.com
21. mailto:Hans.Lambermont@nl.origin-it.com
22. mailto:H.Lambermont@chello.nl
23. mailto:phk@FreeBSD.ORG
24. http://www4.informatik.uni-erlangen.de/~kardel
25. mailto:Frank.Kardel@informatik.uni-erlangen.de
26. mailto:jones@hermes.chpc.utexas.edu
27. mailto:dkatz@cisco.com
28. mailto:leres@ee.lbl.gov
29. mailto:lindholm@ucs.ubc.ca
30. mailto:louie@ni.umd.edu
31. mailto:thorinn@diku.dk
32. mailto:mills@udel.edu
33. mailto:moeller@gwdgv1.dnet.gwdg.de
34. mailto:mogul@pa.dec.com
35. mailto:tmoore@fievel.daytonoh.ncr.com
36. mailto:kamal@whence.com
37. mailto:derek@toybox.demon.co.uk
38. mailto:d@hd.org
39. mailto:Rainer.Pruy@informatik.uni-erlangen.de
40. mailto:dirce@zk3.dec.com
41. mailto:wsanchez@apple.com
42. mailto:mrapple@quack.kfu.com
43. mailto:jack@innovativeinternet.com
44. mailto:schnitz@unipress.com
45. mailto:shields@tembel.org
46. mailto:pebbles.jpl.nasa.gov
47. mailto:harlan@pfcs.com
48. mailto:ken@sdd.hp.com
49. mailto:ajit@ee.udel.edu
50. mailto:tsuruoka@nc.fukuoka-u.ac.jp
51. mailto:vixie@vix.com
52. mailto:Ulrich.Windl@rz.uni-regensburg.de
53. file://localhost/backroom/ntp4/html/index.htm
54. mailto:mills@udel.edu

3233
contrib/ntp/ChangeLog
View File

File diff suppressed because it is too large Load Diff

2
contrib/ntp/INSTALL
View File

@ -3,7 +3,7 @@ Basic Installation
These are generic *nix installation instructions.
For Windows/NT, please see ports/winnt.
For Windows/NT, please see ports/winnt and html/hints/winnt.htm.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses

59
contrib/ntp/Makefile.am
View File

@ -1,13 +1,13 @@
#AUTOMAKE_OPTIONS = foreign dist-tarZ #distdir=$(PACKAGE)$(VERSION)
#AUTOMAKE_OPTIONS = util/ansi2knr foreign dist-tarZ no-dependencies
AUTOMAKE_OPTIONS = util/ansi2knr foreign dist-tarZ
AUTOMAKE_OPTIONS = util/ansi2knr foreign
SUBDIRS = \
scripts \
include \
ElectricFence \
librsaref \
libntp \
libparse \
librsaref \
ntpd \
ntpdate \
ntpdc \
@ -19,39 +19,48 @@ SUBDIRS = \
kernel \
util
EXTRA_DIST = ChangeLog COPYRIGHT NEWS README.cvs README.des README.hackers TODO WHERE-TO-START acconfig.h config.guess config.h.in config.sub excludes install-sh dot.emacs build NOTES.y2kfixes readme.y2kfixes results.y2kfixes
EXTRA_DIST = \
COPYRIGHT \
ChangeLog \
NEWS \
NOTES.y2kfixes \
README.cvs \
README.des \
README.hackers \
README.rsa \
TODO \
WHERE-TO-START \
acconfig.h \
build \
config.guess \
config.h.in \
config.sub \
dot.emacs \
excludes \
flock-build \
install-sh \
ntp_update \
readme.y2kfixes \
results.y2kfixes \
conf \
html \
ports
DISTCLEANFILES = .warning
#ETAGS_ARGS = $(srcdir)/Makefile.am $(srcdir)/configure.in
ETAGS_ARGS = Makefile.am configure.in acconfig.h
# DIST_CPDIRS = conf html scripts
# DIST_MKDIRS = adjtime clockstuff kernel libparse ppsclock
#DIST_HOOK_DIRS = conf html patches ports scripts
# HMS: make ports be the last directory...
DIST_HOOK_DIRS = conf html scripts ports
# DIST_HOOK_DIRS = conf html scripts ports
BUILT_SOURCES = $(srcdir)/COPYRIGHT
$(srcdir)/COPYRIGHT: html/copyright.htm
( echo "This file is automatically generated from html/copyright.htm" ; lynx -dump $(srcdir)/html/copyright.htm ) > $(srcdir)/COPYRIGHT.new && mv $(srcdir)/COPYRIGHT.new $(srcdir)/COPYRIGHT
# local-dist: dist-tarZ
dist-hook:
-for i in $(DIST_HOOK_DIRS); do \
mkdir $(distdir)/$$i ; \
cp -rp $(srcdir)/$$i $(distdir) ; \
done ; \
find $(distdir) -type d -name CVS -exec rm -rf '{}' \; ; \
# find $(distdir)/html -name '*.htm' -exec dos2unix {} {} \; ; \
# cp -rp $(srcdir)/include/winnt $(distdir)/include
dist-export: distdir
rm $(distdir)/libntp/authdes.c
cp $(distdir)/libntp/authdes.c.export $(distdir)/libntp/authdes.c
chmod -R a+r $(distdir)
mv $(distdir) $(distdir)-export
$(TAR) chozf $(distdir)-export.tar.gz $(distdir)-export
rm -rf $(distdir)-export
@find $(distdir) -type d -name CVS -print | xargs rm -rf
Makefile: .warning

368
contrib/ntp/Makefile.in
View File

@ -1,6 +1,7 @@
# Makefile.in generated automatically by automake 1.4a from Makefile.am
# Makefile.in generated automatically by automake 1.4e from Makefile.am.
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
# Free Software Foundation, Inc.
# This Makefile.in 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.
@ -31,8 +32,6 @@ mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
@ -48,7 +47,7 @@ INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_FLAG =
INSTALL_HEADER = $(INSTALL_DATA)
transform = @program_transform_name@
NORMAL_INSTALL = :
@ -57,24 +56,30 @@ POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_alias = @build_alias@
build_triplet = @build@
host_alias = @host_alias@
host_triplet = @host@
target_alias = @target_alias@
target_triplet = @target@
@SET_MAKE@
AMDEP = @AMDEP@
AMTAR = @AMTAR@
AUTOKEY = @AUTOKEY@
AWK = @AWK@
CC = @CC@
CFLAGS = @CFLAGS@
CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CPP = @CPP@
CXX = @CXX@
CXXCPP = @CXXCPP@
DCFD = @DCFD@
DEPDIR = @DEPDIR@
EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
INSTALL_STRIP_PROGRAM_ENV = @INSTALL_STRIP_PROGRAM_ENV@
LDFLAGS = @LDFLAGS@
LIBPARSE = @LIBPARSE@
LIBRSAREF = @LIBRSAREF@
@ -86,30 +91,41 @@ MAKE_LIBPARSE = @MAKE_LIBPARSE@
MAKE_LIBPARSE_KERNEL = @MAKE_LIBPARSE_KERNEL@
MAKE_LIBRSAREF = @MAKE_LIBRSAREF@
MAKE_NTPTIME = @MAKE_NTPTIME@
MAKE_NTP_GENKEYS = @MAKE_NTP_GENKEYS@
MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
OPENSSL_LIB = @OPENSSL_LIB@
PACKAGE = @PACKAGE@
PATH_PERL = @PATH_PERL@
PATH_SH = @PATH_SH@
PROPDELAY = @PROPDELAY@
RANLIB = @RANLIB@
RSADIR = @RSADIR@
RSAOBJS = @RSAOBJS@
RSAREF = @RSAREF@
RSASRCS = @RSASRCS@
STRIP = @STRIP@
TESTDCF = @TESTDCF@
U = @U@
VERSION = @VERSION@
_am_include = @_am_include@
install_sh = @install_sh@
#AUTOMAKE_OPTIONS = foreign dist-tarZ #distdir=$(PACKAGE)$(VERSION)
#AUTOMAKE_OPTIONS = util/ansi2knr foreign dist-tarZ no-dependencies
AUTOMAKE_OPTIONS = util/ansi2knr foreign dist-tarZ
AUTOMAKE_OPTIONS = util/ansi2knr foreign
SUBDIRS = \
scripts \
include \
ElectricFence \
librsaref \
libntp \
libparse \
librsaref \
ntpd \
ntpdate \
ntpdc \
@ -122,46 +138,70 @@ SUBDIRS = \
util
EXTRA_DIST = ChangeLog COPYRIGHT NEWS README.cvs README.des README.hackers TODO WHERE-TO-START acconfig.h config.guess config.h.in config.sub excludes install-sh dot.emacs build NOTES.y2kfixes readme.y2kfixes results.y2kfixes
EXTRA_DIST = \
COPYRIGHT \
ChangeLog \
NEWS \
NOTES.y2kfixes \
README.cvs \
README.des \
README.hackers \
README.rsa \
TODO \
WHERE-TO-START \
acconfig.h \
build \
config.guess \
config.h.in \
config.sub \
dot.emacs \
excludes \
flock-build \
install-sh \
ntp_update \
readme.y2kfixes \
results.y2kfixes \
conf \
html \
ports
DISTCLEANFILES = .warning
#ETAGS_ARGS = $(srcdir)/Makefile.am $(srcdir)/configure.in
ETAGS_ARGS = Makefile.am configure.in acconfig.h
# DIST_CPDIRS = conf html scripts
# DIST_MKDIRS = adjtime clockstuff kernel libparse ppsclock
#DIST_HOOK_DIRS = conf html patches ports scripts
# HMS: make ports be the last directory...
DIST_HOOK_DIRS = conf html scripts ports
# DIST_HOOK_DIRS = conf html scripts ports
BUILT_SOURCES = $(srcdir)/COPYRIGHT
CVO = `$(srcdir)/config.guess`
BHOST = `(hostname || uname -n)`
EXEEXT =
OBJEXT = o
subdir = .
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_HEADER = config.h
CONFIG_CLEAN_FILES =
DIST_SOURCES =
DIST_COMMON = README ./stamp-h.in ChangeLog INSTALL Makefile.am \
Makefile.in NEWS TODO acconfig.h aclocal.m4 config.guess config.h.in \
config.sub configure configure.in depcomp install-sh missing \
mkinstalldirs
CONFIG_CLEAN_FILES =
DIST_SOURCES =
DIST_COMMON = README ./stamp-h.in ChangeLog INSTALL Makefile.am \
Makefile.in NEWS TODO acconfig.h acinclude.m4 aclocal.m4 config.guess \
config.h.in config.sub configure configure.in depcomp install-sh \
missing mkinstalldirs
DIST_SUBDIRS = $(SUBDIRS)
all: $(BUILT_SOURCES) config.h
$(MAKE) $(AM_MAKEFLAGS) all-recursive
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status $(BUILT_SOURCES)
cd $(top_builddir) \
&& CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status
$(ACLOCAL_M4): configure.in
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && \
$(AUTOMAKE) --foreign Makefile
$(ACLOCAL_M4): configure.in acinclude.m4
cd $(srcdir) && $(ACLOCAL)
config.status: $(srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
@ -192,26 +232,18 @@ $(srcdir)/./stamp-h.in: $(top_srcdir)/configure.in $(ACLOCAL_M4) acconfig.h
cd $(top_srcdir) && $(AUTOHEADER)
@mv $(srcdir)/./stamp-h.inT $(srcdir)/./stamp-h.in
mostlyclean-hdr:
clean-hdr:
distclean-hdr:
-rm -f config.h
maintainer-clean-hdr:
# This directory's subdirectories are mostly independent; you can cd
# into them and run `make' without going through this Makefile.
# To change the values of `make' variables: instead of editing Makefiles,
# (1) if the variable is set in `config.status', edit `config.status'
# (which will cause the Makefiles to be regenerated when you run `make');
# (2) otherwise, pass the desired values on the `make' command line.
@SET_MAKE@
all-recursive install-data-recursive install-exec-recursive \
installdirs-recursive install-recursive uninstall-recursive \
installdirs-recursive install-recursive uninstall-recursive \
install-info-recursive uninstall-info-recursive \
check-recursive installcheck-recursive info-recursive dvi-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
@ -235,11 +267,16 @@ mostlyclean-recursive clean-recursive distclean-recursive \
maintainer-clean-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
rev=''; list='$(SUBDIRS)'; for subdir in $$list; do \
rev="$$subdir $$rev"; \
if test "$$subdir" = "."; then dot_seen=yes; else :; fi; \
case "$@" in \
distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
*) list='$(SUBDIRS)' ;; \
esac; \
rev=''; for subdir in $$list; do \
if test "$$subdir" = "."; then :; else \
rev="$$subdir $$rev"; \
fi; \
done; \
test "$$dot_seen" = "no" && rev=". $$rev"; \
rev="$$rev ."; \
target=`echo $@ | sed s/-recursive//`; \
for subdir in $$rev; do \
echo "Making $$target in $$subdir"; \
@ -265,7 +302,7 @@ ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
mkid -f$$here/ID $$unique $(LISP)
mkid -fID $$unique $(LISP)
TAGS: tags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
@ -285,19 +322,60 @@ TAGS: tags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) \
test -z "$(ETAGS_ARGS)config.h.in$$unique$(LISP)$$tags" \
|| etags $(ETAGS_ARGS) $$tags config.h.in $$unique $(LISP)
mostlyclean-tags:
clean-tags:
GTAGS:
here=`CDPATH=: && cd $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $$here
distclean-tags:
-rm -f TAGS ID
maintainer-clean-tags:
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)
top_distdir = .
distdir = $(top_distdir)/$(PACKAGE)-$(VERSION)
GZIP_ENV = --best
distdir: $(DISTFILES)
-chmod -R a+w $(distdir) >/dev/null 2>&1; rm -rf $(distdir)
mkdir $(distdir)
$(mkinstalldirs) $(distdir)/scripts
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pR $$d/$$file $(distdir) \
|| exit 1; \
else \
test -f $(distdir)/$$file \
|| cp -p $$d/$$file $(distdir)/$$file \
|| exit 1; \
fi; \
done
for subdir in $(SUBDIRS); do \
if test "$$subdir" = .; then :; else \
test -d $(distdir)/$$subdir \
|| mkdir $(distdir)/$$subdir \
|| exit 1; \
(cd $$subdir && \
$(MAKE) $(AM_MAKEFLAGS) \
top_distdir="$(top_distdir)" \
distdir=../$(distdir)/$$subdir \
distdir) \
|| exit 1; \
fi; \
done
$(MAKE) $(AM_MAKEFLAGS) \
top_distdir="${top_distdir}" distdir="$(distdir)" \
dist-hook
-find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r $(distdir)
dist: distdir
$(AMTAR) chof - $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz
-chmod -R a+w $(distdir) >/dev/null 2>&1; rm -rf $(distdir)
# This target untars the dist file and tries a VPATH configuration. Then
# it guarantees that the distribution is self-contained by making another
# tarfile.
@ -321,90 +399,32 @@ distcheck: dist
&& $(MAKE) $(AM_MAKEFLAGS) dist \
&& $(MAKE) $(AM_MAKEFLAGS) distclean \
&& rm -f $(distdir).tar.gz \
&& test `find . -type f -print | wc -l` -eq 0
&& (test `find . -type f -print | wc -l` -eq 0 \
|| (echo "Error: files left after distclean" 1>&2; \
exit 1) )
-chmod -R a+w $(distdir) > /dev/null 2>&1; rm -rf $(distdir)
@banner="$(distdir).tar.gz is ready for distribution"; \
dashes=`echo "$$banner" | sed s/./=/g`; \
echo "$$dashes"; \
echo "$$banner"; \
echo "$$dashes"
dist: distdir
-find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r $(distdir)
$(AMTAR) chof - $(distdir) | GZIP=$(GZIP_ENV) gzip -c > $(distdir).tar.gz
-chmod -R a+w $(distdir) > /dev/null 2>&1; rm -rf $(distdir)
dist-tarZ: distdir
-find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r $(distdir)
$(AMTAR) chof - $(distdir) | compress -c > $(distdir).tar.Z
-chmod -R a+w $(distdir) > /dev/null 2>&1; rm -rf $(distdir)
dist-all: distdir
-find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r $(distdir)
$(AMTAR) chof - $(distdir) | GZIP=$(GZIP_ENV) gzip -c > $(distdir).tar.gz
$(AMTAR) chof - $(distdir) | compress -c > $(distdir).tar.Z
-chmod -R a+w $(distdir) > /dev/null 2>&1; rm -rf $(distdir)
distdir: $(DISTFILES)
-chmod -R a+w $(distdir) > /dev/null 2>&1; rm -rf $(distdir)
mkdir $(distdir)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pR $$d/$$file $(distdir); \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
fi; \
done
for subdir in $(SUBDIRS); do \
if test "$$subdir" = .; then :; else \
test -d $(distdir)/$$subdir \
|| mkdir $(distdir)/$$subdir \
|| exit 1; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir=../$(distdir) distdir=../$(distdir)/$$subdir distdir) \
|| exit 1; \
fi; \
done
$(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-hook
info-am:
info: info-recursive
dvi-am:
dvi: dvi-recursive
@echo "$(distdir).tar.gz is ready for distribution" | \
sed 'h;s/./=/g;p;x;p;x'
check-am: all-am
check: check-recursive
installcheck-am:
installcheck: installcheck-recursive
all-recursive-am: config.h
$(MAKE) $(AM_MAKEFLAGS) all-recursive
install-exec-am:
install-exec: install-exec-recursive
install-data-am:
install-data: install-data-recursive
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-recursive
uninstall-am:
uninstall: uninstall-recursive
all-am: Makefile config.h
all-redirect: all-recursive-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
installdirs: installdirs-recursive
installdirs-am:
install: install-recursive
install-exec: install-exec-recursive
install-data: install-data-recursive
uninstall: uninstall-recursive
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-recursive
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
INSTALL_PROGRAM_ENV='$(INSTALL_STRIP_PROGRAM_ENV)' install
mostlyclean-generic:
@ -413,68 +433,72 @@ clean-generic:
distclean-generic:
-rm -f Makefile $(CONFIG_CLEAN_FILES)
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
-test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-rm -f Makefile.in
-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
mostlyclean-am: mostlyclean-hdr mostlyclean-tags mostlyclean-generic
mostlyclean: mostlyclean-recursive
clean-am: clean-hdr clean-tags clean-generic mostlyclean-am
clean: clean-recursive
distclean-am: distclean-hdr distclean-tags distclean-generic clean-am
clean-am: clean-generic mostlyclean-am
dist-all: dist
distclean: distclean-recursive
-rm -f config.status
maintainer-clean-am: maintainer-clean-hdr maintainer-clean-tags \
maintainer-clean-generic distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
distclean-am: clean-am distclean-generic distclean-hdr distclean-tags
dvi:
dvi-am:
info:
info-am:
install-data-am:
install-exec-am:
install-info:
install-man:
installcheck-am:
maintainer-clean: maintainer-clean-recursive
-rm -f config.status
.PHONY: mostlyclean-hdr distclean-hdr clean-hdr maintainer-clean-hdr \
install-recursive uninstall-recursive install-data-recursive \
uninstall-data-recursive install-exec-recursive \
uninstall-exec-recursive installdirs-recursive uninstalldirs-recursive \
all-recursive check-recursive installcheck-recursive info-recursive \
dvi-recursive mostlyclean-recursive distclean-recursive clean-recursive \
maintainer-clean-recursive tags tags-recursive mostlyclean-tags \
distclean-tags clean-tags maintainer-clean-tags distdir info-am info \
dvi-am dvi check check-am installcheck-am installcheck all-recursive-am \
install-exec-am install-exec install-data-am install-data install-am \
install uninstall-am uninstall all-redirect all-am all install-strip \
installdirs-am installdirs mostlyclean-generic distclean-generic \
clean-generic maintainer-clean-generic clean mostlyclean distclean \
maintainer-clean
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-recursive
mostlyclean-am: mostlyclean-generic
.PHONY: all all-am all-recursive check check-am check-recursive clean \
clean-generic clean-recursive dist dist-all distcheck distclean \
distclean-generic distclean-hdr distclean-recursive \
distclean-tags distdir dvi dvi-am dvi-recursive info info-am \
info-recursive install install-am install-data install-data-am \
install-data-recursive install-exec install-exec-am \
install-exec-recursive install-info install-info-recursive \
install-man install-recursive install-strip installcheck \
installcheck-am installcheck-recursive installdirs \
installdirs-am installdirs-recursive maintainer-clean \
maintainer-clean-generic maintainer-clean-recursive mostlyclean \
mostlyclean-generic mostlyclean-recursive tags tags-recursive \
uninstall uninstall-am uninstall-info-recursive \
uninstall-recursive
$(srcdir)/COPYRIGHT: html/copyright.htm
( echo "This file is automatically generated from html/copyright.htm" ; lynx -dump $(srcdir)/html/copyright.htm ) > $(srcdir)/COPYRIGHT.new && mv $(srcdir)/COPYRIGHT.new $(srcdir)/COPYRIGHT
# local-dist: dist-tarZ
dist-hook:
-for i in $(DIST_HOOK_DIRS); do \
mkdir $(distdir)/$$i ; \
cp -rp $(srcdir)/$$i $(distdir) ; \
done ; \
find $(distdir) -type d -name CVS -exec rm -rf '{}' \; ; \
# find $(distdir)/html -name '*.htm' -exec dos2unix {} {} \; ; \
# cp -rp $(srcdir)/include/winnt $(distdir)/include
dist-export: distdir
rm $(distdir)/libntp/authdes.c
cp $(distdir)/libntp/authdes.c.export $(distdir)/libntp/authdes.c
chmod -R a+r $(distdir)
mv $(distdir) $(distdir)-export
$(TAR) chozf $(distdir)-export.tar.gz $(distdir)-export
rm -rf $(distdir)-export
@find $(distdir) -type d -name CVS -print | xargs rm -rf
Makefile: .warning

17
contrib/ntp/NEWS
View File

@ -1,8 +1,23 @@
* Huff-n-Puff filter
* Preparation for OpenSSL support
* Resolver changes/improvements are not backward compatible with mode 7
requests (which are implementation-specific anyway)
* leap second stuff
* manycast should work now
* ntp-genkeys does new good things.
* scripts/ntp-close
* PPS cleanup and improvements
* readline support for ntpdc
* Crypto/authentication rewrite
* WINNT builds with MD5 by default
* WINNT no longer requires Perl for building with Visual C++ 6.0
* algorithmic improvements, bugfixes
* Solaris dosynctodr info update
* html/pic/* is *lots* smaller
* New drivers: Forum Graphic GPS, WWV/H
* New/updated drivers: Forum Graphic GPS, WWV/H, Heath GC-100 II, HOPF
serial and PCI, ONCORE, ulink331
* Rewrite of the audio drivers
(4.0.99)
* Driver updates: CHU, DCF, GPS/VME, Oncore, PCF, Ulink, WWVB, burst
If you use the ONCORE driver with a HARDPPS kernel module,
you *must* have a properly specified:

5
contrib/ntp/README
View File

@ -1,4 +1,7 @@
The ntp Distribution Base Directory
Send patches and bug reports to <bugs@ntp.org> .
The ntp Distribution Base Directory
This directory and its subdirectories contain the Network Time Protocol
Version 4 (NTP) distribution for Unix and Windows/NT systems. This release

46
contrib/ntp/README.cvs
View File

@ -1,24 +1,52 @@
To get the NTP distribution via anonymous CVS:
cvs -d :pserver:anoncvs@www.ntp.org:/cvs/ntp login
% cvs -d :pserver:anoncvs@www.ntp.org:/cvs/ntp login
the password is: anoncvs
cvs -d :pserver:anoncvs@www.ntp.org:/cvs/ntp co ntp
% rm -rf ntp
% cvs -d :pserver:anoncvs@www.ntp.org:/cvs/ntp co ntp
after which the "ntp_update" script in the top-level of the tree should
keep things in synch and properly timestamped.
There are some mailing lists for the NTP CVS distribution. For more
information, send a message to <majordomo@ntp.org> with the "lists" in
the body of the message.
PLEASE NOTE:
If you get NTP via CVS, you will need to build the release using GNU make
When obtaining the NTP distribution directly via CVS instead of
using "ntp_update", the files are installed in an arbitrary
order.
When you run "make", this may cause some of the generated files
to be reconstructed.
If you do not have the right verison of automake and autoconf,
these files will be regenerated incorrectly.
In this case, you can "fix" your distribution by running:
ntp_update -C
which will force any local changes to your NTP files to be
discarded and replaced with the versions in the repository.
If "ntp_update -C" does not work just remove the "broken"
files (probably Makefile.in files) and re-run ntp_udate.
There are some mailing lists for the NTP CVS distribution. For more
information, send a message to <majordomo@ntp.org> with the word "lists"
in the body of the message.
If you get NTP via CVS, you MAY need to build the release using GNU make
and gcc.
You can then "make dist" to build a release tarball that does not require
GNU make or gcc.
The reason GNU make and gcc are required is because the repository version
of NTP does not have the make dependencies built-in. These dependencies
are created dynamically, and this dynamic process requires GNU make and gcc.
The reason GNU make and gcc may be required is because the repository
version of NTP does not have the make dependencies built-in. These
dependencies are created dynamically, and this dynamic process may
require GNU make and gcc.
I'm told that the version of automake we are now using does not require
GNU make or gcc for the dependency tracking, but I haven't tested this
yet.

9
contrib/ntp/README.des
View File

@ -6,14 +6,9 @@ If you want DES support in ntp:
If you *need* DES support:
- first see if you can simply "want" DES support instead
- Get RSAREF or RSAEURO (or a reasonable facsimile thereof)
- - Unpack it in the top-level source directory of the NTP distribution
in a directory named rsaref2
(You should see directories like ports, rsaref2, scripts)
- Follow the instructions in README.rsa
When you run configure, the Right Thing will happen.
Be advised that the RSA DES code is not quite as portable os one might
Be advised that the RSA DES code is not quite as portable as one might
wish for. In particular, DES under NTP will only work between machines
of the same "endianness".

105
contrib/ntp/README.rsa Normal file
View File

@ -0,0 +1,105 @@
If you want to use the RSA stuff for crypto keys:
- Get RSAREF or RSAEURO.
- - Unpack it in the top-level source directory of the NTP distribution
in a directory named rsaref2 or rsaeuro1, respectively
(You should see directories like ports, rsaref2, scripts)
Make sure rsa.c has the security patch applied - a copy of it is at the
end of this file.
When you run configure, the Right Thing will happen.
Be advised that the RSA DES code is not quite as portable os one might
wish for. In particular, DES under NTP will only work between machines
of the same "endianness".
Dave would prefer that new/alternative encryption schemes follow the
RSA API.
--- rsa.c.orig Fri Mar 25 14:01:48 1994
+++ rsaref2/source/rsa.c Mon Dec 13 13:10:28 1999
@@ -33,6 +33,9 @@
unsigned char byte, pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen;
+ if (publicKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
+
modulusLen = (publicKey->bits + 7) / 8;
if (inputLen + 11 > modulusLen)
return (RE_LEN);
@@ -78,6 +81,9 @@
unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen, pkcsBlockLen;
+ if (publicKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
+
modulusLen = (publicKey->bits + 7) / 8;
if (inputLen > modulusLen)
return (RE_LEN);
@@ -128,6 +134,9 @@
int status;
unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen;
+
+ if (privateKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
modulusLen = (privateKey->bits + 7) / 8;
if (inputLen + 11 > modulusLen)
@@ -168,6 +177,9 @@
unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen, pkcsBlockLen;
+ if (privateKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
+
modulusLen = (privateKey->bits + 7) / 8;
if (inputLen > modulusLen)
return (RE_LEN);
--- rsa.c.orig Sat Sep 28 22:59:40 1996
+++ rsaeuro1/source/rsa.c Sat Jul 8 00:33:13 2000
@@ -51,6 +51,9 @@ R_RANDOM_STRUCT *randomStruct; /* rando
unsigned char byte, pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen;
+ if (publicKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
+
modulusLen = (publicKey->bits + 7) / 8;
if(inputLen + 11 > modulusLen)
@@ -101,6 +104,9 @@ R_RSA_PUBLIC_KEY *publicKey; /* RSA p
unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen, pkcsBlockLen;
+ if (publicKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
+
modulusLen = (publicKey->bits + 7) / 8;
if(inputLen > modulusLen)
@@ -154,6 +160,9 @@ R_RSA_PRIVATE_KEY *privateKey; /* RSA p
unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen;
+ if (privateKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
+
modulusLen = (privateKey->bits + 7) / 8;
if(inputLen + 11 > modulusLen)
@@ -193,6 +202,9 @@ R_RSA_PRIVATE_KEY *privateKey; /* RSA p
unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen, pkcsBlockLen;
+ if (privateKey->bits > MAX_RSA_MODULUS_BITS)
+ return (RE_LEN);
+
modulusLen = (privateKey->bits + 7) / 8;
if(inputLen > modulusLen)

2
contrib/ntp/TODO
View File

@ -1,6 +1,8 @@
*** IF YOU CAN HELP FIX ANY OF THESE THINGS, PLEASE DO! ***
010402: Look harder at -lm and -lelf - they are needed less and less...
970711: Look Real Hard at changing the key stuff from u_long to u_int32.
970711: Make sure it's safe to convert proto_config's 2nd argument from

23
contrib/ntp/acconfig.h
View File

@ -1,9 +1,3 @@
/* Package */
#undef PACKAGE
/* Version */
#undef VERSION
/* debugging code */
#undef DEBUG
@ -76,6 +70,12 @@
/* HOPF 6021 clock */
#undef CLOCK_HOPF6021
/* HOPF PCI clock device */
#undef CLOCK_HOPF_PCI
/* HOPF serial clock device*/
#undef CLOCK_HOPF_SERIAL
/* HP 58503A GPS receiver */
#undef CLOCK_HPGPS
@ -374,9 +374,6 @@
/* Define if you have the TIOCGSERIAL, TIOCSSERIAL, ASYNC_PPS_CD_POS, and ASYNC_PPS_CD_NEG ioctls (linux) */
#undef HAVE_TIO_SERIAL_STUFF
/* Define if you use struct timespec rather than struct timeval (time in ns rather than us) */
#undef HAVE_TIMESPEC
/* Define if you have the interface in the Draft RFC */
#undef HAVE_PPSAPI
@ -402,6 +399,9 @@
/* cfset[io]speed()? */
#undef DECL_CFSETISPEED_0
/* hstrerror()? */
#undef DECL_HSTRERROR_0
/* ioctl()? */
#undef DECL_IOCTL_0
@ -472,3 +472,8 @@
/* toupper()? */
#undef DECL_TOUPPER_0
/* strerror()? */
#undef DECL_STRERROR_0
#undef ULONG_CONST

36
contrib/ntp/acinclude.m4 Normal file
View File

@ -0,0 +1,36 @@
AC_DEFUN(hs_ULONG_CONST,
[ AC_EGREP_CPP(Circus,
[#define ACAT(a,b)a ## b
ACAT(Cir,cus)
], AC_DEFINE([ULONG_CONST(a)], [a ## UL]),
AC_EGREP_CPP(Reiser,
[#define RCAT(a,b)a/**/b
RCAT(Rei,ser)
], AC_DEFINE([ULONG_CONST(a)], [a/**/L]),
AC_MSG_ERROR([How do we create an unsigned long constant?])))])
dnl @synopsis AC_DEFINE_DIR(VARNAME, DIR [, DESCRIPTION])
dnl
dnl This macro defines (with AC_DEFINE) VARNAME to the expansion of the DIR
dnl variable, taking care of fixing up ${prefix} and such.
dnl
dnl Note that the 3 argument form is only supported with autoconf 2.13 and
dnl later (i.e. only where AC_DEFINE supports 3 arguments).
dnl
dnl Examples:
dnl
dnl AC_DEFINE_DIR(DATADIR, datadir)
dnl AC_DEFINE_DIR(PROG_PATH, bindir, [Location of installed binaries])
dnl
dnl @version $Id: acinclude.m4,v 1.3 2000/08/04 03:26:22 stenn Exp $
dnl @author Alexandre Oliva <oliva@lsd.ic.unicamp.br>
AC_DEFUN(AC_DEFINE_DIR, [
ac_expanded=`(
test "x$prefix" = xNONE && prefix="$ac_default_prefix"
test "x$exec_prefix" = xNONE && exec_prefix="${prefix}"
eval echo \""[$]$2"\"
)`
ifelse($3, ,
AC_DEFINE_UNQUOTED($1, "$ac_expanded"),
AC_DEFINE_UNQUOTED($1, "$ac_expanded", $3))
])

508
contrib/ntp/aclocal.m4 vendored
View File

@ -1,65 +1,139 @@
dnl aclocal.m4 generated automatically by aclocal 1.4a
# aclocal.m4 generated automatically by aclocal 1.4e
dnl Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000
# 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.
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY, to the extent permitted by law; without
dnl even the implied warranty of MERCHANTABILITY or FITNESS FOR A
dnl PARTICULAR PURPOSE.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
AC_DEFUN(hs_ULONG_CONST,
[ AC_EGREP_CPP(Circus,
[#define ACAT(a,b)a ## b
ACAT(Cir,cus)
], AC_DEFINE([ULONG_CONST(a)], [a ## UL]),
AC_EGREP_CPP(Reiser,
[#define RCAT(a,b)a/**/b
RCAT(Rei,ser)
], AC_DEFINE([ULONG_CONST(a)], [a/**/L]),
AC_MSG_ERROR([How do we create an unsigned long constant?])))])
dnl @synopsis AC_DEFINE_DIR(VARNAME, DIR [, DESCRIPTION])
dnl
dnl This macro defines (with AC_DEFINE) VARNAME to the expansion of the DIR
dnl variable, taking care of fixing up ${prefix} and such.
dnl
dnl Note that the 3 argument form is only supported with autoconf 2.13 and
dnl later (i.e. only where AC_DEFINE supports 3 arguments).
dnl
dnl Examples:
dnl
dnl AC_DEFINE_DIR(DATADIR, datadir)
dnl AC_DEFINE_DIR(PROG_PATH, bindir, [Location of installed binaries])
dnl
dnl @version $Id: acinclude.m4,v 1.3 2000/08/04 03:26:22 stenn Exp $
dnl @author Alexandre Oliva <oliva@lsd.ic.unicamp.br>
AC_DEFUN(AC_DEFINE_DIR, [
ac_expanded=`(
test "x$prefix" = xNONE && prefix="$ac_default_prefix"
test "x$exec_prefix" = xNONE && exec_prefix="${prefix}"
eval echo \""[$]$2"\"
)`
ifelse($3, ,
AC_DEFINE_UNQUOTED($1, "$ac_expanded"),
AC_DEFINE_UNQUOTED($1, "$ac_expanded", $3))
])
# Like AC_CONFIG_HEADER, but automatically create stamp file.
AC_DEFUN(AM_CONFIG_HEADER,
[AC_PREREQ([2.12])
AC_CONFIG_HEADER([$1])
dnl When config.status generates a header, we must update the stamp-h file.
dnl This file resides in the same directory as the config header
dnl that is generated. We must strip everything past the first ":",
dnl and everything past the last "/".
AC_OUTPUT_COMMANDS(changequote(<<,>>)dnl
ifelse(patsubst(<<$1>>, <<[^ ]>>, <<>>), <<>>,
<<test -z "<<$>>CONFIG_HEADERS" || echo timestamp > patsubst(<<$1>>, <<^\([^:]*/\)?.*>>, <<\1>>)stamp-h<<>>dnl>>,
<<am_indx=1
for am_file in <<$1>>; do
case " <<$>>CONFIG_HEADERS " in
*" <<$>>am_file "*<<)>>
echo timestamp > `echo <<$>>am_file | sed -e 's%:.*%%' -e 's%[^/]*$%%'`stamp-h$am_indx
;;
esac
am_indx=`expr "<<$>>am_indx" + 1`
done<<>>dnl>>)
changequote([,]))])
# serial 3
# When config.status generates a header, we must update the stamp-h file.
# This file resides in the same directory as the config header
# that is generated. We must strip everything past the first ":",
# and everything past the last "/".
AC_PREREQ([2.12])
AC_DEFUN([AM_CONFIG_HEADER],
[AC_CONFIG_HEADER([$1])
AC_OUTPUT_COMMANDS(
ifelse(patsubst([$1], [[^ ]], []),
[],
[test -z "$CONFIG_HEADERS" || echo timestamp >dnl
patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]),
[am_indx=1
for am_file in $1; do
case " $CONFIG_HEADERS " in
*" $am_file "*)
echo timestamp > `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx
;;
esac
am_indx=\`expr \$am_indx + 1\`
done])
])
# Do all the work for Automake. This macro actually does too much --
# some checks are only needed if your package does certain things.
# But this isn't really a big deal.
# serial 1
# serial 5
dnl Usage:
dnl AM_INIT_AUTOMAKE(package,version, [no-define])
# There are a few dirty hacks below to avoid letting `AC_PROG_CC' be
# written in clear, in which case automake, when reading aclocal.m4,
# will think it sees a *use*, and therefore will trigger all it's
# C support machinery. Also note that it means that autoscan, seeing
# CC etc. in the Makefile, will ask for an AC_PROG_CC use...
AC_DEFUN(AM_INIT_AUTOMAKE,
[AC_REQUIRE([AC_PROG_INSTALL])
dnl We require 2.13 because we rely on SHELL being computed by configure.
# We require 2.13 because we rely on SHELL being computed by configure.
AC_PREREQ([2.13])
PACKAGE=[$1]
AC_SUBST(PACKAGE)
VERSION=[$2]
AC_SUBST(VERSION)
dnl test to see if srcdir already configured
if test "`CDPATH=: && cd $srcdir && pwd`" != "`pwd`" &&
# AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED)
# -----------------------------------------------------------
# If MACRO-NAME is provided do IF-PROVIDED, else IF-NOT-PROVIDED.
# The purpose of this macro is to provide the user with a means to
# check macros which are provided without letting her know how the
# information is coded.
# If this macro is not defined by Autoconf, define it here.
ifdef([AC_PROVIDE_IFELSE],
[],
[define([AC_PROVIDE_IFELSE],
[ifdef([AC_PROVIDE_$1],
[$2], [$3])])])
# AM_INIT_AUTOMAKE(PACKAGE,VERSION, [NO-DEFINE])
# ----------------------------------------------
AC_DEFUN([AM_INIT_AUTOMAKE],
[AC_REQUIRE([AC_PROG_INSTALL])dnl
# test to see if srcdir already configured
if test "`CDPATH=:; cd $srcdir && pwd`" != "`pwd`" &&
test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
AC_MSG_ERROR([source directory already configured; run \"make distclean\" there first])
fi
# Define the identity of the package.
PACKAGE=$1
AC_SUBST(PACKAGE)dnl
VERSION=$2
AC_SUBST(VERSION)dnl
ifelse([$3],,
AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package])
AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package]))
AC_REQUIRE([AM_SANITY_CHECK])
AC_REQUIRE([AC_ARG_PROGRAM])
[AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package])
AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package])])
# Autoconf 2.50 wants to disallow AM_ names. We explicitly allow
# the ones we care about.
ifdef([m4_pattern_allow],
[m4_pattern_allow([^AM_(C|CPP|CXX|OBJC|F|R|GCJ)FLAGS])])dnl
# Some tools Automake needs.
AC_REQUIRE([AM_SANITY_CHECK])dnl
AC_REQUIRE([AC_ARG_PROGRAM])dnl
AM_MISSING_PROG(ACLOCAL, aclocal)
AM_MISSING_PROG(AUTOCONF, autoconf)
AM_MISSING_PROG(AUTOMAKE, automake)
@ -67,40 +141,49 @@ AM_MISSING_PROG(AUTOHEADER, autoheader)
AM_MISSING_PROG(MAKEINFO, makeinfo)
AM_MISSING_PROG(AMTAR, tar)
AM_MISSING_INSTALL_SH
dnl We need awk for the "check" target. The system "awk" is bad on
dnl some platforms.
AC_REQUIRE([AC_PROG_AWK])
AC_REQUIRE([AC_PROG_MAKE_SET])
AC_REQUIRE([AM_DEP_TRACK])
AC_REQUIRE([AM_SET_DEPDIR])
ifdef([AC_PROVIDE_AC_PROG_CC], [AM_DEPENDENCIES(CC)], [
define([AC_PROG_CC], defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])])
ifdef([AC_PROVIDE_AC_PROG_CXX], [AM_DEPENDENCIES(CXX)], [
define([AC_PROG_CXX], defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])])
AM_PROG_INSTALL_STRIP
# We need awk for the "check" target. The system "awk" is bad on
# some platforms.
AC_REQUIRE([AC_PROG_AWK])dnl
AC_REQUIRE([AC_PROG_MAKE_SET])dnl
AC_REQUIRE([AM_DEP_TRACK])dnl
AC_REQUIRE([AM_SET_DEPDIR])dnl
AC_PROVIDE_IFELSE([AC_PROG_][CC],
[AM_DEPENDENCIES(CC)],
[define([AC_PROG_][CC],
defn([AC_PROG_][CC])[AM_DEPENDENCIES(CC)])])dnl
AC_PROVIDE_IFELSE([AC_PROG_][CXX],
[AM_DEPENDENCIES(CXX)],
[define([AC_PROG_][CXX],
defn([AC_PROG_][CXX])[AM_DEPENDENCIES(CXX)])])dnl
])
#
# Check to make sure that the build environment is sane.
#
AC_DEFUN(AM_SANITY_CHECK,
# serial 3
# AM_SANITY_CHECK
# ---------------
AC_DEFUN([AM_SANITY_CHECK],
[AC_MSG_CHECKING([whether build environment is sane])
# Just in case
sleep 1
echo timestamp > conftestfile
echo timestamp > conftest.file
# Do `set' in a subshell so we don't clobber the current shell's
# arguments. Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
set X `ls -Lt $srcdir/configure conftestfile 2> /dev/null`
if test "[$]*" = "X"; then
set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
if test "$[*]" = "X"; then
# -L didn't work.
set X `ls -t $srcdir/configure conftestfile`
set X `ls -t $srcdir/configure conftest.file`
fi
if test "[$]*" != "X $srcdir/configure conftestfile" \
&& test "[$]*" != "X conftestfile $srcdir/configure"; then
if test "$[*]" != "X $srcdir/configure conftest.file" \
&& test "$[*]" != "X conftest.file $srcdir/configure"; then
# If neither matched, then we have a broken ls. This can happen
# if, for instance, CONFIG_SHELL is bash and it inherits a
@ -110,7 +193,7 @@ if (
alias in your environment])
fi
test "[$]2" = conftestfile
test "$[2]" = conftest.file
)
then
# Ok.
@ -122,72 +205,183 @@ fi
rm -f conftest*
AC_MSG_RESULT(yes)])
dnl AM_MISSING_PROG(NAME, PROGRAM)
AC_DEFUN(AM_MISSING_PROG, [
AC_REQUIRE([AM_MISSING_HAS_RUN])
# serial 2
# AM_MISSING_PROG(NAME, PROGRAM)
# ------------------------------
AC_DEFUN([AM_MISSING_PROG],
[AC_REQUIRE([AM_MISSING_HAS_RUN])
$1=${$1-"${am_missing_run}$2"}
AC_SUBST($1)])
dnl Like AM_MISSING_PROG, but only looks for install-sh.
dnl AM_MISSING_INSTALL_SH()
AC_DEFUN(AM_MISSING_INSTALL_SH, [
AC_REQUIRE([AM_MISSING_HAS_RUN])
# AM_MISSING_INSTALL_SH
# ---------------------
# Like AM_MISSING_PROG, but only looks for install-sh.
AC_DEFUN([AM_MISSING_INSTALL_SH],
[AC_REQUIRE([AM_MISSING_HAS_RUN])
if test -z "$install_sh"; then
install_sh="$ac_aux_dir/install-sh"
test -f "$install_sh" || install_sh="$ac_aux_dir/install.sh"
test -f "$install_sh" || install_sh="${am_missing_run}${ac_auxdir}/install-sh"
dnl FIXME: an evil hack: we remove the SHELL invocation from
dnl install_sh because automake adds it back in. Sigh.
install_sh="`echo $install_sh | sed -e 's/\${SHELL}//'`"
for install_sh in "$ac_aux_dir/install-sh" \
"$ac_aux_dir/install.sh" \
"${am_missing_run}${ac_auxdir}/install-sh";
do
test -f "$install_sh" && break
done
# FIXME: an evil hack: we remove the SHELL invocation from
# install_sh because automake adds it back in. Sigh.
install_sh=`echo $install_sh | sed -e 's/\${SHELL}//'`
fi
AC_SUBST(install_sh)])
dnl AM_MISSING_HAS_RUN.
dnl Define MISSING if not defined so far and test if it supports --run.
dnl If it does, set am_missing_run to use it, otherwise, to nothing.
AC_DEFUN([AM_MISSING_HAS_RUN], [
test x"${MISSING+set}" = xset || \
MISSING="\${SHELL} `CDPATH=: && cd $ac_aux_dir && pwd`/missing"
dnl Use eval to expand $SHELL
# AM_MISSING_HAS_RUN
# ------------------
# Define MISSING if not defined so far and test if it supports --run.
# If it does, set am_missing_run to use it, otherwise, to nothing.
AC_DEFUN([AM_MISSING_HAS_RUN],
[test x"${MISSING+set}" = xset ||
MISSING="\${SHELL} `CDPATH=:; cd $ac_aux_dir && pwd`/missing"
# Use eval to expand $SHELL
if eval "$MISSING --run :"; then
am_missing_run="$MISSING --run "
else
am_missing_run=
AC_MSG_WARN([\`missing' script is too old or missing])
am_backtick='`'
AC_MSG_WARN([${am_backtick}missing' script is too old or missing])
fi
])
dnl See how the compiler implements dependency checking.
dnl Usage:
dnl AM_DEPENDENCIES(NAME)
dnl NAME is "CC", "CXX" or "OBJC".
# AM_AUX_DIR_EXPAND
dnl We try a few techniques and use that to set a single cache variable.
# For projects using AC_CONFIG_AUX_DIR([foo]), Autoconf sets
# $ac_aux_dir to ${srcdir}/foo. In other projects, it is set to `.'.
# Of course, Automake must honor this variable whenever it call a tool
# from the auxiliary directory. The problem is that $srcdir (hence
# $ac_aux_dir) can be either an absolute path or a path relative to
# $top_srcdir or absolute, this depends on how configure is run. This
# is pretty anoying since it makes $ac_aux_dir quite unusable in
# subdirectories: on the top source directory, any form will work
# fine, but in subdirectories relative pat needs to be adapted.
# - calling $top_srcidr/$ac_aux_dir/missing would success if $srcdir is
# relative, but fail if $srcdir is absolute
# - conversly, calling $ax_aux_dir/missing would fail if $srcdir is
# absolute, and success on relative paths.
#
# Consequently, we define and use $am_aux_dir, the "always absolute"
# version of $ac_aux_dir.
AC_DEFUN(AM_DEPENDENCIES,[
AC_REQUIRE([AM_SET_DEPDIR])
AC_REQUIRE([AM_OUTPUT_DEPENDENCY_COMMANDS])
ifelse([$1],CC,[
AC_REQUIRE([AC_PROG_CC])
AC_REQUIRE([AC_PROG_CPP])
AC_DEFUN([AM_AUX_DIR_EXPAND], [
# expand $ac_aux_dir to an absolute path
am_aux_dir=`CDPATH=:; cd $ac_aux_dir && pwd`
])
# One issue with vendor `install' (even GNU) is that you can't
# specify the program used to strip binaries. This is especially
# annoying in cross=compiling environments, where the build's strip
# is unlikely to handle the host's binaries.
# Fortunately install-sh will honor a STRIPPROG variable, so if we ever
# need to use a non standard strip, we just have to make sure we use
# install-sh with the STRIPPROG variable set.
AC_DEFUN([AM_PROG_INSTALL_STRIP],
[AC_REQUIRE([AM_MISSING_INSTALL_SH])
dnl Don't test for $cross_compiling = yes, it might be `maybe'...
# We'd like to do this but we can't because it will unconditionally
# require config.guess. One way would be if autoconf had the capability
# to let us compile in this code only when config.guess was already
# a possibility.
#if test "$cross_compiling" != no; then
# # since we are cross-compiling, we need to check for a suitable `strip'
# AM_PROG_STRIP
# if test -z "$STRIP"; then
# AC_MSG_WARN([strip missing, install-strip will not strip binaries])
# fi
#fi
# If $STRIP is defined (either by the user, or by AM_PROG_STRIP),
# instruct install-strip to use install-sh and the given $STRIP program.
# Otherwise, just use ${INSTALL}: the idea is to use the vendor install
# as much as possible, because it's faster.
if test -z "$STRIP"; then
# The top level make will set INSTALL_PROGRAM=$(INSTALL_STRIP_PROGRAM)
# and the double dolard below is there to make sure that ${INSTALL}
# is substitued in the sub-makes, not at the top-level; this is
# needed if ${INSTALL} is a relative path (ajusted in each subdirectory
# by config.status).
INSTALL_STRIP_PROGRAM='$${INSTALL} -s'
INSTALL_STRIP_PROGRAM_ENV=''
else
_am_dirpart="`echo $install_sh | sed -e 's,//*[[^/]]*$,,'`"
INSTALL_STRIP_PROGRAM="\${SHELL} \`CDPATH=: && cd $_am_dirpart && pwd\`/install-sh -c -s"
INSTALL_STRIP_PROGRAM_ENV="STRIPPROG='\$(STRIP)'"
fi
AC_SUBST([STRIP])
AC_SUBST([INSTALL_STRIP_PROGRAM])
AC_SUBST([INSTALL_STRIP_PROGRAM_ENV])])
#AC_DEFUN([AM_PROG_STRIP],
#[# Check for `strip', unless the installer
# has set the STRIP environment variable.
# Note: don't explicitly check for -z "$STRIP" here because
# that will cause problems if AC_CANONICAL_* is AC_REQUIREd after
# this macro, and anyway it doesn't have an effect anyway.
#AC_CHECK_TOOL([STRIP],[strip])
#])
# serial 3
# There are a few dirty hacks below to avoid letting `AC_PROG_CC' be
# written in clear, in which case automake, when reading aclocal.m4,
# will think it sees a *use*, and therefore will trigger all it's
# C support machinery. Also note that it means that autoscan, seeing
# CC etc. in the Makefile, will ask for an AC_PROG_CC use...
# AM_DEPENDENCIES(NAME)
# ---------------------
# See how the compiler implements dependency checking.
# NAME is "CC", "CXX" or "OBJC".
# We try a few techniques and use that to set a single cache variable.
AC_DEFUN([AM_DEPENDENCIES],
[AC_REQUIRE([AM_SET_DEPDIR])dnl
AC_REQUIRE([AM_OUTPUT_DEPENDENCY_COMMANDS])dnl
ifelse([$1], CC,
[AC_REQUIRE([AC_PROG_][CC])dnl
AC_REQUIRE([AC_PROG_][CPP])
depcc="$CC"
depcpp="$CPP"],[$1],CXX,[
AC_REQUIRE([AC_PROG_CXX])
AC_REQUIRE([AC_PROG_CXXCPP])
depcpp="$CPP"],
[$1], CXX, [AC_REQUIRE([AC_PROG_][CXX])dnl
AC_REQUIRE([AC_PROG_][CXXCPP])
depcc="$CXX"
depcpp="$CXXCPP"],[$1],OBJC,[
am_cv_OBJC_dependencies_compiler_type=gcc],[
AC_REQUIRE([AC_PROG_][$1])
depcc="$[$1]"
depcpp="$CXXCPP"],
[$1], OBJC, [am_cv_OBJC_dependencies_compiler_type=gcc],
[AC_REQUIRE([AC_PROG_][$1])dnl
depcc="$$1"
depcpp=""])
AC_MSG_CHECKING([dependency style of $depcc])
AC_CACHE_VAL(am_cv_[$1]_dependencies_compiler_type,[
if test -z "$AMDEP"; then
echo '#include "conftest.h"' > conftest.c
echo 'int i;' > conftest.h
am_cv_[$1]_dependencies_compiler_type=none
for depmode in `sed -n 's/^#*\([a-zA-Z0-9]*\))$/\1/p' < "$am_depcomp"`; do
AC_REQUIRE([AM_MAKE_INCLUDE])
AC_CACHE_CHECK([dependency style of $depcc],
[am_cv_$1_dependencies_compiler_type],
[if test -z "$AMDEP"; then
# We make a subdir and do the tests there. Otherwise we can end up
# making bogus files that we don't know about and never remove. For
# instance it was reported that on HP-UX the gcc test will end up
# making a dummy file named `D' -- because `-MD' means `put the output
# in D'.
mkdir confdir
# Copy depcomp to subdir because otherwise we won't find it if we're
# using a relative directory.
cp "$am_depcomp" confdir
cd confdir
am_cv_$1_dependencies_compiler_type=none
for depmode in `sed -n ['s/^#*\([a-zA-Z0-9]*\))$/\1/p'] < "./depcomp"`; do
# We need to recreate these files for each test, as the compiler may
# overwrite some of them when testing with obscure command lines.
# This happens at least with the AIX C compiler.
echo '#include "conftest.h"' > conftest.c
echo 'int i;' > conftest.h
case "$depmode" in
nosideeffect)
# after this tag, mechanisms are not by side-effect, so they'll
@ -200,40 +394,51 @@ if test -z "$AMDEP"; then
;;
none) break ;;
esac
# We check with `-c' and `-o' for the sake of the "dashmstdout"
# mode. It turns out that the SunPro C++ compiler does not properly
# handle `-M -o', and we need to detect this.
if depmode="$depmode" \
source=conftest.c object=conftest.o \
depfile=conftest.Po tmpdepfile=conftest.TPo \
$SHELL $am_depcomp $depcc -c conftest.c 2>/dev/null &&
$SHELL ./depcomp $depcc -c conftest.c -o conftest.o >/dev/null 2>&1 &&
grep conftest.h conftest.Po > /dev/null 2>&1; then
am_cv_[$1]_dependencies_compiler_type="$depmode"
am_cv_$1_dependencies_compiler_type="$depmode"
break
fi
done
rm -f conftest.*
cd ..
rm -rf confdir
else
am_cv_[$1]_dependencies_compiler_type=none
am_cv_$1_dependencies_compiler_type=none
fi
])
AC_MSG_RESULT($am_cv_[$1]_dependencies_compiler_type)
[$1]DEPMODE="depmode=$am_cv_[$1]_dependencies_compiler_type"
AC_SUBST([$1]DEPMODE)
$1DEPMODE="depmode=$am_cv_$1_dependencies_compiler_type"
AC_SUBST([$1DEPMODE])
])
dnl Choose a directory name for dependency files.
dnl This macro is AC_REQUIREd in AM_DEPENDENCIES
AC_DEFUN(AM_SET_DEPDIR,[
if test -d .deps || mkdir .deps 2> /dev/null || test -d .deps; then
# AM_SET_DEPDIR
# -------------
# Choose a directory name for dependency files.
# This macro is AC_REQUIREd in AM_DEPENDENCIES
AC_DEFUN([AM_SET_DEPDIR],
[if test -d .deps || mkdir .deps 2> /dev/null || test -d .deps; then
DEPDIR=.deps
# We redirect because .deps might already exist and be populated.
# In this situation we don't want to see an error.
rmdir .deps > /dev/null 2>&1
else
DEPDIR=_deps
fi
AC_SUBST(DEPDIR)
])
AC_DEFUN(AM_DEP_TRACK,[
AC_ARG_ENABLE(dependency-tracking,
# AM_DEP_TRACK
# ------------
AC_DEFUN([AM_DEP_TRACK],
[AC_ARG_ENABLE(dependency-tracking,
[ --disable-dependency-tracking Speeds up one-time builds
--enable-dependency-tracking Do not reject slow dependency extractors])
if test "x$enable_dependency_tracking" = xno; then
@ -257,16 +462,16 @@ subst(AMDEPBACKSLASH)
popdef([subst])
])
dnl Generate code to set up dependency tracking.
dnl This macro should only be invoked once -- use via AC_REQUIRE.
dnl Usage:
dnl AM_OUTPUT_DEPENDENCY_COMMANDS
# Generate code to set up dependency tracking.
# This macro should only be invoked once -- use via AC_REQUIRE.
# Usage:
# AM_OUTPUT_DEPENDENCY_COMMANDS
dnl
dnl This code is only required when automatic dependency tracking
dnl is enabled. FIXME. This creates each `.P' file that we will
dnl need in order to bootstrap the dependency handling code.
AC_DEFUN(AM_OUTPUT_DEPENDENCY_COMMANDS,[
#
# This code is only required when automatic dependency tracking
# is enabled. FIXME. This creates each `.P' file that we will
# need in order to bootstrap the dependency handling code.
AC_DEFUN([AM_OUTPUT_DEPENDENCY_COMMANDS],[
AC_OUTPUT_COMMANDS([
test x"$AMDEP" != x"" ||
for mf in $CONFIG_FILES; do
@ -308,10 +513,35 @@ done
], [AMDEP="$AMDEP"
ac_aux_dir="$ac_aux_dir"])])
# AM_MAKE_INCLUDE()
# -----------------
# Check to see how make treats includes.
AC_DEFUN([AM_MAKE_INCLUDE],
[am_make=${MAKE-make}
# BSD make uses .include
cat > confinc << 'END'
doit:
@echo done
END
# If we don't find an include directive, just comment out the code.
AC_MSG_CHECKING([for style of include used by $am_make])
_am_include='#'
for am_inc in include .include; do
echo "$am_inc confinc" > confmf
if test "`$am_make -f confmf 2> /dev/null`" = "done"; then
_am_include=$am_inc
break
fi
done
AC_SUBST(_am_include)
AC_MSG_RESULT($_am_include)
rm -f confinc confmf
])
# serial 1
AC_DEFUN(AM_C_PROTOTYPES,
AC_DEFUN([AM_C_PROTOTYPES],
[AC_REQUIRE([AM_PROG_CC_STDC])
AC_REQUIRE([AC_PROG_CPP])
AC_MSG_CHECKING([for function prototypes])
@ -322,10 +552,10 @@ if test "$am_cv_prog_cc_stdc" != no; then
else
AC_MSG_RESULT(no)
U=_ ANSI2KNR=./ansi2knr
# Ensure some checks needed by ansi2knr itself.
AC_HEADER_STDC
AC_CHECK_HEADERS(string.h)
fi
# Ensure some checks needed by ansi2knr itself.
AC_HEADER_STDC
AC_CHECK_HEADERS(string.h)
AC_SUBST(U)dnl
AC_SUBST(ANSI2KNR)dnl
])
@ -348,7 +578,7 @@ AC_SUBST(ANSI2KNR)dnl
# program @code{ansi2knr}, which comes with Ghostscript.
# @end defmac
AC_DEFUN(AM_PROG_CC_STDC,
AC_DEFUN([AM_PROG_CC_STDC],
[AC_REQUIRE([AC_PROG_CC])
AC_BEFORE([$0], [AC_C_INLINE])
AC_BEFORE([$0], [AC_C_CONST])
@ -358,7 +588,7 @@ dnl like #elif.
dnl FIXME: can't do this because then AC_AIX won't work due to a
dnl circular dependency.
dnl AC_BEFORE([$0], [AC_PROG_CPP])
AC_MSG_CHECKING(for ${CC-cc} option to accept ANSI C)
AC_MSG_CHECKING([for ${CC-cc} option to accept ANSI C])
AC_CACHE_VAL(am_cv_prog_cc_stdc,
[am_cv_prog_cc_stdc=no
ac_save_CC="$CC"
@ -411,7 +641,7 @@ CC="$ac_save_CC"
if test -z "$am_cv_prog_cc_stdc"; then
AC_MSG_RESULT([none needed])
else
AC_MSG_RESULT($am_cv_prog_cc_stdc)
AC_MSG_RESULT([$am_cv_prog_cc_stdc])
fi
case "x$am_cv_prog_cc_stdc" in
x|xno) ;;

279
contrib/ntp/adjtimed/Makefile.in
View File

@ -1,6 +1,7 @@
# Makefile.in generated automatically by automake 1.4a from Makefile.am
# Makefile.in generated automatically by automake 1.4e from Makefile.am.
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
# Free Software Foundation, Inc.
# This Makefile.in 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.
@ -31,8 +32,6 @@ mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
@ -48,7 +47,7 @@ INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_FLAG =
INSTALL_HEADER = $(INSTALL_DATA)
transform = @program_transform_name@
NORMAL_INSTALL = :
@ -57,24 +56,30 @@ POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_alias = @build_alias@
build_triplet = @build@
host_alias = @host_alias@
host_triplet = @host@
target_alias = @target_alias@
target_triplet = @target@
@SET_MAKE@
AMDEP = @AMDEP@
AMTAR = @AMTAR@
AUTOKEY = @AUTOKEY@
AWK = @AWK@
CC = @CC@
CFLAGS = @CFLAGS@
CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CPP = @CPP@
CXX = @CXX@
CXXCPP = @CXXCPP@
DCFD = @DCFD@
DEPDIR = @DEPDIR@
EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
INSTALL_STRIP_PROGRAM_ENV = @INSTALL_STRIP_PROGRAM_ENV@
LDFLAGS = @LDFLAGS@
LIBPARSE = @LIBPARSE@
LIBRSAREF = @LIBRSAREF@
@ -86,16 +91,27 @@ MAKE_LIBPARSE = @MAKE_LIBPARSE@
MAKE_LIBPARSE_KERNEL = @MAKE_LIBPARSE_KERNEL@
MAKE_LIBRSAREF = @MAKE_LIBRSAREF@
MAKE_NTPTIME = @MAKE_NTPTIME@
MAKE_NTP_GENKEYS = @MAKE_NTP_GENKEYS@
MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
OPENSSL_LIB = @OPENSSL_LIB@
PACKAGE = @PACKAGE@
PATH_PERL = @PATH_PERL@
PATH_SH = @PATH_SH@
PROPDELAY = @PROPDELAY@
RANLIB = @RANLIB@
RSADIR = @RSADIR@
RSAOBJS = @RSAOBJS@
RSAREF = @RSAREF@
RSASRCS = @RSASRCS@
STRIP = @STRIP@
TESTDCF = @TESTDCF@
U = @U@
VERSION = @VERSION@
_am_include = @_am_include@
install_sh = @install_sh@
#AUTOMAKE_OPTIONS = ../ansi2knr #no-dependencies
@ -108,107 +124,93 @@ INCLUDES = -I$(top_srcdir)/include
LDADD = ../libntp/libntp.a
#EXTRA_DIST = TAGS
ETAGS_ARGS = Makefile.am
EXEEXT =
OBJEXT = o
subdir = adjtimed
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_HEADER = ../config.h
CONFIG_CLEAN_FILES =
PROGRAMS = $(bin_PROGRAMS)
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
EXTRA_PROGRAMS = adjtimed$(EXEEXT)
bin_PROGRAMS = @MAKE_ADJTIMED@
PROGRAMS = $(bin_PROGRAMS)
DEFS = @DEFS@ -I. -I$(srcdir) -I..
DEFS = @DEFS@ -I. -I$(srcdir) -I$(top_builddir)
CPPFLAGS = @CPPFLAGS@
LIBS = @LIBS@
ANSI2KNR = ../util/ansi2knr
adjtimed_SOURCES = adjtimed.c
adjtimed_OBJECTS = adjtimed$U.o
adjtimed_OBJECTS = adjtimed$U.$(OBJEXT)
adjtimed_LDADD = $(LDADD)
adjtimed_DEPENDENCIES = ../libntp/libntp.a
adjtimed_DEPENDENCIES = ../libntp/libntp.a
adjtimed_LDFLAGS =
COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
DIST_SOURCES = adjtimed.c
DIST_COMMON = README Makefile.am Makefile.in
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
GZIP_ENV = --best
DIST_SOURCES = adjtimed.c
depcomp = $(SHELL) $(top_srcdir)/depcomp
DEP_FILES = @AMDEP@ $(DEPDIR)/adjtimed$U.Po
@AMDEP@DEP_FILES = $(DEPDIR)/adjtimed$U.Po
DIST_COMMON = README Makefile.am Makefile.in
SOURCES = adjtimed.c
OBJECTS = adjtimed$U.o
OBJECTS = adjtimed$U.$(OBJEXT)
all: all-am
all: all-redirect
.SUFFIXES:
.SUFFIXES: .c .o
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --gnu adjtimed/Makefile
.SUFFIXES: .c .o .obj
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status $(BUILT_SOURCES)
cd $(top_builddir) \
&& CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
mostlyclean-binPROGRAMS:
clean-binPROGRAMS:
-test -z "$(bin_PROGRAMS)" || rm -f $(bin_PROGRAMS)
distclean-binPROGRAMS:
maintainer-clean-binPROGRAMS:
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && \
$(AUTOMAKE) --gnu adjtimed/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) && \
CONFIG_HEADERS= CONFIG_LINKS= \
CONFIG_FILES=$(subdir)/$@ $(SHELL) ./config.status
install-binPROGRAMS: $(bin_PROGRAMS)
@$(NORMAL_INSTALL)
$(mkinstalldirs) $(DESTDIR)$(bindir)
@list='$(bin_PROGRAMS)'; for p in $$list; do \
if test -f $$p; then \
f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \
echo " $(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f"; \
$(INSTALL_PROGRAM) $(INSTALL_STRIP_FLAG) $$p $(DESTDIR)$(bindir)/$$f; \
f=`echo $$p|sed 's/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
echo " $(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) $$p $(DESTDIR)$(bindir)/$$f"; \
$(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) $$p $(DESTDIR)$(bindir)/$$f; \
else :; fi; \
done
uninstall-binPROGRAMS:
@$(NORMAL_UNINSTALL)
@list='$(bin_PROGRAMS)'; for p in $$list; do \
f="`echo $$p|sed -e 's/$(EXEEXT)$$//' -e '$(transform)' -e 's/$$/$(EXEEXT)/'`"; \
f=`echo $$p|sed 's/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
echo " rm -f $(DESTDIR)$(bindir)/$$f"; \
rm -f $(DESTDIR)$(bindir)/$$f; \
done
mostlyclean-compile:
-rm -f *.o core *.core
clean-binPROGRAMS:
-test -z "$(bin_PROGRAMS)" || rm -f $(bin_PROGRAMS)
clean-compile:
mostlyclean-compile:
-rm -f *.$(OBJEXT) core *.core
distclean-compile:
-rm -f *.tab.c
maintainer-clean-compile:
../util/ansi2knr: ../util/ansi2knr.o
../util/ansi2knr: ../util/ansi2knr.$(OBJEXT)
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr
../util/ansi2knr.o:
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr.o
../util/ansi2knr.$(OBJEXT):
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr.$(OBJEXT)
mostlyclean-kr:
-rm -f *_.c
clean-kr:
distclean-kr:
maintainer-clean-kr:
adjtimed: $(adjtimed_OBJECTS) $(adjtimed_DEPENDENCIES)
@rm -f adjtimed
$(LINK) $(adjtimed_LDFLAGS) $(adjtimed_OBJECTS) $(adjtimed_LDADD) $(LIBS)
adjtimed_.c: adjtimed.c $(ANSI2KNR)
$(CPP) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) `if test -f $(srcdir)/adjtimed.c; then echo $(srcdir)/adjtimed.c; else echo adjtimed.c; fi` | sed 's/^# \([0-9]\)/#line \1/' | $(ANSI2KNR) > adjtimed_.c
adjtimed_.o : $(ANSI2KNR)
adjtimed_.$(OBJEXT) : $(ANSI2KNR)
tags: TAGS
@ -219,9 +221,9 @@ ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
mkid -f$$here/ID $$unique $(LISP)
mkid -fID $$unique $(LISP)
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
here=`pwd`; \
@ -234,74 +236,71 @@ TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
|| etags $(ETAGS_ARGS) $$tags $$unique $(LISP)
mostlyclean-tags:
clean-tags:
GTAGS:
here=`CDPATH=: && cd $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $$here
distclean-tags:
-rm -f TAGS ID
maintainer-clean-tags:
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
distdir: $(DISTFILES)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pR $$d/$$file $(distdir); \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
fi; \
done
@AMDEP@include $(DEPDIR)/adjtimed$U.Po
mostlyclean-depend:
clean-depend:
@AMDEP@@_am_include@ $(DEPDIR)/adjtimed$U.Po
distclean-depend:
-rm -rf $(DEPDIR)
maintainer-clean-depend:
@AMDEP@CCDEPMODE = @CCDEPMODE@
.c.o:
@AMDEP@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP@ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' @AMDEPBACKSLASH@
@AMDEP@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ $<
$(COMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$<
info-am:
info: info-am
dvi-am:
dvi: dvi-am
.c.obj:
@AMDEP@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP@ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' @AMDEPBACKSLASH@
@AMDEP@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ `cygpath -w $<`
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
top_distdir = ..
distdir = $(top_distdir)/$(PACKAGE)-$(VERSION)
distdir: $(DISTFILES)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pR $$d/$$file $(distdir) \
|| exit 1; \
else \
test -f $(distdir)/$$file \
|| cp -p $$d/$$file $(distdir)/$$file \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
installcheck-am:
installcheck: installcheck-am
install-exec-am: install-binPROGRAMS
install-exec: install-exec-am
all-am: Makefile $(PROGRAMS)
install-data-am:
installdirs:
$(mkinstalldirs) $(DESTDIR)$(bindir)
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-am
uninstall-am: uninstall-binPROGRAMS
uninstall: uninstall-am
all-am: Makefile $(PROGRAMS)
all-redirect: all-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
installdirs:
$(mkinstalldirs) $(DESTDIR)$(bindir)
installcheck: installcheck-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
INSTALL_PROGRAM_ENV='$(INSTALL_STRIP_PROGRAM_ENV)' install
mostlyclean-generic:
@ -312,45 +311,55 @@ distclean-generic:
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-rm -f Makefile.in
mostlyclean-am: mostlyclean-binPROGRAMS mostlyclean-compile \
mostlyclean-kr mostlyclean-tags mostlyclean-depend \
mostlyclean-generic
mostlyclean: mostlyclean-am
clean-am: clean-binPROGRAMS clean-compile clean-kr clean-tags \
clean-depend clean-generic mostlyclean-am
clean: clean-am
distclean-am: distclean-binPROGRAMS distclean-compile distclean-kr \
distclean-tags distclean-depend distclean-generic \
clean-am
clean-am: clean-binPROGRAMS clean-generic mostlyclean-am
distclean: distclean-am
maintainer-clean-am: maintainer-clean-binPROGRAMS \
maintainer-clean-compile maintainer-clean-kr \
maintainer-clean-tags maintainer-clean-depend \
maintainer-clean-generic distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
distclean-am: clean-am distclean-compile distclean-depend \
distclean-generic distclean-tags
dvi:
dvi-am:
info:
info-am:
install-data-am:
install-exec-am: install-binPROGRAMS
install-info:
install-man:
installcheck-am:
maintainer-clean: maintainer-clean-am
.PHONY: mostlyclean-binPROGRAMS distclean-binPROGRAMS clean-binPROGRAMS \
maintainer-clean-binPROGRAMS uninstall-binPROGRAMS install-binPROGRAMS \
mostlyclean-compile distclean-compile clean-compile \
maintainer-clean-compile mostlyclean-kr distclean-kr clean-kr \
maintainer-clean-kr tags mostlyclean-tags distclean-tags clean-tags \
maintainer-clean-tags distdir mostlyclean-depend distclean-depend \
clean-depend maintainer-clean-depend info-am info dvi-am dvi check \
check-am installcheck-am installcheck install-exec-am install-exec \
install-data-am install-data install-am install uninstall-am uninstall \
all-redirect all-am all install-strip installdirs mostlyclean-generic \
distclean-generic clean-generic maintainer-clean-generic clean \
mostlyclean distclean maintainer-clean
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-compile mostlyclean-generic mostlyclean-kr
uninstall-am: uninstall-binPROGRAMS
.PHONY: all all-am check check-am clean clean-binPROGRAMS clean-generic \
distclean distclean-compile distclean-depend distclean-generic \
distclean-tags distdir dvi dvi-am info info-am install \
install-am install-binPROGRAMS install-data install-data-am \
install-exec install-exec-am install-info install-man \
install-strip installcheck installcheck-am installdirs \
maintainer-clean maintainer-clean-generic mostlyclean \
mostlyclean-compile mostlyclean-generic mostlyclean-kr tags \
uninstall uninstall-am uninstall-binPROGRAMS
# Tell versions [3.59,3.63) of GNU make to not export all variables.

37
contrib/ntp/build
View File

@ -1,11 +1,27 @@
#! /bin/sh
LOGF=make.log
CONFIG_ARGS="$@"
IAM=`hostname || uname -n`
case "$1" in
0.*)
SIG=$1
shift
CONFIG_ARGS="$@"
KEY=`sed -e q < .buildkey`
case "$SIG" in
$KEY) ;;
*)
echo "Wrong directory for build on host $IAM"
exit 1
;;
esac
;;
*)
CONFIG_ARGS="$@"
;;
esac
#set -e
#set -x
@ -28,6 +44,17 @@ case "$IAM" in
;;
esac
KEYSUF=""
case "$CONFIG_ARGS" in
*--with-crypto=autokey*)
KEYSUF="-autokey"
;;
*--without-crypto*)
[ -d rsaref2 ] && KEYSUF="-norsaref"
;;
esac
CCSUF=""
case "$CC" in
@ -36,7 +63,7 @@ case "$CC" in
;;
esac
BDIR="$BDIR$CCSUF"
BDIR="$BDIR$KEYSUF$CCSUF"
[ -d "$BDIR" ] || mkdir $BDIR
[ -f "$BDIR/.buildcvo" ] || echo $CVO > $BDIR/.buildcvo
@ -47,6 +74,8 @@ cd $BDIR
(
[ -f config.status ] || ../configure $CONFIG_ARGS
./config.status
case "$MAKE" in
'') make && make check
;;

275
contrib/ntp/clockstuff/Makefile.in
View File

@ -1,6 +1,7 @@
# Makefile.in generated automatically by automake 1.4a from Makefile.am
# Makefile.in generated automatically by automake 1.4e from Makefile.am.
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
# Free Software Foundation, Inc.
# This Makefile.in 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.
@ -31,8 +32,6 @@ mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
@ -48,7 +47,7 @@ INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_FLAG =
INSTALL_HEADER = $(INSTALL_DATA)
transform = @program_transform_name@
NORMAL_INSTALL = :
@ -57,24 +56,30 @@ POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_alias = @build_alias@
build_triplet = @build@
host_alias = @host_alias@
host_triplet = @host@
target_alias = @target_alias@
target_triplet = @target@
@SET_MAKE@
AMDEP = @AMDEP@
AMTAR = @AMTAR@
AUTOKEY = @AUTOKEY@
AWK = @AWK@
CC = @CC@
CFLAGS = @CFLAGS@
CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CPP = @CPP@
CXX = @CXX@
CXXCPP = @CXXCPP@
DCFD = @DCFD@
DEPDIR = @DEPDIR@
EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
INSTALL_STRIP_PROGRAM_ENV = @INSTALL_STRIP_PROGRAM_ENV@
LDFLAGS = @LDFLAGS@
LIBPARSE = @LIBPARSE@
LIBRSAREF = @LIBRSAREF@
@ -86,16 +91,27 @@ MAKE_LIBPARSE = @MAKE_LIBPARSE@
MAKE_LIBPARSE_KERNEL = @MAKE_LIBPARSE_KERNEL@
MAKE_LIBRSAREF = @MAKE_LIBRSAREF@
MAKE_NTPTIME = @MAKE_NTPTIME@
MAKE_NTP_GENKEYS = @MAKE_NTP_GENKEYS@
MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
OPENSSL_LIB = @OPENSSL_LIB@
PACKAGE = @PACKAGE@
PATH_PERL = @PATH_PERL@
PATH_SH = @PATH_SH@
PROPDELAY = @PROPDELAY@
RANLIB = @RANLIB@
RSADIR = @RSADIR@
RSAOBJS = @RSAOBJS@
RSAREF = @RSAREF@
RSASRCS = @RSASRCS@
STRIP = @STRIP@
TESTDCF = @TESTDCF@
U = @U@
VERSION = @VERSION@
_am_include = @_am_include@
install_sh = @install_sh@
#AUTOMAKE_OPTIONS = ../ansi2knr no-dependencies
@ -111,90 +127,77 @@ propdelay_LDADD = -lm
chutest_LDADD = ../libntp/libntp.a
clktest_LDADD = ../libntp/libntp.a
ETAGS_ARGS = Makefile.am
EXEEXT =
OBJEXT = o
subdir = clockstuff
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_HEADER = ../config.h
CONFIG_CLEAN_FILES =
PROGRAMS = $(noinst_PROGRAMS)
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
EXTRA_PROGRAMS = propdelay$(EXEEXT) chutest$(EXEEXT) clktest$(EXEEXT)
noinst_PROGRAMS = @PROPDELAY@ @CHUTEST@ @CLKTEST@
PROGRAMS = $(noinst_PROGRAMS)
DEFS = @DEFS@ -I. -I$(srcdir) -I..
DEFS = @DEFS@ -I. -I$(srcdir) -I$(top_builddir)
CPPFLAGS = @CPPFLAGS@
LIBS = @LIBS@
ANSI2KNR = ../util/ansi2knr
chutest_SOURCES = chutest.c
chutest_OBJECTS = chutest$U.o
chutest_DEPENDENCIES = ../libntp/libntp.a
chutest_OBJECTS = chutest$U.$(OBJEXT)
chutest_DEPENDENCIES = ../libntp/libntp.a
chutest_LDFLAGS =
clktest_SOURCES = clktest.c
clktest_OBJECTS = clktest$U.o
clktest_DEPENDENCIES = ../libntp/libntp.a
clktest_OBJECTS = clktest$U.$(OBJEXT)
clktest_DEPENDENCIES = ../libntp/libntp.a
clktest_LDFLAGS =
propdelay_SOURCES = propdelay.c
propdelay_OBJECTS = propdelay$U.o
propdelay_DEPENDENCIES =
propdelay_OBJECTS = propdelay$U.$(OBJEXT)
propdelay_DEPENDENCIES =
propdelay_LDFLAGS =
COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
DIST_SOURCES = chutest.c clktest.c propdelay.c
DIST_COMMON = README Makefile.am Makefile.in
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
GZIP_ENV = --best
DIST_SOURCES = chutest.c clktest.c propdelay.c
depcomp = $(SHELL) $(top_srcdir)/depcomp
DEP_FILES = @AMDEP@ $(DEPDIR)/chutest$U.Po $(DEPDIR)/clktest$U.Po \
$(DEPDIR)/propdelay$U.Po
@AMDEP@DEP_FILES = $(DEPDIR)/chutest$U.Po $(DEPDIR)/clktest$U.Po \
@AMDEP@ $(DEPDIR)/propdelay$U.Po
DIST_COMMON = README Makefile.am Makefile.in
SOURCES = chutest.c clktest.c propdelay.c
OBJECTS = chutest$U.o clktest$U.o propdelay$U.o
OBJECTS = chutest$U.$(OBJEXT) clktest$U.$(OBJEXT) propdelay$U.$(OBJEXT)
all: all-am
all: all-redirect
.SUFFIXES:
.SUFFIXES: .c .o
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --gnu clockstuff/Makefile
.SUFFIXES: .c .o .obj
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status $(BUILT_SOURCES)
cd $(top_builddir) \
&& CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && \
$(AUTOMAKE) --gnu clockstuff/Makefile
mostlyclean-noinstPROGRAMS:
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) && \
CONFIG_HEADERS= CONFIG_LINKS= \
CONFIG_FILES=$(subdir)/$@ $(SHELL) ./config.status
clean-noinstPROGRAMS:
-test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)
distclean-noinstPROGRAMS:
maintainer-clean-noinstPROGRAMS:
mostlyclean-compile:
-rm -f *.o core *.core
clean-compile:
-rm -f *.$(OBJEXT) core *.core
distclean-compile:
-rm -f *.tab.c
maintainer-clean-compile:
../util/ansi2knr: ../util/ansi2knr.o
../util/ansi2knr: ../util/ansi2knr.$(OBJEXT)
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr
../util/ansi2knr.o:
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr.o
../util/ansi2knr.$(OBJEXT):
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr.$(OBJEXT)
mostlyclean-kr:
-rm -f *_.c
clean-kr:
distclean-kr:
maintainer-clean-kr:
propdelay: $(propdelay_OBJECTS) $(propdelay_DEPENDENCIES)
@rm -f propdelay
$(LINK) $(propdelay_LDFLAGS) $(propdelay_OBJECTS) $(propdelay_LDADD) $(LIBS)
@ -204,7 +207,8 @@ clktest_.c: clktest.c $(ANSI2KNR)
$(CPP) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) `if test -f $(srcdir)/clktest.c; then echo $(srcdir)/clktest.c; else echo clktest.c; fi` | sed 's/^# \([0-9]\)/#line \1/' | $(ANSI2KNR) > clktest_.c
propdelay_.c: propdelay.c $(ANSI2KNR)
$(CPP) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) `if test -f $(srcdir)/propdelay.c; then echo $(srcdir)/propdelay.c; else echo propdelay.c; fi` | sed 's/^# \([0-9]\)/#line \1/' | $(ANSI2KNR) > propdelay_.c
chutest_.o clktest_.o propdelay_.o : $(ANSI2KNR)
chutest_.$(OBJEXT) clktest_.$(OBJEXT) propdelay_.$(OBJEXT) : \
$(ANSI2KNR)
tags: TAGS
@ -215,9 +219,9 @@ ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
mkid -f$$here/ID $$unique $(LISP)
mkid -fID $$unique $(LISP)
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
here=`pwd`; \
@ -230,75 +234,72 @@ TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
|| etags $(ETAGS_ARGS) $$tags $$unique $(LISP)
mostlyclean-tags:
clean-tags:
GTAGS:
here=`CDPATH=: && cd $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $$here
distclean-tags:
-rm -f TAGS ID
maintainer-clean-tags:
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
distdir: $(DISTFILES)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pR $$d/$$file $(distdir); \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
fi; \
done
@AMDEP@include $(DEPDIR)/chutest$U.Po
@AMDEP@include $(DEPDIR)/clktest$U.Po
@AMDEP@include $(DEPDIR)/propdelay$U.Po
mostlyclean-depend:
clean-depend:
@AMDEP@@_am_include@ $(DEPDIR)/chutest$U.Po
@AMDEP@@_am_include@ $(DEPDIR)/clktest$U.Po
@AMDEP@@_am_include@ $(DEPDIR)/propdelay$U.Po
distclean-depend:
-rm -rf $(DEPDIR)
maintainer-clean-depend:
@AMDEP@CCDEPMODE = @CCDEPMODE@
.c.o:
@AMDEP@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP@ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' @AMDEPBACKSLASH@
@AMDEP@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ $<
$(COMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$<
info-am:
info: info-am
dvi-am:
dvi: dvi-am
.c.obj:
@AMDEP@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP@ depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' @AMDEPBACKSLASH@
@AMDEP@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ `cygpath -w $<`
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
top_distdir = ..
distdir = $(top_distdir)/$(PACKAGE)-$(VERSION)
distdir: $(DISTFILES)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pR $$d/$$file $(distdir) \
|| exit 1; \
else \
test -f $(distdir)/$$file \
|| cp -p $$d/$$file $(distdir)/$$file \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
installcheck-am:
installcheck: installcheck-am
install-exec-am:
install-exec: install-exec-am
all-am: Makefile $(PROGRAMS)
install-data-am:
installdirs:
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-am
uninstall-am:
uninstall: uninstall-am
all-am: Makefile $(PROGRAMS)
all-redirect: all-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
installdirs:
installcheck: installcheck-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
INSTALL_PROGRAM_ENV='$(INSTALL_STRIP_PROGRAM_ENV)' install
mostlyclean-generic:
@ -309,45 +310,53 @@ distclean-generic:
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-rm -f Makefile.in
mostlyclean-am: mostlyclean-noinstPROGRAMS mostlyclean-compile \
mostlyclean-kr mostlyclean-tags mostlyclean-depend \
mostlyclean-generic
mostlyclean: mostlyclean-am
clean-am: clean-noinstPROGRAMS clean-compile clean-kr clean-tags \
clean-depend clean-generic mostlyclean-am
clean: clean-am
distclean-am: distclean-noinstPROGRAMS distclean-compile distclean-kr \
distclean-tags distclean-depend distclean-generic \
clean-am
clean-am: clean-generic clean-noinstPROGRAMS mostlyclean-am
distclean: distclean-am
maintainer-clean-am: maintainer-clean-noinstPROGRAMS \
maintainer-clean-compile maintainer-clean-kr \
maintainer-clean-tags maintainer-clean-depend \
maintainer-clean-generic distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
distclean-am: clean-am distclean-compile distclean-depend \
distclean-generic distclean-tags
dvi:
dvi-am:
info:
info-am:
install-data-am:
install-exec-am:
install-info:
install-man:
installcheck-am:
maintainer-clean: maintainer-clean-am
.PHONY: mostlyclean-noinstPROGRAMS distclean-noinstPROGRAMS \
clean-noinstPROGRAMS maintainer-clean-noinstPROGRAMS \
mostlyclean-compile distclean-compile clean-compile \
maintainer-clean-compile mostlyclean-kr distclean-kr clean-kr \
maintainer-clean-kr tags mostlyclean-tags distclean-tags clean-tags \
maintainer-clean-tags distdir mostlyclean-depend distclean-depend \
clean-depend maintainer-clean-depend info-am info dvi-am dvi check \
check-am installcheck-am installcheck install-exec-am install-exec \
install-data-am install-data install-am install uninstall-am uninstall \
all-redirect all-am all install-strip installdirs mostlyclean-generic \
distclean-generic clean-generic maintainer-clean-generic clean \
mostlyclean distclean maintainer-clean
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-compile mostlyclean-generic mostlyclean-kr
.PHONY: all all-am check check-am clean clean-generic \
clean-noinstPROGRAMS distclean distclean-compile \
distclean-depend distclean-generic distclean-tags distdir dvi \
dvi-am info info-am install install-am install-data \
install-data-am install-exec install-exec-am install-info \
install-man install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-compile mostlyclean-generic \
mostlyclean-kr tags uninstall uninstall-am
#EXTRA_DIST = TAGS

13
contrib/ntp/conf/baldwin.conf
View File

@ -6,18 +6,17 @@
# driver, as well as a multicast server. The prefer keyword on the
# local clock driver declares an external clock and that the time of
# this server should not be wiggled by an NTP peer, unless the
# external clock comes unstuck. Note the use of the multicast group
# external source comes unstuck. Note the use of the multicast group
# ID assigned to NTP, 224.0.1.1, which identifies this as a multicast
# server rather than a broadcast one. The other NTP peers are known
# stratum-1 chimes intended as backup should the external clock croak.
#
peer 127.127.1.0 prefer # local clock driver
fudge 127.127.12.0 stratum 0 refid GPS
server 127.127.1.0 prefer # local clock driver
broadcast 224.0.1.1 key 6 ttl 127
peer rackety.udel.edu # (Sun4c/40 IPC)
peer barnstable.udel.edu # (Sun4c/65 SS1+)
peer mizbeaver.udel.edu #(Bancomm bc700LAN)
peer pogo.udel.edu # (Sun4c/65 SS1+)
peer rackety.udel.edu
peer barnstable.udel.edu
peer mizbeaver.udel.edu
peer pogo.udel.edu
#
# Miscellaneous stuff
#

166
contrib/ntp/conf/grundoon.conf
View File

@ -2,153 +2,35 @@
# NTP configuration file (ntp.conf)
# grundoon.udel.edu
#
# This machine can best be described as the kitchen sink. It has, in
# addition to the baseboard tty ports ttya and ttyb, an 8-line
# Serial/Parallel Interface (SPIF) with ports ttyz00 through ttyz07. The
# configuration includes the following drivers, clock addresses and Unix
# device names.
#
# Local Clock 127.127.1.0 /dev/audio
# PST 1020 WWV/WWVH Receiver 127.127.3.1 /dev/pst1
# Spectracom 8170 WWVB Receiver 127.127.4.1 /dev/wwvb1
# IRIG Audio Decoder 127.127.6.0 /dev/audio
# Scratchbuilt CHU Receiver 127.127.7.1 /dev/chu1
# NIST ACTS modem 127.127.18.1 /dev/acts1
# Heath GC-1000 WWV Receiver 127.127.19.1 /dev/pst1
# PPS Clock 127.127.22.1 none
#
# This machine has the kernel modifications described in the README.kern
# file, as well as the tty_clk, tty_chu and ppsclock streams modules.
#
# Spectracom 8170/Netclock-2 WWVB receiver. This receiver is equipped
# with a 1-pps and IRIG outputs. The 1-pps signal is connected via the
# ppsclock streams module and the carrier detect line of the CHU
# receiver below (ttyb). The IRIG signal is connected via an attenuator
# to the audio port (/dev/audio). The propagation delay computed from
# geographical coordinates is 8.8 ms, while the receiver delay
# calibrated at the factory is 17.3 ms, for a total delay of 26.1 ms.
# This is confirmed within 0.1 ms at the 1-pps signal output using a
# portable cesium clock. We add a fudge time1 of 3.5 ms so the driver
# time agrees with the 1-pps signal to within 1 ms. The fudge flag4 is
# set to cause the receiver to dump the quality table once each day to
# the clockstats file.
server 127.127.11.1 prefer # Arbiter 1088 GPS receiver
fudge 127.127.11.1 time1 .00487 flag1 1 flag4 1
server 127.127.22.1 minpoll 4 # PPS quick poll
fudge 127.127.22.1 # use PLL/FLL loop
#
#server 127.127.4.1 # /dev/wwvb1 -> /dev/ttyz03
#fudge 127.127.4.1 time1 0.0035 flag4 1
#
# IRIG Audio Decoder. The IRGI signal of the Spectracom WWVB receiver is
# connected to the audio codec via a resistor attenuator. We add a fudge
# time1 of 3.5 ms so the driver agrees with the calibrated 1-pps signal
# to within 0.1 ms. We also specify a reference ID of WWVB to indicate
# the signal origin. Note the prefer keyword in the server line, which
# favors this driver over all others that survive the clock selection
# algorithm. See README.refclock for further insight on this feature.
#
server 127.127.6.0 prefer # /dev/audio
fudge 127.127.6.0 time1 0.0005 refid WWVB
broadcast 128.4.2.255 key 5 # brpadcast on LAN shared key
broadcast 239.1.1.2 autokey # multicast on WAN autokey
manycastclient 239.1.1.1 autokey maxpoll 12 ttl 7
manycastserver 239.1.1.1
#
# PST/Traconex 1020 WWV/WWVH Receier. The internal DIPswitches are set
# as near as possible to the delays to WWV (8.8 ms) and WWVH (28.1 ms),
# as computed from geographical coordinates. We add a fudge time1 of 5.9
# ms so the driver time agrees with the 1-pps signal to within 1 ms for
# WWV. We also set the stratum to 1, so this receiver will not normally
# be selected, unless the primary WWVB receiver comes unstuck.
# Access control stuff
#
server 127.127.3.1 # /dev/pst1 -> ttyz05
fudge 127.127.3.1 time1 0.0059 stratum 1
#
# Scratchbuilt CHU Receiver. The audio signal from a computer controlled
# CHU receiver is connected to a gadget box, which contains a 103A modem
# chip and level converter operating at 300 bps. The propagation delay
# computed from geographical coordinates is 3.0 ms, which is the value
# of the fudge time1 parameter. We add a fudge time2 of 9.9 ms so that
# the driver time agrees with the 1-pps signal to within a few ms,
# ordinarily the best possible with this receiver. The fudge flag3 is
# set because the 1-pps signal happens to be connected vit the carrier
# detect line on this port (ttyb). We also set the stratum to 1, so this
# receiver will not normally be selected, unless the primary WWVB
# receiver comes unstuck.
#
server 127.127.7.1 # /dev/chu1 -> /dev/ttyb
fudge 127.127.7.1 time1 0.0030 time2 0.0099 flag3 1 stratum 1
#
# NIST Automated Computer Time Service. This driver calls a special
# telephone number in Boulder, CO, to fetch the time directly from the
# NIST cesium farm. The details of the complicated calling program are
# in the README.refclock file. The Practical Peripherals 9600SA modem
# does not work correctly with the ACTS echo-delay scheme for
# automatically calculating the propagation delay, so the fudge flag2 is
# set to disable the feature. Instead, we add a fudge time1 of 65.0 ms
# so that the driver time agrees with th e1-pps signal to within 1 ms.
# The phone command specifies three alternate telephone numbers,
# including AT modem command prefix, which will be tried one after the
# other at each measurement attempt. In this case, a cron job is used to
# set fudge flag1, causing a measurement attempt, every six hours.
#
server 127.127.18.1 # /dev/acts1 -> /dev/ttyz00
fudge 127.127.18.1 time1 0.0650 flag2 1
phone atdt13034944774 atdt13034944785 atdt13034944774
#
# Heath GC-1000 Most Accurate Clock. This is a WWV receiver with a
# claimed accuracy better than 100 ms under "hi spec" conditions, but
# such conditions are not frequent. The propagation delay DIPswitchs are
# set to 9 ms, as close as possible to the 8.8 ms computed from
# geographical coordinates. We add a fudge time2 of 40.0 ms so that the
# driver time agrees with the 1-pps signal to within 50 ms, ordinarily
# the best possible with this receiver. We also set the stratum to 1, so
# this receiver will not normally be selected, unless the primary WWVB
# receiver comes unstuck.
#
server 127.127.19.1 # /dev/heath1 -> ttyz07
fudge 127.127.19.1 time1 0.040 stratum 1
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 0
#
# PPS Clock. This driver is used to capture a 1-pps signal when the PPS
# kernel modifications are not in use. It can be configured for the
# tty_clk or ppsclock streams module or no module at all, assuming the
# RS232 connector is properly wired. Normally, the 1-pps signal is
# generated by a radio clock, in this cast the Spectracom clock
# 127.127.4.1 also configured for this host. When used this way, the
# associated radio clock normally has the prefer keyword in the serve
# command line. The PPS driver then will be selected only if the prefer
# peer is operating within nominal error bounds. See the README.refclock
# file for further details.
#
#server 127.127.22.1 # pps clock
#
# Miscellaneous stuff. We enable authentication in order to prevent
#
driftfile /etc/ntp.drift # path for drift file
statsdir /grundoon/ntpstats/ # directory for statistics files
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
restrict default noserve # default deny
restrict 127.0.0.1 # allow local host
restrict 128.4.0.0 mask 255.255.0.0 # allow DCnet clients
restrict 128.175.0.0 mask 255.255.0.0 # allow UDel clients
restrict 140.173.0.0 mask 255.255.0.0 # allow DARTnet/CAIRN clients
#
# Authentication stuff
#
crypto # enable public key
keys /usr/local/etc/ntp.keys # path for keys file
trustedkey 1 2 3 4 5 6 14 15 # define trusted keys
requestkey 15 # key (7) for accessing server variables
controlkey 15 # key (6) for accessing server variables
trustedkey 3 4 5 14 # define trusted keys
requestkey 14 # key (7) for accessing server variables
controlkey 14 # key (6) for accessing server variables
#
# Miscellaneous stuff
#
driftfile /etc/ntp.drift # path for drift file
statsdir /var/spool/ntpstats/ # directory for statistics files
filegen loopstats file loopstats type day enable

67
contrib/ntp/conf/pogo.conf
View File

@ -1,30 +1,55 @@
#
# NTP configuration file (ntp.conf)
# pogo.udel.edu
# SunOS pogo.udel.edu 5.8 Generic sun4u sparc SUNW,Ultra-1
#
server 127.127.10.1 prefer # austron 2201A gps receiver
peer 128.4.1.1 # rackety.udel.edu (Sun4c/40 IPC)
peer 128.4.1.2 # mizbeaver.udel.edu (Bancomm bc700LAN)
peer 128.4.1.4 # barnstable.udel.edu (Sun4c/65 SS1+)
peer 128.4.1.5 maxpoll 8 # churchy.udel.edu (cisco IGS router)
peer 132.163.135.130 maxpoll 8 # time_A.timefreq.bldrdoc.gov (Cesium)
peer 131.188.1.40 maxpoll 8 # ntps1-0.uni-erlangen.de (DCF77)
peer 129.132.2.21 maxpoll 8 # swisstime.ethz.ch (DCF77)
peer 130.155.98.13 maxpoll 8 # terss.ml.csiro.au (Cesium)
peer 192.36.143.150 maxpoll 8 # Time1.Stupi.SE (Cesium)
server 127.127.6.1 prefer # IRIG from GPS1
fudge 127.127.6.1 refid GPS1 time1 -.002777 flag2 1
server 127.127.4.1 # spectracom GPS receiver
# delays: prop 0.0088 ant .0002 rcvr .0173 = 26.3 ms; os .0035
fudge 127.127.4.1 refid GPS2 time1 .000221
server 127.127.22.0 # PPS from GPS2
fudge 127.127.22.0 flag3 1 # kernel PPS
#
# Miscellaneous stuff
# Backups
#
precision -18 # clock reading precision (usec)
driftfile /etc/ntp.drift # path for drift file
statsdir /pogo/ntpstats/ # directory for statistics files
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
server 128.4.1.2 # mizbeaver
server 128.175.60.175 version 3 # ntp1.nss
#
# Services
#
manycastclient 239.1.1.1 autokey maxpoll 12 ttl 7
manycastserver 239.1.1.1
#
# Access control stuff
#
restrict default noserve # default deny
restrict 127.0.0.1 # allow local host
restrict 128.4.0.0 mask 255.255.0.0 # allow DCnet clients
restrict 128.175.0.0 mask 255.255.0.0 # allow UDel clients
restrict 140.173.0.0 mask 255.255.0.0 # allow DARTnet/CAIRN clients
#
# Authentication stuff
#
# Local filesystem
# /etc/ntpkey -> ntpkey.3171396491
# /etc/ntpkey.3171396491
#
# NFS mounted filesystem
# /usr/local/etc/ntpkey -> /etc/ntpkey
# /usr/local/etc/ntpkey_dh -> ntpkey_dh.3171396491
# /usr/local/etc/ntpkey_dh.3171396491
# /usr/local/etc/ntpkey_pogo.udel.edu -> ntpkey_pogo.udel.edu.3171396491
# /usr/local/etc/ntpkey_pogo.udel.edu.3171396491
#
crypto privatekey /etc/ntpkey # enable public key
keys /usr/local/etc/ntp.keys # path for keys file
trustedkey 3 4 5 6 14 # define trusted keys
requestkey 15 # key (7) for accessing server variables
controlkey 15 # key (6) for accessing server variables
trustedkey 3 4 5 14 # define trusted keys
requestkey 14 # key (7) for accessing server variables
controlkey 14 # key (6) for accessing server variables
#
# Miscellaneous stuff
#
driftfile /etc/ntp.drift # path for drift file
statsdir /var/spool/ntpstats/ # directory for statistics files
filegen loopstats file loopstats type day enable

48
contrib/ntp/conf/rackety.conf Normal file
View File

@ -0,0 +1,48 @@
#
# NTP configuration file (ntp.conf)
# SunOS rackety.u 4.1.3 243 sun4c
#
server 127.127.4.0 prefer # Spectracom GPS receiver #1
fudge 127.127.4.0 refid GPS1 time1 -.000097 flag1 1
server 127.127.4.1 # Spectracom GPS receiver #2
fudge 127.127.4.1 refid GPS2 time1 -.000097 flag1 1
server 127.127.4.2 # Spectracom WWVB receiver #1
# delays: prop 0.0088 ant .0002 rcvr .0173 = 26.3 ms; os .0035
fudge 127.127.4.2 refid WVB1 time1 .0021 flag4 1 flag1 1
server 127.127.4.3 # Spectracom WWVB receiver #2
# delays: prop 0.0088 ant .0002 rcvr .0173 = 26.3 ms; os .0035
fudge 127.127.4.3 refid WVB2 time1 .0021 flag4 1 flag1 1
server 127.127.22.1 # PPS
fudge 127.127.22.1 flag3 1 # kernel PPS
#
# Services
#
broadcast 224.0.1.1 autokey # multicast
broadcast 128.4.1.255 autokey # local subnet broadcast
manycastclient 239.1.1.1 autokey maxpoll 12 ttl 7 # manycast
manycastserver 239.1.1.1 # manycast
#
# Access controls
#
restrict default limited # default limit clients per net
restrict 127.0.0.1 # allow local host
restrict 128.4.0.0 mask 255.255.0.0 # allow DCnet clients
restrict 128.175.0.0 mask 255.255.0.0 # allow UDELnet clients
restrict 140.173.0.0 mask 255.255.0.0 # allow DARTnet/CAIRN clients
#
# Authentication stuff
#
crypto # enable public key
keys /usr/local/etc/ntp.keys # symmetric keys file
trustedkey 3 4 5 14 # define trusted keys
requestkey 14 # key (7) for accessing server variables
controlkey 14 # key (6) for accessing server variables
#
# Miscellaneous stuff
#
driftfile /etc/ntp.drift # frequency offset
statsdir /rackety/ntpstats/ # directory for statistics files
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable

747
contrib/ntp/config.guess vendored
View File

File diff suppressed because it is too large Load Diff

882
contrib/ntp/config.h.in
View File

@ -1,67 +1,4 @@
/* config.h.in. Generated automatically from configure.in by autoheader. */
/* Define if on AIX 3.
System headers sometimes define this.
We just want to avoid a redefinition error message. */
#ifndef _ALL_SOURCE
#undef _ALL_SOURCE
#endif
/* Define if type char is unsigned and you are not using gcc. */
#ifndef __CHAR_UNSIGNED__
#undef __CHAR_UNSIGNED__
#endif
/* Define to empty if the keyword does not work. */
#undef const
/* Define to `int' if <sys/types.h> doesn't define. */
#undef gid_t
/* Define as __inline if that's what the C compiler calls it. */
#undef inline
/* Define if on MINIX. */
#undef _MINIX
/* Define if your struct nlist has an n_un member. */
#undef NLIST_NAME_UNION
/* Define if you have <nlist.h>. */
#undef NLIST_STRUCT
/* Define to `long' if <sys/types.h> doesn't define. */
#undef off_t
/* Define if the system does not provide POSIX.1 features except
with this defined. */
#undef _POSIX_1_SOURCE
/* Define if you need to in order for stat and other things to work. */
#undef _POSIX_SOURCE
/* Define as the return type of signal handlers (int or void). */
#undef RETSIGTYPE
/* Define to `unsigned' if <sys/types.h> doesn't define. */
#undef size_t
/* Define if you have the ANSI C header files. */
#undef STDC_HEADERS
/* Define if you can safely include both <sys/time.h> and <time.h>. */
#undef TIME_WITH_SYS_TIME
/* Define if your <sys/time.h> declares struct tm. */
#undef TM_IN_SYS_TIME
/* Define to `int' if <sys/types.h> doesn't define. */
#undef uid_t
/* Define if your processor stores words with the most significant
byte first (like Motorola and SPARC, unlike Intel and VAX). */
#undef WORDS_BIGENDIAN
/* debugging code */
#undef DEBUG
@ -134,6 +71,12 @@
/* HOPF 6021 clock */
#undef CLOCK_HOPF6021
/* HOPF PCI clock device */
#undef CLOCK_HOPF_PCI
/* HOPF serial clock device*/
#undef CLOCK_HOPF_SERIAL
/* HP 58503A GPS receiver */
#undef CLOCK_HPGPS
@ -326,6 +269,9 @@
/* can we use SIGPOLL for tty IO? */
#undef USE_TTY_SIGPOLL
/* should we use clock_settime()? */
#undef USE_CLOCK_SETTIME
/* do we want the CHU driver? */
#undef CLOCK_CHU
@ -353,6 +299,9 @@
/* do we need an s_char typedef? */
#undef NEED_S_CHAR_TYPEDEF
/* include the GDT Surveying code? */
#undef GDT_SURVEYING
/* does SIOCGIFCONF return size in the buffer? */
#undef SIZE_RETURNED_IN_BUFFER
@ -426,9 +375,6 @@
/* Define if you have the TIOCGSERIAL, TIOCSSERIAL, ASYNC_PPS_CD_POS, and ASYNC_PPS_CD_NEG ioctls (linux) */
#undef HAVE_TIO_SERIAL_STUFF
/* Define if you use struct timespec rather than struct timeval (time in ns rather than us) */
#undef HAVE_TIMESPEC
/* Define if you have the interface in the Draft RFC */
#undef HAVE_PPSAPI
@ -438,6 +384,10 @@
/* Do we have support for SHMEM_STATUS? */
#undef ONCORE_SHMEM_STATUS
/***/
/* Which way should we declare... */
/* adjtime()? */
#undef DECL_ADJTIME_0
@ -450,6 +400,9 @@
/* cfset[io]speed()? */
#undef DECL_CFSETISPEED_0
/* hstrerror()? */
#undef DECL_HSTRERROR_0
/* ioctl()? */
#undef DECL_IOCTL_0
@ -459,6 +412,9 @@
/* memmove()? */
#undef DECL_MEMMOVE_0
/* memset()? */
#undef DECL_MEMSET_0
/* mkstemp()? */
#undef DECL_MKSTEMP_0
@ -518,387 +474,511 @@
/* toupper()? */
#undef DECL_TOUPPER_0
/* The number of bytes in a int. */
#undef SIZEOF_INT
/* strerror()? */
#undef DECL_STRERROR_0
/* The number of bytes in a long. */
#undef SIZEOF_LONG
#undef ULONG_CONST
/* The number of bytes in a signed char. */
#undef SIZEOF_SIGNED_CHAR
/* Autokey? */
#undef AUTOKEY
/* Define if you have the K_open function. */
#undef HAVE_K_OPEN
/* Define if you have the __adjtimex function. */
#undef HAVE___ADJTIMEX
/* Define if you have the __ntp_gettime function. */
#undef HAVE___NTP_GETTIME
/* Define if you have the clock_settime function. */
#undef HAVE_CLOCK_SETTIME
/* Define if you have the daemon function. */
#undef HAVE_DAEMON
/* Define if you have the getbootfile function. */
#undef HAVE_GETBOOTFILE
/* Define if you have the getdtablesize function. */
#undef HAVE_GETDTABLESIZE
/* Define if you have the getrusage function. */
#undef HAVE_GETRUSAGE
/* Define if you have the gettimeofday function. */
#undef HAVE_GETTIMEOFDAY
/* Define if you have the getuid function. */
#undef HAVE_GETUID
/* Define if you have the kvm_open function. */
#undef HAVE_KVM_OPEN
/* Define if you have the memcpy function. */
#undef HAVE_MEMCPY
/* Define if you have the memlk function. */
#undef HAVE_MEMLK
/* Define if you have the memmove function. */
#undef HAVE_MEMMOVE
/* Define if you have the memset function. */
#undef HAVE_MEMSET
/* Define if you have the mkstemp function. */
#undef HAVE_MKSTEMP
/* Define if you have the mktime function. */
#undef HAVE_MKTIME
/* Define if you have the mlockall function. */
#undef HAVE_MLOCKALL
/* Define if you have the mrand48 function. */
#undef HAVE_MRAND48
/* Define if you have the nice function. */
#undef HAVE_NICE
/* Define if you have the nlist function. */
#undef HAVE_NLIST
/* Define if you have the ntp_adjtime function. */
#undef HAVE_NTP_ADJTIME
/* Define if you have the ntp_gettime function. */
#undef HAVE_NTP_GETTIME
/* Define if you have the plock function. */
#undef HAVE_PLOCK
/* Define if you have the pututline function. */
#undef HAVE_PUTUTLINE
/* Define if you have the pututxline function. */
#undef HAVE_PUTUTXLINE
/* Define if you have the random function. */
#undef HAVE_RANDOM
/* Define if you have the rtprio function. */
#undef HAVE_RTPRIO
/* Define if you have the sched_setscheduler function. */
#undef HAVE_SCHED_SETSCHEDULER
/* Define if you have the setlinebuf function. */
#undef HAVE_SETLINEBUF
/* Define if you have the setpgid function. */
#undef HAVE_SETPGID
/* Define if you have the setpriority function. */
#undef HAVE_SETPRIORITY
/* Define if you have the setsid function. */
#undef HAVE_SETSID
/* Define if you have the settimeofday function. */
#undef HAVE_SETTIMEOFDAY
/* Define if you have the setvbuf function. */
#undef HAVE_SETVBUF
/* Define if you have the sigaction function. */
#undef HAVE_SIGACTION
/* Define if you have the sigset function. */
#undef HAVE_SIGSET
/* Define if you have the sigsuspend function. */
#undef HAVE_SIGSUSPEND
/* Define if you have the sigvec function. */
#undef HAVE_SIGVEC
/* Define if you have the srand48 function. */
#undef HAVE_SRAND48
/* Define if you have the srandom function. */
#undef HAVE_SRANDOM
/* Define if you have the stime function. */
#undef HAVE_STIME
/* Define if you have the strchr function. */
#undef HAVE_STRCHR
/* Define if you have the strerror function. */
#undef HAVE_STRERROR
/* Define if you have the sysconf function. */
#undef HAVE_SYSCONF
/* Define if you have the sysctl function. */
#undef HAVE_SYSCTL
/* Define if you have the timer_create function. */
#undef HAVE_TIMER_CREATE
/* Define if you have the timer_settime function. */
#undef HAVE_TIMER_SETTIME
/* Define if you have the umask function. */
#undef HAVE_UMASK
/* Define if you have the uname function. */
#undef HAVE_UNAME
/* Define if you have the updwtmp function. */
#undef HAVE_UPDWTMP
/* Define if you have the updwtmpx function. */
#undef HAVE_UPDWTMPX
/* Define if you have the vsprintf function. */
#undef HAVE_VSPRINTF
/* Define if you have the </sys/sync/queue.h> header file. */
#undef HAVE__SYS_SYNC_QUEUE_H
/* Define if you have the </sys/sync/sema.h> header file. */
#undef HAVE__SYS_SYNC_SEMA_H
/* Define if you have the <arpa/nameser.h> header file. */
/* Define if you have the <arpa/nameser.h> header file. */
#undef HAVE_ARPA_NAMESER_H
/* Define if you have the <bstring.h> header file. */
/* Do we have audio support? */
#undef HAVE_AUDIO
/* Define if you have the <bstring.h> header file. */
#undef HAVE_BSTRING_H
/* Define if you have the <errno.h> header file. */
/* Define if you have the `clock_settime' function. */
#undef HAVE_CLOCK_SETTIME
/* Define if you have the `daemon' function. */
#undef HAVE_DAEMON
/* Define if you have the <errno.h> header file. */
#undef HAVE_ERRNO_H
/* Define if you have the <fcntl.h> header file. */
/* Define if you have the <fcntl.h> header file. */
#undef HAVE_FCNTL_H
/* Define if you have the <machine/inline.h> header file. */
#undef HAVE_MACHINE_INLINE_H
/* Define if you have the `finite' function. */
#undef HAVE_FINITE
/* Define if you have the <memory.h> header file. */
#undef HAVE_MEMORY_H
/* Define if you have the `getbootfile' function. */
#undef HAVE_GETBOOTFILE
/* Define if you have the <net/if.h> header file. */
#undef HAVE_NET_IF_H
/* Define if you have the `getclock' function. */
#undef HAVE_GETCLOCK
/* Define if you have the <netdb.h> header file. */
#undef HAVE_NETDB_H
/* Define if you have the `getdtablesize' function. */
#undef HAVE_GETDTABLESIZE
/* Define if you have the <netinet/in.h> header file. */
#undef HAVE_NETINET_IN_H
/* Define if you have the `getrusage' function. */
#undef HAVE_GETRUSAGE
/* Define if you have the <netinet/in_systm.h> header file. */
#undef HAVE_NETINET_IN_SYSTM_H
/* Define if you have the `gettimeofday' function. */
#undef HAVE_GETTIMEOFDAY
/* Define if you have the <netinfo/ni.h> header file. */
#undef HAVE_NETINFO_NI_H
/* Define if you have the `getuid' function. */
#undef HAVE_GETUID
/* Define if you have the <poll.h> header file. */
#undef HAVE_POLL_H
/* Define if you have the `hstrerror' function. */
#undef HAVE_HSTRERROR
/* Define if you have the <resolv.h> header file. */
#undef HAVE_RESOLV_H
/* Define if you have the <ieeefp.h> header file. */
#undef HAVE_IEEEFP_H
/* Define if you have the <sched.h> header file. */
#undef HAVE_SCHED_H
/* Define if you have the <inttypes.h> header file. */
#undef HAVE_INTTYPES_H
/* Define if you have the <sgtty.h> header file. */
#undef HAVE_SGTTY_H
/* Define if you have the `isfinite' function. */
#undef HAVE_ISFINITE
/* Define if you have the <stdlib.h> header file. */
#undef HAVE_STDLIB_H
/* Define if you have the `kvm_open' function. */
#undef HAVE_KVM_OPEN
/* Define if you have the <string.h> header file. */
#undef HAVE_STRING_H
/* Define if you have the `K_open' function. */
#undef HAVE_K_OPEN
/* Define if you have the <sun/audioio.h> header file. */
#undef HAVE_SUN_AUDIOIO_H
/* Define if you have the <sys/audioio.h> header file. */
#undef HAVE_SYS_AUDIOIO_H
/* Define if you have the <sys/clkdefs.h> header file. */
#undef HAVE_SYS_CLKDEFS_H
/* Define if you have the <sys/file.h> header file. */
#undef HAVE_SYS_FILE_H
/* Define if you have the <sys/i8253.h> header file. */
#undef HAVE_SYS_I8253_H
/* Define if you have the <sys/ioctl.h> header file. */
#undef HAVE_SYS_IOCTL_H
/* Define if you have the <sys/lock.h> header file. */
#undef HAVE_SYS_LOCK_H
/* Define if you have the <sys/mman.h> header file. */
#undef HAVE_SYS_MMAN_H
/* Define if you have the <sys/modem.h> header file. */
#undef HAVE_SYS_MODEM_H
/* Define if you have the <sys/param.h> header file. */
#undef HAVE_SYS_PARAM_H
/* Define if you have the <sys/pcl720.h> header file. */
#undef HAVE_SYS_PCL720_H
/* Define if you have the <sys/ppsclock.h> header file. */
#undef HAVE_SYS_PPSCLOCK_H
/* Define if you have the <sys/ppstime.h> header file. */
#undef HAVE_SYS_PPSTIME_H
/* Define if you have the <sys/proc.h> header file. */
#undef HAVE_SYS_PROC_H
/* Define if you have the <sys/resource.h> header file. */
#undef HAVE_SYS_RESOURCE_H
/* Define if you have the <sys/sched.h> header file. */
#undef HAVE_SYS_SCHED_H
/* Define if you have the <sys/select.h> header file. */
#undef HAVE_SYS_SELECT_H
/* Define if you have the <sys/sio.h> header file. */
#undef HAVE_SYS_SIO_H
/* Define if you have the <sys/sockio.h> header file. */
#undef HAVE_SYS_SOCKIO_H
/* Define if you have the <sys/stat.h> header file. */
#undef HAVE_SYS_STAT_H
/* Define if you have the <sys/stream.h> header file. */
#undef HAVE_SYS_STREAM_H
/* Define if you have the <sys/stropts.h> header file. */
#undef HAVE_SYS_STROPTS_H
/* Define if you have the <sys/sysctl.h> header file. */
#undef HAVE_SYS_SYSCTL_H
/* Define if you have the <sys/syssgi.h> header file. */
#undef HAVE_SYS_SYSSGI_H
/* Define if you have the <sys/termios.h> header file. */
#undef HAVE_SYS_TERMIOS_H
/* Define if you have the <sys/time.h> header file. */
#undef HAVE_SYS_TIME_H
/* Define if you have the <sys/timepps.h> header file. */
#undef HAVE_SYS_TIMEPPS_H
/* Define if you have the <sys/timers.h> header file. */
#undef HAVE_SYS_TIMERS_H
/* Define if you have the <sys/timex.h> header file. */
#undef HAVE_SYS_TIMEX_H
/* Define if you have the <sys/tpro.h> header file. */
#undef HAVE_SYS_TPRO_H
/* Define if you have the <sys/types.h> header file. */
#undef HAVE_SYS_TYPES_H
/* Define if you have the <sys/wait.h> header file. */
#undef HAVE_SYS_WAIT_H
/* Define if you have the <termio.h> header file. */
#undef HAVE_TERMIO_H
/* Define if you have the <termios.h> header file. */
#undef HAVE_TERMIOS_H
/* Define if you have the <timepps.h> header file. */
#undef HAVE_TIMEPPS_H
/* Define if you have the <timex.h> header file. */
#undef HAVE_TIMEX_H
/* Define if you have the <unistd.h> header file. */
#undef HAVE_UNISTD_H
/* Define if you have the <utmp.h> header file. */
#undef HAVE_UTMP_H
/* Define if you have the <utmpx.h> header file. */
#undef HAVE_UTMPX_H
/* Define if you have the advapi32 library (-ladvapi32). */
/* Define if you have the `advapi32' library (-ladvapi32). */
#undef HAVE_LIBADVAPI32
/* Define if you have the elf library (-lelf). */
/* Define if you have the `elf' library (-lelf). */
#undef HAVE_LIBELF
/* Define if you have the gen library (-lgen). */
/* Define if you have the `gen' library (-lgen). */
#undef HAVE_LIBGEN
/* Define if you have the kvm library (-lkvm). */
/* Define if you have the `kvm' library (-lkvm). */
#undef HAVE_LIBKVM
/* Define if you have the ld library (-lld). */
/* Define if you have the `ld' library (-lld). */
#undef HAVE_LIBLD
/* Define if you have the mld library (-lmld). */
/* Define if you have the `mld' library (-lmld). */
#undef HAVE_LIBMLD
/* Define if you have the nsl library (-lnsl). */
/* Define if you have the `nsl' library (-lnsl). */
#undef HAVE_LIBNSL
/* Define if you have the rt library (-lrt). */
/* Define if you have the `posix4' library (-lposix4). */
#undef HAVE_LIBPOSIX4
/* Define if you have the `readline' library (-lreadline). */
#undef HAVE_LIBREADLINE
/* Define if you have the `rt' library (-lrt). */
#undef HAVE_LIBRT
/* Define if you have the socket library (-lsocket). */
/* Define if you have the `socket' library (-lsocket). */
#undef HAVE_LIBSOCKET
/* Name of package */
#undef PACKAGE
/* Define if you have the <machine/inline.h> header file. */
#undef HAVE_MACHINE_INLINE_H
/* Version number of package */
#undef VERSION
/* Define if you have the <math.h> header file. */
#undef HAVE_MATH_H
/* Define if compiler has function prototypes */
#undef PROTOTYPES
/* Define if you have the `memcpy' function. */
#undef HAVE_MEMCPY
/* Define if you have the `memlk' function. */
#undef HAVE_MEMLK
/* Define if you have the `memmove' function. */
#undef HAVE_MEMMOVE
/* Define if you have the <memory.h> header file. */
#undef HAVE_MEMORY_H
/* Define if you have the `memset' function. */
#undef HAVE_MEMSET
/* Define if you have the `mkstemp' function. */
#undef HAVE_MKSTEMP
/* Define if you have the `mktime' function. */
#undef HAVE_MKTIME
/* Define if you have the `mlockall' function. */
#undef HAVE_MLOCKALL
/* Define if you have the `mrand48' function. */
#undef HAVE_MRAND48
/* Define if you have the <netdb.h> header file. */
#undef HAVE_NETDB_H
/* Define if you have the <netinet/in.h> header file. */
#undef HAVE_NETINET_IN_H
/* Define if you have the <netinet/in_systm.h> header file. */
#undef HAVE_NETINET_IN_SYSTM_H
/* Define if you have the <netinfo/ni.h> header file. */
#undef HAVE_NETINFO_NI_H
/* Define if you have the <net/if.h> header file. */
#undef HAVE_NET_IF_H
/* Define if you have the `nice' function. */
#undef HAVE_NICE
/* Define if you have the `nlist' function. */
#undef HAVE_NLIST
/* Define if you have the `ntp_adjtime' function. */
#undef HAVE_NTP_ADJTIME
/* Define if you have the `ntp_gettime' function. */
#undef HAVE_NTP_GETTIME
/* Define if you have the `plock' function. */
#undef HAVE_PLOCK
/* Define if you have the <poll.h> header file. */
#undef HAVE_POLL_H
/* Define if you have the `pututline' function. */
#undef HAVE_PUTUTLINE
/* Define if you have the `pututxline' function. */
#undef HAVE_PUTUTXLINE
/* Define if you have the `random' function. */
#undef HAVE_RANDOM
/* Define if you have the `readlink' function. */
#undef HAVE_READLINK
/* Define if you have the <resolv.h> header file. */
#undef HAVE_RESOLV_H
/* Define if you have the `rtprio' function. */
#undef HAVE_RTPRIO
/* Define if you have the <sched.h> header file. */
#undef HAVE_SCHED_H
/* Define if you have the `sched_setscheduler' function. */
#undef HAVE_SCHED_SETSCHEDULER
/* Define if you have the `setlinebuf' function. */
#undef HAVE_SETLINEBUF
/* Define if you have the `setpgid' function. */
#undef HAVE_SETPGID
/* Define if you have the `setpriority' function. */
#undef HAVE_SETPRIORITY
/* Define if you have the `setsid' function. */
#undef HAVE_SETSID
/* Define if you have the `settimeofday' function. */
#undef HAVE_SETTIMEOFDAY
/* Define if you have the `setvbuf' function. */
#undef HAVE_SETVBUF
/* Define if you have the <sgtty.h> header file. */
#undef HAVE_SGTTY_H
/* Define if you have the `sigaction' function. */
#undef HAVE_SIGACTION
/* Define if you have the `sigset' function. */
#undef HAVE_SIGSET
/* Define if you have the `sigsuspend' function. */
#undef HAVE_SIGSUSPEND
/* Define if you have the `sigvec' function. */
#undef HAVE_SIGVEC
/* Define if you have the `snprintf' function. */
#undef HAVE_SNPRINTF
/* Define if you have the `srand48' function. */
#undef HAVE_SRAND48
/* Define if you have the <stdlib.h> header file. */
#undef HAVE_STDLIB_H
/* Define if you have the `stime' function. */
#undef HAVE_STIME
/* Define if you have the `strchr' function. */
#undef HAVE_STRCHR
/* Define if you have the `strdup' function. */
#undef HAVE_STRDUP
/* Define if you have the `strerror' function. */
#undef HAVE_STRERROR
/* Define if you have the <strings.h> header file. */
#undef HAVE_STRINGS_H
/* Define if you have the <string.h> header file. */
#undef HAVE_STRING_H
/* Do we have struct ntptimeval? */
#undef HAVE_STRUCT_NTPTIMEVAL
/* Does ntptimeval use struct timespec? */
#undef TIMESPEC_IN_NTPTIMEVAL
/* Define if `time.tv_nsec' is member of `struct ntptimeval'. */
#undef HAVE_STRUCT_NTPTIMEVAL_TIME_TV_NSEC
/* Do we have struct timespec? */
#undef HAVE_STRUCT_TIMESPEC
/* Define if you have the <sun/audioio.h> header file. */
#undef HAVE_SUN_AUDIOIO_H
/* Define if you have the `sysconf' function. */
#undef HAVE_SYSCONF
/* Define if you have the `sysctl' function. */
#undef HAVE_SYSCTL
/* Define if you have the <sys/audioio.h> header file. */
#undef HAVE_SYS_AUDIOIO_H
/* Define if you have the <sys/clkdefs.h> header file. */
#undef HAVE_SYS_CLKDEFS_H
/* Define if you have the <sys/file.h> header file. */
#undef HAVE_SYS_FILE_H
/* Define if you have the <sys/i8253.h> header file. */
#undef HAVE_SYS_I8253_H
/* Define if you have the <sys/ioctl.h> header file. */
#undef HAVE_SYS_IOCTL_H
/* Define if you have the <sys/lock.h> header file. */
#undef HAVE_SYS_LOCK_H
/* Define if you have the <sys/mman.h> header file. */
#undef HAVE_SYS_MMAN_H
/* Define if you have the <sys/modem.h> header file. */
#undef HAVE_SYS_MODEM_H
/* Define if you have the <sys/param.h> header file. */
#undef HAVE_SYS_PARAM_H
/* Define if you have the <sys/pcl720.h> header file. */
#undef HAVE_SYS_PCL720_H
/* Define if you have the <sys/ppsclock.h> header file. */
#undef HAVE_SYS_PPSCLOCK_H
/* Define if you have the <sys/ppstime.h> header file. */
#undef HAVE_SYS_PPSTIME_H
/* Define if you have the <sys/proc.h> header file. */
#undef HAVE_SYS_PROC_H
/* Define if you have the <sys/resource.h> header file. */
#undef HAVE_SYS_RESOURCE_H
/* Define if you have the <sys/sched.h> header file. */
#undef HAVE_SYS_SCHED_H
/* Define if you have the <sys/select.h> header file. */
#undef HAVE_SYS_SELECT_H
/* Define if you have the <sys/sio.h> header file. */
#undef HAVE_SYS_SIO_H
/* Define if you have the <sys/sockio.h> header file. */
#undef HAVE_SYS_SOCKIO_H
/* Define if you have the <sys/stat.h> header file. */
#undef HAVE_SYS_STAT_H
/* Define if you have the <sys/stream.h> header file. */
#undef HAVE_SYS_STREAM_H
/* Define if you have the <sys/stropts.h> header file. */
#undef HAVE_SYS_STROPTS_H
/* Define if you have the <sys/sysctl.h> header file. */
#undef HAVE_SYS_SYSCTL_H
/* Define if you have the <sys/syssgi.h> header file. */
#undef HAVE_SYS_SYSSGI_H
/* Define if you have the <sys/termios.h> header file. */
#undef HAVE_SYS_TERMIOS_H
/* Define if you have the <sys/timepps.h> header file. */
#undef HAVE_SYS_TIMEPPS_H
/* Define if you have the <sys/timers.h> header file. */
#undef HAVE_SYS_TIMERS_H
/* Define if you have the <sys/timex.h> header file. */
#undef HAVE_SYS_TIMEX_H
/* Define if you have the <sys/time.h> header file. */
#undef HAVE_SYS_TIME_H
/* Define if you have the <sys/tpro.h> header file. */
#undef HAVE_SYS_TPRO_H
/* Define if you have the <sys/types.h> header file. */
#undef HAVE_SYS_TYPES_H
/* Define if you have the <sys/wait.h> header file. */
#undef HAVE_SYS_WAIT_H
/* Define if the system has the type `s_char'. */
#undef HAVE_S_CHAR
/* Define if you have the <termios.h> header file. */
#undef HAVE_TERMIOS_H
/* Define if you have the <termio.h> header file. */
#undef HAVE_TERMIO_H
/* Define if you have the <timepps.h> header file. */
#undef HAVE_TIMEPPS_H
/* Define if you have the `timer_create' function. */
#undef HAVE_TIMER_CREATE
/* Define if you have the `timer_settime' function. */
#undef HAVE_TIMER_SETTIME
/* Define if you have the <timex.h> header file. */
#undef HAVE_TIMEX_H
/* Define if you have the `umask' function. */
#undef HAVE_UMASK
/* Define if you have the `uname' function. */
#undef HAVE_UNAME
/* Define if you have the <unistd.h> header file. */
#undef HAVE_UNISTD_H
/* Define if you have the `updwtmp' function. */
#undef HAVE_UPDWTMP
/* Define if you have the `updwtmpx' function. */
#undef HAVE_UPDWTMPX
/* Define if you have the <utmpx.h> header file. */
#undef HAVE_UTMPX_H
/* Define if you have the <utmp.h> header file. */
#undef HAVE_UTMP_H
/* Define if you have the `vsprintf' function. */
#undef HAVE_VSPRINTF
/* Define if you have the </sys/sync/queue.h> header file. */
#undef HAVE__SYS_SYNC_QUEUE_H
/* Define if you have the </sys/sync/sema.h> header file. */
#undef HAVE__SYS_SYNC_SEMA_H
/* Define if you have the `__adjtimex' function. */
#undef HAVE___ADJTIMEX
/* Define if you have the `__ntp_gettime' function. */
#undef HAVE___NTP_GETTIME
/* Default location of crypto key info */
#undef NTP_KEYSDIR
/* Use OpenSSL? */
#undef OPENSSL
/* Name of package */
#undef PACKAGE
/* Define if compiler has function prototypes */
#undef PROTOTYPES
/* Public key? */
#undef PUBKEY
/* Define as the return type of signal handlers (`int' or `void'). */
#undef RETSIGTYPE
/* Use RSAREF? */
#undef RSAREF
/* The size of a `int', as computed by sizeof. */
#undef SIZEOF_INT
/* The size of a `long', as computed by sizeof. */
#undef SIZEOF_LONG
/* The size of a `signed char', as computed by sizeof. */
#undef SIZEOF_SIGNED_CHAR
/* Define if you have the ANSI C header files. */
#undef STDC_HEADERS
/* Define if you can safely include both <sys/time.h> and <time.h>. */
#undef TIME_WITH_SYS_TIME
/* Define if your <sys/time.h> declares `struct tm'. */
#undef TM_IN_SYS_TIME
/* Version number of package */
#undef VERSION
/* Define if your processor stores words with the most significant byte first
(like Motorola and SPARC, unlike Intel and VAX). */
#undef WORDS_BIGENDIAN
/* Define if on AIX 3.
System headers sometimes define this.
We just want to avoid a redefinition error message. */
#ifndef _ALL_SOURCE
# undef _ALL_SOURCE
#endif
/* Define if on MINIX. */
#undef _MINIX
/* Define if the system does not provide POSIX.1 features except with this
defined. */
#undef _POSIX_1_SOURCE
/* Define if you need to in order for stat and other things to work. */
#undef _POSIX_SOURCE
/* Define if type `char' is unsigned and you are not using gcc. */
#ifndef __CHAR_UNSIGNED__
# undef __CHAR_UNSIGNED__
#endif
/* Define to empty if `const' does not conform to ANSI C. */
#undef const
/* Define to `int' if <sys/types.h> doesn't define. */
#undef gid_t
/* Define as `__inline' if that's what the C compiler calls it, or to nothing
if it is not supported. */
#undef inline
/* Define to `long' if <sys/types.h> does not define. */
#undef off_t
/* Define to `unsigned' if <sys/types.h> does not define. */
#undef size_t
/* Define to `long' if <sys/types.h> does not define. */
#undef time_t
/* Define to `int' if <sys/types.h> doesn't define. */
#undef uid_t

309
contrib/ntp/config.sub vendored
View File

@ -1,6 +1,10 @@
#! /bin/sh
# Configuration validation subroutine script, version 1.1.
# Copyright (C) 1991, 92-97, 1998, 1999 Free Software Foundation, Inc.
# Configuration validation subroutine script.
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
# Free Software Foundation, Inc.
timestamp='2001-06-08'
# This file is (in principle) common to ALL GNU software.
# The presence of a machine in this file suggests that SOME GNU software
# can handle that machine. It does not imply ALL GNU software can.
@ -25,6 +29,8 @@
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that program.
# Please send patches to <config-patches@gnu.org>.
#
# Configuration subroutine to validate and canonicalize a configuration type.
# Supply the specified configuration type as an argument.
# If it is invalid, we print an error message on stderr and exit with code 1.
@ -45,30 +51,73 @@
# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
# It is wrong to echo any other type of specification.
if [ x$1 = x ]
then
echo Configuration name missing. 1>&2
echo "Usage: $0 CPU-MFR-OPSYS" 1>&2
echo "or $0 ALIAS" 1>&2
echo where ALIAS is a recognized configuration type. 1>&2
exit 1
fi
me=`echo "$0" | sed -e 's,.*/,,'`
# First pass through any local machine types.
case $1 in
*local*)
echo $1
exit 0
;;
*)
;;
usage="\
Usage: $0 [OPTION] CPU-MFR-OPSYS
$0 [OPTION] ALIAS
Canonicalize a configuration name.
Operation modes:
-h, --help print this help, then exit
-t, --time-stamp print date of last modification, then exit
-v, --version print version number, then exit
Report bugs and patches to <config-patches@gnu.org>."
version="\
GNU config.sub ($timestamp)
Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
help="
Try \`$me --help' for more information."
# Parse command line
while test $# -gt 0 ; do
case $1 in
--time-stamp | --time* | -t )
echo "$timestamp" ; exit 0 ;;
--version | -v )
echo "$version" ; exit 0 ;;
--help | --h* | -h )
echo "$usage"; exit 0 ;;
-- ) # Stop option processing
shift; break ;;
- ) # Use stdin as input.
break ;;
-* )
echo "$me: invalid option $1$help"
exit 1 ;;
*local*)
# First pass through any local machine types.
echo $1
exit 0;;
* )
break ;;
esac
done
case $# in
0) echo "$me: missing argument$help" >&2
exit 1;;
1) ;;
*) echo "$me: too many arguments$help" >&2
exit 1;;
esac
# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
# Here we must recognize all the valid KERNEL-OS combinations.
maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
case $maybe_os in
linux-gnu*)
nto-qnx* | linux-gnu* | storm-chaos* | os2-emx* | windows32-*)
os=-$maybe_os
basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
;;
@ -94,7 +143,7 @@ case $os in
-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
-apple)
-apple | -axis)
os=
basic_machine=$1
;;
@ -105,9 +154,17 @@ case $os in
-scout)
;;
-wrs)
os=vxworks
os=-vxworks
basic_machine=$1
;;
-chorusos*)
os=-chorusos
basic_machine=$1
;;
-chorusrdb)
os=-chorusrdb
basic_machine=$1
;;
-hiux*)
os=-hiuxwe2
;;
@ -156,33 +213,50 @@ case $os in
-psos*)
os=-psos
;;
-mint | -mint[0-9]*)
basic_machine=m68k-atari
os=-mint
;;
esac
# Decode aliases for certain CPU-COMPANY combinations.
case $basic_machine in
# Recognize the basic CPU types without company name.
# Some are omitted here because they have special meanings below.
tahoe | i860 | ia64 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \
| arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \
tahoe | i860 | ia64 | m32r | m68k | m68000 | m88k | ns32k | arc \
| arm | arme[lb] | arm[bl]e | armv[2345] | armv[345][lb] | strongarm | xscale \
| pyramid | mn10200 | mn10300 | tron | a29k \
| 580 | i960 | h8300 \
| x86 | ppcbe | mipsbe | mipsle | shbe | shle \
| hppa | hppa1.0 | hppa1.1 | hppa2.0 | hppa2.0w | hppa2.0n \
| alpha | alphaev[4-7] | alphaev56 | alphapca5[67] \
| we32k | ns16k | clipper | i370 | sh | powerpc | powerpcle \
| 1750a | dsp16xx | pdp11 | mips16 | mips64 | mipsel | mips64el \
| hppa64 \
| alpha | alphaev[4-8] | alphaev56 | alphapca5[67] \
| alphaev6[78] \
| we32k | ns16k | clipper | i370 | sh | sh[34] \
| powerpc | powerpcle \
| 1750a | dsp16xx | pdp10 | pdp11 \
| mips16 | mips64 | mipsel | mips64el \
| mips64orion | mips64orionel | mipstx39 | mipstx39el \
| mips64vr4300 | mips64vr4300el | mips64vr4100 | mips64vr4100el \
| mips64vr5000 | miprs64vr5000el | mcore \
| sparc | sparclet | sparclite | sparc64 | sparcv9 | v850 | c4x \
| thumb | d10v)
| mips64vr5000 | mips64vr5000el | mcore | s390 | s390x \
| sparc | sparclet | sparclite | sparc64 | sparcv9 | sparcv9b \
| v850 | c4x \
| thumb | d10v | d30v | fr30 | avr | openrisc | tic80 \
| pj | pjl | h8500 | z8k)
basic_machine=$basic_machine-unknown
;;
m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | z8k | v70 | h8500 | w65)
m6811 | m68hc11 | m6812 | m68hc12)
# Motorola 68HC11/12.
basic_machine=$basic_machine-unknown
os=-none
;;
m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65 | z8k)
;;
# We use `pc' rather than `unknown'
# because (1) that's what they normally are, and
# (2) the word "unknown" tends to confuse beginning users.
i[34567]86)
i*86 | x86_64)
basic_machine=$basic_machine-pc
;;
# Object if more than one company name word.
@ -192,23 +266,30 @@ case $basic_machine in
;;
# Recognize the basic CPU types with company name.
# FIXME: clean up the formatting here.
vax-* | tahoe-* | i[34567]86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \
| m88k-* | sparc-* | ns32k-* | fx80-* | arc-* | arm-* | c[123]* \
vax-* | tahoe-* | i*86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \
| m88k-* | sparc-* | ns32k-* | fx80-* | arc-* | c[123]* \
| arm-* | armbe-* | armle-* | armv*-* | strongarm-* | xscale-* \
| mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
| power-* | none-* | 580-* | cray2-* | h8300-* | h8500-* | i960-* \
| xmp-* | ymp-* \
| hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0-* | hppa2.0w-* | hppa2.0n-* \
| alpha-* | alphaev[4-7]-* | alphaev56-* | alphapca5[67]-* \
| x86-* | ppcbe-* | mipsbe-* | mipsle-* | shbe-* | shle-* \
| hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0-* | hppa2.0w-* \
| hppa2.0n-* | hppa64-* \
| alpha-* | alphaev[4-8]-* | alphaev56-* | alphapca5[67]-* \
| alphaev6[78]-* \
| we32k-* | cydra-* | ns16k-* | pn-* | np1-* | xps100-* \
| clipper-* | orion-* \
| sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \
| sparc64-* | sparcv9-* | sparc86x-* | mips16-* | mips64-* | mipsel-* \
| sparclite-* | pdp10-* | pdp11-* | sh-* | sh[34]-* | sh[34]eb-* \
| powerpc-* | powerpcle-* | sparc64-* | sparcv9-* | sparcv9b-* | sparc86x-* \
| mips16-* | mips64-* | mipsel-* \
| mips64el-* | mips64orion-* | mips64orionel-* \
| mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* | mips64vr4300el-* \
| mipstx39-* | mipstx39el-* | mcore-* \
| f301-* | armv*-* | t3e-* \
| f30[01]-* | f700-* | s390-* | s390x-* | sv1-* | t3e-* \
| [cjt]90-* \
| m88110-* | m680[01234]0-* | m683?2-* | m68360-* | z8k-* | d10v-* \
| thumb-* | v850-* | d30v-* | tic30-* | c30-* )
| thumb-* | v850-* | d30v-* | tic30-* | tic80-* | c30-* | fr30-* \
| bs2000-* | tic54x-* | c54x-* | x86_64-* | pj-* | pjl-*)
;;
# Recognize the various machine names and aliases which stand
# for a CPU type and a company and sometimes even an OS.
@ -245,14 +326,14 @@ case $basic_machine in
os=-sysv
;;
amiga | amiga-*)
basic_machine=m68k-cbm
basic_machine=m68k-unknown
;;
amigaos | amigados)
basic_machine=m68k-cbm
basic_machine=m68k-unknown
os=-amigaos
;;
amigaunix | amix)
basic_machine=m68k-cbm
basic_machine=m68k-unknown
os=-sysv4
;;
apollo68)
@ -299,13 +380,16 @@ case $basic_machine in
basic_machine=cray2-cray
os=-unicos
;;
[ctj]90-cray)
basic_machine=c90-cray
[cjt]90)
basic_machine=${basic_machine}-cray
os=-unicos
;;
crds | unos)
basic_machine=m68k-crds
;;
cris | cris-* | etrax*)
basic_machine=cris-axis
;;
da30 | da30-*)
basic_machine=m68k-da30
;;
@ -353,6 +437,10 @@ case $basic_machine in
basic_machine=tron-gmicro
os=-sysv
;;
go32)
basic_machine=i386-pc
os=-go32
;;
h3050r* | hiux*)
basic_machine=hppa1.1-hitachi
os=-hiuxwe2
@ -426,22 +514,21 @@ case $basic_machine in
;;
i370-ibm* | ibm*)
basic_machine=i370-ibm
os=-mvs
;;
# I'm not sure what "Sysv32" means. Should this be sysv3.2?
i[34567]86v32)
i*86v32)
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
os=-sysv32
;;
i[34567]86v4*)
i*86v4*)
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
os=-sysv4
;;
i[34567]86v)
i*86v)
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
os=-sysv
;;
i[34567]86sol2)
i*86sol2)
basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
os=-solaris2
;;
@ -453,14 +540,6 @@ case $basic_machine in
basic_machine=i386-unknown
os=-vsta
;;
i386-go32 | go32)
basic_machine=i386-unknown
os=-go32
;;
i386-mingw32 | mingw32)
basic_machine=i386-unknown
os=-mingw32
;;
iris | iris4d)
basic_machine=mips-sgi
case $os in
@ -486,10 +565,14 @@ case $basic_machine in
basic_machine=ns32k-utek
os=-sysv
;;
mingw32)
basic_machine=i386-pc
os=-mingw32
;;
miniframe)
basic_machine=m68000-convergent
;;
*mint | *MiNT)
*mint | -mint[0-9]* | *MiNT | *MiNT[0-9]*)
basic_machine=m68k-atari
os=-mint
;;
@ -507,14 +590,22 @@ case $basic_machine in
mips3*)
basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown
;;
mmix*)
basic_machine=mmix-knuth
os=-mmixware
;;
monitor)
basic_machine=m68k-rom68k
os=-coff
;;
msdos)
basic_machine=i386-unknown
basic_machine=i386-pc
os=-msdos
;;
mvs)
basic_machine=i370-ibm
os=-mvs
;;
ncr3000)
basic_machine=i486-ncr
os=-sysv4
@ -524,7 +615,7 @@ case $basic_machine in
os=-netbsd
;;
netwinder)
basic_machine=armv4l-corel
basic_machine=armv4l-rebel
os=-linux
;;
news | news700 | news800 | news900)
@ -572,9 +663,16 @@ case $basic_machine in
basic_machine=i960-intel
os=-mon960
;;
nonstopux)
basic_machine=mips-compaq
os=-nonstopux
;;
np1)
basic_machine=np1-gould
;;
nsr-tandem)
basic_machine=nsr-tandem
;;
op50n-* | op60c-*)
basic_machine=hppa1.1-oki
os=-proelf
@ -604,28 +702,28 @@ case $basic_machine in
pc532 | pc532-*)
basic_machine=ns32k-pc532
;;
pentium | p5 | k5 | k6 | nexen)
pentium | p5 | k5 | k6 | nexgen)
basic_machine=i586-pc
;;
pentiumpro | p6 | 6x86)
pentiumpro | p6 | 6x86 | athlon)
basic_machine=i686-pc
;;
pentiumii | pentium2)
basic_machine=i786-pc
basic_machine=i686-pc
;;
pentium-* | p5-* | k5-* | k6-* | nexen-*)
pentium-* | p5-* | k5-* | k6-* | nexgen-*)
basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'`
;;
pentiumpro-* | p6-* | 6x86-*)
pentiumpro-* | p6-* | 6x86-* | athlon-*)
basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
;;
pentiumii-* | pentium2-*)
basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'`
basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
;;
pn)
basic_machine=pn-gould
;;
power) basic_machine=rs6000-ibm
power) basic_machine=power-ibm
;;
ppc) basic_machine=powerpc-unknown
;;
@ -640,6 +738,10 @@ case $basic_machine in
ps2)
basic_machine=i386-ibm
;;
pw32)
basic_machine=i586-unknown
os=-pw32
;;
rom68k)
basic_machine=m68k-rom68k
os=-coff
@ -719,6 +821,10 @@ case $basic_machine in
sun386 | sun386i | roadrunner)
basic_machine=i386-sun
;;
sv1)
basic_machine=sv1-cray
os=-unicos
;;
symmetry)
basic_machine=i386-sequent
os=-dynix
@ -727,6 +833,10 @@ case $basic_machine in
basic_machine=t3e-cray
os=-unicos
;;
tic54x | c54x*)
basic_machine=tic54x-unknown
os=-coff
;;
tx39)
basic_machine=mipstx39-unknown
;;
@ -779,6 +889,10 @@ case $basic_machine in
basic_machine=hppa1.1-winbond
os=-proelf
;;
windows32)
basic_machine=i386-pc
os=-windows32-msvcrt
;;
xmp)
basic_machine=xmp-cray
os=-unicos
@ -822,13 +936,20 @@ case $basic_machine in
vax)
basic_machine=vax-dec
;;
pdp10)
# there are many clones, so DEC is not a safe bet
basic_machine=pdp10-unknown
;;
pdp11)
basic_machine=pdp11-dec
;;
we32k)
basic_machine=we32k-att
;;
sparc | sparcv9)
sh3 | sh4)
basic_machine=sh-unknown
;;
sparc | sparcv9 | sparcv9b)
basic_machine=sparc-sun
;;
cydra)
@ -850,6 +971,9 @@ case $basic_machine in
basic_machine=c4x-none
os=-coff
;;
*-unknown)
# Make sure to match an already-canonicalized machine name.
;;
*)
echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
exit 1
@ -906,14 +1030,29 @@ case $os in
| -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
| -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
| -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
| -chorusos* | -chorusrdb* \
| -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
| -mingw32* | -linux-gnu* | -uxpv* | -beos* | -mpeix* | -udk* \
| -interix* | -uwin* | -rhapsody* | -openstep* | -oskit*)
| -interix* | -uwin* | -rhapsody* | -darwin* | -opened* \
| -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \
| -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* | -os2*)
# Remember, each alternative MUST END IN *, to match a version number.
;;
-qnx*)
case $basic_machine in
x86-* | i*86-*)
;;
*)
os=-nto$os
;;
esac
;;
-nto*)
os=-nto-qnx
;;
-sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
| -windows* | -osx | -abug | -netware* | -os9* | -beos* \
| -macos* | -mpw* | -magic* | -mon960* | -lnews*)
| -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*)
;;
-mac*)
os=`echo $os | sed -e 's|mac|macos|'`
@ -927,6 +1066,12 @@ case $os in
-sunos6*)
os=`echo $os | sed -e 's|sunos6|solaris3|'`
;;
-opened*)
os=-openedition
;;
-wince*)
os=-wince
;;
-osfrose*)
os=-osfrose
;;
@ -951,6 +1096,9 @@ case $os in
-ns2 )
os=-nextstep2
;;
-nsk*)
os=-nsk
;;
# Preserve the version number of sinix5.
-sinix5.*)
os=`echo $os | sed -e 's|sinix|sysv|'`
@ -985,7 +1133,7 @@ case $os in
-xenix)
os=-xenix
;;
-*mint | -*MiNT)
-*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*)
os=-mint
;;
-none)
@ -1013,12 +1161,15 @@ case $basic_machine in
*-acorn)
os=-riscix1.2
;;
arm*-corel)
arm*-rebel)
os=-linux
;;
arm*-semi)
os=-aout
;;
pdp10-*)
os=-tops20
;;
pdp11-*)
os=-none
;;
@ -1127,7 +1278,7 @@ case $basic_machine in
*-masscomp)
os=-rtu
;;
f301-fujitsu)
f30[01]-fujitsu | f700-fujitsu)
os=-uxpv
;;
*-rom68k)
@ -1187,7 +1338,7 @@ case $basic_machine in
-genix*)
vendor=ns
;;
-mvs*)
-mvs* | -opened*)
vendor=ibm
;;
-ptx*)
@ -1205,7 +1356,7 @@ case $basic_machine in
-mpw* | -macos*)
vendor=apple
;;
-*mint | -*MiNT)
-*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*)
vendor=atari
;;
esac
@ -1214,3 +1365,11 @@ case $basic_machine in
esac
echo $basic_machine$os
exit 0
# Local variables:
# eval: (add-hook 'write-file-hooks 'time-stamp)
# time-stamp-start: "timestamp='"
# time-stamp-format: "%:y-%02m-%02d"
# time-stamp-end: "'"
# End:

14933
contrib/ntp/configure vendored
View File

File diff suppressed because it is too large Load Diff

613
contrib/ntp/configure.in
View File

File diff suppressed because it is too large Load Diff

158
contrib/ntp/depcomp
View File

@ -1,7 +1,7 @@
#! /bin/sh
# depcomp - compile a program generating dependencies as side-effects
# Copyright (C) 1999 Free Software Foundation, Inc.
# Copyright 1999, 2000 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@ -48,6 +48,18 @@ if test "$depmode" = dashXmstdout; then
fi
case "$depmode" in
gcc3)
## gcc 3 implements dependency tracking that does exactly what
## we want. Yay!
if "$@" -MT "$object" -MF "$tmpdepfile" -MD -MP; then :
else
stat=$?
rm -f "$tmpdepfile"
exit $stat
fi
mv "$tmpdepfile" "$depfile"
;;
gcc)
## There are various ways to get dependency output from gcc. Here's
## why we pick this rather obscure method:
@ -67,9 +79,12 @@ gcc)
rm -f "$tmpdepfile"
exit $stat
fi
rm -f "$depfile"
rm -f "$depfile"
echo "$object : \\" > "$depfile"
sed 's/^[^:]*: / /' < "$tmpdepfile" >> "$depfile"
alpha=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
## The second -e expression handles DOS-style file names with drive letters.
sed -e 's/^[^:]*: / /' \
-e 's/^['$alpha']:\/[^:]*: / /' < "$tmpdepfile" >> "$depfile"
## This next piece of magic avoids the `deleted header file' problem.
## The problem is that when a header file which appears in a .P file
## is deleted, the dependency causes make to die (because there is
@ -94,41 +109,84 @@ hp)
exit 1
;;
dashmd)
# The Java front end to gcc doesn't run cpp, so we can't use the -Wp
# trick. Instead we must use -M and then rename the resulting .d
# file. This is also the case for older versions of gcc, which
# don't implement -Wp.
if "$@" -MD; then :
else
stat=$?
rm -f FIXME
exit $stat
fi
FIXME: rewrite the file
;;
sgi)
if test "$libtool" = yes; then
"$@" "-Wc,-MDupdate,$tmpdepfile"
"$@" "-Wp,-MDupdate,$tmpdepfile"
else
"$@" -MDupdate "$tmpdepfile"
fi
stat=$?
if test $stat -eq 0; then :
else
stat=$?
rm -f "$tmpdepfile"
exit $stat
fi
rm -f "$depfile"
echo "$object : \\" > "$depfile"
sed 's/^[^:]*: / /' < "$tmpdepfile" >> "$depfile"
tr ' ' '
rm -f "$depfile"
if test -f "$tmpdepfile"; then # yes, the sourcefile depend on other files
echo "$object : \\" > "$depfile"
# Clip off the initial element (the dependent). Don't try to be
# clever and replace this with sed code, as IRIX sed won't handle
# lines with more than a fixed number of characters (4096 in
# IRIX 6.2 sed, 8192 in IRIX 6.5).
tr ' ' '
' < "$tmpdepfile" | sed 's/^[^\.]*\.o://' | tr '
' ' ' >> $depfile
tr ' ' '
' < "$tmpdepfile" | \
## Some versions of the HPUX 10.20 sed can't process this invocation
## correctly. Breaking it into two sed invocations is a workaround.
sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
else
# The sourcefile does not contain any dependencies, so just
# store a dummy comment line, to avoid errors with the Makefile
# "include basename.Plo" scheme.
echo "#dummy" > "$depfile"
fi
rm -f "$tmpdepfile"
;;
aix)
# The C for AIX Compiler uses -M and outputs the dependencies
# in a .u file.
tmpdepfile=`echo "$object" | sed 's/\(.*\)\..*$/\1.u/'`
if test "$libtool" = yes; then
"$@" -Wc,-M
else
"$@" -M
fi
stat=$?
if test $stat -eq 0; then :
else
rm -f "$tmpdepfile"
exit $stat
fi
if test -f "$tmpdepfile"; then
echo "$object : \\" > "$depfile"
# Clip off the initial element (the dependent). Don't try to be
# clever and replace this with sed code, as IRIX sed won't handle
# lines with more than a fixed number of characters (4096 in
# IRIX 6.2 sed, 8192 in IRIX 6.5).
tr ' ' '
' < "$tmpdepfile" | sed 's/^[^\.]*\.o://' | tr '
' ' ' >> $depfile
tr ' ' '
' < "$tmpdepfile" | \
## Some versions of the HPUX 10.20 sed can't process this invocation
## correctly. Breaking it into two sed invocations is a workaround.
sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
else
# The sourcefile does not contain any dependencies, so just
# store a dummy comment line, to avoid errors with the Makefile
# "include basename.Plo" scheme.
echo "#dummy" > "$depfile"
fi
rm -f "$tmpdepfile"
;;
@ -166,7 +224,7 @@ dashmstdout)
stat=$?
wait "$proc"
if test "$stat" != 0; then exit $stat; fi
rm -f "$depfile"
rm -f "$depfile"
cat < "$tmpdepfile" > "$depfile"
tr ' ' '
' < "$tmpdepfile" | \
@ -210,7 +268,7 @@ makedepend)
stat=$?
wait "$proc"
if test "$stat" != 0; then exit $stat; fi
rm -f "$depfile"
rm -f "$depfile"
cat < "$tmpdepfile" > "$depfile"
tail +3 "$tmpdepfile" | tr ' ' '
' | \
@ -229,7 +287,7 @@ cpp)
*" --mode=compile "*)
for arg
do # cycle over the arguments
case "$arg" in
case $arg in
"--mode=compile")
# insert --quiet before "--mode=compile"
set fnord "$@" --quiet
@ -243,7 +301,8 @@ cpp)
;;
esac
"$@" -E |
sed -n '/^# [0-9][0-9]* "\([^"]*\)"/ s::'"$object"'\: \1:p' > "$tmpdepfile"
sed -n '/^# [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' |
sed '$ s: \\$::' > "$tmpdepfile"
) &
proc=$!
"$@"
@ -251,8 +310,47 @@ cpp)
wait "$proc"
if test "$stat" != 0; then exit $stat; fi
rm -f "$depfile"
cat < "$tmpdepfile" > "$depfile"
sed < "$tmpdepfile" -e 's/^[^:]*: //' -e 's/$/ :/' >> "$depfile"
echo "$object : \\" > "$depfile"
cat < "$tmpdepfile" >> "$depfile"
sed < "$tmpdepfile" '/^$/d;s/^ //;s/ \\$//;s/$/ :/' >> "$depfile"
rm -f "$tmpdepfile"
;;
msvisualcpp)
# Important note: in order to support this mode, a compiler *must*
# always write the proprocessed file to stdout, regardless of -o,
# because we must use -o when running libtool.
( IFS=" "
case " $* " in
*" --mode=compile "*)
for arg
do # cycle over the arguments
case $arg in
"--mode=compile")
# insert --quiet before "--mode=compile"
set fnord "$@" --quiet
shift # fnord
;;
esac
set fnord "$@" "$arg"
shift # fnord
shift # "$arg"
done
;;
esac
"$@" -E |
sed -n '/^#line [0-9][0-9]* "\([^"]*\)"/ s::echo "`cygpath -u \\"\1\\"`":p' | sort | uniq > "$tmpdepfile"
) &
proc=$!
"$@"
stat=$?
wait "$proc"
if test "$stat" != 0; then exit $stat; fi
rm -f "$depfile"
echo "$object : \\" > "$depfile"
. "$tmpdepfile" | sed 's% %\\ %g' | sed -n '/^\(.*\)$/ s:: \1 \\:p' >> "$depfile"
echo " " >> "$depfile"
. "$tmpdepfile" | sed 's% %\\ %g' | sed -n '/^\(.*\)$/ s::\1\::p' >> "$depfile"
rm -f "$tmpdepfile"
;;

45
contrib/ntp/flock-build Executable file
View File

@ -0,0 +1,45 @@
#! /bin/sh
BUILD_ARGS="$@"
PARSE="--enable-parse-clocks"
#PARSE=
# * baldwin sparc-sun-solaris2.7
# bridgeport sparc-sun-solaris2.6
# bunnylou alpha-dec-osf4.0
# * churchy alpha-dec-osf4.0
# cowbird alpha-dec-osf4.0
# grundoon sparc-sun-sunos4.1.3
# * hepzibah freebsd-2.2.5
# malarky sparc-sun-solaris2.8
# * pogo sparc-sun-solaris2.8
# * porkypine mips-dec-ultrix4.4
# * rackety sparc-sun-sunos4.1.3/cc
# * snavely hppa1.1-hp-hpux10.20
# whimsy sparc-sun-solaris2.7
c_d=`pwd`
SIG=`perl -e 'print rand'`
echo $SIG > .buildkey
case "$LIST" in
'') LIST="baldwin churchy hepzibah pogo porkypine rackety snavely" ;;
esac
for i in $LIST
do
echo $i
case "1" in
0)
ssh $i "cd $c_d ; ./build $SIG $PARSE $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $PARSE --with-crypto=autokey $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $PARSE --without-crypto $BUILD_ARGS" &
;;
1) ssh $i "cd $c_d ; \
./build $SIG $PARSE $BUILD_ARGS ; \
./build $SIG $PARSE --with-crypto=autokey $BUILD_ARGS ; \
./build $SIG $PARSE --without-crypto $BUILD_ARGS" &
;;
esac
done

257
contrib/ntp/html/Oncore-SHMEM.htm Normal file
View File

@ -0,0 +1,257 @@
<HTML>
<HEAD>
<TITLE> ONCORE - SHMEM </TITLE>
</HEAD>
<BODY>
<H3>
Motorola ONCORE - The Shared Memory Interface
</H3>
<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>
In particular, you can ask for satellite positions, satellite health, signal levels,
the ephemeris and the almanac, and you can set many operational parameters.
In the case of the VP,
you can get the pseudorange corrections necessary to act as a DGPS base station, and you can see
the raw satellite data messages themselves.
<P>
When using the Oncore GPS receiver with NTP, this additional information is usually
not available since the receiver is only talking to the oncore driver in NTPD.
To make this information available for use in other programs,
(say graphic displays of satellites positions, plots of SA, etc.), a shared memory interface
(SHMEM) has been added to the refclock_oncore driver on those operating systems that support
shared memory.
<P>
To make use of this information you will need an Oncore Reference Manual for the
Oncore GPS receiver that you have. The Manual for the VP only exists as a paper
document, the UT manuals are available as a pdf document online.
<P>
This interface was written by Poul-Henning Kamp (phk@FreeBSD.org), and modified by
Reg Clemens (reg@dwf.com).
The interface is known to work in FreeBSD, Linux, and Solaris.
<H4>
Activating the Interface
</H4>
Although the Shared Memory Interface will be compiled into the Oncore driver
on those systems where Shared Memory is supported, to activate this interface you must
include a <B>STATUS</B> line in the <tt>/etc/ntp.oncore</tt> data file that looks like
<PRE>
STATUS < file_name >
</PRE>
Thus a line like
<PRE>
STATUS /var/adm/ntpstats/ONCORE
</PRE>
would be acceptable.
This file name will be used to access the Shared Memory.
<P>
In addition, one the two keywords <B>Posn2D</B> and <B>Posn3D</B> can be added to
see @@Ea records containing the 2D or 3D position of the station (see below).
Thus to activate the interface, and see 3D positions, something like
<PRE>
STATUS /var/adm/ntpstats/ONCORE
Posn3D
</PRE>
would be required.
<H4>
Storage of Messages in Shared Memory
</H4>
With the shared memory interface, the oncore driver (refclock_oncore) allocates space
for all of the messages that it is configured to receive, and then puts each message
in the appropriate slot in shared memory as it arrives from the receiver.
Since there is no easy way for a client program to know when the shared memory has
been updated,
a sequence number is associated with each message, and is incremented when a new message
arrives.
With the sequence number it is easy to check through the shared memory segment for messages that
have changed.
<P>
The Oncore binary messages are kept in their full length, as described in the Reference
manual, that is everything from the @@ prefix thru the &lt;checksum&gt;&lt;CR&gt;&lt;LF&gt;.
<P>
The data starts at location ONE of SHMEM (NOT location ZERO).
<P>
The messages are stacked in a series of variable length structures, that look like
<PRE>
struct message {
u_int length;
u_char sequence;
u_char message[length];
}
</PRE>
<P>
if something like that were legal.
That is, there are two bytes (caution, these may NOT be aligned with word boundaries, so
the field needs to be treated as a pair of u_char), that contains the length of the next
message.
This is followed by a u_char sequence number, that is incremented whenever a new message of
this type is received.
This is followed by 'length' characters of the actual message.
<P>
The next structure starts immediately following the last char of the previous message (no alignment).
Thus, each structure starts a distance of 'length+3' from the previous structure.
<P>
Following the last structure, is a u_int containing a zero length to indicate the end
of the data.
<P>
The messages are recognized by reading the headers in the data itself, viz @@Ea or whatever.
<P>
There are two special cases.
<P>
(1) The almanac takes a total of 34 submessages all starting with @@Cb. <br>
35 slots are allocated in shared memory.
Each @@Cb message is initially placed in the first of these locations,
and then later it is moved to the appropriate location for that submessage.
The submessages can be distinguished by the first two characters following the @@Cb header,
and new data is received only when the almanac changes.
<P>
(2) The @@Ea message contains the calculated location of the antenna, and is received
once per second.
However, when in timekeeping mode, the receiver is normally put in 0D mode, with the
position fixed, to get better accuracy.
In 0D mode no position is calculated.
<P>
When the SHMEM option is active,
and if one of <B>Posn2D</B> or <B>Posn3D</B> is specified,
one @@Ea record is hijacked each 15s, and the receiver
is put back in 2D/3D mode so the the current location can be determined (for position determination, or for
tracking SA).
The timekeeping code is careful NOT to use the time associated with this (less accurate) 2D/3D tick
in its timekeeping functions.
<P>
Following the initial @@Ea message are 3 additional slots for a total of four.
As with the almanac, the first gets filled each time a new record becomes available,
later in the code, the message is distributed to the appropriate slot.
The additional slots are for messages containing 0D, 2D and 3D positions.
These messages can be distinguished by different bit patterns in the last data byte of the record.
<H4>
Opening the Shared Memory File
</H4>
The shared memory segment is accessed through a file name given on a <B>ACCESS</B> card in the
<tt>/etc/ntp.oncore</tt> input file.
The following code could be used to open the Shared Memory Segment:
<PRE>
char *Buf, *file;
int size, fd;
struct stat statbuf;
file = "/var/adm/ntpstats/ONCORE"; /* the file name on my ACCESS card */
if ((fd=open(file, O_RDONLY)) < 0) {
fprintf(stderr, "Cant open %s\n", file);
exit(1);
}
if (stat(file, &statbuf) < 0) {
fprintf(stderr, "Cant stat %s\n", file);
exit(1);
}
size = statbuf.st_size;
if ((Buf=mmap(0, size, PROT_READ, MAP_SHARED, fd, (off_t) 0)) < 0) {
fprintf(stderr, "MMAP failed\n");
exit(1);
}
</PRE>
<H4>
Accessing the data
</H4>
The following code shows how to get to the individual records.
<PRE>
void oncore_msg_Ea(), oncore_msg_As(), oncore_msg_Bb();
struct Msg {
char c[5];
unsigned int seq;
void (*go_to)(uchar *);
};
struct Msg Hdr[] = { {"@@Bb", 0, &oncore_msg_Bb},
{"@@Ea", 0, &oncore_msg_Ea},
{"@@As", 0, &oncore_msg_As}};
void
read_data()
{
int i, j, k, n, iseq, jseq;
uchar *cp, *cp1;
for(cp=Buf+1; (n = 256*(*cp) + *(cp+1)) != 0; cp+=(n+3)) {
for (k=0; k < sizeof(Hdr)/sizeof(Hdr[0]); k++) {
if (!strncmp(cp+3, Hdr[k].c, 4)) { /* am I interested? */
iseq = *(cp+2);
jseq = Hdr[k].seq;
Hdr[k].seq = iseq;
if (iseq > jseq) { /* has it changed? */
/* verify checksum */
j = 0;
cp1 = cp+3; /* points to start of oncore response */
for (i=2; i < n-3; i++)
j ^= cp1[i];
if (j == cp1[n-3]) { /* good checksum */
Hdr[k].go_to(cp1);
} else {
fprintf(stderr, "Bad Checksum for %s\n", Hdr[k].c);
break;
}
}
}
}
if (!strncmp(cp+3, "@@Ea", 4))
cp += 3*(n+3);
if (!strncmp(cp+3, "@@Cb", 4))
cp += 34*(n+3);
}
}
oncore_msg_Bb(uchar *buf)
{
/* process Bb messages */
}
oncore_msg_Ea(uchar *buf)
{
/* process Ea messages */
}
oncore_msg_As(uchar *buf)
{
/* process As messages */
}
</PRE>
The structure Hdr contains the Identifying string for each of the messages that
we want to examine, and the name of a program to call when a new message of that
type is arrives.
The loop can be run every few seconds to check for new data.
<H4>
Examples
</H4>
There are two complete examples available.
The first plots satellite positions and the station position as affected by SA, and
keeps track of the mean station position, so you can run it for periods of days
to get a better station position.
The second shows the effective horizon by watching satellite tracks.
The examples will be found in the GNU-zipped tar file
<A HREF=ftp://ftp.udel.edu/pub/ntp/software/OncorePlot.tar.gz>
ftp://ftp.udel.edu/pub/ntp/software/OncorePlot.tar.gz</A>.
<P>
Try the new interface, enjoy.
<HR>
<ADDRESS>
Reg.Clemens (reg@dwf.com),
Poul-Henning Kamp (phk@FreeBSD.org)
<ADDRESS>
</BODY>
</HTML>

341
contrib/ntp/html/accopt.htm
View File

@ -1,219 +1,210 @@
<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>Access Control Options
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Access Control Options</title>
</head>
<body>
<h3>Access Control Options</h3>
<H3>
Access Control Options</H3>
<img align="left" src="pic/pogo6.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<HR>
<H4>
Access Control Support</H4>
<TT>ntpd</TT> implements a general purpose address-and-mask based restriction
list. The list is sorted by address and by mask, and the list is searched
in this order for matches, with the last match found defining the restriction
flags associated with the incoming packets. The source address of incoming
packets is used for the match, with the 32-bit address being and'ed with
the mask associated with the restriction entry and then compared with the
entry's address (which has also been and'ed with the mask) to look for
a match. Additional information and examples can be found in the <A HREF="notes.htm">Notes
on Configuring NTP and Setting up a NTP Subnet </A>page.
<p>The skunk watches for intruders and sprays.<br clear="left">
</p>
<P>The restriction facility was implemented in conformance with the access
policies for the original NSFnet backbone time servers. While this facility
may be otherwise useful for keeping unwanted or broken remote time servers
from affecting your own, it should not be considered an alternative to
the standard NTP authentication facility. Source address based restrictions
are easily circumvented by a determined cracker.
<H4>
Access Control Commands</H4>
<hr>
<h4>Access Control Support</h4>
<DL>
<DT>
<TT>restrict <I>numeric_address</I> [mask <I>numeric_mask</I>] [<I>flag</I>]
[...]</TT></DT>
<tt>ntpd</tt> implements a general purpose address-and-mask based
restriction list. The list is sorted by address and by mask, and
the list is searched in this order for matches, with the last match
found defining the restriction flags associated with the incoming
packets. The source address of incoming packets is used for the
match, with the 32- bit address being and'ed with the mask
associated with the restriction entry and then compared with the
entry's address (which has also been and'ed with the mask) to look
for a match. Additional information and examples can be found in
the <a href="notes.htm">Notes on Configuring NTP and Setting up a
NTP Subnet</a> page.
<DD>
The <I><TT>numeric_address</TT></I> argument, expressed in dotted-quad
form, is the address of an host or network. The <I><TT>mask</TT></I> argument,
also expressed in dotted-quad form, defaults to <TT>255.255.255.255</TT>,
meaning that the <I><TT>numeric_address</TT></I> is treated as the address
of an individual host. A default entry (address <TT>0.0.0.0</TT>, mask
<TT>0.0.0.0</TT>) is always included and, given the sort algorithm, is
always the first entry in the list. Note that, while <I><TT>numeric_address</TT></I>
is normally given in dotted-quad format, the text string <TT>default</TT>,
with no mask option, may be used to indicate the default entry.</DD>
<p>The restriction facility was implemented in conformance with the
access policies for the original NSFnet backbone time servers.
While this facility may be otherwise useful for keeping unwanted or
broken remote time servers from affecting your own, it should not
be considered an alternative to the standard NTP authentication
facility. Source address based restrictions are easily circumvented
by a determined cracker.</p>
<DD>
In the current implementation, <I><TT>flag</TT></I> always restricts access,
i.e., an entry with no flags indicates that free access to the server is
to be given. The flags are not orthogonal, in that more restrictive flags
will often make less restrictive ones redundant. The flags can generally
be classed into two catagories, those which restrict time service and those
which restrict informational queries and attempts to do run-time reconfiguration
of the server. One or more of the following flags may be specified:</DD>
<h4>The Kiss-of-Death Packet</h4>
<DD>
&nbsp;</DD>
<p>Ordinarily, packets denied service are simply dropped with no
further action except incrementing statistics counters. Sometimes a
more proactive response is needed, such as a server message that
explicitly requests the client to stop sending and leave a message
for the system operator. A special packet format has been created
for this purpose called the kiss-of-death packet. If the <tt>
kod</tt> flag is set and either service is denied or the client
limit is exceeded, the server it returns the packet and sets the
leap bits unsynchronized, stratum zero and the ASCII string "DENY"
in the reference source identifier field. If the <tt>kod</tt> flag
is not set, the server simply drops the packet.</p>
<DL>
<DT>
<TT>ignore</TT></DT>
<p>A client or peer receiving a kiss-of-death packet performs a set
of sanity checks to minimize security exposure. If this is the
first packet received from the server, the client assumes an access
denied condition at the server. It updates the stratum and
reference identifier peer variables and sets the access denied
(test 4) bit in the peer flash variable. If this bit is set, the
client sends no packets to the server. If this is not the first
packet, the client assumes a client limit condition at the server,
but does not update the peer variables. In either case, a message
is sent to the system log.</p>
<DD>
Ignore all packets from hosts which match this entry. If this flag is specified
neither queries nor time server polls will be responded to.</DD>
<h4>Access Control Commands</h4>
<DD>
&nbsp;</DD>
<dl>
<dt><tt>restrict <i>numeric_address</i> [mask <i>numeric_mask</i>]
[<i>flag</i>][...]</tt></dt>
<DT>
<TT>noquery</TT></DT>
<dd>The <i><tt>numeric_address</tt></i> argument, expressed in
dotted- quad form, is the address of an host or network. The <i>
<tt>mask</tt></i> argument, also expressed in dotted-quad form,
defaults to <tt>255.255.255.255</tt>, meaning that the <i><tt>
numeric_address</tt></i> is treated as the address of an individual
host. A default entry (address <tt>0.0.0.0</tt>, mask <tt>
0.0.0.0</tt>) is always included and, given the sort algorithm, is
always the first entry in the list. Note that, while <i><tt>
numeric_address</tt></i> is normally given in dotted-quad format,
the text string <tt>default</tt>, with no mask option, may be used
to indicate the default entry.</dd>
<DD>
Ignore all NTP mode 6 and 7 packets (i.e. information queries and configuration
requests) from the source. Time service is not affected.</DD>
<dd>In the current implementation, <i><tt>flag</tt></i> always
restricts access, i.e., an entry with no flags indicates that free
access to the server is to be given. The flags are not orthogonal,
in that more restrictive flags will often make less restrictive
ones redundant. The flags can generally be classed into two
catagories, those which restrict time service and those which
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>
&nbsp;</DD>
<dd>
<dl>
<dt><tt>kod</tt></dt>
<DT>
<TT>nomodify</TT></DT>
<dd>If access is denied, send a kiss-of-death packet.</dd>
<DD>
Ignore all NTP mode 6 and 7 packets which attempt to modify the state of
the server (i.e. run time reconfiguration). Queries which return information
are permitted.</DD>
<dt><tt>ignore</tt></dt>
<DD>
&nbsp;</DD>
<dd>Ignore all packets from hosts which match this entry. If this
flag is specified neither queries nor time server polls will be
responded to.</dd>
<DT>
<TT>notrap</TT></DT>
<dt><tt>noquery</tt></dt>
<DD>
Decline to provide mode 6 control message trap service to matching hosts.
The trap service is a subsystem of the mode 6 control message protocol
which is intended for use by remote event logging programs.</DD>
<dd>Ignore all NTP mode 6 and 7 packets (i.e. information queries
and configuration requests) from the source. Time service is not
affected.</dd>
<DD>
&nbsp;</DD>
<dt><tt>nomodify</tt></dt>
<DT>
<TT>lowpriotrap</TT></DT>
<dd>Ignore all NTP mode 6 and 7 packets which attempt to modify the
state of the server (i.e. run time reconfiguration). Queries which
return information are permitted.</dd>
<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>notrap</tt></dt>
<DD>
&nbsp;</DD>
<dd>Decline to provide mode 6 control message trap service to
matching hosts. The trap service is a subsystem of the mode 6
control message protocol which is intended for use by remote event
logging programs.</dd>
<DT>
<TT>noserve</TT></DT>
<dt><tt>lowpriotrap</tt></dt>
<DD>
Ignore NTP packets whose mode is other than 6 or 7. In effect, time service
is denied, though queries may still be permitted.</DD>
<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>
<DD>
&nbsp;</DD>
<dt><tt>noserve</tt></dt>
<DT>
<TT>nopeer</TT></DT>
<dd>Ignore NTP packets whose mode is other than 6 or 7. In effect,
time service is denied, though queries may still be permitted.</dd>
<DD>
Provide stateless time service to polling hosts, but do not allocate peer
memory resources to these hosts even if they otherwise might be considered
useful as future synchronization partners.</DD>
<dt><tt>nopeer</tt></dt>
<DD>
&nbsp;</DD>
<dd>Provide stateless time service to polling hosts, but do not
allocate peer memory resources to these hosts even if they
otherwise might be considered useful as future synchronization
partners.</dd>
<DT>
<TT>notrust</TT></DT>
<dt><tt>notrust</tt></dt>
<DD>
Treat these hosts normally in other respects, but never use them as synchronization
sources.</DD>
<dd>Treat these hosts normally in other respects, but never use
them as synchronization sources.</dd>
<DD>
&nbsp;</DD>
<dt><tt>limited</tt></dt>
<DT>
<TT>limited</TT></DT>
<dd>These hosts are subject to limitation of number of clients from
the same net. Net in this context refers to the IP notion of net
(class A, class B, class C, etc.). Only the first <tt>
client_limit</tt> hosts that have shown up at the server and that
have been active during the last <tt>client_limit_period</tt>
seconds are accepted. Requests from other clients from the same net
are rejected. Only time request packets are taken into account.
Query packets sent by the <tt>ntpq</tt> and <tt>ntpdc</tt> programs
are not subject to these limits. A history of clients is kept using
the monitoring capability of <tt>ntpd</tt>. Thus, monitoring is
always active as long as there is a restriction entry with the <tt>
limited</tt> flag.</dd>
<DD>
These hosts are subject to limitation of number of clients from the same
net. Net in this context refers to the IP notion of net (class A, class
B, class C, etc.). Only the first <TT>client_limit</TT> hosts that have
shown up at the server and that have been active during the last <TT>client_limit_period</TT>
seconds are accepted. Requests from other clients from the same net are
rejected. Only time request packets are taken into account. Query packets
sent by the <TT>ntpq</TT> and <TT>ntpdc</TT> programs are not subject to
these limits. A history of clients is kept using the monitoring capability
of <TT>ntpd</TT>. Thus, monitoring is always active as long as there is
a restriction entry with the <TT>limited</TT> flag.</DD>
<dt><tt>ntpport</tt></dt>
<DD>
&nbsp;</DD>
<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>ntpport</TT></DT>
<dt><tt>version</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>
<dd>Ignore these hosts if not the current NTP version.</dd>
</dl>
</dd>
<DD>
&nbsp;</DD>
</DL>
<dd>Default restriction list entries, with the flags <tt>ignore,
interface, 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>
<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><tt>clientlimit <i>limit</i></tt></dt>
<DD>
&nbsp;</DD>
<dd>Set the <tt>client_limit</tt> variable, which limits the number
of simultaneous access-controlled clients. The default value for
this variable is 3.</dd>
<DT>
<TT>clientlimit <I>limit</I></TT></DT>
<dt><tt>clientperiod <i>period</i></tt></dt>
<DD>
Set the <TT>client_limit</TT> variable, which limits the number of simultaneous
access-controlled clients. The default value for this variable is 3.</DD>
<dd>Set the <tt>client_limit_period</tt> variable, which specifies
the number of seconds after which a client is considered inactive
and thus no longer is counted for client limit restriction. The
default value for this variable is 3600 seconds.</dd>
</dl>
<DD>
&nbsp;</DD>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<DT>
<TT>clientperiod <I>period</I></TT></DT>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<DD>
Set the <TT>client_limit_period</TT> variable, which specifies the number
of seconds after which a client is considered inactive and thus no longer
is counted for client limit restriction. The default value for this variable
is 3600 seconds.</DD>
</DL>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

223
contrib/ntp/html/assoc.htm
View File

@ -1,170 +1,89 @@
<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>Release Notes
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><title>
Association Management
</title></head><body><h3>
Association Management
</h3>
<H3>
Association Management</H3>
<img align=left src=pic/alice51.gif alt="gif"><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<HR>
<H4>
Association Modes</H4>
This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates
new features and refinements to the NTP Version 3 (NTPv3) algorithms. However,
it continues the tradition of retaining backwards compatibility with older
versions. The NTPv4 version has been under development for quite a while
and isn't finished yet. In fact, quite a number of NTPv4 features have
already been implemented in the current NTPv3, including a number of new
operating modes for automatic server discovery and improved accuracy in
occasionally-connected networks. Following is an extended abstract describing
the new features..
<p>Make sure who your friends are.
<br clear=left><hr>
<P>An ephemeral association of some mode is mobilized when a message arrives
from another client or server. For instance, a symmetric-passive association
is mobilized upon arrival of a message from a symmetric- active peer. A
client association is mobilized upon arrival of a broadcast message from
a multicast server or a server message from a manycast server. Ephemeral
associations are demobilized when either (a) the server becomes unreachable
or (b) an error occurs on initial contact before the association is mobilized.
<h4>Association Modes</h4>
<P>The one exception to (a) and (b) above is when
<TT><A HREF="authopt.htm">autokey</A></TT> is in use and the initial
authentication check fails due to unknown
key identifier or autokey mismatch. This exception is necessary because
the Unix kernel does not bind the local address until the first packet
is received. The result in broadcast mode is a rather painful initial exchange,
where authentication fails until after the first round of messages. The
result in multicast mode is in general fatal, especially if multiple interfaces
are in use. As promiscuous modes such as multicast and manycast require
authentication for reliable and safe operation, autokey is in general useless
with these modes until and if the input/output machinery is overhauled.
<p>NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the <a href=confopt.htm>Configuration Options</a> and <a href=authopt.htm>Authentication Options</a> pages and in the papers, reports, memoranda and briefings at <a href=http://www.ntp.org>www.ntp.org</a>.
<P>Following is a summary of the protocol operations for each mode.
<p>There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message.
<P>Peer Modes (Active and Passive)
<UL>In these modes, two client/server peers agree to back each other up,
should the synchronization source for either peer fail. One or both peers
is configured in symmetric-active mode using the peer command. Alternatively,
one - the active peer - is configured in this mode and the other, the passive
peer, operates in symmetric-passive mode and requires no prior configuration.
Both association scenarios operate in NTPv4 as in NTPv3; however, several
bugs in the handling of keys and recovery of resources when an active peer
fails, have been corrected in NTPv4. The original NTPv3 authentication
scheme is applicable in this mode, as well as the new NTPv3 autokey scheme.</UL>
Client/Server Modes
<UL>In these modes, a client sends a request to the server and expects
a reply at some future time. The client is configured in client mode using
the server (sic) command; the server requires no prior configuration. The
original NTPv3 authentication scheme is applicable in this mode, as well
as the new NTPv3 autokey scheme.</UL>
Broadcast/Multicast Modes
<UL>In these modes, the server generates messages at intervals specified
by the minpoll subcommand. When using IP multicast addresses, the scope
of the multicast tree is specified by the ttl subcommand in hops. When
using a local interface broadcast address, the scope is limited to the
attached subnet. The client responds to the first message received by waiting
an interval randomized over the minpoll interval, in order to avoid implosions.
Then, it polls the server in burst mode, in order to accumulate data to
reliably set the host clock. This normally results in eight client/server
cycles over a 32-s interval. When the next multicast message is received,
the client computes the offset between the system clock just set and the
apparent time of the multicast message in order to correct the apparent
time in future multicast messages.</UL>
Manycast Mode
<UL>In this mode, a configured client broadcasts a request message as in
client mode to a designated multicast group address. All servers configured
as manycast clients and in ttl range respond with a server reply message.
Each reply mobilizes a persistent client/server association as in client
mode. Then, the NTP intersection and clustering algorithms act to discard
all but the "best" of these associations, which then continue as in client/server
mode.</UL>
<p>Ordinarily, successful mobilization of an ephemeral association requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric-key or public-key cryptography, as described in the <a href=authopt.htm>Authentication Options</a> page. The cryptographic means insure an unbroken chain of trust between the dependent client and the primary servers at the root of the synchronization subnet. We call this chain the provenance of the client and define new vocabulary as to proventicate a client or provide proventic credentials. Once mobilized, ephemeral associations are demobilized when either (a) the server becomes unreachable or (b) the server refreshes the key media without notifying the client.
<H4>
Burst Mode</H4>
Burst mode can be configured when the network attachment requires an initial
calling or training procedure. Each poll initiates a burst of eight request
messages at intervals randomized over the range 3-5 s. The reply messages
update the clock filter, which then selects the best (most accurate) among
them. When the last reply in the burst is sent, the next reply updates
the client variables and system clock in the usual manner, as if only a
single request/reply cycle had occurred. This mode does produce additional
network overhead and can cause trouble if used indiscriminately. It should
only be used where the poll interval is expected to settle to values above
1024 s.
<H4>
Revised Error Checking</H4>
It is very important to avoid spurious mobilizations from possibly broken
or rogue servers; in particular, to avoid denial-of-service attacks. In
order to resist such attacks, arriving messages that might mobilize ephemeral
associations are carefully screened using a series of eleven sanity checks.
<OL>
<LI>
Duplicate packet. This message is a duplicate of one previously received.</LI>
<p>There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP Multicast support: multicast and manycast. These modes are selected based on the scope of service, intended flow of time and proventic values and means of configuration. Following is a summary of the operations in each mode.
<BR>&nbsp;
<LI>
Bogus packet. This message did not result from a message previously sent,
or messages have been received out of order.</LI>
<h4>Client/Server Mode</h4>
<BR>&nbsp;
<LI>
Unsynchronized. The server has not yet stored the previous timestamps.</LI>
<p>Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a "pull" operation, in that the client pulls the time and proventic values from the server. A client is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS name or address; the server requires no prior configuration. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme. In addition, two burst modes described below can be used in appropriate cases.
<BR>&nbsp;
<LI>
Invalid delay or dispersion. Either the delay or dispersion or both computed
from the message timestamps are above the normal range.</LI>
<h4>Symmetric Active/Passive Mode</h4>
<BR>&nbsp;
<LI>
Authentication failed. The sent MAC does not match the received MAC, either
due to the wrong key material or damaged message.</LI>
<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 subset of secondary servers known to be reliable and proventicated. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and proventication values can flow from the surviving peers to all the others in the clique. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and proventic values depending on the particular configuration.
<BR>&nbsp;
<LI>
Server unsynchronized. The server indicates unsynchronized in the leap
bits included in the packet.</LI>
<p>Symmetric peers operate with their sources in some NTP mode and with each other in symmetric mode. A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or address. The other peer can also be configured in symmetric active mode in a similar way. However, if the other peer is not specifically configured in this way, a symmetric passive association is mobilized upon arrival of a symmetric active message. Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.
<BR>&nbsp;
<LI>
Server stratum check. The server is operating at a stratum above the normal
range.</LI>
<h4>Broadcast Mode</h4>
<BR>&nbsp;
<LI>
Delay/dispersion check. The related server packet data values are above
the normal range.</LI>
<p>Broadcast mode is intended for configurations involving one or a few servers and a possibly very large client population. A broadcast server is configured using the <tt>broadcast</tt> command and a local subnet address. A broadcast client is configured using the <tt>broadcastclient</tt> command, in which case it responds to broadcast messages received on any interface. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.
<BR>&nbsp;
<LI>
Autokey failed. The hash of the current session key does not match the
most recent key identifiers used. (The hash is repeated four times, in
order to recover from lost packets whenever possible.)</LI>
<p>The server generates broadcast messages continuously at intervals specified by the <tt>minpoll</tt> keyword and with a time-to-live span specified by the <tt>ttl</tt> keyword. A NTPv4 broadcast client responds to the first proventicated message received by waiting an interval randomized over the <tt>minpoll</tt> interval, in order to avoid implosion at the server. Then, the client polls the server in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server cycles over a 30-s interval during which both the synchronization and cryptographic protocols run concurrently. When the next broadcast message is received after the volley, the client computes the offset between the apparent broadcast time and the (unicast) client time. This offset is used to compensate for the propagation time between the broadcast server and client. Once the offset is computed, the server continues as before and the client sends no further messages.
<BR>&nbsp;
<LI>
Access denied. The sender has been blocked by the access control list.</LI>
<h4>IP Multicast Support</h4>
<BR>&nbsp;
<LI>
Key not found. The key identifier does not match any identifier in the
key list or the key has expired or been revoked.</LI>
</OL>
Failure to pass tests 5-11 is sufficient evidence to discard the packet
without forming an association. However, failure to pass tests 1-4 is not
necessarily grounds to reject the packet, since subsequent packets may
be acceptable. In this case, the association is mobilized, but only the
packet timestamps are stored. For the moment, and until the cryptographic
signature algorithm is available, test 9 is temporarily disabled.
<BR>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<p>Broadcast mode in both NTPv3 and NTPv4 is limited to directly connected subnets such as Ethernets which support broadcast technology. Ordinarily, this technology does not operate beyond the first hop router or gateway. Where service is intended beyond the local subnet, IP multicasting can be used where supported by the operating system and the routers support the Internet Group Management Protocol (IGMP). Most current kernels and available routers do support IP multicast technology, although service providers are sometimes reluctant to deploy it.
<BR>&nbsp;
</BODY>
</HTML>
<p>A general discussion of IP multicast technology is beyond the scope here. In simple terms a host or router sending to a IP multicast group (class D) address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa. The IANA has assigned multicast group address 224.0.1.1 to NTP, but this address should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.
<h4>Multicasting</h4>
<p>IP multicasting can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A multicast client is configured using the <tt>broadcast</tt> command, but with a multicast group (class D) address instead of a local subnet broadcast address. However, there is a subtle difference between broadcasting and multicasting. Broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate <tt>broadcast</tt> command applies to each one separately. This provides a way to limit exposure in a firewall, for example.
<p>IP multicasting is a different paradigm. A multicast message has the same format as a broadcast message and is configured with the same <tt>broadcast</tt> command, but with a multicast group address instead of a local subnet address. By design, multicast messages travel from the sender via a shortest-path or shared tree to the receivers, which may require these messages emit from one or all interfaces, but carry a common source address. However, it is possible to configure multiple multicast group addresses using multiple <tt>broadcast</tt> commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.
<h4>Manycasting</h4>
<p>Manycasting 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 client associations with the "best" three of the available manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail.
<p>Note that the manycasting paradigm does not coincide with the anycasting paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycasting paradigm is designed to find a plurality of redundant servers, in this case willing NTP servers.
<p>A persistent manycast client association is configured using the <tt>server</tt> command, but with a multicast (class D) group address instead of an ordinary IP (class A, B, C) address. It sends client mode messages to this address at the maximum feasible poll interval and minimum feasible time-to-live hops, depending on how many servers have already been found. There can be as many manycast client associations as different group addresss, each one serving as a template for a future ephemeral client/server mode association.
<p>Manycast servers configured with the <tt>manycastserver</tt> command listen on the specified group address for manycast client messages. Note the distinction between manycast client, which is configured with a <tt>server</tt> command, and manycast server, which is configured with a <tt>manycastserver</tt> command. If a manycast server is in range of the current time-to-live and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies to the manycast client message with an ordinary server mode message.
<p>The manycast client receiving this message mobilizes an ephemeral client association as in ordinary client/server mode according to the matching manycast client template. Then, the client polls the server at its unicast address in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server cycles over a 30-s interval during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client runs the NTP intersection and clustering algorithms, which act to discard all but the best three associations. The surviving associations then continue in ordinary client/server mode.
<p>The manycast client polling program is designed to reduce as much as possible the volume of messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The program uses a poll interval eight times the system poll interval, which starts out at the <tt>minpoll</tt> value and under normal circumstances increases gradually to the <tt>maxpolll</tt> value. Initially, the time-to-live is set at one hop. At each retransmission the time-to-live is incremented by one until at least three manycast servers are found. Further retransmissions use the same time-to-live value.
<p>If less than three servers are found when the time-to-live has reached the maximum specified by the <tt>ttl</tt> keyword, the poll interval is doubled. For each transmission after that, the poll interval is doubled again until reaching the maximum of eight times the value specified by the <tt>maxpoll</tt> keyword. Further transmissions use the same poll interval and time-to-live values.
<p>The above scenario happens for each manycast client message, which repeats at the designated poll interval. However, once the ephemeral client association is mobilized, subsequent manycast server replies are discarded, since they will fail the message digest test. If during a poll interval the number of client associations falls below three, all manycast client prototype associations are reset to the initial poll interval and time-to-live values and operation resumes from the beginning. It is important in manycast mode to avoid frequent manycast client messages, since each one requires all manycast servers in range to respond. The result could well be an implosion, either minor or major, depending on the number of servers in range. The recommended value for <tt>maxpoll</tt> is 12 (4,096 s) and for <tt>ttl</tt> is 7.
<p>It is possible and frequently useful to configure a host as both a manycast client and manycast server. A number of hosts configured this way and sharing a common group address will automatically organize themselves in an optimum configuration based on the smallest synchronization distance computed by the NTP mitigation algorithms. For example, consider an NTP subnet of two primary servers and maybe a dozen dependent clients. All servers and clients are configured as both multicast client and multicast server with multicast group address 239.1.1.1. In addition, the primary servers are configured for a primary reference source such as a GPS receiver.
Once operations have stabilized in this scenario, the primary servers will affiliate with the primary reference source and each other, since they both operate at the same stratum (1), but not with any client, since clients operate at a higher stratum. The clients will find both primary servers and in addition, one of their own at the minimum synchronization distance. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.
<h4>Burst Modes</h4>
<p>There are two burst modes that can be enabled in client/server mode using the <tt>iburst</tt> and <tt>burst</tt> keywords. In either mode a single poll initiates a burst of eight client messages at intervals randomized over the range 1-4 s. However, the interval between the first and second messages is increased to about 16 s in order for a dialup modem to complete a call, if necessary. Received server messages update the NTPv4 clock filter, which selects the best (most accurate) time values. When the last client message in the burst is sent, the next received server message updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.
<p>The <tt>iburst</tt> keyword can be configured for cases where it is important to set the clock quickly when an association is first mobilized or first becomes reachable or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable and results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within 30 s after the first message.
<p>The <tt>burst</tt> keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. It should only be used where the poll interval is expected to settle to values at or above 1024 s.
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

254
contrib/ntp/html/audio.htm
View File

@ -1,153 +1,187 @@
<html><head><title>
Reference Clock Audio Drivers
</title></head><body><h3>
Reference Clock Audio Drivers
</h3><hr>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Reference Clock Audio Drivers</title>
</head>
<body>
<h3>Reference Clock Audio Drivers</h3>
<img align="left" src="pic/radio2.jpg" alt="gif">
<p>Make a little noise here.<br clear="left">
</p>
<hr>
<p>There are some applications in which the computer time can be
disciplined to an audio signal, rather than a serial timecode and
communications port or special purpose bus peripheral. This is useful in
such cases where the audio signal is sent over a telephone circuit, for
example, or received directly from a shortwave receiver. In such cases
the audio signal can be connected via an ordinary sound card or
baseboard audio codec. The suite of NTP reference clock drivers
currently includes three drivers suitable for these applications. They
include a driver for the Inter Range Instrumentation Group (IRIG)
signals produced by most radio clocks and timing devices, another for
the Canadian time/frequency radio station CHU and a third for the NIST
communications port or special purpose bus peripheral. This is
useful in such cases where the audio signal is sent over a
telephone circuit, for example, or received directly from a
shortwave receiver. In such cases the audio signal can be connected
via an ordinary sound card or baseboard audio codec. The suite of
NTP reference clock drivers currently includes three drivers
suitable for these applications. They include a driver for the
Inter Range Instrumentation Group (IRIG) signals produced by most
radio clocks and timing devices, another for the Canadian
time/frequency radio station CHU and a third for the NIST
time/frequency radio stations WWV and WWVH. The radio drivers are
designed to work with ordinary inexpensive shortwave radios and may be
one of the least expensive ways to build a good primary time server.
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, modelled and evaluated in a technical report.
processing algorithms designed to efficiently extract timing
signals from noise and interference. The radio station drivers in
particular implement optimum linear demodulation and decoding
techniques, including maximum likelihood and soft-decision methods.
The documentation page for each driver contains an in-depth
discussion on the algorithms and performance expectations. In some
cases the algorithms are further analyzed, modelled and evaluated
in a technical report.</p>
<p>Currently, the audio drivers are compatible with Sun operating
systems, including Solaris and SunOS, and the native audio codec
interface supported by these systems. In fact, the interface is quite
generic and support for other systems, in particular the various Unix
generics, should not be difficult. Volunteers are solicited.
interface supported by these systems. In fact, the interface is
quite generic and support for other systems, in particular the
various Unix generics, should not be difficult. Volunteers are
solicited.</p>
<p>The audio drivers include a number of common features designed to
groom input signals, suppress spikes and normalize signal levels. An
automatic gain control (AGC) feature provides protection against
overdriven or underdriven input signals. It is designed to maintain
adequate demodulator signal amplitude while avoiding occasional noise
spikes. In order to assure reliable operation, the signal level must be
in the range where the audio gain control is effective. In general, this
means the input signal level must be such as to cause the AGC to set the
gain somewhere in the middle of the range from 0 to 255, as indicated in
the timecode displayed by the <tt>ntpq</tt> program.
<p>The 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 drivers operate by disciplining a logical clock based on the
codec sample clock to the audio signal as received. This is done by
stuffing or slipping samples as required to maintain exact frequency to
the order of 0.1 PPM. In order for the driver to reliably lock on the
audio signal, the sample clock frequency tolerance must be less than 250
PPM (.025 percent) for the IRIG driver and half that for the radio
drivers. The largest error observed so far is about 60 PPM, but it is
possible some sound cards or codecs may exceed that value.
stuffing or slipping samples as required to maintain exact
frequency to the order of 0.1 PPM. In order for the driver to
reliably lock on the audio signal, the sample clock frequency
tolerance must be less than 250 PPM (.025 percent) for the IRIG
driver and half that for the radio drivers. The largest error
observed so far is about 60 PPM, but it is possible some sound
cards or codecs may exceed that value.</p>
<p>The drivers include provisions to select the input port and to
monitor the input signal. The <tt>fudge flag 2</tt> selects the
microphone port if set to zero or the line-in port if set to one. It
does not seem useful to specify the compact disc player port. The
<tt>fudge flag 3</tt> enables the input signal monitor using the
previously selected output port and output gain. Both of these flags can
be set in the configuration file or remotely using the <tt>ntpdc</tt>
utility program.
microphone port if set to zero or the line-in port if set to one.
It does not seem useful to specify the compact disc player port.
The <tt>fudge flag 3</tt> enables the input signal monitor using
the previously selected output port and output gain. Both of these
flags can be set in the configuration file or remotely using the
<tt>ntpdc</tt> utility program.</p>
<H4>Shortwave Radio Drivers</H4>
<h4>Shortwave Radio Drivers</h4>
<p>The WWV/H and CHU audio drivers require an external shortwave radio
with the radio output - speaker or headphone jack - connected to either
the microphone or line-in port on the computer. There is some degree of
art in setting up the radio and antenna and getting the setup to work.
While the drivers are highly sophisticated and efficient in extracting
timing signals from noise and interference, it always helps to have as
clear a signal as possible.
<p>The 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>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 AC neutral wire.
elevator penthouse connected by house wiring, which can also be
used to power the radio. A couple of center-tapped audio
transformers will minimize noise pickup and provide phantom power
to the radio with return via the AC neutral wire.</p>
<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.
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>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>
<p><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 nightime conditions generally
occur somewhat after sunrise and sunset at the midpoint of the path
from transmitter to receiver.</li>
<p><li>Transitions between daytime and nightime conditions generally
occur somewhat after sunrise and sunset at the midpoint of the path from
transmitter to receiver.
<li>Ambient noise (static) on the lower frequencies follows the
thunderstorm season, so is higher on summer afternoons and
evenings.</li>
<p><li>Ambient noise (static) on the lower frequencies follows the
thunderstorm season, so is higher on summer afternoons and evenings.
<p><li>The lower frequency bands are best for shorter distances, while
the higher bands are best for longer distances.
<p><li>The optimum frequencies are higher at the peak of the 11-year
sunspot cycle and lower at the trough. The current sunspot cycle should
peak in the first couple of years beginning the century.
<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
should peak in the first couple of years beginning the
century.</li>
</ul>
The best way to choose a frequency is to listen at various times over
the day and determine the best highest (daytime) and lowest (nighttime)
frequencies. Then, assuming one is available, choose the highest
frequency between these frequencies. This strategy assumes that the high
frequency is more problematic than the low, that the low frequency
probably comes with severe multipath and static, and insures that
probably twice a day the chosen frequency will work. For instance, on
the east coast the best compromise CHU frequency is probably 7335 kHz
and the best WWV frequency is probably 15 MHz.
The best way to choose a frequency is to listen at various times
over the day and determine the best highest (daytime) and lowest
(nighttime) frequencies. Then, assuming one is available, choose
the highest frequency between these frequencies. This strategy
assumes that the high frequency is more problematic than the low,
that the low frequency probably comes with severe multipath and
static, and insures that probably twice a day the chosen frequency
will work. For instance, on the east coast the best compromise CHU
frequency is probably 7335 kHz and the best WWV frequency is
probably 15 MHz.
<h4>Debugging Aids</h4>
<p>The audio drivers include extensive debugging support to help hook up
the audio signals and monitor the driver operations. The documentation
page for each driver describes the various messages that can be produced
either in real-time or written to the <tt>clockstats</tt> file for
later analysis. Of particular help in verifying signal connections and
compatibility is a provision to monitor the signal via headphones or
speaker.
<p>The audio drivers include extensive debugging support to help
hook up the audio signals and monitor the driver operations. The
documentation page for each driver describes the various messages
that can be produced either in real-time or written to the <tt>
clockstats</tt> file for later analysis. Of particular help in
verifying signal connections and compatibility is a provision to
monitor the signal via headphones or speaker.</p>
<p>The drivers write a synthesized timecode to the <tt>
clockstats</tt> file each time the clock is set or verified and at
other times if verbose monitoring is enabled. The format includes
several fixed-length fields defining the Gregorian time to the
millisecond, together with additional variable-length fields
specific to each driver. The data include the intervals since the
clock was last set or verified, the audio gain and various state
variables and counters specific to each driver.</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 Gregorian time to the millisecond, together with additional variable-length fields specific to each driver. The data include the intervals since the clock was last set or verified, the audio gain and various state variables and counters specific to each driver.
<h4>Additional Information</h4>
<H4>Additional Information</H4>
<a href="refclock.htm">Reference Clock Drivers</a> <br>
<a href="driver7.htm">Radio CHU Audio Demodulator/Decoder</a> <br>
<a href="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</a>
<br>
<a href="driver6.htm">IRIG Audio Decoder</a>
<A HREF="refclock.htm">Reference Clock Drivers</A>
<br><A HREF="driver7.htm">Radio CHU Audio Demodulator/Decoder</A>
<br><A HREF="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</A>
<br><A HREF="driver6.htm">IRIG Audio Decoder</A>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

620
contrib/ntp/html/authopt.htm
View File

@ -1,281 +1,415 @@
<HTML><HEAD><TITLE>
Authentication Options
</TITLE></HEAD><BODY><H3>
Authentication Options
</H3><HR>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Authentication Options</title>
</head>
<body>
<h3>Authentication Options</h3>
<H4>Authentication Support</H4>
<img align="left" src="pic/alice44.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
Adventures in Wonderland</i>, Lewis Carroll</a>
Authentication support allows the NTP client to verify that the server
is in fact known and trusted and not an intruder intending accidentally
or on purpose to masquerade as that server. The NTPv3 specification RFC-1305
defines an scheme which provides cryptographic authentication of received
NTP packets. Originally, this was done using the Data Encryption Standard
(DES) operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC.
Subsequently, this was augmented by the RSA Message Digest 5 (MD5) using
a private key, commonly called keyed-MD5. Either algorithm computes a message
digest, or one-way hash, which can be used to verify the server has the
correct private key and key identifier. NTPv4 retains this scheme and,
in addition, provides a new <I>autokey </I>scheme based on reverse hashing
and public key cryptography. Authentication can be configured separately
for each association using the <TT>key </TT>or <TT>autokey </TT>subcommands
on the <TT>peer</TT>, <TT>server</TT>, <TT>broadcast</TT> and <TT>manycastclient</TT>
commands as described in the&nbsp; <A HREF="config.htm">Configuration Options</A>
page.
<p>Our resident cryptographer; now you see him, now you don't.<br
clear="left">
</p>
<P>The authentication options specify the suite of keys, select the key
for each configured association and manage the configuration operations,
as described below. The <TT>auth</TT> flag which controls these functions
can be set or reset by the <TT>enable</TT> and <TT>disable</TT> configuration
commands and also by remote configuration commands sent by a <TT>ntpdc</TT>
program running in another machine. If this flag is set, persistent peer
associations and remote configuration commands are effective only if cryptographically
authenticated. If this flag is disabled, these operations are effective
even if not cryptographic authenticated. It should be understood that operating
in the latter mode invites a significant vulnerability where a rogue hacker
can seriously disrupt client operations.
<hr>
<h4>Authentication Support</h4>
<P>The <TT>auth</TT> flag affects all authentication procedures described
below; however, it operates differently if cryptographic support is compiled
in the distribution. If this support is available and the flag is enabled,
then persistent associations are mobilized and remote configuration commands
are effective only if successfully authenticated. If the support is unavailable
and the flag is enabled, then it is not possible under any conditions to
mobilize persistent associations or respond to remote configuration commands.
The <TT>auth </TT>flag normally defaults to set if cryptographic support
is available and to reset otherwise.
<p>Authentication support allows the NTP client to verify that the
server is in fact known and trusted and not an intruder intending
accidentally or on purpose to masquerade as that server. The NTPv3
specification RFC-1305 defines an scheme which provides
cryptographic authentication of received NTP packets. Originally,
this was done using the Data Encryption Standard (DES) algorithm
operating in Cipher Block Chaining (CBC) mode, commonly called
DES-CBC. Subsequently, this was augmented by the RSA Message Digest
5 (MD5) algorithm using a private key, commonly called keyed-MD5.
Either algorithm computes a message digest, or one-way hash, which
can be used to verify the server has the correct private key and
key identifier.</p>
<P>With the above vulnerabilities in mind, it is desirable to set the auth
flag in all cases. One aspect which is often confusing is the name resolution
process which maps server names in the configuration file to IP addresses.
In order to protect against bogus name server messages, this process is
authenticated using an internally generated key which is normally invisible
to the user. However, if cryptographic support is unavailable and the <TT>auth</TT>
flag is enabled, the name resolution process will fail. This can be avoided
either by specifying IP addresses instead of host names, which is generally
inadvisable, or by leaving the flag disabled and enabling it once the name
resolution process is complete.
<H4>
Private Key Scheme</H4>
The original RFC-1305 specification allows any one of possibly 65,536 keys,
each distinguished a 32-bit key identifier, to authenticate an association.
The servers involved must agree on the key and key identifier to authenticate
their messages. Keys and related information are specified in a key file,
usually called <TT>ntp.key</TT>s, which should be exchanged and stored
using secure procedures beyond the scope of the NTP protocol itself. Besides
the keys used for ordinary NTP associations, additional ones can be used
as passwords for the <TT><A HREF="ntpq.htm">ntpq</A></TT> and <TT><A HREF="ntpdc.htm">ntpdc</A></TT>
utility programs.
<p>NTPv4 retains the NTPv3 schemes, properly described as
symmetric-key cryptography and, in addition, provides a new Autokey
scheme based on public-key cryptography. Public-key cryptography is
generally considered more secure than symmetric-key cryptography,
since the security is based on a private value which is generated
by each server and never revealed. With Autokey all key
distribution and management functions involve only public values,
which considerably simplifies key distribution and storage.</p>
<P>When <TT>ntpd </TT>is first started, it reads the key file and installs
the keys in the key cache. However, the keys must be activated before they
can be used with the <TT>trusted </TT>command. This allows, for instance,
the installation of possibly several batches of keys and then activating
or inactivating each batch remotely using <TT>ntpdc</TT>. This also provides
a revocation capability that can be used if a key becomes compromised.
The <TT>requestkey </TT>command selects the key used as the password for
the <TT>ntpdc </TT>utility, while the <TT>controlkey </TT>command selects
the key used as the password for the the <TT>ntpq </TT>utility.
<H4>
Autokey Scheme</H4>
The original NTPv3 authentication scheme described in RFC-1305 continues
to be supported. In NTPv4, an additional authentication scheme called <I>autokey
</I>is available. It operates much like the S-KEY scheme, in that a session
key list is constructed and the entries used in reverse order. A description
of the scheme, along with a comprehensive security analysis, is contained
in a technical report available from the IETF web page <A HREF="www.ietf.org">www.ietf.org</A>
.
<p>Authentication is configured separately for each association
using the <tt>key</tt> or <tt>autokey</tt> subcommands on the <tt>
peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>
manycastclient</tt> commands as described in the <a href=
"config.htm">Configuration Options</a> page. The authentication
options described below specify the suite of keys, select the key
for each configured association and manage the configuration
operations.</p>
<P>The autokey scheme is specifically designed for multicast modes, where
clients normally do not send messages to the server. In these modes, the
server uses the scheme to generate a key list by repeated hashing of a
secret value. The list is used in reverse order to generate a unique session
key for each message sent. The client regenerates the session key and verifies
the hash matches the previous session key. Each message contains the public
values binding the session key to the secret value, but these values need
to be verified only when the server generates a new key list or more than
four server messages have been lost.
<p>The <tt>auth</tt> flag controls whether new associations or
remote configuration commands require cryptographic authentication.
This flag can be set or reset by the <tt>enable</tt> and <tt>
disable</tt> configuration commands and also by remote
configuration commands sent by a <tt>ntpdc</tt> program running in
another machine. If this flag is enabled, which is the default
case, new broadcast client and symmetric passive associations and
remote configuration commands must be cryptographically
authenticated using either symmetric-key or public-key schemes. If
this flag is disabled, these operations are effective even if not
cryptographic authenticated. It should be understood that operating
in the latter mode invites a significant vulnerability where a
rogue hacker can seriously disrupt client timekeeping.</p>
<P>The scheme is appropriate for client/server and symmetric-peer modes
as well. In these modes, the client generates a session key as in multicast
modes. The server regenerates the session key and uses it to formulates
a reply using its own public values. The client verifies the key identifier
of the reply matches the request, verifies the public values and validates
the message. In peer mode, each peer independently generates a key list
and operates as in the multicast mode.
<p>In networks with firewalls and large numbers of broadcast
clients it may be acceptable to disable authentication, since that
avoids key distribution and simplifies network maintenance.
However, when the configuration file contains host names, or when a
server or client is configured remotely, host names are resolved
using the DNS and a separate name resolution process. In order to
protect against bogus name server messages, name resolution
messages are authenticated using an internally generated key which
is normally invisible to the user. However, if cryptographic
support is disabled, the name resolution process will fail. This
can be avoided either by specifying IP addresses instead of host
names, which is generally inadvisable, or by enabling the flag for
name resolution and disabled it once the name resolution process is
complete.</p>
<P>The autokey scheme requires no change to the NTP packet header format
or message authentication code (MAC), which is appended to the header;
however, if autokey is in use, an extensions field is inserted between
the header and MAC. The extensions field contains a random public value
which is updated at intervals specified by the revoke command, together
with related cryptographic values used in the signing algorithm. The format
of the extensions field is defined in Internet Draft draft-NTP- auth-coexist-00.txt.
The MAC itself is constructed in the same way as NTPv3, but using the original
NTP header and the extensions field padded to a 64-bit boundary. Each new
public value is encrypted by the host private value. It is the intent of
the design, not yet finalized, that the public value, encrypted public
value, public key and certificate be embedded in the extensions field where
the client can decrypt as needed. However, the relatively expensive encryption
and decryption operations are necessary only when the public value is changed.
<p>An attractive alternative where multicast support is available
is manycast mode, in which clients periodically troll for servers.
Cryptographic authentication in this mode uses public-key schemes
as described below. The principle advantage of this manycast mode
is that potential servers need not be configured in advance, since
the client finds them during regular operation, and the
configuration files for all clients can be identical.</p>
<P>Note that both the original NTPv3 authentication scheme and the new
NTPv4 autokey scheme operate separately for each configured association,
so there may be several session key lists operating independently at the
same time. Since all keys, including session keys, occupy the same key
cache, provisions have been made to avoid collisions, where some random
roll happens to collide with another already generated. Since something
like four billion different session key identifiers are available, the
chances are small that this might happen. If it happens during generation,
the generator terminates the current session key list. By the time the
next list is generated, the collided key will probably have been expired
or revoked.
<p>In addition to the default symmetric-key cryptographic support,
support for public-key cryptography is available if the requisite
<tt>rsaref20</tt> software distribution has been installed before
building the distribution. Public-key cryptography provides secure
authentication of servers without compromising accuracy and
stability. The security model and protocol schemes for both
symmetric-key and public-key cryptography are described below.</p>
<P>While permanent keys have lifetimes that expire only when manually revoked,
random session keys have a lifetime specified at the time of generation.
When generating a key list for an association, the lifetime of each key
is set to expire one poll interval later than it is scheduled to be used.
The maximum lifetime of any key in the list is specified by the <TT>autokey</TT>
command. Lifetime enforcement is a backup to the normal procedure that
revokes the last-used key at the time the next key on the key list is used.
<H4>
Authentication Commands</H4>
<h4>Symmetric-Key Scheme</h4>
<DL>
<DT>
<TT>keys <I>keyfile</I></TT></DT>
The original RFC-1305 specification allows any one of possibly
65,534 keys, each distinguished by a 32-bit key identifier, to
authenticate an association. The servers and clients involved must
agree on the key and key identifier to authenticate their messages.
Keys and related information are specified in a key file, usually
called <tt>ntp.keys</tt>, which should be exchanged and stored
using secure procedures 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.htm">ntpq</a></tt> and <tt><a href="ntpdc.htm">ntpdc</a></tt>
utility programs.
<DD>
Specifies the file name containing the encryption keys and key identifiers
used by <TT>ntpd</TT>, <TT>ntpq</TT> and <TT>ntpdc</TT> when operating
in authenticated mode. The format of this file is described later in this
document.</DD>
<p>When <tt>ntpd</tt> is first started, it reads the key file
specified int he <tt>keys</tt> command and installs the keys in the
key cache. However, the keys must be activated with the <tt>
trusted</tt> command before use. This allows, for instance, the
installation of possibly several batches of keys and then
activating or deactivating each batch remotely using <tt>
ntpdc</tt>. This also provides a revocation capability that can be
used if a key becomes compromised. The <tt>requestkey</tt> command
selects the key used as the password for the <tt>ntpdc</tt>
utility, while the <tt>controlkey</tt> command selects the key used
as the password for the <tt>ntpq</tt> utility.</p>
<DD>
&nbsp;</DD>
<h4>Public-Key Scheme</h4>
<DT>
<TT>trustedkey <I>key</I> [...]</TT></DT>
The original NTPv3 authentication scheme described in RFC-1305
continues to be supported; however, in NTPv4 an additional
authentication scheme called Autokey is available. It uses MD5
message digest, RSA public-key signature and Diffie-Hellman key
agreement algorithms available from several sources, but not
included in the NTPv4 software distribution. In order to be
effective, the <tt>rsaref20</tt> package must be installed as
described in the <tt>README.rsa</tt> file. Once installed, the
configure and build process automatically detects it and compiles
the routines required. The Autokey scheme has several modes of
operation corresponding to the various NTP modes supported. RSA
signatures with timestamps are used in all modes to verify the
source of cryptographic values. All modes use a special cookie
which can be computed independently by the client and server. In
symmetric modes the cookie is constructed using the Diffie-Hellman
key agreement algorithm. In other modes the cookie is constructed
from the IP addresses and a private value known only to the server.
All modes use in addition a variant of the S-KEY scheme, in which a
pseudo-random key list is generated and used in reverse order.
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.htm">Autonomous
Authentication</a> page.
<DD>
Specifies the encryption key identifiers which are trusted for the purposes
of authenticating peers suitable for synchronization, as well as keys used
by the <TT>ntpq </TT>and <TT>ntpdc </TT>programs. The authentication procedures
require that both the local and remote servers share the same key and key
identifier for this purpose, although different keys can be used with different
servers. The <I><TT>key</TT></I> arguments are 32-bit unsigned integers
with values less than 65,536. Note that NTP key 0 is used to indicate an
invalid key and/or key identifier, so should not be used for any other
purpose.</DD>
<p>The cryptographic values used by the Autokey scheme are
incorporated as a set of files generated by the <a href=
"genkeys.htm"><tt>ntp-genkeys</tt></a> program, including the
symmetric private keys, public/private key pair, and the agreement
parameters. See the <tt>ntp-genkeys</tt> page for a description of
the formats of these files. They contain cryptographic values
generated by the algorithms of the <tt>rsaref20</tt> package and
are in printable ASCII format. All file names include the
timestamp, in NTP seconds, following the default names given below.
Since the file data are derived from random values seeded by the
system clock and the file name includes the timestamp, every
generation produces a different file and different file name.</p>
<DD>
&nbsp;</DD>
<p>The <tt>ntp.keys</tt> file contains the DES/MD5 private keys. It
must be distributed by secure means to other servers and clients
sharing the same security compartment and made visible only to
root. While this file is not used with the Autokey scheme, it is
needed to authenticate some remote configuration commands used by
the <a href="ntpdc.htm"><tt>ntpq</tt></a> and <a href="ntpq.htm">
<tt>ntpdc</tt></a> utilities. The <tt>ntpkey</tt> file contains the
RSA private key. It is useful only to the machine that generated it
and never shared with any other daemon or application program, so
must be made visible only to root.</p>
<DT>
<TT>requestkey <I>key</I></TT></DT>
<p>The <tt>ntp_dh</tt> file contains the agreement parameters,
which are used only in symmetric (active and passive) modes. It is
necessary that both peers beginning a symmetric-mode association
share the same parameters, but it does not matter which <tt>
ntp_dh</tt> file generates them. If one of the peers contains the
parameters, the other peer obtains them using the Autokey protocol.
If both peers contain the parameters, the most recent copy is used
by both peers. If a peer does not have the parameters, they will be
requested by all associations, either configured or not; but, none
of the associations can proceed until one of them has received the
parameters. Once loaded, the parameters can be provided on request
to other clients and servers. The <tt>ntp_dh</tt> file can be also
be distributed using insecure means, since the data are public
values.</p>
<DD>
Specifies the key identifier to use with the <TT>ntpdc</TT> program, which
uses a proprietary protocol specific to this implementation of <TT>ntpd</TT>.
This program is useful to diagnose and repair problems that affect <TT>ntpd</TT>
operation. The <I><TT>key</TT></I> argument to this command is a 32-bit
key identifier for a previously defined trusted key.&nbsp; If no <TT>requestkey
</TT>command is included in the configuration file, or if the keys don't
match, any request to change a server variable with be denied.</DD>
<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public
key, where <tt><i>host</i></tt> is the name of the host. Each host
must have its own <tt>ntpkey_<i>host</i></tt> file, which is
normally provided to other hosts using the Autokey protocol Each
<tt>server</tt> or <tt>peer</tt> association requires the public
key associated with the particular server or peer to be loaded
either directly from a local file or indirectly from the server
using the Autokey protocol. These files can be widely distributed
and stored using insecure means, since the data are public
values.</p>
<DD>
&nbsp;</DD>
<p>The optional <tt>ntpkey_certif_<i>host</i></tt> file contains
the PKI certificate for the host. This provides a binding between
the host hame and RSA public key. In the current implementation the
certificate is obtained by a client, if present, but the contents
are ignored.</p>
<DT>
<TT>controlkey <I>key</I></TT></DT>
<p>Due to the widespread use of interface-specific naming, the host
names used in configured and mobilized associations are determined
by the Unix <tt>gethostname()</tt> library routine. Both the <tt>
ntp-genkeys</tt> program and the Autokey protocol derive the name
of the public key file using the name returned by this routine.
While every server and client is required to load their own public
and private keys, the public keys for each client or peer
association can be obtained from the server or peer using the
Autokey protocol. Note however, that at the current stage of
development the authenticity of the server or peer and the
cryptographic binding of the server name, address and public key is
not yet established by a certificate authority or web of trust.</p>
<DD>
Specifies the key identifier to use with the <TT>ntpq</TT> program, which
uses the standard protocol defined in RFC-1305. This program is useful
to diagnose and repair problems that affect <TT>ntpd</TT> operation. The
<I><TT>key</TT></I> argument to this command is a 32-bit key identifier
for a trusted key in the key cache. If no <TT>controlkey </TT>command is
included in the configuration file, or if the keys don't match, any request
to change a server variable with be denied.</DD>
</DL>
<h4>Leapseconds Table</h4>
<H4>
Authentication Key File Format</H4>
In the case of DES, the keys are 56 bits long with, depending on type,
a parity check on each byte. In the case of MD5, the keys are 64 bits (8
bytes). <TT>ntpd</TT> reads its keys from a file specified using the <TT>-k</TT>
command line option or the <TT>keys</TT> statement in the configuration
file. While key number 0 is fixed by the NTP standard (as 56 zero bits)
and may not be changed, one or more of the keys numbered 1 through 15 may
be arbitrarily set in the keys file.
<p>The NIST provides a table showing the epoch for all historic
occasions of leap second insertion since 1972. The leapsecond table
shows each epoch of insertion along with the offset of
International Atomic Time (TAI) with respect to Coordinated
Universtal Time (UTC), as disseminated by NTP. The table can be
obtained directly from NIST national time servers using <tt>
ftp</tt> as the ASCII file <tt>pub/leap-seconds</tt>.</p>
<P>The key file uses the same comment conventions as the configuration
file. Key entries use a fixed format of the form
<p>While not strictly a security function, the Autokey scheme
provides means to securely retrieve the leapsecond table from a
server or peer. Servers load the leapsecond table directly from the
file specified in the <tt>crypto</tt> command, while clients can
load the table indirectly from the servers using the Autokey
protocol. Once loaded, the table can be provided on request to
other clients and servers.</p>
<P><I><TT>keyno type key</TT></I>
<h4>Key Management</h4>
<P>where <I><TT>keyno</TT></I> is a positive integer, <I><TT>type</TT></I>
is a single character which defines the key format, and <I><TT>key</TT></I>
is the key itself.
<p>All key files are installed by default in <tt>
/usr/local/etc</tt>, which is normally in a shared filesystem in
NFS-mounted networks and avoids installing them in each machine
separately. The default can be overridden by the <tt>keysdir</tt>
configuration command. However, this is not a good place to install
the private key file, since each machine needs its own file. A
suitable place to install it is in <tt>/etc</tt>, which is normally
not in a shared filesystem.</p>
<P>The key may be given in one of three different formats, controlled by
the <I><TT>type</TT></I> character. The three key types, and corresponding
formats, are listed following.
<DL>
<DT>
<TT>S</TT></DT>
<p>The recommended practice is to keep the timestamp extensions
when installing a file and to install a link from the default name
(without the timestamp extension) to the actual file. This allows
new file generations to be activated simply by changing the link.
However, <tt>ntpd</tt> parses the link name when present to extract
the extension value and sends it along with the public key and host
name when requested. This allows clients to verify that the file
and generation time are always current. However, the actual
location of each file can be overridden by the <tt>crypto</tt>
configuration command.</p>
<DD>
The key is a 64-bit hexadecimal number in the format specified in the DES
specification; that is, the high order seven bits of each octet are used
to form the 56-bit key while the low order bit of each octet is given a
value such that odd parity is maintained for the octet. Leading zeroes
must be specified (i.e., the key must be exactly 16 hex digits long) and
odd parity must be maintained. Hence a zero key, in standard format, would
be given as <TT>0101010101010101</TT>.</DD>
<p>All cryptographic keys and related parameters should be
regenerated on a periodic and automatic basis, like once per month.
The <tt>ntp-genkeys</tt> program uses the same timestamp extension
for all files generated at one time, so each generation is distinct
and can be readily recognized in monitoring data. While a
public/private key pair must be generated by every server and
client, the public keys and agreement parameters do not need to be
explicitly copied to all machines in the same security compartment,
since they can be obtained automatically using the Autokey
protocol. However, it is necessary that all primary servers have
the same agreement parameter file. The recommended way to do this
is for one of the primary servers to generate that file and then
copy it to the other primary servers in the same compartment using
the Unix <tt>rdist</tt> command. Future versions of the Autokey
protocol are to contain provisions for an agreement protocol to do
this automatically.</p>
<DD>
&nbsp;</DD>
<p>Servers and clients can make a new generation in the following
way. All machines have loaded the old generation at startup and are
operating normally. At designated intervals, each machine generates
a new public/private key pair and makes links from the default file
names to the new file names. The <tt>ntpd</tt> is then restarted
and loads the new generation, with result clients no longer can
authenticate correctly. The Autokey protocol is designed so that
after a few minutes the clients time out and restart the protocol
from the beginning, with result the new generation is loaded and
operation continues as before. A similar procedure can be used for
the agreement parameter file, but in this case precautions must be
take to be sure that all machines with this file have the same
copy.</p>
<DT>
<TT>N</TT></DT>
<h4>Authentication Commands</h4>
<DD>
The key is a 64-bit hexadecimal number in the format specified in the NTP
standard. This is the same as the DES format, except the bits in each octet
have been rotated one bit right so that the parity bit is now the high
order bit of the octet. Leading zeroes must be specified and odd parity
must be maintained. A zero key in NTP format would be specified as <TT>8080808080808080</TT>.</DD>
<dl>
<dt><tt>autokey [<i>logsec</i>]</tt></dt>
<DD>
&nbsp;</DD>
<dd>Specifies the interval between regenerations of the session key
list used with the Autokey protocol. Note that the size of the key
list for each association depends on this interval and the current
poll interval. The default value is 12 (4096 s or about 1.1 hours).
For poll intervals above the specified interval, a session key list
with a single entry will be regenerated for every message
sent.</dd>
<DT>
<TT>A</TT></DT>
<dt><tt>controlkey <i>key</i></tt></dt>
<DD>
The key is a 1-to-8 character ASCII string. A key is formed from this by
using the low order 7 bits of each ASCII character in the string, with
zeroes added on the right when necessary to form a full width 56-bit key,
in the same way that encryption keys are formed from Unix passwords.</DD>
<dd>Specifies the key identifier to use with the <a href=
"ntpq.htm"><tt>ntpq</tt></a> utility, which uses the standard
protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is
the key identifier for a trusted key, where the value can be in the
range 1 to 65534, inclusive.</dd>
<DD>
&nbsp;</DD>
<dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>]
[publickey <i>file</i>] [dhparms <i>file</i>] [leap <i>
file</i>]</tt></dt>
<DT>
<TT>M</TT></DT>
<dd>This command requires the NTP daemon build process be
configured with the RSA library. This command activates public-key
cryptography and loads the required RSA private and public key
files and the optional Diffie-Hellman agreement parameter file, if
present. If one or more files are left unspecified, the default
names are used as described below. Following are the
subcommands:</dd>
<DD>
The key is a 1-to-8 character ASCII string, using the MD5 authentication
scheme. Note that both the keys and the authentication schemes (DES or
MD5) must be identical between a set of peers sharing the same key number.</DD>
</DL>
Note that the keys used by the <TT>ntpq</TT> and <TT>ntpdc</TT> programs
are checked against passwords requested by the programs and entered by
hand, so it is generally appropriate to specify these keys in ASCII format.&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<dd>
<dl>
<dt><tt>privatekey <i>file</i></tt></dt>
<dd>Specifies the location of the RSA private key file, which
otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd>
<dt><tt>publickey <i>file</i></tt></dt>
<dd>Specifies the location of the RSA public key file, which
otherwise defaults to <tt>/usr/local/etc/ntpkey_<i>host</i></tt>.,
where <i>host</i> is the name of the generating machine.</dd>
<dt><tt>dhparms <i>file</i></tt></dt>
<dd>Specifies the location of the Diffie-Hellman parameters file,
which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd>
<dt><tt>leap <i>file</i></tt></dt>
<dd>Specifies the location of the leapsecond table file, which
otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd>
</dl>
</dd>
<dt><tt>keys <i>keyfile</i></tt></dt>
<dd>Specifies the location of the DES/MD5 private key file
containing the keys and key identifiers used by <tt>ntpd</tt>, <tt>
ntpq</tt> and <tt>ntpdc</tt> when operating in symmetric-key
mode.</dd>
<dt><tt>keysdir <i>path</i></tt></dt>
<dd>This command requires the NTP daemon build process be
configured with the RSA library. It specifies the default directory
path for the private key file, agreement parameters file and one or
more public key files. The default when this command does not
appear in the configuration file is <tt>/usr/local/etc/</tt>.</dd>
<dt><tt>requestkey <i>key</i></tt></dt>
<dd>Specifies the key identifier to use with the <a href=
"ntpdc.htm"><tt>ntpdc</tt></a> utility program, which uses a
proprietary protocol specific to this implementation of <tt>
ntpd</tt>. The <tt><i>key</i></tt> argument is a key identifier for
the trusted key, where the value can be in the range 1 to 65534,
inclusive.</dd>
<dt><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 of the scheme;
however, updating some values is a relatively expensive operation.
The default interval is 16 (65,536 s or about 18 hours). For poll
intervals above the specified interval, the values will be updated
for every message sent.</dd>
<dt><tt>trustedkey <i>key</i> [...]</tt></dt>
<dd>Specifies the key identifiers which are trusted for the
purposes of authenticating peers with symmetric-key cryptography,
as well as keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt>
programs. The authentication procedures require that both the local
and remote servers share the same key and key identifier for this
purpose, although different keys can be used with different
servers. The <tt><i>key</i></tt> arguments are 32-bit unsigned
integers with values from 1 to 65,534.</dd>
</dl>
<h4>Files</h4>
<tt>ntp.keys</tt> private MD5 keys <br>
<tt>ntpkey</tt> RSA private key <br>
<tt>ntpkey_<i>host</i></tt> RSA public key <br>
<tt>ntp_dh</tt> Diffie-Hellman agreement parameters
<h4>Bugs</h4>
The <tt>ntpkey_<i>host</i></tt> files are really digital
certificates. These should be obtained via secure directory
services when they become universally available.
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

273
contrib/ntp/html/biblio.htm
View File

@ -3,257 +3,104 @@ Protocol Conformance Statement
</title></head><body><h3>
Protocol Conformance Statement
</h3>
<BR><IMG align=left SRC="pic/flatheads.gif">From <i>The
Wizard of Oz</i>, L. Frank Baum
<img align=left src=pic/flatheads.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>From <i>The
Wizard of Oz</i>, L. Frank Baum</a>
<p>Say it three times and it must be right.
<br clear=left>
<hr>
<p>The Network Time Protocol (NTP) is used to synchronize the time of
a computer client or server to another server or reference time source,
such as a radio or satellite receiver or modem. It provides accuracies
typically within a millisecond on LANs up to a few tens of milliseconds
on WANs relative to Coordinated Universal Time (UTC), as provided by a
Global Positioning Service (GPS) receiver, for example.
<p>The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC), as provided by a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks.
<p>Typical NTP configurations utilize multiple redundant servers and
diverse network paths, in order to achieve high accuracy and
reliability. Some configurations include cryptographic authentication to
prevent accidental or malicious protocol attacks. Information on the NTP
architecture, protocol and algorithms can be found in the following
articles and reports, which are available online. General issues of the
concepts and facilities assumed by NTP are discussed in tne <a
href=exec.htm>Executive Summary - Computer Network Time
Synchronization</a> page, while issues related to the NTP timescale and
pending century are discussed in the <A HREF=y2k.htm> Network Time
Protocol Year 2000 Conformance Statement</A> page, both of which are
included in this document.
<p>Information on the NTP architecture, protocol and algorithms can be found in the following articles and reports, which are available online. General issues of the concepts and facilities assumed by NTP are discussed in the <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page, while issues related to the NTP timescale and pending century are discussed in the <a href=y2k.htm> Network Time Protocol Year 2000 Conformance Statement</a> page, both of which are included in this software distribution. Network timekeeping technology continues to advance and may obsolete some of the following documents. For a current list of all papers, reports, briefings and other documents relevant to the NTP community, see the <a href=http://www.eecis.udel.edu/~mills>David L. Mills</a> web page. A historical perspective is available in
<p>Note that network timekeeping technology continues to advance and may
obsolete some of the following documents. For a current list of all
papers, reports, briefings and other documents relevant to the NTP
community, see the <a href=http://www.eecis.udel.edu/~mills>David L.
Mills</a> web page.
<ul>
<P>The NTP architecture, protocol and algorithm models are described in
<p><li>Mills, D.L. A brief history of NTP time: confessions of an Internet timekeeper. Submitted for publication; please do not cite or redistribute. <a href=database/papers/history.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/history.pdf>PDF</a>
<UL>
</ul>
<li>Mills, D.L. Internet time synchronization: the Network Time
Protocol. <I>IEEE Trans. Communications COM-39, 10</I> (October 1991),
1482-1493. <A
HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf>
PDF</a>. Also in: Yang, Z., and T.A. Marsland (Eds.). <I>Global States
and Time in Distributed Systems</I>. IEEE Computer Society Press, Los
Alamitos, CA, 1994, 91-102.
</UL>
<p>The NTP architecture, protocol and algorithm models are described in
The NTP specification and implementation has evolved over the last two
decades to the current Version 4 of the protocol. This version includes
significant enhancements in accuracy and reliability, as determined by
experience in an estimated total of well over 100,000 clients and
servers in the Internet, while retaining backward compatibility with
previous versions.
<ul>
<P>This software distribution contains an implementation of the NTP
Version 4 architecture, protocol and algorithms. While a formal
specification of this version is not yet available, this version is
fully compliant with the previous NTP Version 3 specification and
implementation defined in
<UL>
<p><li>Mills, D.L. Internet time synchronization: the Network Time Protocol. <I>IEEE Trans. Communications COM-39, 10</I> (October 1991), 1482-1493. <a href=http://www.eecis.udel.edu/~mills/database/papers/trans.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf> PDF</a>. Also in: Yang, Z., and T.A. Marsland (Eds.). <I>Global States and Time in Distributed Systems</I>. IEEE Computer Society Press, Los Alamitos, CA, 1994, 91-102.
<li>Mills, D.L. Network Time Protocol (Version 3) specification,
implementation and analysis. Network Working Group Report RFC-1305,
University of Delaware, March 1992, 113 pp. Abstract: <A
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps>
PostScript)</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf>
PDF</A>, Body: <a
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps>
PostScript)</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf>
PDF</A>, Appendices: <A
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps>
PostScript</a> | <a
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf>
PDF</A>.
</ul>
</UL>
<p>The NTP specification and implementation has evolved over the last two decades to the current Version 4 of the protocol. This version includes significant enhancements in accuracy and reliability, as determined by experience in an estimated total of well over 100,000 clients and servers in the Internet, while retaining backward compatibility with previous versions. This software distribution contains an implementation of the NTP Version 4 architecture, protocol and algorithms. While a formal specification of this version is not yet available, this version is fully compliant with the previous NTP Version 3 specification and implementation defined in
<ul>
The NTP Version 4 implementation adds a number of extensions and
refinements to the previous version, including an autonomous
configuration and authentication capability, improved clock discipline
algorithms capable of submicrosecond accuracy and many other
refinements. Specific changes since the Version 3 specification was
issued include:
<p><li>Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992, 113 pp. Abstract: <a
href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps> PostScript)</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps> PostScript)</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf> PDF</a>, Appendices: <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf> PDF</a>.
<OL>
</ul>
<p><LI>Support for precision-time kernel modifications, as described
in</LI>
<p>The NTP Version 4 implementation adds a number of extensions and refinements to the previous version, including an autonomous configuration and authentication capability, improved clock discipline algorithms capable of submicrosecond accuracy and many other refinements. Specific changes since the Version 3 specification was issued include:
<P>Mills, D.L. Unix kernel modifications for precision time
synchronization. Electrical Engineering Department Report 94-10-1,
University of Delaware, October 1994, 24 pp. Abstract: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf>
PDF</a>, Body: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf>
PDF</a>. Major revision and update of: Network Working Group Report
RFC-1589, University of Delaware, March 1994. 31 pp. <A
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</A>
<ol>
<p><LI>Support for IP Multicasting, as described in</LI>
<p><li>Support for precision-time kernel modifications, as described in
<P>Mills, D.L, and A. Thyagarajan. Network time protocol version 4
proposed changes. Electrical Engineering Department Report 94-10-2,
University of Delaware, October 1994, 32 pp. Abstract: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps>
PostScript</A> | <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf>
PDF</A>, Body: <a
HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf>
PDF</a>
<p>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf>PDF</a>, Slides: <a href=database/brief/nano/nano.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ppt>PowerPoint</a>
<p><LI>A new hybrid phase/frequency-lock clock discipline, which
replaces the RFC-1305 local clock algorithm, as described in</LI>
<p>Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf> PDF</a>. Major revision and update of: Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</a>
<p><li>Support for IP Multicasting, as described the <a href=assoc.htm>Association Management</a> page and in
<P>Mills, D.L. Clock discipline algorithms for the Network Time Protocol
Version 4. Electrical Engineering Report 97-3-3, University of Delaware,
March 1997, 35 pp. Abstract: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps>
PostScript</A> | <a
HREF=
http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf>
PDF</a>, Body: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps>
PostScript</A> | <a
HREF=
http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf>
PDF</a>
<p>Mills, D.L, and A. Thyagarajan. Network time protocol version 4 proposed changes. Electrical Engineering Department Report 94-10-2, University of Delaware, October 1994, 32 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf> PDF</a>
<P>Mills, D.L. Improved algorithms for synchronizing computer network
clocks. <I>IEEE/ACM Trans. Networks 3, 3</I> (June 1995), 245-254. <A
HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf>
PDF</a>
<p><li>A new hybrid phase/frequency-lock clock discipline, which
replaces the RFC-1305 local clock algorithm, as described in</li>
<P><LI>Engineered refinements to radio clock drivers and interface code,
as describedin:</LI>
<p>Mills, D.L. Improved algorithms for synchronizing computer network clocks. <I>IEEE/ACM Trans. Networks 3, 3</I> (June 1995), 245-254. <a href=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf>PDF</a>
<P>Mills, D.L. Precision synchronization of computer network clocks.
<I>ACM Computer Communication Review 24, 2</I> (April 1994). 28-43. <A
HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.ps>
PostScript</A> | <A
HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.pdf>
PDF</a>
<p>Mills, D.L. Clock discipline algorithms for the Network Time Protocol Version 4. Electrical Engineering Report 97-3-3, University of Delaware, March 1997, 35 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf>PDF</a>
<P><LI>Support for over two dozen reference clock drivers for all known
national and international radio, satellite and modem standard time
services known at this time. See the <A HREF=refclock.htm>Reference
Clock Drivers </A>page.</LI>
<p><li>Simple Network Monitoring Protocol (SNMP) monitoring tools, as described in</li>
<P><LI>A new security model and authentication scheme based on public-
key cryptography called <I>autokey</I>, as described in</LI>
<p>Sethi, A.S., H. Gao, and D.L. Mills. Management of the Network Time Protocol (NTP) with SNMP. Computer and Information Sciences Report 98-09, University of Delaware, November 1998, 32 pp. <a href=http://www.eecis.udel.edu/~mills/database/reports/ntp-mib-tr.ps>PostScript</a> | <a href=database/reports/ntp-mib-tr.pdf>PDF</a>
<P>Mills, D.L., T.S. Glassey, and M.E. McNeil. Coexistence and
interoperability of NTP authentication schemes. Internet Draft
draft-mills-ntp-auth-coexist-00.txt, University of Delaware and Coastek
InfoSys, Inc., November 1997, 8 pp. <A
HREF=http://www.eecis.udel.edu/~mills/memos/draft.txt>ASCII</A>
<p><li>Engineered refinements to radio clock drivers and interface code, as described in in the <a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a> page and</li>
<P>Mills, D.L. Authentication scheme for distributed, ubiquitous, real-
time protocols. <I>Proc. Advanced Telecommunications/Information
Distribution Research Program (ATIRP) Conference</I> (College Park MD,
January 1997), 293-298. <A
HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf>
PDF</a>
<p>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2783.txt>ASCII</a>
<P>Mills, D.L. Proposed authentication enhancements for the Network Time
<p>Mills, D.L. Precision synchronization of computer network clocks. <I>ACM Computer Communication Review 24, 2</I> (April 1994). 28-43. <a href=http://www.eecis.udel.edu/~mills/database/papers/fine.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/fine.pdf>PDF</a>
<p><li>Support for over two dozen reference clock drivers for all known national and international radio, satellite and modem standard time services known at this time. See the <a href=refclock.htm>Reference Clock Drivers</a> page.</li>
<p><li>A new security model and authentication scheme based on public-key cryptography called <I>Autokey</I>, as described in the <a href=authopt.htm>Authentication Options</a> page and in</li>
<p>Mills, D.L. Public-Key cryptography for the Network Time Protocol. Internet Draft draft-ietf-stime-ntpauth-00.txt, University of Delaware, June 2000, 36 pp. <a href=http://www.eecis.udel.edu/~mills/database/memos/draft-ietf-stime-ntpauth-00.txt>ASCII</a>
<p>Mills, D.L. Public key cryptography for the Network Time Protocol. Electrical Engineering Report 00-5-1, University of Delaware, May 2000. 23 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeya.ps>PostScript</a> | <a href=database/reports/pkey/pkeya.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeyb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeyb.pdf>PDF</a>
<p>Mills, D.L. Authentication scheme for distributed, ubiquitous, real-time protocols. <I>Proc. Advanced Telecommunications/Information Distribution Research Program (ATIRP) Conference</I> (College Park MD, January 1997), 293-298. <a href=http://www.eecis.udel.edu/~mills/database/papers/atirp.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf>PDF</a>
<p>Mills, D.L. Proposed authentication enhancements for the Network Time
Protocol version 4. Electrical Engineering Report 96-10-3, University of
Delaware, October 1996, 36 pp. Abstract: <A
HREF=
http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps>
PostScript</A> | <a
HREF=
http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf>
PDF</a>, Body: <A
HREF=
http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps>
PostScript</A> | <a
HREF=
http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf>
PDF</a>
Delaware, October 1996, 36 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf>PDF</a>
<P><LI> Support for the MD5 cryptographic hash algorithm, in addition to
the DES-CBC algorithm described in RFC-1305, as described in the <A
HREF=ntpd.htm><TT>ntpd</TT> - Network Time Protocol (NTP) daemon
</A>page.</LI>
<p><li> Support for the MD5 cryptographic hash algorithm, in addition to the DES-CBC algorithm described in RFC-1305, as described in the <a href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP) daemon </a>page.</li>
<P><LI>The prefer-peer scheme, as described in the <A
HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT> Keyword
</A>page.</LI>
<p><li>The prefer-peer scheme, as described in the <a href=prefer.htm>Mitigation Rules and the <tt>prefer</tt> Keyword </a>page.</li>
<P><LI>Specification for the Simple Network Time Protocol (SNTP), as
described in</LI>
<p><li>Specification for the Simple Network Time Protocol (SNTP), as described in</li>
<P>Mills, D.L. Simple network time protocol (SNTP) version 4 for IPv4,
IPv6 and OSI. Network Working Group Report RFC-2030, University of
Delaware, October 1996, 18 pp. <A
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt>
ASCII</A>. Obsoletes RFC-1769 and RFC-1361.
<p>Mills, D.L. Simple network time protocol (SNTP) version 4 for IPv4, IPv6 and OSI. Network Working Group Report RFC-2030, University of Delaware, October 1996, 18 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt>ASCII</a>. Obsoletes RFC-1769 and RFC-1361.
<P><LI>Performance surveys for NTP Version 4 can be found in</LI>
<p><li>Support for International Atomic Time (TAI), as described in</li>
<p><li>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet
timekeeping around the globe. <i>Proc. Precision Time and Time Interval
(PTTI) Applications and Planning Meeting</i> (Long Beach CA, December
1997), 365-371. Paper: <a
href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf>
PDF</a>, Slides: <a
href=
http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm>
HTML</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt>
PowerPoint</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf>
PDF</a></li>
<p>Levine, J., and D. Mills. Using the Network Time Protocol to transmit International Atomic Time (TAI). <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/tai.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/tai.pdf>PDF</a>
<p><li>Mills, D.L. The network computer as precision timekeeper.
<i>Proc. Precision Time and Time Interval (PTTI) Applications and
Planning Meeting</i> (Reston VA, December 1996), 96-108. Paper: <a
href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf>
PDF</a>, Slides: <a
href=
http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm>
HTML</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt>
PowerPoint</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf>
PDF</a></li>
<p><li>Performance surveys for NTP Version 4 can be found in</li>
</OL>
<p>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet timekeeping around the globe. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Long Beach CA, December 1997), 365-371. Paper: <a
href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf>PDF</a>, Slides: <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt>PowerPoint</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf>PDF</a>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<p>Mills, D.L. The network computer as precision timekeeper. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, December 1996), 96-108. Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf>PDF</a>, Slides: <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt>PowerPoint</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf>PDF</a>
</ol>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a></address></a></body></html>

353
contrib/ntp/html/build.htm
View File

@ -1,186 +1,239 @@
<HTML><HEAD><TITLE>
Building and Installing the Distribution
</TITLE></HEAD><BODY><H3>
Building and Installing the Distribution
</H3>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Building and Installing the Distribution</title>
</head>
<body>
<h3>Building and Installing the Distribution</h3>
<img align=left src=pic/beaver.gif>From <i>pogo</i>, Walt Kelly
<img align="left" src="pic/beaver.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<p>For putting out compiler fires.
<br clear=left><hr>
<p>For putting out compiler fires.<br clear="left">
</p>
<H4>Building and Installing the Distribution</H4>
<hr>
<h4>Building and Installing the Distribution</h4>
As a practical matter, every computer architecture and operating system
version seems to be different than any other. The device drivers may be
different, the input/output system may bew idiosyncratic and the
libraries may have different semantics. It is not possible in a software
distribution such as this one to support every individual sysdtem with a
common set of binaries, even with the same system but different
versions. Therefore, it is necessary to configure each system
individually for each system and version, both at compile time and at
run time. In almost all cases, these procedures are completely automatic
and all the newbie user need do is type "make" and the autoconfigure
system does the rest. There are some exceptions, as noted below.
<p>As a practical matter, every computer architecture and operating
system version seems to be different than any other. The device
drivers may be different, the input/output system may be
idiosyncratic and the libraries may have different semantics. It is
not possible in a software distribution such as this one to support
every individual sysdtem with a common set of binaries, even with
the same system but different versions. Therefore, it is necessary
to configure each system individually for each system and version,
both at compile time and at run time. In almost all cases, these
procedures are completely automatic and all the newbie user need do
is type "make" and the autoconfigure system does the rest. There
are some exceptions, as noted below.</p>
<p>The autoconfigure system inspects the hardware and software
environment and tests for the presence of system header files and the
contents of these files to determine if certain features are available.
When one or more of these features are present, the code is compiled to
use them; if not, no special code is compiled. However, even if the code
is compiled to use these features, the code does a special test at run
time to see if one or more are actually present and avoids using them if
not present. In such cases a warning message is sent to the system log,
but the daemon should still work properly.
<p>Some programs included in this distribution use cryptographic
algorithms to verify server authenticity and credentials. As
required by the International Trade in Arms Regulations (ITAR), now
called the Defense Trade Regulations (DTR), certain cryptographic
products and media, including the Data Encryption Standard (DES),
cannot be exported without per-instance license. For this reason,
the DES encryption routine has been removed from the the current
version, even though it is used only to compute a message digest.
Current DTR regulations allow export of the the MD5 message digest
routine, which is in fact the preferred algorithm, and this is
included in the current version.</p>
Some programs included in this distribution use cryptographic algorithms
to verify server authenticity and credentials. As required by the
International Trade in Arms Regulations (ITAR), now called the Defense
Trade Regulations (DTR), certain cryptographic products and media,
including the Data Encryption Standard (DES), cannot be exported without
per-instance license. For this reason, the DES encryption routine has
been removed from the the current version, even though it is used only
to compute a message digest. Current DTR regulations allow export of the
the MD5 message digest routine, which is in fact the preferred
algorithm, and this is included in the current
version.
<p>The NTP authentication routines conform to the interface used by
RSA Laboratories in the <tt>rsaref20.zip</tt> package, which was
formerly downloadable from <tt>ftp.rsa.com</tt> or via the web at
<tt>www.rsa.com</tt>, but this may no longer be the case. Outside
the US and Canada, the functionally identical <tt>rsaeuro.zip</tt>
package is available from J.S.A. Kapp and other sources. The
recommended way to integrate the routines in either package with
the NTP build procedures is to uncompress and extract the <tt>
rsaref20</tt> files in a top level directory with that name. Then
install a link to that directory from <tt>rsaref2</tt> in the top
level directory of the distribution. Use <tt>rsaeuro1</tt> instead
for that distribution. These steps must be completed
before the configuration process described below.</p>
<P>The NTP authentication routines conform to the interface used by RSA
Laboratories in the <TT>rsaref20.zip</TT> package, which is downloadable
from <TT>ftp.rsa.com</TT> or via the web at <TT>www.rsa.com</TT>.
Outside the U.S. and Canada, the functionally identical
<TT>rsaeuro.zip</TT> package is available from J.S.A. Kapp and other
sources. The recommended way to integrate the DES routines in either
package with the NTP build procedures is to copy the <TT>desc.c</TT>
file from the <TT>./source</TT> directory in the package to the
<TT>./libntp</TT> directory in the distribution. Then copy the header
files <TT>rsaref.h</TT>, <TT>des.h</TT> and <TT>md2.h</TT> in the
<TT>./source</TT> directory to the <TT>./include</TT> directory. Do not
copy the <TT>global.h</TT> header file; the one in the distribution has
been modified. These steps must be completed before the configuration
process described below.
<h4>Building and Installing under Unix</h4>
<H4>Building and Installing under Unix</H4>
Make sure that you have all necessary tools for building
executables. These tools include <tt>cc/gcc, make, awk, sed, tr,
sh, grep, egrep</tt> and a few others. Not all of these tools exist
in the standard distribution of modern Unix versions (compilers are
likely to be an add-on product - consider using the GNU tools and
<tt>gcc</tt> compiler in this case). For a successful build, all of
these tools should be accessible via the current path.
Make sure that you have all necessary tools for building executables.
These tools include <TT>cc/gcc, make, awk, sed, tr, sh, grep, egrep</TT>
and a few others. Not all of these tools exist in the standard
distribution of modern Unix versions (compilers are likely to be an
add-on product - consider using the GNU tools and <TT>gcc</TT>
compiler in this case). For a successful build, all of these tools
should be accessible via the current path.
<p>The first thing to do is uncompress the distribution and extract
the source tree. Use the <tt>./configure</tt> command to perform an
automatic configuration procedure. This command inspects the
hardware and software environment and tests for the presence of
system header files and the contents of these files to determine if
certain features are present. When one or more of these features
are present, the code is compiled to use them; if not, no special
code is compiled. However, even if the code is compiled to use
these features, the code does a special test at run time to see if
one or more are actually present and avoids using them if not
present. In such cases a warning message is sent to the system log,
but the daemon should still work properly.</p>
<H4>Configuration</H4>
Use the <TT>./configure</TT> command to perform an automatic
configuration procedure. This procedure normally includes the debugging
code, which can be useful in diagnosing problems found in initial test,
and all reference clock drivers known to work with each machine and
<p>The default build normally includes the debugging code, which
can be useful in diagnosing problems found in initial test, and all
reference clock drivers known to work with each machine and
operating system. Unless memory space is at a premium, this is a
sensible strategy and saves lots of messy fiddling. If you need to
delete either the debugging code or one or more or all reference clock
drivers to save space, see the <A HREF="config.htm">Configuration
Options</A> page.
delete either the debugging code or one or more or all reference
clock drivers to save space, see the <a href="config.htm">
Configuration Options</a> page.</p>
<P>If your site supports multiple architectures and uses NFS to share
files, you can use a single source tree to compile executables for all
architectures. While running on a target architecture machine and with
the distribution base directory active, create a subdirectory using a
command like <TT>mkdir A.`config.guess`</TT>, which will create an
architecture-specific directory with name peculiar to the architecture
and operating system. Then change to this directory and configure with
the <TT>../configure</TT> command. The remaining steps are the same
whether building in the base directory or in the subdirectory.
<p>If your site supports multiple architectures and uses NFS to
share files, you can use a single source tree to compile
executables for all architectures. While running on a target
architecture machine and with the distribution base directory
active, create a subdirectory using a command like <tt>mkdir
A.`config.guess`</tt>, which will create an architecture-specific
directory with name peculiar to the architecture and operating
system. Then change to this directory and configure with the <tt>
../configure</tt> command. The remaining steps are the same whether
building in the base directory or in the subdirectory.</p>
<H4>Compilation</H4>
<h4>Compilation</h4>
Peruse the operating-system-specific information for your architecture
under <A HREF="hints.htm">Hints and Kinks</A>.
Peruse the operating-system-specific information for your
architecture under <a href="hints.htm">Hints and Kinks</a>.
<P>Use the <TT>make</TT> command to compile all source modules,
<p>Use the <tt>make</tt> command to compile all source modules,
construct the libraries and link the distribution. Expect few or no
warnings using <TT>cc</TT> and a moderate level of warnings using
<TT>gcc</TT>. Note: On some Unix platforms the use of <TT>gcc</TT> can
result in quite a few complaints about system header files and type
inconsistencies, especially about pointer variables. This is usually the
case when the system header files are not up to ANSI standards or
<TT>gcc</TT>-isms, when gcc is not installed properly, or when operating
system updates and patches are applied and gcc is not reinstalled. While
the autoconfigure process is quite thorough, the Unix programming
cultures of the various workstation makers still remain idiosyncratic.
warnings using <tt>cc</tt> and a moderate level of warnings using
<tt>gcc</tt>. Note: On some Unix platforms the use of <tt>gcc</tt>
can result in quite a few complaints about system header files and
type inconsistencies, especially about pointer variables. This is
usually the case when the system header files are not up to ANSI
standards or <tt>gcc</tt>-isms, when gcc is not installed properly,
or when operating system updates and patches are applied and gcc is
not reinstalled. While the autoconfigure process is quite thorough,
the Unix programming cultures of the various workstation makers
still remain idiosyncratic.</p>
<H4>Installation</H4>
<h4>Installation</h4>
As root, use the <TT>make install</TT> command to install the binaries
in the destination directory. You must of course have write permission
on the install destination directory. This includes the programs <TT><A
HREF="ntpd.htm">ntpd</A></TT> (the daemon), <TT><A
HREF="ntpdc.htm">ntpdc</A></TT> (an <TT>ntpd</TT>-dependent query
program), <TT><A HREF="ntpq.htm">ntpq</A></TT> (a standard query
program), <TT><A HREF="ntpdate.htm">ntpdate</A></TT> (an <TT>rdate</TT>
replacement for boot time date setting and sloppy time keeping) and
<TT><A HREF="ntptrace.htm">ntptrace</A></TT> (a utility useful to find
the primary (stratum-1) servers). In some systems, the <TT><A
HREF="tickadj.htm">tickadj</A></TT> (a utility useful to adjust kernel
variables) is installed. If the precision time kernel modifications are
present, the <TT><A HREF="ntptime.htm">ntptime</A></TT> (a utility
useful to debug kernel time functions) is installed.
As root, use the <tt>make install</tt> command to install the
binaries in the destination directory. You must of course have
write permission on the install in the destination directory. This
includes the following programs:
<P>You are now ready to configure the daemon and start it. You will need
to create a NTP configuration file <TT>ntp.conf</TT> and possibly a
cryptographic key file <TT>ntp.keys</TT>. Directions for doing that are
in the <A HREF="notes.htm">Notes on Configuring NTP and Setting up a NTP
Subnet</A>. The behavior when the daemon starts for the first time can
be counterintuitive. To reduce the level of angst, see the <a
href=quick.htm>Quick Start</a> page. A tutorial on debugging technique
is in <A HREF="debug.htm">NTP Debugging Technique</A>.
<ul>
<li><a href="ntpd.htm"><tt>ntpd</tt> - Network Time Protocol (NTP)
daemon</a></li>
<P>If problems peculiar to the particular hardware and software
environment (e.g. operating system -specific issues) are suspected,
browse the <A HREF="hints.htm">Hints and Kinks</A> page.
<li><a href="ntpq.htm"><tt>ntpq</tt> - standard NTP query
program</a></li>
<P>Bug reports of a general nature can be sent to David Mills <A
HREF="mailto: mills@udel.edu">&lt;mills@udel.edu></A>. Bug reports of a
specific nature on features implemented by the programmer corps
mentioned in the <A HREF="copyright.htm">Copyright</A> page should be
sent directly to the implementor listed in that page, with copy to
mills@udel.edu.
<li><a href="ntpdc.htm"><tt>ntpdc</tt> - special NTP query
program</a></li>
<P><B>Please include the version of the source distribution (e.g., ntp-
4.0.70a) in your bug report.</B>
<li><a href="ntpdate.htm"><tt>ntpdate</tt> - set the date and time
via NTP</a></li>
<P><B>Please include the <B>output</B> of <TT>config.guess</TT> in your
bug report.</B>
<li><a href="ntptrace.htm"><tt>ntptrace</tt> - trace a chain of NTP
servers back to the primary source</a></li>
</ul>
<P><B>It will look something like: <TT>pdp11-dec-fuzzos3.4</TT></B>
<p>If the precision time kernel modifications are present, the
following program is installed:</p>
<P>Additional <TT>make</TT> commands
<ul>
<li><a href="ntptime.htm"><tt>ntptime</tt> - read kernel time
variables</a></li>
</ul>
<DL>
<p>If the public key authentication functions are present, the
following program is installed:</p>
<DT><TT>make clean</TT></DT>
<ul>
<li><a href="genkeys.htm"><tt>ntp-genkeys</tt> - generate public
and private keys</a></li>
</ul>
<DD>Cleans out object files, programs and temporary files.</DD>
<p>In some systems that include the capability to edit kernel
variables, the following program is installed:</p>
<DT><TT>make distclean</TT></DT>
<ul>
<li><a href="tickadj.htm"><tt>tickadj</tt> - set time-related
kernel variables</a></li>
</ul>
<DD>Does the work of <TT>clean</TT>, but cleans out all directories in
preparation for a new distribution release.</DD>
<h4>Configuration</h4>
<DT><TT>make dist</TT></DT>
<p>You are now ready to configure the daemon and start it. You will
need to create a NTP configuration file <tt>ntp.conf</tt> and
possibly a cryptographic key file <tt>ntp.keys</tt>. Newbies should
see the <a href="quick.htm">Quick Start</a> page for orientation.
Seasoned veterans can start with the <a href="ntpd.htm"><tt>
ntpd</tt> - Network Time Protocol (NTP) daemon</a> page and move on
to the specific configuration option pages from there. A tutorial
on NTP subnet design and configuration options is in the <a href=
"notes.htm">Notes on Configuring NTP and Setting up a NTP
Subnet</a> page.</p>
<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>
<h4>If You Have Problems</h4>
</DL>
<p>If you have problems peculiar to the particular hardware and
software environment (e.g. operating system-specific issues),
browse the <a href="hints.htm">Hints and Kinks</a> page. For other
problems a tutorial on debugging technique is in the <a href=
"debug.htm">NTP Debugging Technique</a> page. As always, the first
line of general assistance is the <a href="http://www.ntp.org">NTP
web site www.ntp.org</a> and the FAQ resident there. Requests for
assistance of a general nature and of interest to other timekeepers
should be sent to the NTP newsgroup. Bug reports of a specific
nature should be sent to <a href="mailto:bugs@mail.ntp.org">
&lt;bugs@mail.ntp.org&gt;</a>. Bug reports of a specific nature on
features implemented by the programmer corps mentioned in the <a
href="copyright.htm">Copyright</a> page should be sent directly to
the implementor listed in that page, with copy to
bugs@mail.ntp.org.</p>
<H4>Building and Installing under Windows NT</H4>
See <tt><a href="hints/winnt.htm">hints/winnt.htm</a> </tt>for directions
to compile the sources and install the executables.
<p>Please include the version of the source distribution (e.g.,
ntp-4.0.70a) in your bug report, as well as billboards from the
relevant utility programs and debug trace, if available. Please
include the output of <tt>config.guess</tt> in your bug report. It
will look something like:</p>
<p><tt>pdp11-dec-fuzzos3.4</tt></p>
<p>Additional <tt>make</tt> commands</p>
<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>
<h4>Building and Installing under Windows NT</h4>
See <tt><a href="hints/winnt.htm">hints/winnt.htm</a></tt> for
directions to compile the sources and install the executables.
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left
src=pic/home.gif></a><address><a href="mailto:mills@udel.edu"> David L.
Mills &lt;mills@udel.edu&gt;</a>
</address></body></html>

215
contrib/ntp/html/clockopt.htm
View File

@ -1,193 +1,76 @@
<HTML><HEAD><TITLE>
<html><head><title>
Reference Clock Options
</TITLE></HEAD><BODY><H3>
</title></head><body><h3>
Reference Clock Options
</H3><HR>
</h3>
<H4>Reference Clock Support</H4>
<img align=left src=pic/boom4.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
The NTP Version 4 daemon supports many 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.htm">Reference Clock Drivers </A>page. Additional
information can be found in the pages referenced there, including the <A
HREF="rdebug.htm">Debugging Hints for Reference Clock Drivers</A> and <A
HREF="howto.html">How To Write a Reference Clock Driver</A> pages. In
many drivers, support for a PPS signal is available as described in <A
HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A> page. Many
drivers support special line discipline/streams modules which can
significantly improve the accuracy using the driver. These are described
in the <A HREF="ldisc.htm">Line Disciplines and Streams Drivers</A>
<p>See the radios, all in a row.
<br clear=left><hr>
<h4>Reference Clock Support</h4>
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.htm">Reference Clock Drivers </a>page. Additional information can be found in the pages linked there, including the <a HREF="rdebug.htm">Debugging Hints for Reference Clock Drivers</a> and <a HREF="howto.htm">How To Write a Reference Clock Driver</a> pages. In addition, support for a PPS signal is available as described in <a HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</a> page. Many drivers support special line discipline/streams modules which can significantly improve the accuracy using the driver. These are described in the <a HREF="ldisc.htm">Line Disciplines and Streams Drivers</a>
page.
<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 U.S. 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 included 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>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>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. 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&nbsp; must be unique.
<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>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.htm">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>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.htm">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>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 stratum 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>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.
<H4>Reference Clock Commands</H4>
<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.
<DL><DT><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:</DD>
<h4>Reference Clock Commands</h4>
<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.htm">Mitigation Rules
and the <TT>prefer</TT> Keyword </A>page for further information.</DD>
<dl><dt><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:</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>
<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.htm">Mitigation Rules and the <tt>prefer</tt> Keyword </a>page for further information.</dd>
<DT><TT>minpoll <I>int</I></TT></DT>
<DT><TT>maxpoll<I> int</I></TT></DT>
<DD>These options specify the minimum and maximum polling interval for
reference clock messages, in seconds to the power of two. 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> defaults to 10 (17.1 m) and <TT>maxpoll</TT> defaults
to 14 (4.5 h). The allowable range is 4 (16 s) to 17 (36.4 h)
inclusive.</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>
</DL>
<dt><tt>minpoll <i>int</i></tt></dt>
<dt><tt>maxpoll<i> int</i></tt></dt>
<dd>These options specify the minimum and maximum polling interval for reference clock messages, in seconds to the power of two. 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> defaults to 10 (17.1 m) and <tt>maxpoll</tt> defaults to 14 (4.5 h). The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.</dd>
<DT><TT>fudge 127.127.<I>t.u</I> [time1 <I>sec</I>] [time2 <I>sec</I>]
[stratum <I>int</I>] [refid <I>string</I>] [mode <I>int</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
</dl>
<dt><tt>fudge 127.127.<i>t.u</i> [time1 <i>sec</i>] [time2 <i>sec</i>]
[stratum <i>int</i>] [refid <i>string</i>] [mode <i>int</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.htm">ntpdc</A></TT> program. The
options are interpreted as follows:</DD>
time using the <tt><a HREF="ntpdc.htm">ntpdc</a></tt> program. The
options are interpreted as follows:</dd>
<DL>
<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 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>
<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>
<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.htm">reference clock drivers</A>
page.</DD>
<p><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.htm>Miscellaneous Options</a> page and operates as described in the <a href=refclock.hrm>Reference Clock Drivers</a> page.</dd>
<DT><TT>stratum <I>int</I></TT></DT>
<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.</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.htm">reference clock drivers</a> page.</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>stratum <i>int</i></tt></dt>
<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.</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>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</TT> <TT>flag2</TT> <TT>flag3</TT> <TT>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 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.
When a PPS signal is available, a special automatic calibration facility
is provided. If the <tt>flag1</tt> switch is set and the PPS signal is
actively disciplining the system time, the calibration value is
automatically adjusted to maintain a residual offset of zero. Further
information on the <TT>filegen</TT> command can be found in the <A
HREF="monopt.htm">Monitoring Options </A>page.</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>
</DL>
<dt><tt>flag1</tt> <tt>flag2</tt> <tt>flag3</tt> <tt>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 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.htm">Monitoring Options </a>page.</dd>
<DT><TT>pps <I>device</I> [assert|clear] [hardpps]</TT></DT>
<DD>Specifies the name and options for the serial port device to which
the PPS signal is connected. Note, this command replaces use of
<TT>fudge flag3</TT>, which was used for the same purpose in NTPv3. Note
that this command should preceed the <TT>server</TT> and <TT>fudge</TT>
command for the same device. Note also that the <TT>assert</TT>,
<TT>clear</TT> and <TT>hardpps</TT> options are only available if the
<tt>ppsapi</tt> standard PPS interface is available.</DD>
</dl>
<DL>
<DT><TT>device</TT></DT>
<DD>Specify the device name associated with the PPS signal. The name
must match exactly the link name specified in the driver documentation
page.</DD>
<DT><TT>assert</TT></DT>
<DT><TT>clear</TT></DT>
<DD>Using <TT>assert</TT> or <TT>clear</TT> specifies if the high going
or low going edge of the signal must be used. The default is
<TT>assert</TT>.</DD>
<DT><TT>hardpps</TT></DT>
<DD>This flag is used to tell the kernel that the signal from this
device must be used to drive hardpps().</DD>
<DD>The <TT>assert</TT>, <TT>clear</TT> and <TT>hardpps</TT> options
are only available if the PPSAPI is used.</DD>
</DL>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>/address></a></body></html>

407
contrib/ntp/html/config.htm
View File

@ -1,11 +1,15 @@
<HTML><HEAD><TITLE>
<html><head><title>
Configuration Options
</TITLE></HEAD><BODY><H3>
</title></head><body><h3>
Configuration Options
</H3>
</h3>
<IMG align=left SRC="pic/pogo3a.gif">From <i>pogo</i>, Walt Kelly
<BR clear=left><HR>
<img align=left src=pic/pogo3a.gif><a
href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>,
Walt Kelly</a>
<p>Gnu autoconfigure tools are in the backpack.
<br clear=left><hr>
<H4>Basic Configuration Options - the <TT>configure</TT> utility</H4>
@ -18,273 +22,166 @@ driver support, debugging support, and so forth.
<P>Configuration options are specified as arguments to the
<TT>configure</TT> script. Following is a summary of the current
options:
options, as of the 4.0.99m version:
<P>Usage: <TT>configure [options] [host]</TT>
<BR>Options: <TT>[defaults in brackets after descriptions]</TT>
<PRE>Configuration
&nbsp; --cache-file=FILE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cache test
results in FILE
&nbsp; --
help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp; print this message
&nbsp; --no-
create&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
do not create output files
&nbsp; --quiet, --silent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not print
`checking...' messages
&nbsp; --
version&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; print the version of autoconf that created
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Configuration:
<PRE>
--cache-file=FILE cache test results in FILE
--help print this message
--no-create do not create output files
--quiet, --silent do not print `checking...' messages
--version print the version of autoconf that created
configure
Directory and file names
</PRE>
&nbsp; --prefix=PREFIX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; install
architecture-independent files in
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PREFIX [/usr/local]
&nbsp; --exec-prefix=EPREFIX&nbsp; install architecture-dependent files
in EPREFIX
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Directory and file names:
<PRE>
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[same as prefix]
&nbsp; --
bindir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
user executables in DIR [EPREFIX/bin]
&nbsp; --
sbindir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; system
admin executables in DIR [EPREFIX/sbin]
&nbsp; --libexecdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; program
executables in DIR [EPREFIX/libexec]
&nbsp; --
datadir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; read-
only architecture-independent data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--bindir=DIR user executables in DIR [EPREFIX/bin]
--sbindir=DIR system admin executables in DIR [EPREFIX/sbin]
--libexecdir=DIR program executables in DIR [EPREFIX/libexec]
--datadir=DIR read-only architecture-independent data in DIR
[PREFIX/share]
&nbsp; --sysconfdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; read-only
single-machine data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--sysconfdir=DIR read-only single-machine data in DIR
[PREFIX/etc]
&nbsp; --sharedstatedir=DIR&nbsp;&nbsp; modifiable architecture-
independent data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--sharedstatedir=DIR modifiable architecture-independent data in DIR
[PREFIX/com]
&nbsp; --localstatedir=DIR&nbsp;&nbsp;&nbsp; modifiable single-machine
data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--localstatedir=DIR modifiable single-machine data in DIR
[PREFIX/var]
&nbsp; --
libdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
object code libraries in DIR [EPREFIX/lib]
&nbsp; --includedir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C header
files in DIR [PREFIX/include]
&nbsp; --oldincludedir=DIR&nbsp;&nbsp;&nbsp; C header files for non-gcc
in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[/usr/include]
&nbsp; --
infodir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; info
documentation in DIR [PREFIX/info]
&nbsp; --
mandir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
man documentation in DIR [PREFIX/man]
&nbsp; --
srcdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
find the sources in DIR [configure dir or ..]
&nbsp; --program-prefix=PREFIX prepend PREFIX to installed program names
&nbsp; --program-suffix=SUFFIX append SUFFIX to installed program names
&nbsp; --program-transform-name=PROGRAM run sed PROGRAM on installed
program
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--libdir=DIR object code libraries in DIR [EPREFIX/lib]
--includedir=DIR C header files in DIR [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc in DIR [/usr/include]
--infodir=DIR info documentation in DIR [PREFIX/info]
--mandir=DIR man documentation in DIR [PREFIX/man]
--srcdir=DIR find the sources in DIR [configure dir or ..]
--x-includes=DIR X include files are in DIR
--x-libraries=DIR X library files are in DIR
--program-prefix=PREFIX prepend PREFIX to installed program
names
Host type
--program-suffix=SUFFIX append SUFFIX to installed program
names
--program-transform-name=PROGRAM run sed PROGRAM on installed program
names
</PRE>
&nbsp; --
build=BUILD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
configure for building on BUILD [BUILD=HOST]
&nbsp; --
host=HOST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; configure for HOST [guessed]
&nbsp; --target=TARGET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
configure for TARGET [TARGET=HOST]</PRE>
Host type:
<PRE>Features and packages
<PRE>
--build=BUILD configure for building on BUILD [BUILD=HOST]
--host=HOST configure for HOST [guessed]
--target=TARGET configure for TARGET [TARGET=HOST]
</PRE>
&nbsp; --disable-FEATURE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not include
FEATURE (same as --enable-
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FEATURE=no)
&nbsp; --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
&nbsp; --with-PACKAGE[=ARG]&nbsp;&nbsp; use PACKAGE [ARG=yes]
&nbsp; --without-PACKAGE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not use
PACKAGE (same as --with-PACKAGE=no)
&nbsp; --x-includes=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; X include
files are in DIR
&nbsp; --x-libraries=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; X library files
are in DIR
Optional packages:
--enable- and --disable- with options recognized
<PRE>
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
&nbsp;&nbsp;&nbsp;&nbsp;
debugging&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Include debugging code [enable]
&nbsp;&nbsp;&nbsp;&nbsp; gdt-
surveying&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Include GDT survey code
[disable]
&nbsp;&nbsp;&nbsp;&nbsp;
md5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; Include support for MD5 keys [enable]
&nbsp;&nbsp;&nbsp;&nbsp;
des&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; Include support for DES keys [enable]
&nbsp;&nbsp;&nbsp;&nbsp; all-
clocks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Include
drivers for all reference clocks
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
openssl-libdir=DIR OpenSSL object code libraries in DIR [/usr/lib
/usr/local/lib /usr/local/ssl/lib]
openssl-incdir=DIR OpenSSL header files in DIR [/usr/include
/usr/local/include /usr/local/ssl/include]
crypto=autokey Use autokey cryptography
crypto=rsaref Use the RSAREF library
electricfence Compile with ElectricFence malloc debugger
</PRE>
Optional features:
<PRE>
--disable-FEATURE do not include FEATURE (same as
--enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
accurate-adjtime The adjtime() call is accurate
debugging Include debugging code [enable]
des Include support for DES keys [enable]
dst-minutes=VALUE Minutes per DST adjustment [60]
gdt-surveying Include GDT survey code [disable]
hourly-todr-sync If we should sync TODR hourly
kernel-fll-bug If we should avoid a (Solaris) kernel FLL bug
kmem Read /dev/kmem for 'tick' and/or 'tickadj'
md5 Include support for MD5 keys [enable]
ntpdate-step If ntpdate should step the time
slew-always Always slew the time
step-slew Step and slew the time
tick=VALUE Force a value for 'tick'
tickadj=VALUE Force a value for 'tickadj'
udp-wildcard Use UDP wildcard delivery
</PRE>
Radio clocks (these are ordinarily enabled, if supported by the
machine and operating system):
<PRE>
all-clocks Include drivers for all suitable non-PARSE
clocks [enable]
ACTS NIST dialup clock
ARBITER Arbiter 1088A/B GPS receiver
ARCRON_MSF Arcron MSF receiver
AS2201 Austron 2200A or 2201A GPS receiver
ATOM ATOM PPS interface
AUDIO-CHU CHU audio decoder
BANCOMM Datum/Bancomm BC635/VME interface
(requires an explicit --enable-BANCOMM request)
CHRONOLOG Chrono-log K-series WWVB receiver
CHU CHU modem decoder
DATUM Datum Programmable Time System
DUMBCLOCK Dumb generic hh:mm:ss local clock
FG Forum Graphic GPS
GPSVME TrueTime GPS receiver with VME interface
(requires an explicit --enable-GPSVME request)
HEATH HeathKit GC-1000 Most Accurate Clock
HOPFPCI HOPF 6039 PCI board
HOPFSERIAL HOPF serial clock device
HPGPS HP 58503A GPS Time &amp; Frequency receiver
IRIG IRIG (Audio) Clock
JUPITER Rockwell Jupiter GPS receiver
LEITCH Leitch CSD 5300 Master Clock System Driver
LOCAL-CLOCK Local clock driver
MSFEES EES M201 MSF receiver
MX4200 Magnavox MX4200 GPS receiver
NMEA NMEA GPS receiver
ONCORE Motorola VP/UT Oncore GPS receiver
PALISADE Palisade clock
PCF Conrad parallel port radio clock
PST PST/Traconex 1020 WWV/H receiver
PTBACTS PTB dialup clock support
SHM Clock attached through shared memory
(requires an explicit --enable-SHM request)
SPECTRACOM Spectracom 8170/Netclock/2 WWVB receiver
TRAK TRAK 8810 GPS station clock
TPRO KSI/Odetics TPRO/S IRIG Interface
TRUETIME Kinemetrics/TrueTime (generic) receiver
ULINK Ultralink WWVB receiver
USNO US Naval Observatory dialup clock
WWV WWV audio receiver
</PRE>
PARSE Clocks:
<PRE>
parse-clocks Include drivers for all suitable PARSE clocks
[enable]
&nbsp; Radio Clocks (these are ordinarily enabled, if supported by the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
machine and operating system)
&nbsp;&nbsp;&nbsp;&nbsp;
ACTS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; NIST dialup clock
&nbsp;&nbsp;&nbsp;&nbsp;
ARBITER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; Arbiter 1088A/B GPS receiver
&nbsp;&nbsp;&nbsp;&nbsp;
AS2201&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; Austron 2200A or 2201A GPS receiver
&nbsp;&nbsp;&nbsp;&nbsp;
ATOM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; ATOM clock
&nbsp;&nbsp;&nbsp;&nbsp;
BANCOMM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; BANCOMM clock
&nbsp;&nbsp;&nbsp;&nbsp;
CHU&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; CHU clock
&nbsp;&nbsp;&nbsp;&nbsp;
DATUM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; Datum Programmable Time System
&nbsp;&nbsp;&nbsp;&nbsp;
DCF7000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; ELV/DCF7000
&nbsp;&nbsp;&nbsp;&nbsp;
GPSVME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; GPS-VME Clock
&nbsp;&nbsp;&nbsp;&nbsp;
HEATH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; HeathKit GC-1000 Most Accurate Clock
&nbsp;&nbsp;&nbsp;&nbsp;
HOPF6021&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; HOPF6021 Radio Clock support
&nbsp;&nbsp;&nbsp;&nbsp;
HPGPS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; HP 58503A GPS Time &amp; Frequency receiver
&nbsp;&nbsp;&nbsp;&nbsp;
IRIG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; IRIG (Audio) Clock
&nbsp;&nbsp;&nbsp;&nbsp;
LEITCH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; Leitch CSD 5300 Master Clock System Driver
&nbsp;&nbsp;&nbsp;&nbsp; LOCAL-
CLOCK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local Clock driver
&nbsp;&nbsp;&nbsp;&nbsp;
MEINBERG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Meinberg clocks
&nbsp;&nbsp;&nbsp;&nbsp;
MSFEES&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; MSFEES clock
&nbsp;&nbsp;&nbsp;&nbsp;
MOTO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; Motorola GPS clock
&nbsp;&nbsp;&nbsp;&nbsp;
MX4200&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; MX4200 clock
&nbsp;&nbsp;&nbsp;&nbsp;
NMEA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; NMEA GPS clock
&nbsp;&nbsp;&nbsp;&nbsp;
PARSE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; PARSE clock code
&nbsp;&nbsp;&nbsp;&nbsp;
PST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; PST/Traconex 1020 WWV/H receiver
&nbsp;&nbsp;&nbsp;&nbsp;
PTBACTS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; PTB dialup clock support
&nbsp;&nbsp;&nbsp;&nbsp;
RAWDCF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; use raw DCF77 time code
&nbsp;&nbsp;&nbsp;&nbsp;
RCC8000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; RCC8000 Radio Clock support
&nbsp;&nbsp;&nbsp;&nbsp;
SCHMID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; SCHMID DCF77 clock support
&nbsp;&nbsp;&nbsp;&nbsp;
TRAK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; TRAK 8810 GPS station clock
&nbsp;&nbsp;&nbsp;&nbsp;
TPRO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; KSI/Odetics TPRO/S IRIG Interface
&nbsp;&nbsp;&nbsp;&nbsp;
TRIMTAIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Trimble GPS/TAIP Protocol
&nbsp;&nbsp;&nbsp;&nbsp;
TRIMTSIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Trimble GPS/TSIP Protocol
&nbsp;&nbsp;&nbsp;&nbsp;
TRUETIME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Kinemetrics/TrueTime (generic) receiver
&nbsp;&nbsp;&nbsp;&nbsp;
WWVB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; Spectracom 8170 or Netclock/2 WWVB receiver
&nbsp;&nbsp;&nbsp;&nbsp;
USNO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; US Naval Observatory dialup clock
&nbsp; Miscellany
&nbsp;&nbsp;&nbsp;&nbsp; accurate-adjtime&nbsp;&nbsp;&nbsp; The
adjtime() call is accurate
&nbsp;&nbsp;&nbsp;&nbsp;
kmem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; Read kmem
&nbsp;&nbsp;&nbsp;&nbsp;
tick=VALUE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Force a
value for 'tick'
&nbsp;&nbsp;&nbsp;&nbsp;
tickadj=VALUE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Force a value for
'tickadj'
&nbsp;&nbsp;&nbsp;&nbsp; udp-
wildcard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Use UDP wildcard
delivery
&nbsp;&nbsp;&nbsp;&nbsp; slew-
always&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Always slew the
time
&nbsp;&nbsp;&nbsp;&nbsp; step-
slew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Step
and slew the time
&nbsp;&nbsp;&nbsp;&nbsp; ntpdate-
step&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If ntpdate should step
the time
&nbsp;&nbsp;&nbsp;&nbsp; hourly-todr-sync&nbsp;&nbsp;&nbsp; If we should
sync TODR hourly</PRE>
COMPUTIME Diem Computime Radio Clock
DCF7000 ELV/DCF7000 Clock
HOPF6021 HOPF 6021 Radio Clock support
MEINBERG Meinberg clocks
RAWDCF DCF77 raw time code
RCC8000 RCC 8000 Radio Clock support
SCHMID SCHMID DCF77 clock support
TRIMTAIP Trimble GPS/TAIP Protocol
TRIMTSIP Trimble GPS/TSIP Protocol
VARITEXT VARITEXT clock
WHARTON Wharton 400A Series clock
</PRE>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>

565
contrib/ntp/html/confopt.htm
View File

@ -1,330 +1,257 @@
<html><head><title>
Configuration Options
</title></head><body><h3>
Configuration Options
</h3><hr>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Configuration Options</title>
</head>
<body>
<h3>Configuration Options</h3>
<img align="left" src="pic/boom3a.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<p>The chicken is getting configuration advice.<br clear="left">
</p>
<hr>
<h4>Configuration Support</h4>
<p>Following is a description of the configuration commands in
NTPv4. These commands have the same basic functions as in NTPv3
and in some cases new functions and new operands. The various
modes are determined by the command keyword and the type of the
required IP address. Addresses are classed by type as (s) a
remote server or peer (IP class A, B and C), (b) the broadcast
address of a local interface, (m) a multicast address (IP class
D), or (r) a reference clock address (127.127.x.x). Note that,
while autokey and burst modes are supported by these commands,
their effect in some weird mode combinations can be meaningless
or even destructive.</p>
NTPv4. These commands have the same basic functions as in NTPv3 and
in some cases new functions and new arguments. There are two
classes of commands, configuration commands that configure a
persistent association with a remote server or peer or reference
clock, and auxilliary commands that specify environmental variables
that control various related operations.</p>
<h4>Configuration Commands</h4>
<p>The various modes are determined by the command keyword and the
type of the required IP address. Addresses are classed by type as
(s) a remote server or peer (IP class A, B and C), (b) the
broadcast address of a local interface, (m) a multicast address (IP
class D), or (r) a reference clock address (127.127.x.x). Note that
only those options applicable to each command are listed below. Use
of options not listed may not be caught as an error, but may result
in some weird and even destructive behavior.</p>
<dl>
<dt><tt>peer </tt><i><tt>address</tt></i><tt> [autokey | key </tt><i><tt>key</tt></i><tt>]
[burst] [version </tt><i><tt>version</tt></i><tt>]
[prefer] [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt>
</tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
<dd>&nbsp;</dd>
<dt><tt>server </tt><i><tt>address</tt></i><tt> [autokey |
key </tt><i><tt>key</tt></i><tt>] [burst] [version </tt><i><tt>version</tt></i><tt>]
[prefer] [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt>
</tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
<dd>&nbsp;</dd>
<dt><tt>broadcast </tt><i><tt>address</tt></i><tt> [autokey |
key </tt><i><tt>key</tt></i><tt>] [burst] [version </tt><i><tt>version</tt></i><tt>]
[minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt> </tt></i><tt>[maxpoll
</tt><i><tt>maxpoll</tt></i><tt>] [ttl </tt><i><tt>ttl</tt></i><tt>]</tt></dt>
<dd>&nbsp;</dd>
<dt><tt>manycastclient </tt><i><tt>address</tt></i><tt>
[autokey | key </tt><i><tt>key</tt></i><tt>] [burst]
[version </tt><i><tt>version</tt></i><tt>] [minpoll </tt><i><tt>minpoll
</tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]
[ttl </tt><i><tt>ttl</tt></i><tt>]</tt></dt>
<dd>&nbsp;</dd>
<dd>These four commands specify the time server name or
address to be used and the mode in which to operate. The <i><tt>address</tt></i><tt>
</tt>can be either a DNS name or a IP address in
dotted-quad notation. Additional information on
association behavior can be found in the <a
href="assoc.htm">Association Management</a> page.</dd>
<dd>&nbsp;</dd>
<dd><dl>
<dt><tt>server</tt></dt>
<dd>For type s and r addresses, this operates as the
NTPv3 server command, which mobilizes a
persistent client mode association. The <tt>server</tt>
command specifies that the local server is to
operate in client mode with the specified remote
server. In this mode, the local server can be
synchronized to the remote server, but the remote
server can never be synchronized to the local
server.</dd>
<dd>&nbsp;</dd>
<dt><tt>peer</tt></dt>
<dd>For type s addresses (only), this operates as the
current <tt>peer </tt>command, which mobilizes a
persistent symmetric-active mode association,
except that additional modes are available. This
command should NOT be used for type b, m or r
addresses.</dd>
<dd>&nbsp;</dd>
<dd>The <tt>peer</tt> command specifies that the
local server is to operate in symmetric active
mode with the remote server. In this mode, the
local server can be synchronized to the remote
server and, in addition, the remote server can be
synchronized by the local server. This is useful
in a network of servers where, depending on
various failure scenarios, either the local or
remote server may be the better source of time.</dd>
<dd>&nbsp;</dd>
<dt><tt>broadcast</tt></dt>
<dd>For type b and m addresses (only), this is
operates as the current NTPv3 <tt>broadcast </tt>command,
which mobilizes a persistent broadcast mode
association, except that additional modes are
available. Multiple commands can be used to
specify multiple local broadcast interfaces
(subnets) and/or multiple multicast groups. Note
that local broadcast messages go only to the
interface associated with the subnet specified,
but multicast messages go to all interfaces. In
the current implementation, the source address
used for these messages is the Unix host default
address.</dd>
<dd>&nbsp;</dd>
<dd>In broadcast mode, the local server sends
periodic broadcast messages to a client
population at the <i><tt>address </tt></i>specified,
which is usually the broadcast address on (one
of) the local network(s) or a multicast address
assigned to NTP. The IANA has assigned the
multicast group address 224.0.1.1 exclusively to
NTP, but other nonconflicting addresses can be
used to contain the messages within
administrative boundaries.. Ordinarily, this
specification applies only to the local server
operating as a sender; for operation as a
broadcast client, see the <tt>broadcastclient</tt>
or <tt>multicastclient</tt> commands below.</dd>
<dd>&nbsp;</dd>
<dt><tt>manycastclient</tt> </dt>
<dd>For type m addresses (only), this mobilizes a
manycast client-mode association for the
multicast address specified. In this case a
specific address must be supplied which matches
the address used on the <tt>manycastserver </tt>command
for the designated manycast servers. The NTP
multicast address 224.0.1.1 assigned by the IANA
should NOT be used, unless specific means are
taken to avoid spraying large areas of the
Internet with these messages and causing a
possibly massive implosion of replies at the
sender. </dd>
<dd>&nbsp;</dd>
<dd>The <tt>manycast </tt>command specifies that the
local server is to operate in client mode with
the remote server that are discovered as the
result of broadcast/multicast messages. The
client broadcasts a request message to the group
address associated with the specified <i><tt>address
</tt></i>and specifically enabled servers respond
to these messages. The client selects the servers
providing the best time and continues as with the
<tt>server </tt>command. The remaining servers
are discarded as if never heard.</dd>
<dd>&nbsp;</dd>
</dl>
</dd>
<dd>Options</dd>
<dd>&nbsp;</dd>
<dd><dl>
<dt><tt>autokey</tt></dt>
<dd>All packets sent to the address are to include
authentication fields encrypted using the autokey
scheme.</dd>
<dd>&nbsp;</dd>
<dt><tt>burst</tt></dt>
<dd>At each poll interval, send a burst of eight
packets spaced, instead of the usual one.</dd>
<dd>&nbsp;</dd>
<dt><tt>key </tt><i><tt>key</tt></i></dt>
<dd>All packets sent to the address are to include
authentication fields encrypted using the
specified <i>key</i> identifier, which is an
unsigned 32-bit integer less than 65536. The
default is to include no encryption field.</dd>
<dd>&nbsp;</dd>
<dt><tt>version </tt><i><tt>version</tt></i></dt>
<dd>Specifies the version number to be used for
outgoing NTP packets. Versions 1-4 are the
choices, with version 4 the default.</dd>
<dd>&nbsp;</dd>
<dt><tt>prefer</tt></dt>
<dd>Marks 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.htm">Mitigation
Rules and the <tt>prefer</tt> Keyword </a>page
for further information.</dd>
<dd>&nbsp;</dd>
<dt><tt>ttl </tt><i><tt>ttl</tt></i></dt>
<dd>This option is used only with broadcast mode. It
specifies the time-to-live <i><tt>ttl</tt></i> to
use on multicast packets. Selection of the proper
value, which defaults to 127, is something of a
black art and must be coordinated with the
network administrator.</dd>
<dd>&nbsp;</dd>
<dt><tt>minpoll </tt><i><tt>minpoll</tt></i></dt>
<dt><tt>maxpoll </tt><i><tt>maxpoll</tt></i></dt>
<dd>These options specify the minimum and maximum
polling intervals for NTP messages, in seconds to
the power of two. The default range is 6 (64 s)
to 10 (1,024 s).The allowable range is 4 (16 s)
to 17 (36.4 h) inclusive.</dd>
<dd>&nbsp;</dd>
</dl>
</dd>
<dt><tt>broadcastclient</tt></dt>
<dd>This command directs the local server to listen for and
respond to broadcast messages received on any local
interface. Upon hearing a broadcast message for the first
time, the local server measures the nominal network delay
using a brief client/server exchange with the remote
server, then enters the broadcastclient mode, in which it
listens for and synchronizes to succeeding broadcast
messages. Note that, in order to avoid accidental or
malicious disruption in this mode, both the local and
remote servers should operate using authentication and
the same trusted key and key identifier.</dd>
<dd>&nbsp;</dd>
<dt><tt>multicastclient [</tt><i><tt>address</tt></i><tt>]
[...]</tt></dt>
<dd>This command directs the local server to listen for
multicast messages at the group address(es) of the global
network. The default address is that assigned by the
Numbers Czar to NTP (224.0.1.1). This command operates in
the same way as the <tt>broadcastclient</tt> command, but
uses IP multicasting. Support for this command requires a
multicast kernel.</dd>
<dd>&nbsp;</dd>
<dt><tt>driftfile </tt><i><tt>driftfile</tt></i></dt>
<dd>This command specifies the name of the file used to
record the frequency offset of the local clock
oscillator. If the file exists, it is read at startup in
order to set the initial frequency offset and then
updated once per hour with the current frequency offset
computed by the daemon. If the file does not exist or
this command is not given, the initial frequency offset
is assumed zero. In this case, it may take some hours for
the frequency to stabilize and the residual timing errors
to subside.</dd>
<dd>&nbsp;</dd>
<dd>The file format consists of a single line containing a
single floating point number, which records the frequency
offset measured in parts-per-million (PPM). The file is
updated by first writing the current drift value into a
temporary file and then renaming this file to replace the
old version. This implies that <tt>ntpd</tt> must have
write permission for the directory the drift file is
located in, and that file system links, symbolic or
otherwise, should be avoided.</dd>
<dd>&nbsp;</dd>
<dt><tt>manycastserver </tt><i><tt>address </tt></i><tt>[...]</tt></dt>
<dd>This command directs the local server to listen for and
respond to broadcast messages received on any local
interface, and in addition enables the server to respond
to client mode messages to the multicast group
address(es) (type m) specified. At least one address is
required, but The NTP multicast address 224.0.1.1
assigned by the IANA should NOT be used, unless specific
means are taken to limit the span of the reply and avoid
a possibly massive implosion at the original sender.</dd>
<dd>&nbsp;</dd>
<dt><tt>revoke [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
<dd>Specifies the interval between recomputations of the
private value used with the autokey feature, which
ordinarily requires an expensive public- key computation.
The default value is 12 (65,536 s or about 18 hours). For
poll intervals above the specified interval, a new
private value will be recomputed for every message sent.</dd>
<dd>&nbsp;</dd>
<dt><tt>autokey [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
<dd>Specifies the interval between regenerations of the
session key list used with the autokey feature. Note that
the size of the key list for each association depends on
this interval and the current poll interval. The default
value is 12 (4096 s or about 1.1 hours). For poll
intervals above the specified interval, a session key
list with a single entry will be regenerated for every
message sent.</dd>
<dd>&nbsp;</dd>
<dt><tt>enable [auth | bclient | kernel | monitor | ntp |
stats]</tt></dt>
<dt><tt>disable [auth | bclient | kernel | monitor | ntp |
stats</tt><font face="Courier New">] </font></dt>
<dd>Provides a way to enable or disable various server
options. Flags not mentioned are unaffected. Note that
all of these flags can be controlled remotely using the <a
href="ntpdc.htm"><tt>ntpdc</tt></a> utility program.</dd>
<dd>&nbsp;</dd>
<dd><dl>
<dt><tt>auth</tt></dt>
<dd>Enables the server to synchronize with
unconfigured peers only if the peer has been
correctly authenticated using a trusted key and
key identifier. The default for this flag is
enable.</dd>
<dd>&nbsp;</dd>
<dt><tt>bclient</tt></dt>
<dd>When enabled, this is identical to the <tt>broadcastclient</tt>
command. The default for this flag is disable.</dd>
<dd>&nbsp;</dd>
<dt><tt>kernel</tt></dt>
<dd>Enables the precision-time kernel support for the
<tt>ntp_adjtime()</tt> system call, if
implemented. Ordinarily, support for this routine
is detected automatically when the NTP daemon is
compiled, so it is not necessary for the user to
worry about this flag. It flag is provided
primarily so that this support can be disabled
during kernel development.</dd>
<dd>&nbsp;</dd>
<dt><tt>monitor</tt></dt>
<dd>Enables the monitoring facility. See the <tt>ntpdc</tt>
program and the <tt>monlist</tt> command or
further information. The default for this flag is
enable.</dd>
<dd>&nbsp;</dd>
<dt><tt>ntp</tt></dt>
<dd>Enables the server to adjust its local clock by
means of NTP. If disabled, the local clock
free-runs at its intrinsic time and frequency
offset. This flag is useful in case the local
clock is controlled by some other device or
protocol and NTP is used only to provide
synchronization to other clients. In this case,
the local clock driver can be used to provide
this function and also certain time variables for
error estimates and leap-indicators. See the <a
href="refclock.htm">Reference Clock Drivers </a>page
for further information. The default for this
flag is enable.</dd>
<dd>&nbsp;</dd>
<dt><tt>stats</tt></dt>
<dd>Enables the statistics facility. See the <a
href="monopt.htm">Monitoring Options </a>page for
further information. The default for this flag is
enable.</dd>
<dd>&nbsp;</dd>
</dl>
</dd>
<dt><tt>server <i>address</i> [key <i>key</i> | autokey] [burst]
[iburst] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>]
[maxpoll <i>maxpoll</i>]</tt></dt>
<dt><tt>peer <i>address</i> [key <i>key</i> | autokey] [version <i>
version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll <i>
maxpoll</i>]</tt></dt>
<dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey]
[version <i>version</i>] [minpoll <i>minpoll</i>] [ttl <i>
ttl</i>]</tt></dt>
<dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey]
[version <i>version</i>] [minpoll <i>minpoll</i> [maxpoll <i>
maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
<dd>These four 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 IP address in dotted-quad notation.
Additional information on association behavior can be found in the
<a href="assoc.htm">Association Management</a> page.
<dl>
<dt><tt>server</tt></dt>
<dd>For type s and r addresses, this command mobilizes a persistent
client mode association with the specified remote server or local
radio clock. In this mode the local clock can synchronized to the
remote server, but the remote server can never be synchronized to
the local clock. This command should NOT be used for type <tt>
b</tt> or <tt>m</tt> addresses.</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. In this mode the local clock can be synchronized to
the remote peer or the remote peer can be synchronized to the local
clock. This is useful in a network of servers where, depending on
various failure scenarios, either the local or remote peer may be
the better source of time. This command should NOT be used for type
<tt>b</tt>, <tt>m</tt> or <tt>r</tt> addresses.</dd>
<dt><tt>broadcast</tt></dt>
<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this
command mobilizes a persistent broadcast mode association. Multiple
commands can be used to specify multiple local broadcast interfaces
(subnets) and/or multiple multicast groups. Note that local
broadcast messages go only to the interface associated with the
subnet specified, but multicast messages go to all interfaces.</dd>
<dd>In broadcast mode the local server sends periodic broadcast
messages to a client population at the <i><tt>address</tt></i>
specified, which is usually the broadcast address on (one of) the
local network(s) or a multicast address assigned to NTP. The IANA
has assigned the multicast group address 224.0.1.1 exclusively to
NTP, but other nonconflicting addresses can be used to contain the
messages within administrative boundaries. Ordinarily, this
specification applies only to the local server operating as a
sender; for operation as a broadcast client, see the <tt>
broadcastclient</tt> or <tt>multicastclient</tt> commands
below.</dd>
<dt><tt>manycastclient</tt></dt>
<dd>For type <tt>m</tt> addresses (only), this command mobilizes a
manycast client mode association for the multicast address
specified. In this case a specific address must be supplied which
matches the address used on the <tt>manycastserver</tt> command for
the designated manycast servers. The NTP multicast address
224.0.1.1 assigned by the IANA should NOT be used, unless specific
means are taken to avoid spraying large areas of the Internet with
these messages and causing a possibly massive implosion of replies
at the sender.</dd>
<dd>The <tt>manycast</tt> command specifies that the local server
is to operate in client mode with the remote servers that are
discovered as the result of broadcast/multicast messages. The
client broadcasts a request message to the group address associated
with the specified <i><tt>address</tt></i> and specifically enabled
servers respond to these messages. The client selects the servers
providing the best time and continues as with the <tt>server</tt>
command. The remaining servers are discarded as if never
heard.</dd>
<dt>Options</dt>
<dt><tt>autokey</tt></dt>
<dd>All packets sent to and received from the server or peer are to
include authentication fields encrypted using the autokey scheme
described in the <a href="authopt.htm">Authentication Options</a>
page.</dd>
<dt><tt>burst</tt></dt>
<dd>when the server is reachable and at each poll interval, send a
burst of eight packets instead of the usual one packet. The spacing
between the first and the second packets is about 16s to allow a
modem call to complete, while the spacing between the remaining
packets is about 2s. This is designed to improve timekeeping
quality with the <tt>server</tt> command and <tt>s</tt>
addresses.</dd>
<dt><tt>iburst</tt></dt>
<dd>When the server is unreachable and at each poll interval, send
a burst of eight packets instead of the usual one. As long as the
server is unreachable, the spacing between packets is about 16s to
allow a modem call to complete. Once the server is reachable, the
spacing between packets is about 2s. This is designed to speed the
initial synchronization acquisition with the <tt>server</tt>
command and <tt>s</tt> addresses and when <tt>ntpd</tt> is started
with the <tt>-q</tt> option.</dd>
<dt><tt>key</tt> <i><tt>key</tt></i></dt>
<dd>All packets sent to and received from the server or peer are to
include authentication fields encrypted using the specified <i>
key</i> identifier with values from 1 to 65534, inclusive. The
default is to include no encryption field.</dd>
<dt><tt>minpoll <i>minpoll</i></tt><br>
<tt>maxpoll <i>maxpoll</i></tt></dt>
<dd>These options specify the minimum and maximum poll intervals
for NTP messages, in seconds to the power of two. The maximum poll
interval defaults to 10 (1,024 s), but can be increased by the <tt>
maxpoll</tt> option to an upper limit of 17 (36.4 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 4 (16 s).</dd>
<dt><tt>prefer</tt></dt>
<dd>Marks 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.htm">Mitigation
Rules and the <tt>prefer</tt> Keyword</a> page for further
information.</dd>
<dt><tt>ttl <i>ttl</i></tt></dt>
<dd>This option is used only with broadcast server and manycast
client modes. It specifies the time-to-live <i><tt>ttl</tt></i> to
use on broadcast server and multicast server and the maximum <i>
<tt>ttl</tt></i> for the expanding ring search with manycast client
packets. Selection of the proper value, which defaults to 127, is
something of a black art and should be coordinated with the network
administrator.</dd>
<dt><tt>version <i>version</i></tt></dt>
<dd>Specifies the version number to be used for outgoing NTP
packets. Versions 1-4 are the choices, with version 4 the
default.</dd>
</dl>
</dd>
</dl>
<hr>
<h4>Auxilliary Commands</h4>
<address>
David L. Mills (mills@udel.edu)
</address>
<dl>
<dt><tt>broadcastclient</tt></dt>
<dd>This command enables reception of broadcast server messages to
any local interface (type b) address. Upon receiving a message for
the first time, the broadcast 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 broadcast 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.htm">
Authentication Options</a> page.</dd>
<dt><tt>manycastserver <i>address</i> [...]</tt></dt>
<dd>This command enables reception of manycast client messages to
the multicast group address(es) (type m) specified. At least one
address is required, but The NTP multicast address 224.0.1.1
assigned by the IANA should NOT be used, unless specific means are
taken to limit the span of the reply and avoid a possibly massive
implosion at the original sender. 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.htm">
Authentication Options</a> page.</dd>
<dt><tt>multicastclient [<i>address</i>] [...]</tt></dt>
<dd>This command enables 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.htm">Authentication Options</a> page.</dd>
</dl>
<h4>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>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

228
contrib/ntp/html/copyright.htm
View File

@ -1,202 +1,142 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><head><title>
Copyright Notice
</title></head><body><h3>
Copyright Notice
</h3>
<IMG align=left HEIGHT=264 WIDTH=206 SRC=pic/sheepb.jpg >"Clone
me," says Dolly sheepishly
<img align=left src=pic/sheepb.jpg>"Clone me," says Dolly sheepishly
<br clear=left><hr>
<P>The following copyright notice applies to all files collectively
called the Network Time Protocol Version 4 Distribution. Unless
specifically declared otherwise in an individual file, this notice
applies as if the text was explicitly included in the file.
<P>The following copyright notice applies to all files collectively called the Network Time Protocol Version 4 Distribution. Unless specifically declared otherwise in an individual file, this notice applies as if the text was explicitly included in the file.
<br>
<PRE>
/***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2000 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission *
* notice appear in supporting documentation, and that the name *
* University of Delaware not be used in advertising or publicity *
* pertaining to distribution of the software without specific, *
* written prior permission. The University of Delaware makes no *
* representations about the suitability this software for any *
* purpose. It is provided "as is" without express or implied *
* warranty. *
* *
***********************************************************************
*/
</PRE>
<pre>
***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2001 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission *
* notice appear in supporting documentation, and that the name *
* University of Delaware not be used in advertising or publicity *
* pertaining to distribution of the software without specific, *
* written prior permission. The University of Delaware makes no *
* representations about the suitability this software for any *
* purpose. It is provided "as is" without express or implied *
* warranty. *
* *
***********************************************************************
</pre>
The following individuals contributed in part to the Network Time
Protocol Distribution Version 4 and are acknowledged as authors of this
work.
The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.
<OL>
<ol>
<LI><A HREF="mailto: marka@syd.dms.csiro.au">Mark Andrews
&lt;marka@syd.dms.csiro.au&gt;</a> Leitch atomic clock controller</LI>
<li><A HREF="mailto: marka@syd.dms.csiro.au">Mark Andrews &lt;marka@syd.dms.csiro.au&gt;</a> Leitch atomic clock controller</li>
<LI><A HREF="mailto: vbais@mailman1.intel.co">Viraj Bais
&lt;vbais@mailman1.intel.com&gt;</a> and <A HREF="mailto:
<li><A HREF="mailto: altmeier@atlsoft.de">Bernd Altmeier &lt;altmeier@atlsoft.de&gt;</a> hopf Elektronik serial line and PCI-bus devices</li>
<li><A HREF="mailto: vbais@mailman1.intel.co">Viraj Bais &lt;vbais@mailman1.intel.com&gt;</a> and <A HREF="mailto:
kirkwood@striderfm.intel.com">Clayton Kirkwood
&lt;kirkwood@striderfm.intel.com&gt;</a> port to WindowsNT 3.5</LI>
&lt;kirkwood@striderfm.intel.com&gt;</a> port to WindowsNT 3.5</li>
<LI><A HREF="mailto: michael.barone@lmco.com">Michael Barone
&lt;michael,barone@lmco.com&gt;</a> GPSVME fixes</LI>
<li><A HREF="mailto: michael.barone@lmco.com">Michael Barone &lt;michael,barone@lmco.com&gt;</a> GPSVME fixes</li>
<LI><A HREF="mailto: karl@owl.HQ.ileaf.com">Karl Berry
&lt;karl@owl.HQ.ileaf.com&gt;</a> syslog to file option</LI>
<li><A HREF="mailto: karl@owl.HQ.ileaf.com">Karl Berry &lt;karl@owl.HQ.ileaf.com&gt;</a> syslog to file option</li>
<LI><A HREF="mailto: greg.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: greg.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: Piete.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: Marc.Brett@westgeo.com">Marc Brett &lt;Marc.Brett@westgeo.com&gt;</a> Magnavox GPS clock driver</li>
<LI><A HREF="mailto: clift@ml.csiro.au">Steve Clift
&lt;clift@ml.csiro.au&gt;</a> OMEGA clock driver</LI>
<li><A HREF="mailto: Piete.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:casey@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: reg@dwf.com">Reg Clemens &lt;reg@dwf.com&gt;</a> Oncore driver (Current maintainer)</li>
<LI><A HREF="mailto: Sven_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: clift@ml.csiro.au">Steve Clift &lt;clift@ml.csiro.au&gt;</a> OMEGA clock driver</li>
<LI><A HREF="mailto: dundas@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:casey@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: duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe
&lt;duwe@immd4.informatik.uni-erlangen.de&gt;</a> Linux port</LI>
<li><A HREF="mailto: Sven_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: dennis@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: dundas@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: glenn@herald.usask.ca">Glenn Hollinger
&lt;glenn@herald.usask.ca&gt;</a> GOES clock driver</LI>
<li><A HREF="mailto: duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe &lt;duwe@immd4.informatik.uni-erlangen.de&gt;</a> Linux port</li>
<LI><A HREF="mailto: iglesias@uci.edu">Mike Iglesias
&lt;iglesias@uci.edu&gt;</a> DEC Alpha port</LI>
<li><A HREF="mailto: dennis@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: jagubox.gsfc.nasa.gov">Jim Jagielski
&lt;jim@jagubox.gsfc.nasa.gov&gt;</a> A/UX port</LI>
<li><A HREF="mailto: glenn@herald.usask.ca">Glenn Hollinger &lt;glenn@herald.usask.ca&gt;</a> GOES clock driver</li>
<LI><A HREF="mailto: jbj@chatham.usdesign.com">Jeff Johnson
&lt;jbj@chatham.usdesign.com&gt;</a> massive prototyping overhaul</LI>
<li><A HREF="mailto: iglesias@uci.edu">Mike Iglesias &lt;iglesias@uci.edu&gt;</a> DEC Alpha port</li>
<LI><A HREF="mailto: jones@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: jagubox.gsfc.nasa.gov">Jim Jagielski &lt;jim@jagubox.gsfc.nasa.gov&gt;</a> A/UX port</li>
<LI><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>
<li><A HREF="mailto: jbj@chatham.usdesign.com">Jeff Johnson &lt;jbj@chatham.usdesign.com&gt;</a> massive prototyping overhaul</li>
<LI><A HREF="http://www4.informatik.uni-erlangen.de/~kardel">Frank
Kardel</A> <A HREF="mailto: Frank.Kardel@informatik.uni-erlangen.de">
&lt;Frank.Kardel@informatik.uni-erlangen.de&gt;</a> PARSE
&lt;GENERIC&gt; driver (14 reference clocks), STREAMS modules for PARSE,
support scripts, syslog cleanup</LI>
<li><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>
<LI><A HREF="mailto: dkatz@cisco.com">Dave Katz
&lt;dkatz@cisco.com&gt;</a> RS/6000 AIX port</LI>
<li><A HREF="mailto: phk@FreeBSD.ORG">Poul-Henning Kamp &lt;phk@FreeBSD.ORG&gt;</a> Oncore driver (Original author)</li>
<LI><A HREF="mailto: leres@ee.lbl.gov">Craig Leres
&lt;leres@ee.lbl.gov&gt;</a> 4.4BSD port, ppsclock, Maganavox GPS clock
driver</LI>
<li><A HREF="http://www4.informatik.uni-erlangen.de/~kardel">Frank Kardel</A> <A HREF="mailto: Frank.Kardel@informatik.uni-erlangen.de"> &lt;Frank.Kardel@informatik.uni-erlangen.de&gt;</a> PARSE &lt;GENERIC&gt; driver (14 reference clocks), STREAMS modules for PARSE, support scripts, syslog cleanup</li>
<LI><A HREF="mailto: lindholm@ucs.ubc.ca">George Lindholm
&lt;lindholm@ucs.ubc.ca&gt;</a> SunOS 5.1 port</LI>
<li><A HREF="mailto: jones@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: louie@ni.umd.edu">Louis A. Mamakos
&lt;louie@ni.umd.edu&gt;</a> MD5-based authentication</LI>
<li><A HREF="mailto: dkatz@cisco.com">Dave Katz &lt;dkatz@cisco.com&gt;</a> RS/6000 AIX port</li>
<LI><A HREF="mailto: thorinn@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: leres@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: mills@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>
<li><A HREF="mailto: lindholm@ucs.ubc.ca">George Lindholm &lt;lindholm@ucs.ubc.ca&gt;</a> SunOS 5.1 port</li>
<LI><A HREF="mailto: moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller
&lt;moeller@gwdgv1.dnet.gwdg.de&gt;</a> VMS port</LI>
<li><A HREF="mailto: louie@ni.umd.edu">Louis A. Mamakos &lt;louie@ni.umd.edu&gt;</a> MD5-based authentication</li>
<LI><A HREF="mailto: mogul@pa.dec.com">Jeffrey Mogul
&lt;mogul@pa.dec.com&gt;</a> ntptrace utility</LI>
<li><A HREF="mailto: thorinn@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: tmoore@fievel.daytonoh.ncr.com">Tom Moore
&lt;tmoore@fievel.daytonoh.ncr.com&gt;</a> i386 svr4 port</LI>
<li><A HREF="mailto: mills@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>
<LI><A HREF="mailto: derek@toybox.demon.co.uk">Derek Mulcahy
&lt;derek@toybox.demon.co.uk&gt;</a> and <A HREF="mailto:
d@hd.org">Damon Hart-Davis &lt;d@hd.org&gt;</a> ARCRON MSF clock
driver</LI>
<li><A HREF="mailto: moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller &lt;moeller@gwdgv1.dnet.gwdg.de&gt;</a> VMS port</li>
<LI><A HREF="mailto: Rainer.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: mogul@pa.dec.com">Jeffrey Mogul &lt;mogul@pa.dec.com&gt;</a> ntptrace utility</li>
<LI><A HREF="mailto: dirce@zk3.dec.com">Dirce Richards
&lt;dirce@zk3.dec.com&gt;</a> Digital UNIX V4.0 port</LI>
<li><A HREF="mailto: tmoore@fievel.daytonoh.ncr.com">Tom Moore &lt;tmoore@fievel.daytonoh.ncr.com&gt;</a> i386 svr4 port</li>
<LI><A HREF="mailto: wsanchez@apple.com">Wilfredo S&aacute;nchez
&lt;wsanchez@apple.com&gt;</A> added support for NetInfo</LI>
<li><A HREF="mailto: kamal@whence.com">Kamal A Mostafa &lt;kamal@whence.com&gt;</a> SCO OpenServer port</li>
<LI><A HREF="mailto: mrapple@quack.kfu.com">Nick Sayer
&lt;mrapple@quack.kfu.com&gt;</a> SunOS streams modules</LI>
<li><A HREF="mailto: derek@toybox.demon.co.uk">Derek Mulcahy &lt;derek@toybox.demon.co.uk&gt;</a> and <A HREF="mailto: d@hd.org">Damon Hart-Davis &lt;d@hd.org&gt;</a> ARCRON MSF clock driver</li>
<LI><A HREF="mailto: jack@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: Rainer.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: schnitz@unipress.com">Ray Schnitzler
&lt;schnitz@unipress.com&gt;</a> Unixware1 port</LI>
<li><A HREF="mailto: dirce@zk3.dec.com">Dirce Richards &lt;dirce@zk3.dec.com&gt;</a> Digital UNIX V4.0 port</li>
<LI><A HREF="mailto: shields@tembel.org">Michael Shields
&lt;shields@tembel.org&gt;</a> USNO clock driver</LI>
<li><A HREF="mailto: wsanchez@apple.com">Wilfredo S&aacute;nchez &lt;wsanchez@apple.com&gt;</A> added support for NetInfo</li>
<LI><A HREF="mailto: pebbles.jpl.nasa.gov">Jeff Steinman
&lt;jss@pebbles.jpl.nasa.gov&gt;</a> Datum PTS clock driver</LI>
<li><A HREF="mailto: mrapple@quack.kfu.com">Nick Sayer &lt;mrapple@quack.kfu.com&gt;</a> SunOS streams modules</li>
<LI><A HREF="mailto: harlan@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: jack@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: ken@sdd.hp.com">Kenneth Stone
&lt;ken@sdd.hp.com&gt;</a> HP-UX port</LI>
<li><A HREF="mailto: schnitz@unipress.com">Ray Schnitzler &lt;schnitz@unipress.com&gt;</a> Unixware1 port</li>
<LI><A HREF="mailto: ajit@ee.udel.edu">Ajit Thyagarajan
&lt;ajit@ee.udel.edu&gt;</a>IP multicast/anycast support</LI>
<li><A HREF="mailto: shields@tembel.org">Michael Shields &lt;shields@tembel.org&gt;</a> USNO clock driver</li>
<LI><A HREF="mailto: tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA
&lt;tsuruoka@nc.fukuoka-u.ac.jp&gt;</a>TRAK clock driver</LI>
<li><A HREF="mailto: pebbles.jpl.nasa.gov">Jeff Steinman &lt;jss@pebbles.jpl.nasa.gov&gt;</a> Datum PTS clock driver</li>
<LI><A HREF="mailto: vixie@vix.com">Paul A Vixie
&lt;vixie@vix.com&gt;</a> TrueTime GPS driver, generic TrueTime clock
driver</LI>
<li><A HREF="mailto: harlan@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: Ulrich.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>
<li><A HREF="mailto: ken@sdd.hp.com">Kenneth Stone &lt;ken@sdd.hp.com&gt;</a> HP-UX port</li>
</OL>
<li><A HREF="mailto: ajit@ee.udel.edu">Ajit Thyagarajan &lt;ajit@ee.udel.edu&gt;</a>IP multicast/anycast support</li>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<li><A HREF="mailto: tsuruoka@nc.fukuoka-u.ac.jp">Tomoaki TSURUOKA &lt;tsuruoka@nc.fukuoka-u.ac.jp&gt;</a>TRAK clock driver</li>
<li><A HREF="mailto: vixie@vix.com">Paul A Vixie &lt;vixie@vix.com&gt;</a> TrueTime GPS driver, generic TrueTime clock driver</li>
<li><A HREF="mailto: Ulrich.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>
<a href=index.htm><img align=left src=pic/home.gif alt="gif"></a><address><a href=mailto:mills@udel.edu>David L. Mills &lt;mills@udel.edu&gt;</a></address></body></html>

693
contrib/ntp/html/debug.htm
View File

@ -1,288 +1,477 @@
<HTML><HEAD><TITLE>
NTP Debugging Techniques
</TITLE></HEAD><BODY><H3>
NTP Debugging Techniques
</H3>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>NTP Debugging Techniques</title>
</head>
<body>
<h3>NTP Debugging Techniques</h3>
<IMG align=left SRC="pic/pogo.gif"><I>Pogo Possum</I>, with toolkit
and bug, Walt Kelly
<br clear=left><hr>
<img align="left" src="pic/pogo.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<P>Once the NTP software distribution has been compiled and installed
and the configuration file constructed, the next step is to verify
correct operation and fix any bugs that may result. Usually, the command
line that starts the daemon is included in the system startup file, so
it is executed only at system boot time; however, the daemon can be
stopped and restarted from root at any time. Usually, no command-line
arguments are required, unless special actions described in the
<TT><A HREF="ntpd.htm">ntpd</A></TT> page are required. Once started,
the daemon will begin sending messages, as specified in the
configuration file, and interpreting received messages.
<p>We make house calls and bring our own bugs.<br clear="left">
</p>
<P>The best way to verify correct operation is using the <TT><A
HREF="ntpq.htm">ntpq</A></TT> and <TT><A HREF="ntpdc.htm">ntpdc</A></TT>
utility programs, either on the server itself or from another machine
elsewhere in the network. The <TT>ntpq</TT> program implements the
management functions specified in Appendix A of the NTP specification <A
HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps"
>
RFC-1305, Appendix A</A>. The <TT>ntpdc</TT> program implements
additional functions not provided in the standard. Both programs can be
used to inspect the state variables defined in the specification and, in
the case of <TT>ntpdc</TT>, additional ones of interest. In addition,
the <TT>ntpdc</TT> program can be used to selectively enable and disable
some functions of the daemon while the daemon is running.
<hr>
<p>Once the NTP software distribution has been compiled and
installed and the configuration file constructed, the next step is
to verify correct operation and fix any bugs that may result.
Usually, the command line that starts the daemon is included in the
system startup file, so it is executed only at system boot time;
however, the daemon can be stopped and restarted from root at any
time. Usually, no command-line arguments are required, unless
special actions described in the <tt><a href="ntpd.htm">
ntpd</a></tt> page are required. Once started, the daemon will
begin sending and receiving messages, as specified in the
configuration file.</p>
<P>In extreme cases with elusive bugs, the daemon can operate in two
modes, depending on the presence of the <TT>-d</TT> command-line debug
switch. If not present, the daemon detaches from the controlling
terminal and proceeds autonomously. If one or more <TT>-d</TT> switches
are present, the daemon does not detach and generates special output
useful for debugging. In general, interpretation of this output requires
reference to the sources. However, a single <TT>-d</TT> does produce
only mildly cryptic output and can be very useful in finding problems
with configuration and network troubles. With a little experience, the
volume of output can be reduced by piping the output to <TT>grep
</TT>and specifying the keyword of the trace you want to see.
<h4>Initial Startup</h4>
<P>Some problems are immediately apparent when the daemon first starts
running. The most common of these are the lack of a ntp (UDP port 123)
in the host <TT>/etc/services</TT> file. Note that NTP does not use TCP
in any form. Other problems are apparent in the system log file. The log
file should show the startup banner, some cryptic initialization data,
and the computed precision value. The next most common problem is
incorrect DNS names. Check that each DNS name used in the configuration
file responds to the Unix <TT>ping</TT> command.
<p>The best way to verify correct operation is using the <tt><a
href="ntpq.htm">ntpq</a></tt> and <tt><a href="ntpdc.htm">
ntpdc</a></tt> utility programs, either on the server itself or
from another machine elsewhere in the network. The <tt>ntpq</tt>
program implements the management functions specified in the NTP
specification <a href=
"http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps">
RFC-1305, Appendix A</a>. The <tt>ntpdc</tt> program implements
additional functions not provided in the standard. Both programs
can be used to inspect the state variables defined in the
specification and, in the case of <tt>ntpdc</tt>, additional ones
of interest. In addition, the <tt>ntpdc</tt> program can be used to
selectively reconfigure and enable or disable some functions while
the daemon is running.</p>
<P>When first started, the daemon normally polls the servers listed in
the configuration file at 64-second intervals. In order to allow a
<p>In extreme cases with elusive bugs, the daemon can operate in
two modes, depending on the presence of the <tt>-d</tt>
command-line debug switch. If not present, the daemon detaches from
the controlling terminal and proceeds autonomously. If one or more
<tt>-d</tt> switches are present, the daemon does not detach and
generates special output useful for debugging. In general,
interpretation of this output requires reference to the sources.
However, a single <tt>-d</tt> does produce only mildly cryptic
output and can be very useful in finding problems with
configuration and network troubles. With a little experience, the
volume of output can be reduced by piping the output to <tt>
grep</tt> and specifying the keyword of the trace you want to
see.</p>
<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). Note that NTP does not use TCP in any
form. Other problems are apparent in the system log file. The log
file should show the startup banner, some cryptic initialization
data and the computed precision value. The next most common problem
is incorrect DNS names. Check that each DNS name used in the
configuration file exists and that the address responds to the Unix
<tt>ping</tt> command.</p>
<p>When first started, the daemon normally polls the servers listed
in the configuration file at 64-s intervals. In order to allow a
sufficient number of samples for the NTP algorithms to reliably
discriminate between correctly operating servers and possible intruders,
at least four valid messages from at least one server is required before
the daemon can set the local clock. However, if the current local time
is greater than 1000 seconds in error from the server time, the daemon
will not set the local clock; instead, it will plant a message in the
system log and shut down. It is necessary to set the local clock to
within 1000 seconds first, either by a time-of-year hardware clock, by
first using the <A HREF="ntpdate.htm"><TT>ntpdate</TT> </A>program or
manually be eyeball and wristwatch.
discriminate between correctly operating servers and possible
intruders, at least four valid messages from the majority of
servers and peers listed in the configuration file is required
before the daemon can set the local clock. However, if the
difference between the client time and server time is greater than
the panic threshold, which defaults to 1000 s, the daemon will send
a message to the system log and shut down without setting the
clock. It is necessary to set the local clock to within the panic
threshold first, either manually by eyeball and wristwatch and the
Unix <tt>date</tt> command, or by the <tt>ntpdate</tt> or <tt>ntpd
-q</tt> commands. The panic threshold can be changed by the <tt>
tinker panic</tt> command discribed on the <a href="miscopt.htm">
Miscellaneous Options</a> page. The panic threshold can be disabled
entirely by the <tt>-g</tt> command line option described on the <a
href="ntpd.htm">ntpd - Network Time Protocol (NTP) daemon</a>
page.</p>
<P>After starting the daemon, run the <TT>ntpq</TT> program using the
<TT>-n</TT> switch, which will avoid possible distractions due to name
resolution problems. Use the <TT>pe</TT> command to display a billboard
showing the status of configured peers and possibly other clients poking
the daemon. After operating for a few minutes, the display should be
something like:
<p>If the difference between local time and server time is less
than the panic threshold but greater than the step threshold, which
defaults to 125 ms, the daemon will perform a step adjustment;
otherwise, it will gradually slew the clock to the nominal time.
The step threshold can be changed by the <tt>tinker step</tt>
command discribed on the <a href="miscopt.htm">Miscellaneous
Options</a> page. The step threshold can be disabled entirely by
the <tt>-x</tt> command line option described on the <a href=
"ntpd.htm">ntpd - Network Time Protocol (NTP) daemon</a> page. In
this case the clock will never be stepped; however, users should
understand the implications for doing this in a distributed data
network where all processing must be tightly synchronized. See the
<a href="leap.htm">NTP Timescale and Leap Seconds</a> page for
further information. If a step adjustment is made, the clock
discipline algorithm will start all over again, requiring another
round of at least four messages as before. This is necessary so
that all servers and peers operate on the same set of time
values.</p>
<PRE>ntpq>pe
remote refid st t when poll reach delay offset disp
===================================================================
+128.4.2.6 132.249.16.1 2 u 131 256 373 9.89 16.28 23.25
*128.4.1.20 .WWVB. 1 u 137 256 377 280.62 21.74 20.23
-128.8.2.88 128.8.10.1 2 u 49 128 376 294.14 5.94 17.47
+128.4.2.17 .WWVB. 1 u 173 256 377 279.95 20.56 16.40
</PRE>
<p>The clock discipline algorithm is designed to avoid large noise
spikes that might occur on a congested network or access line. If
an offset sample exceeds the step threshold, it is ignored and a
timer started. If a later sample is below the step threshold, the
counter is reset. However, if the counter is greater than the
stepout interval, which defaults to 900 s, the next sample will
step or slew the time as directed. The stepout threshold can be
changed by the <tt>tinker stepout</tt> command discribed on the <a
href="miscopt.htm">Miscellaneous Options</a> page.</p>
The host addresses shown in the <TT>remote</TT> column should agree with
the DNS entries in the configuration file, plus any peers not mentioned
in the file at the same or lower than your stratum that happen to be
configured to peer with you. Be prepared for surprises in cases where
the peer has multiple addresses or multiple names. The <TT>refid</TT>
entry shows the current source of synchronization for each peer, while
the <TT>st</TT> reveals the stratum, <TT>t</TT> the type (<TT>u</TT> =
unicast, <TT>m</TT> = multicast, <TT>l</TT> = local, <TT>-</TT> = don't
know), and <TT>poll</TT> the polling interval in seconds. The
<TT>when</TT> entry shows the time since the peer was last heard,
normally in seconds, while the <TT>reach</TT> entry shows the status of
the reachability register (see RFC-1305) in octal. The remaining entries
show the latest delay, offset and dispersion computed for the peer in
milliseconds. Note that in NTP Version 4 the dispersion entry includes
only the RMS error component; earlier versions included all components.
<p>If, as discussed later on this page, for some reason the
hardware clock oscillator frequency error is very large, the time
errors upon first startup of the daemon may increase over time
until exceeding the step threshold, which requires another step
correction. However, due to provisions that reduce vulnerability to
noise spikes, the second correction will not be done until after
the stepout threshold. When the frequency error is very large, it
may take a number of cycles like this until converging on the
nominal frequency correction. After this, the correction is written
to the <tt>ntp.drift</tt> file, which is read upon subsequent
restarts, so the herky-jerky cycles should not recur.</p>
<P>The tattletale character at the left margin displays the
<h4>Verifying Correct Operation</h4>
<p>After starting the daemon, run the <tt>ntpq</tt> program using
the <tt>-n</tt> switch, which will avoid possible distractions due
to name resolution problems. Use the <tt>pe</tt> command to display
a billboard showing the status of configured peers and possibly
other clients poking the daemon. After operating for a few minutes,
the display should be something like:</p>
<pre>
ntpq&gt; pe
remote refid st t when poll reach delay offset jitter
=====================================================================
-isipc6.cairn.ne .GPS1. 1 u 18 64 377 65.592 -5.891 0.044
+saicpc-isiepc2. pogo.udel.edu 2 u 241 128 370 10.477 -0.117 0.067
+uclpc.cairn.net pogo.udel.edu 2 u 37 64 177 212.111 -0.551 0.187
*pogo.udel.edu .GPS1. 1 u 95 128 377 0.607 0.123 0.027
</pre>
<p>The host names or addresses shown in the <tt>remote</tt> column
correspond to the server and peer entries listed in the
configuration file; however, the DNS names might not agree if the
names listed are not the canonical DNS names. The <tt>refid</tt>
column shows the current source of synchronization, while the <tt>
st</tt> column reveals the stratum, <tt>t</tt> the type (<tt>u</tt>
= unicast, <tt>m</tt> = multicast, <tt>l</tt> = local, <tt>-</tt> =
don't know), and <tt>poll</tt> the poll interval in seconds. The
<tt>when</tt> column shows the time since the peer was last heard
in seconds, while the <tt>reach</tt> column shows the status of the
reachability register (see RFC-1305) in octal. The remaining
entries show the latest delay, offset and jitter in milliseconds.
Note that in NTP Version 4 what used to be the <tt>dispersion</tt>
column has been replaced by the <tt>jitter</tt> column.</p>
<p>The tattletale symbol at the left margin displays the
synchronization status of each peer. The currently selected peer is
marked <TT>*</TT>, while additional peers designated acceptable for
synchronization, but not currently selected, are marked <TT>+</TT>.
Peers marked <TT>*</TT> and <TT>+</TT> are included in a weighted
average computation to set the local clock; the data produced by peers
marked with other symbols are discarded. See the <TT>ntpq</TT>
documentation for the meaning of these symbols.
marked <tt>*</tt>, while additional peers designated acceptable for
synchronization, but not currently selected, are marked <tt>+</tt>.
Peers marked <tt>*</tt> and <tt>+</tt> are included in the weighted
average computation to set the local clock; the data produced by
peers marked with other symbols are discarded. See the <tt>
ntpq</tt> page for the meaning of these symbols.</p>
<P>Additional details for each peer separately can be determined by the
following procedure. First, use the <TT>as</TT> command to display an
index of association identifiers, such as
<p>Additional details for each peer separately can be determined by
the following procedure. First, use the <tt>as</tt> command to
display an index of association identifiers, such as</p>
<PRE>ntpq>as
ind assID status conf reach auth condition last_event cnt
=========================================================
1 11670 7414 no yes ok candidate reachable 1
2 11673 7614 no yes ok sys.peer reachable 1
3 11833 7314 no yes ok outlyer reachable 1
4 11868 7414 no yes ok candidate reachable 1
</PRE>
<pre>
ntpq&gt; as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 50252 f314 yes yes ok outlyer reachable 1
2 50253 f414 yes yes ok candidat reachable 1
3 50254 f414 yes yes ok candidat reachable 1
4 50255 f614 yes yes ok sys.peer reachable 1
</pre>
Each line in this billboard is associated with the corresponding line
the <TT>pe</TT> billboard above. Next, use the <TT>rv</TT> command and
the respective identifier to display a detailed synopsis of the selected
peer, such as
<p>Each line in this billboard is associated with the corresponding
line in the <tt>pe</tt> billboard above. The <tt>assID</tt> shows
the unique identifier for each mobilized association, while the
<tt>status</tt> column shows the peer status word in hex, as
defined in the NTP specification. Next, use the <tt>rv</tt> command
and the respective <tt>assID</tt> identifier to display a detailed
synopsis for the selected peer, such as</p>
<PRE>ntpq>rv 11670
status=7414 reach, auth, sel_sync, 1 event, event_reach
srcadr=128.4.2.6, srcport=123, dstadr=128.4.2.7, dstport=123, keyid=1,
stratum=2, precision=-10, rootdelay=362.00, rootdispersion=21.99,
refid=132.249.16.1,
reftime=af00bb44.849b0000 Fri, Jan 15 1993 4:25:40.517,
delay= 9.89, offset= 16.28,
dispersion=23.25, reach=373, valid=8,
hmode=2, pmode=1, hpoll=8, ppoll=10, leap=00, flash=0x0,
org=af00bb48.31a90000 Fri, Jan 15 1993 4:25:44.193,
rec=af00bb48.305e3000 Fri, Jan 15 1993 4:25:44.188,
xmt=af00bb1e.16689000 Fri, Jan 15 1993 4:25:02.087,
filtdelay= 16.40 9.89 140.08 9.63 9.72 9.22 10.79 122.99,
filtoffset= 13.24 16.28 -49.19 16.04 16.83 16.49 16.95 -39.43,
filterror= 16.27 20.17 27.98 31.89 35.80 39.70 43.61 47.52
</PRE>
<pre>
ntpq&gt; rv 50253
status=f414 reach, conf, auth, sel_candidat, 1 event, event_reach,
srcadr=saicpc-isiepc2.cairn.net, srcport=123, dstadr=140.173.1.46,
dstport=123, keyid=3816249004, stratum=2, precision=-27,
rootdelay=10.925, rootdispersion=12.848, refid=pogo.udel.edu,
reftime=bd11b225.133e1437 Sat, Jul 8 2000 13:59:01.075, delay=10.550,
offset=-1.357, jitter=0.074, dispersion=1.444, reach=377, valid=7,
hmode=1, pmode=1, hpoll=6, ppoll=7, leap=00, flash=00 ok,
org=bd11b23c.01385836 Sat, Jul 8 2000 13:59:24.004,
rec=bd11b23c.02dc8fb8 Sat, Jul 8 2000 13:59:24.011,
xmt=bd11b21a.ac34c1a8 Sat, Jul 8 2000 13:58:50.672,
filtdelay= 10.45 10.50 10.63 10.40 10.48 10.43 10.49 11.26,
filtoffset= -1.18 -1.26 -1.26 -1.35 -1.35 -1.42 -1.54 -1.81,
filtdisp= 0.51 1.47 2.46 3.45 4.40 5.34 6.33 7.28,
hostname="miro.time.saic.com", publickey=3171359012, pcookie=0x6629adb2,
hcookie=0x61f99cdb, initsequence=61, initkey=0x287b649c,
timestamp=3172053041
</pre>
A detailed explanation of the fields in this billboard are beyond the
scope of this discussion; however, most variables defined in the
specification RFC-1305 can be found. The most useful portion for
debugging is the last three lines, which give the roundtrip delay, clock
offset and dispersion for each of the last eight measurement rounds, all
in milliseconds. Note that the dispersion, which is an estimate of the
error, increases as the age of the sample increases. From these data, it
is usually possible to determine the incidence of severe packet loss,
network congestion, and unstable local clock oscillators. There are no
hard and fast rules here, since every case is unique; however, if one or
more of the rounds show zeros, or if the clock offset changes
dramatically in the same direction for each round, cause for alarm
exists.
<p>A detailed explanation of the fields in this billboard are
beyond the scope of this discussion; however, most variables
defined in the NTP Version 3 specification RFC-1305 are available
along with others defined for NTP Version 4. This particular
example was chosen to illustrate probably the most complex
configuration involving symmetric modes and public-key
cryptography. As the result of debugging experience, the names and
values of these variables may change from time to time. An
explanation of the current set is on the <tt>ntpq</tt> page.</p>
<P>Finally, the state of the local clock can be determined using the
<TT>rv</TT> command (without the argument), such as
<p>A useful indicator of miscellaneous problems is the <tt>
flash</tt> value, which reveals the state of the various sanity
tests on incoming packets. There are currently eleven bits, one for
each test, numbered from the right, which is for test 1. If the
test fails, the corresponding bit is set to one and zero otherwise.
If any bit is set following each processing step, the packet is
discarded. The meaning of each test is described on the <tt>
ntpq</tt> page.</p>
<PRE>ntpq>rv
status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg
system="UNIX", leap=00, stratum=2, rootdelay=280.62,
rootdispersion=45.26, peer=11673, refid=128.4.1.20,
reftime=af00bb42.56111000 Fri, Jan 15 1993 4:25:38.336,
poll=8, clock=af00bbcd.8a5de000 Fri, Jan 15 1993 4:27:57.540,
phase=21.147, freq=13319.46, compliance=2
</PRE>
<p>The three lines identified as <tt>filtdelay</tt>, <tt>
filtoffset</tt> and <tt>filtdisp</tt> reveal the roundtrip delay,
clock offset and dispersion for each of the last eight measurement
rounds, all in milliseconds. Note that the dispersion, which is an
estimate of the error, increases as the age of the sample
increases. From these data, it is usually possible to determine the
incidence of severe packet loss, network congestion, and unstable
local clock oscillators. There are no hard and fast rules here,
since every case is unique; however, if one or more of the rounds
show large values or change radically from one round to another,
the network is probably congested or lossy.</p>
The most useful data in this billboard show when the clock was last
adjusted <TT>reftime</TT>, together with its status and most recent
exception event. An explanation of these data is in the specification
RFC-1305.
<p>Once the daemon has set the local clock, it will continuously
track the discrepancy between local time and NTP time and adjust
the local clock accordingly. There are two components of this
adjustment, time and frequency. These adjustments are automatically
determined by the clock discipline algorithm, which functions as a
hybrid phase/frequency feedback loop. The behavior of this
algorithm is carefully controlled to minimize residual errors due
to network jitter and frequency variations of the local clock
hardware oscillator that normally occur in practice. However, when
started for the first time, the algorithm may take some time to
converge on the intrinsic frequency error of the host machine.</p>
<P>When nothing seems to happen in the <TT>pe</TT> billboard after some
minutes, there may be a network problem. The most common network problem
is an access controlled router on the path to the selected peer. No
known public NTP time server selectively restricts access at this time,
although this may change in future; however, many private networks do.
It also may be the case that the server is down or running in
unsynchronized mode due to a local problem. Use the <TT>ntpq</TT>
program to spy on its own variables in the same way you can spy on your
own.
<p>The state of the local clock itself can be determined using the
<tt>rv</tt> command (without the argument), such as</p>
<P>Once the daemon has set the local clock, it will continuously track
the discrepancy between local time and NTP time and adjust the local
clock accordingly. There are two components of this adjustment, time and
frequency. These adjustments are automatically determined by the clock
discipline algorithm, which functions as a hybrid phase/frequency
feedback loop. The behavior of this algorithm is carefully controlled to
minimize residual errors due to network jitter and frequency variations
of the local clock hardware oscillator that normally occur in practice.
However, when started for the first time, the algorithm may take some
time to converge on the intrinsic frequency error of the host machine.
<pre>
ntpq&gt; rv
status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd 4.0.99j4-r Fri Jul 7 23:38:17 GMT 2000 (1)",
processor="i386", system="FreeBSD3.4-RELEASE", leap=00, stratum=2,
precision=-27, rootdelay=0.552, rootdispersion=12.532, peer=50255,
refid=pogo.udel.edu,
reftime=bd11b220.ac89f40a Sat, Jul 8 2000 13:58:56.673, poll=6,
clock=bd11b225.ee201472 Sat, Jul 8 2000 13:59:01.930, state=4,
phase=0.179, frequency=44.298, jitter=0.022, stability=0.001,
hostname="barnstable.udel.edu", publickey=3171372095, params=3171372095,
refresh=3172016539
</pre>
<P>It has sometimes been the experience that the local clock oscillator
frequency error is too large for the NTP discipline algorithm, which can
correct frequency errors as large as 43 seconds per day. There are two
possibilities that may result in this problem. First, the hardware time-
of-year clock chip must be disabled when using NTP, since this can
destabilize the discipline process. This is usually done using the
<TT><A HREF="tickadj.htm">tickadj</A></TT> program and the <TT>-s</TT>
command line argument, but other means may be necessary. For instance,
in the Sun Solaris kernel, this can be done using a command in the
system startup file.
<p>An explanation about most of these variables is in the RFC-1305
specification. The most useful ones include <tt>clock</tt>, which
shows when the clock was last adjusted, and <tt>reftime</tt>, which
shows when the server clock of <tt>refid</tt> was last adjusted.
The <tt>version</tt>, <tt>processor</tt> and <tt>system</tt> values
are very helpful when included in bug reports. The mean millisecond
time offset (<tt>phase</tt>) and deviation (<tt>jitter</tt>)
monitor the clock quality, while the mean PPM frequency offset
(<tt>frequency</tt>) and deviation (<tt>stability</tt>) monitor the
clock stability and serve as a useful diagnostic tool. It has been
the experience of NTP operators over the years that these data
represent useful environment and hardware alarms. If the
motherboard fan freezes up or some hardware bit sticks, the system
clock is usually the first to notice it.</p>
<P>Normally, the daemon will adjust the local clock in small steps in
such a way that system and user programs are unaware of its operation.
The adjustment process operates continuously as long as the apparent
clock error exceeds 128 milliseconds, which for most Internet paths is a
quite rare event. If the event is simply an outlyer due to an occasional
network delay spike, the correction is simply discarded; however, if the
apparent time error persists for an interval of about 20 minutes, the
local clock is stepped to the new value (as an option, the daemon can be
compiled to slew at an accelerated rate to the new value, rather than be
stepped). This behavior is designed to resist errors due to severely
congested network paths, as well as errors due to confused radio clocks
upon the epoch of a leap second.
<p>Among the new variables added for NTP Version 4 are the <tt>
hostname</tt>, <tt>publickey</tt>, <tt>params</tt> and <tt>
refresh</tt>, which are used for the Autokey public-key
cryptography described on the <a href="authopt.htm">Authentication
Options</a> page. The values show the filestamps, in NTP seconds,
that the associated values were created. These are useful in
diagnosing problems with cryptographic key consistency and ordering
principles.</p>
<H4>Debugging Checklist</H4>
<p>When nothing seems to happen in the <tt>pe</tt> billboard after
some minutes, there may be a network problem. One common network
problem is an access controlled router on the path to the selected
peer or an access controlled server using methods described on the
<a href="accopt.htm">Access Control Options</a> page. Another
common problem is that the server is down or running in
unsynchronized mode due to a local problem. Use the <tt>ntpq</tt>
program to spy on the server variables in the same way you can spy
on your own.</p>
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>Normally, the daemon will adjust the local clock in small steps
in such a way that system and user programs are unaware of its
operation. The adjustment process operates continuously as long as
the apparent clock error exceeds the step threshold for a period
longer than the stepout threshold, which for most Internet paths is
a very rare event. If the event is simply an outlyer due to an
occasional network delay spike, the correction is simply discarded;
however, if the apparent time error persists for longer than the
stepout threshold of about 17 minutes, the local clock is stepped
or slewed to the new value as directed. This behavior is designed
to resist errors due to severely congested network paths, as well
as errors due to confused radio clocks upon the epoch of a leap
second.</p>
<OL>
<h4>Special Problems</h4>
<P><LI>Verify the <TT>/etc/services</TT> file host machine is configured
to
accept UDP packets on the NTP port 123. NTP is specifically designed to
use UDP and does not respond to TCP.</LI>
<p>The frequency tolerance of computer clock oscillators can vary
widely, which can put a strain on the daemon's ability to
compensate for the intrinsic frequency error. While the daemon can
handle frequency errors up to 500 parts-per-million (PPM), or 43
seconds per day, values much above 100 PPM reduce the headroom and
increase the time to learn the particular value and record it in
the <tt>ntp.drift</tt> file. In extreme cases before the particular
oscillator frequency error has been determined, the residual system
time offsets can sweep from one extreme to the other of the 128-ms
tracking window only for the behavior to repeat at 900-s intervals
until the measurements have converged.</p>
<P><LI>Check the system log for <TT>ntpd</TT> messages about
configuration
errors, name-lookup failures or initialization problems.</LI>
<p>In order to determine if excessive frequency error is a problem,
observe the nominal <tt>filtoffset</tt> values for a number of
rounds and divide by the poll interval. If the result is something
approaching 500 PPM, there is a good chance that NTP will not work
properly until the frequency error is reduced by some means. A
common cause is the hardware time-of-year (TOY) clock chip, which
must be disabled when NTP disciplines the software clock. For some
systems this can be done using the <tt><a href="tickadj.htm">
tickadj</a></tt> utility and the <tt>-s</tt> command line argument.
For other systems this can be done using a command in the system
startup file.</p>
<P><LI>Using the <TT>ntpdc</TT> program and <TT>iostats</TT> command,
verify that the received packets and packets sent counters are
incrementing. If the packets send counter does not increment and the
configuration file includes designated servers, something may be wrong
in the network configuration of the ntpd host. If this counter does
increment and packets are actually being sent to the network, but the
received packets counter does not increment, something may be wrong in
the network or the server may not be responding.</LI>
<p>If the TOY chip is not the cause, the problem may be that the
hardware clock frequency may simply be too slow or two fast. In
some systems this might require tweaking a trimmer capacitor on the
motherboard. For other systems the clock frequency can be adjusted
in increments of 100 PPM using the <tt>tickadj</tt> utility and the
<tt>-t</tt> command line argument. Note that the <tt>tickadj</tt>
alters certain kernel variables and, while the utility attempts to
figure out an acceptable way to do this, there are many cases where
<tt>tickadj</tt> is incompatible with a running kernel.</p>
<P><LI>If both the packets sent counter and received packets counter do
increment, but the <TT>rec</TT> timestamp in the <TT>pe</TT> billboard
shows far from the current date, received packets are probably being
discarded for some reason. There is a handy, undocumented state variable
<TT>flash</TT> visible in the <TT>pe</TT>billboard. The value is in hex
and normally has the value zero (OK). However, if something is wrong,
the bits of this variable, reading from the right, correspond to the
sanity checks listed in Section 3.4.3 of the NTP specification <A
HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps"
>RFC-1305</A>. A bit other than zero indicates the associated sanity
check failed.</LI>
<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.htm">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 configure to generate what is called a
kiss-of-death (KOD) packet and send to the client. In case of
outright access denied, the KOD is the response to the first client
packet. In this case the client association is permanently disabled
and the access denied bit (test 4) is set in the flash peer
variable mentioned above and a message is sent to the system
log.</p>
<P><LI>If the <TT>org, rec</TT> and <TT>xmt</TT> timestamps in the
<TT>pe</TT> billboard appear current, but the local clock is not set, as
indicated by a stratum number less than 16 in the <TT>rv</TT> command
without arguments, verify that valid clock offset, roundtrip delay and
dispersion are displayed for at least one peer. The clock offset should
be less than 1000 seconds, the roundtrip delay less than one second and
the dispersion less than one second.</LI>
<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.htm">Access Control Options</a> page for further
informatin.</p>
<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><LI>While the algorithm can tolerate a relatively large frequency
error (up to 500 parts per million or 43 seconds per day), various
configuration errors (and in some cases kernel bugs) can exceed this
tolerance, leading to erratic behavior. This can result in frequent loss
of synchronization, together with wildly swinging offsets. Use the
<TT>ntpdc</TT> program (or temporary configuration file) and <TT>disable
pll</TT> command to prevent the <TT>ntpd</TT> daemon from setting the
clock. Using the <TT>ntpq</TT> or <TT>ntpdc</TT> programs, watch the
apparent offset as it varies over time to determine the intrinsic
frequency error. If the error increases by more than 22 milliseconds per
64-second poll interval, the intrinsic frequency must be reduced by some
means. The easiest way to do this is with the <TT><A
HREF="tickadj.htm">tickadj</A></TT> program and the <TT>-t</TT>
command line argument.</LI>
<p>The recommended 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>
</OL>
<h4>Debugging Checklist</h4>
If the <tt>ntpq</tt> or <tt>ntpdc</tt> programs do not show that
messages are being received by the daemon or that received messages
do not result in correct synchronization, verify the following:
<ol>
<li style="list-style: none"></li>
<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 style="list-style: none"></li>
<li>Check the system log for <tt>ntpd</tt> messages about
configuration errors, name-lookup failures or initialization
problems.</li>
<li style="list-style: none"></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>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 style="list-style: none"></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.</li>
<li style="list-style: none"></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 style="list-style: none"></li>
<li>If all else fails, see the FAQ and/or the discussion and
briefings at <a href="http://www.eecis.udel.edu/~mills/ntp.htm">
Network Time Synchronization Project.</a></li>
</ol>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

256
contrib/ntp/html/driver1.htm
View File

@ -1,157 +1,157 @@
<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>Undisciplined Local Clock
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<meta http-equiv="Content-Type" content=
"text/html; charset=iso-8859-1">
<meta name="GENERATOR" content=
"Mozilla/4.01 [en] (Win95; I) [Netscape]">
<title>Undisciplined Local Clock</title>
</head>
<body>
<h3>Undisciplined Local Clock</h3>
<H3>
Undisciplined Local Clock</H3>
<hr>
<h4>Synopsis</h4>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.1.<I>u</I>
<BR>Reference ID: <TT>LCL</TT>
<BR>Driver ID: <TT>LOCAL</TT>
<H4>
Description</H4>
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 (not multicast) mode to distribute time.
Address: 127.127.1.<i>u</i> <br>
Reference ID: <tt>LCL</tt> <br>
Driver ID: <tt>LOCAL</tt>
<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 configure this driver at a stratum
greater than any other likely sources of time (say 3 or 4) to prevent the
server taking over when legitimate sources are still available.
<h4>Description</h4>
<P>A third application for this driver is when an external discipline source
is available, such as the NIST <TT>lockclock</TT> program, which synchronizes
the local clock via a telephone modem and the NIST Automated Computer Time
Service (ACTS), or the Digital Time Synchronization Service (DTSS), which
runs on DCE machines. In this case the stratum should be set at zero, indicating
a bona fide stratum-1 source. In the case of DTSS, the local clock can
have a rather large jitter, depending on the interval between corrections
and the intrinsic frequency error of the clock oscillator. In extreme cases,
this can cause clients to exceed the 128-ms slew window and drop off the
NTP subnet.
<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 (not multicast) mode to distribute time.</p>
<P>In the case where a NTP time server is synchronized to some device or
protocol that is not external to the NTP daemon itself, some means should
be provided to pass such things as error and health values to the NTP daemon
for dissemination to its clients. If this is not done, there is a very
real danger that the device or protocol could fail and with no means to
tell NTP clients of the mishap. When ordinary Unix system calls like <TT>adjtime()</TT>
are used to discipline the kernel clock, there is no obvious way this can
be done without modifying the code for each case. However, when a modified
kernel with the <TT>ntp_adjtime()</TT> system call&nbsp; is available,
that routine can be used for the same purpose as the <TT>adjtime()</TT>
routine and in addition provided with the estimated error, maximum error,
and leap-indicator values. This is the preferred way to synchronize the
kernel clock and pass information to the NTP clients.
<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 configure this driver at a stratum greater than any other
likely sources of time (say 3 or 4) to prevent the server taking
over when legitimate sources are still available.</p>
<P>In the default mode the behavior of the clock selection algorithm is
modified when this driver is in use. The algorithm is designed so that
this driver will never be selected unless no other discipline source is
available. This can be overridden with the <TT>prefer</TT> keyword of the
<TT>server</TT> configuration command, in which case only this driver will
be selected for synchronization and all other discipline sources will be
ignored. This behavior is intended for use when an external discipline
source controls the system clock. See the <A HREF="prefer.htm">Mitigation
Rules and the <TT>prefer</TT> Keyword </A>page for a detailed description
of the exact behavior.
<p>A third application for this driver is when an external
discipline source is available, such as the NIST <tt>lockclock</tt>
program, which synchronizes the local clock via a telephone modem
and the NIST Automated Computer Time Service (ACTS), or the Digital
Time Synchronization Service (DTSS), which runs on DCE machines. In
this case the stratum should be set at zero, indicating a bona fide
stratum-1 source. In the case of DTSS, the local clock can have a
rather large jitter, depending on the interval between corrections
and the intrinsic frequency error of the clock oscillator. In
extreme cases, this can cause clients to exceed the 128-ms slew
window and drop off the NTP subnet.</p>
<P>The stratum for this driver is set at 3 by default, but can be changed
by the <TT>fudge</TT> configuration command and/or the <TT>ntpdc</TT> utility.
The reference ID is <TT>LCL</TT> by default, but can be changed using the
same mechanisms. <B>*NEVER*</B> configure this driver to operate at a stratum
which might possibly disrupt a client with access to a bona fide primary
server, unless the local clock oscillator is reliably disciplined by another
source. <B>*NEVER NEVER*</B> configure a server which might devolve to
an undisciplined local clock to use multicast mode.
<p>In the case where a NTP time server is synchronized to some
device or protocol that is not external to the NTP daemon itself,
some means should be provided to pass such things as error and
health values to the NTP daemon for dissemination to its clients.
If this is not done, there is a very real danger that the device or
protocol could fail and with no means to tell NTP clients of the
mishap. When ordinary Unix system calls like <tt>adjtime()</tt> are
used to discipline the kernel clock, there is no obvious way this
can be done without modifying the code for each case. However, when
a modified kernel with the <tt>ntp_adjtime()</tt> system call&nbsp;
is available, that routine can be used for the same purpose as the
<tt>adjtime()</tt> routine and in addition provided with the
estimated error, maximum error, and leap-indicator values. This is
the preferred way to synchronize the kernel clock and pass
information to the NTP clients.</p>
<P>This driver provides a mechanism to trim the local clock in both time
and frequency, as well as a way to manipulate the leap bits. The <TT>fudge
time1</TT> parameter adjusts the time (in seconds) and the <TT>fudge time2</TT>
parameter adjusts the frequency (in parts per million). Both parameters
are additive and operate only once; that is, each command (as from <TT>ntpdc</TT>)
adds signed increments in time or frequency to the nominal local clock
time and frequency.
<H4>
Monitor Data</H4>
No <TT>filegen clockstats</TT> monitor data are produced by this driver.
<H4>
Fudge Factors</H4>
<p>In the default mode the behavior of the clock selection
algorithm is modified when this driver is in use. The algorithm is
designed so that this driver will never be selected unless no other
discipline source is available. This can be overridden with the
<tt>prefer</tt> keyword of the <tt>server</tt> configuration
command, in which case only this driver will be selected for
synchronization and all other discipline sources will be ignored.
This behavior is intended for use when an external discipline
source controls the system clock. See the <a href="prefer.htm">
Mitigation Rules and the <tt>prefer</tt> Keyword</a> page for a
detailed description of the exact behavior.</p>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<p>The stratum for this driver is set at 3 by default, but can be
changed by the <tt>fudge</tt> configuration command and/or the <tt>
ntpdc</tt> utility. The reference ID is <tt>LCL</tt> by default,
but can be changed using the same mechanisms. <b>*NEVER*</b>
configure this driver to operate at a stratum which might possibly
disrupt a client with access to a bona fide primary server, unless
the local clock oscillator is reliably disciplined by another
source. <b>*NEVER NEVER*</b> configure a server which might devolve
to an undisciplined local clock to use multicast mode.</p>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<p>This driver provides a mechanism to trim the local clock in both
time and frequency, as well as a way to manipulate the leap bits.
The <tt>fudge time1</tt> parameter adjusts the time (in seconds)
and the <tt>fudge time2</tt> parameter adjusts the frequency (in
parts per million). Both parameters are additive and operate only
once; that is, each command (as from <tt>ntpdc</tt>) adds signed
increments in time or frequency to the nominal local clock time and
frequency.</p>
<DT>
<TT>time2 <I>time</I></TT></DT>
<h4>Monitor Data</h4>
<DD>
Specifies the frequency offset calibration factor, in parts per million,
with default 0.0.</DD>
No <tt>filegen clockstats</tt> monitor data are produced by this
driver.
<DT>
<TT>stratum <I>number</I></TT></DT>
<h4>Fudge Factors</h4>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 3.</DD>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<DT>
<TT>refid <I>string</I></TT></DT>
<dd>Specifies the time offset calibration factor, in seconds and
fraction, with default 0.0.</dd>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>LCL</TT>.</DD>
<dt><tt>time2 <i>time</i></tt></dt>
<DT>
<TT>flag1 0 | 1</TT></DT>
<dd>Specifies the frequency offset calibration factor, in parts per
million, with default 0.0.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>stratum <i>number</i></tt></dt>
<DT>
<TT>flag2 0 | 1</TT></DT>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 3.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>refid <i>string</i></tt></dt>
<DT>
<TT>flag3 0 | 1</TT></DT>
<dd>Specifies the driver reference identifier, an ASCII string from
one to four characters, with default <tt>LCL</tt>.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>flag1 0 | 1</tt></dt>
<DT>
<TT>flag4 0 | 1</TT></DT>
<dd>Not used by this driver.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<P>Additional Information
<dt><tt>flag3 0 | 1</tt></dt>
<P><A HREF="refclock.htm">Reference Clock Drivers</A></DL>
<dd>Not used by this driver.</dd>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
</dl>
<p>Additional Information</p>
<p><a href="refclock.htm">Reference Clock Drivers</a></p>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

202
contrib/ntp/html/driver20.htm
View File

@ -1,39 +1,46 @@
<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>Generic NMEA GPS Receiver
</TITLE>
</HEAD>
<BODY>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22 i586) [Netscape]">
<title>Generic NMEA GPS Receiver
</title>
</head>
<body>
<H3>
Generic NMEA GPS Receiver</H3>
<h3>
Generic NMEA GPS Receiver</h3>
<HR>
<H4>
Synopsis</H4>
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 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver supports GPS receivers with the <TT>$GPRMC</TT> NMEA output string.
The driver expect the receiver to be set up to transmit a <TT>$GPRMC</TT>
<hr>
<h4>
Synopsis</h4>
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 baud, 8-bits, no parity
<br>Features: <tt>tty_clk</tt>
<h4>
Description</h4>
This driver supports GPS receivers with the <tt>$GPRMC</tt> NMEA output
string by default.&nbsp; Alternately the <tt>$GPGGA</tt> or <tt>$GPGLL
</tt>may
be selected.
<br>The driver expects the receiver to be set up to transmit a <tt>$GPRMC</tt>
message every second.
<P>The accuracy depend on the receiver used. Inexpesive GPS models are
available with a claimed PPS signal accuracy of 1 <FONT FACE="Symbol">m</FONT>s
<p>The accuracy depend on the receiver used. Inexpesive 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>If the Operating System supports the PPSAPI, RFC-2783, it will be used.
<br>&nbsp;
<p>The various GPS sentences that this driver recognises look like this:
<br>(others quietly ignored)
<pre><tt>$GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC&lt;cr>&lt;lf>
$GPGLL,LAT,LAT_REF,LONG,LONG_REF,POS_UTC,POS_STAT*CC&lt;cr>&lt;lf>
$GPGGA,POS_UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CC&lt;cr>&lt;lf>
<P>The $GPRMC message that the GPS transmits look like this:
<PRE>$GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC&lt;cr>&lt;lf>
&nbsp; POS_UTC&nbsp; - UTC of position. Hours, minutes and seconds. (hhmmss)
&nbsp; POS_UTC&nbsp; - UTC of position. 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)
@ -44,88 +51,111 @@ of the serial interface and operating system.
&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, >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; CC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Checksum (optional)
&nbsp; &lt;cr>&lt;lf> - Sentence terminator.</PRE>
The driver will send a <TT>$PMOTG,RMC,0000*1D&lt;cr>&lt;lf></TT> message
each time a <TT>$GPRMC</TT> string is needed. This is not needed on most
GPS receivers because they automatically send the <TT>$GPRMC</TT> string
every second and will only work on GPS receivers that understand the <TT>$PMOTG</TT>
&nbsp; &lt;cr>&lt;lf> - Sentence terminator.</tt></pre>
Alternate GPS sentences (other than <tt>$GPRMC</tt> - the default) may
be enabled by setting the relevent bits of 'mode' in the server configuration
line
<br>&nbsp;* server 127.127.20.x mode X
<br>&nbsp;&nbsp;&nbsp; bit 0 - enables RMC&nbsp;&nbsp;&nbsp; ( value =
1)
<br>&nbsp;&nbsp;&nbsp; bit 1 - enables GGA&nbsp;&nbsp;&nbsp; ( value =
2)
<br>&nbsp;&nbsp;&nbsp; bit 2 - enables GLL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
( value = 4)
<br>multiple sentences may be selected
<br>&nbsp;
<p>The driver will send a <tt>$PMOTG,RMC,0000*1D&lt;cr>&lt;lf></tt> message
each time a <tt>$GPRMC</tt> string is needed. This is not needed on most
GPS receivers because they automatically send the <tt>$GPRMC</tt> string
every second and will only work on GPS receivers that understand the <tt>$PMOTG</tt>
string. Others will just ignore it.
<H4>
Setting up the Garmin GPS-25XL</H4>
<h4>
Setting up the Garmin GPS-25XL</h4>
Switch off all output with by sending it the following string.
<PRE>"$PGRMO,,2&lt;cr>&lt;lf>"</PRE>
<pre>"$PGRMO,,2&lt;cr>&lt;lf>"</pre>
Now switch only $GPRMC on by sending it the following string.
<PRE>"$PGRMO,GPRMC,1&lt;cr>&lt;lf>"</PRE>
<pre>"$PGRMO,GPRMC,1&lt;cr>&lt;lf>"</pre>
On some systems the PPS signal isn't switched on by default. It can be
switched on by sending the following string.
<PRE>"$PGRMC,,,,,,,,,,,,2&lt;cr>&lt;lf>"</PRE>
<pre>"$PGRMC,,,,,,,,,,,,2&lt;cr>&lt;lf>"</pre>
<H4>
Monitor Data</H4>
The $GPRMC string that is used is written to the clockstats file.
<H4>
Fudge Factors</H4>
<h4>
Monitor Data</h4>
The GPS sentence(s) that is used is written to the clockstats file.
<h4>
Fudge Factors</h4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<dl>
<dt>
<tt>time1 <i>time</i></tt></dt>
<DD>
<dd>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
with default 0.0.</dd>
<DT>
<TT>time2 <I>time</I></TT></DT>
<dt>
<tt>time2 <i>time</i></tt></dt>
<DD>
Not used by this driver.</DD>
<dd>
Not used by this driver.</dd>
<DT>
<TT>stratum <I>number</I></TT></DT>
<dt>
<tt>stratum <i>number</i></tt></dt>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<dd>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd>
<DT>
<TT>refid <I>string</I></TT></DT>
<dt>
<tt>refid <i>string</i></tt></dt>
<DD>
<dd>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>GPS</TT>.</DD>
four characters, with default <tt>GPS</tt>.</dd>
<DT>
<TT>flag1 0 | 1</TT></DT>
<dt>
<tt>flag1 0 | 1</tt></dt>
<DD>
Not used by this driver.</DD>
<dd>
Not used by this driver.</dd>
<DT>
<TT>flag2 0 | 1</TT></DT>
<dt>
<tt>flag2 0 | 1</tt></dt>
<DD>
Not used by this driver.</DD>
<dd>
Specifies the PPS signal on-time edge: 0 for assert (default), 1 for clear.</dd>
<DT>
<TT>flag3 0 | 1</TT></DT>
<dt>
<tt>flag3 0 | 1</tt></dt>
<DD>
Not used by this driver.</DD>
<dd>
Controls the kernel PPS discipline: 0 for disable (default), 1 for enable.</dd>
<DT>
<TT>flag4 0 | 1</TT></DT>
<dt>
<tt>flag4 0 | 1</tt></dt>
<DD>
Not used by this driver.</DD>
<dd>
Not used by this driver.</dd>
<br>&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Additional Information
<p><a href="refclock.htm">Reference Clock Drivers</a></dl>
<P>Additional Information
<hr>
<address>
David L. Mills (mills@udel.edu)</address>
<P><A HREF="refclock.htm">Reference Clock Drivers</A></DL>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>
</body>
</html>

234
contrib/ntp/html/driver22.htm
View File

@ -1,129 +1,159 @@
<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>PPS Clock Discipline
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>PPS Clock Discipline</title>
</head>
<body>
<h3>PPS Clock Discipline</h3>
<H3>
PPS Clock Discipline</H3>
<hr>
<h4>Synopsis</h4>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.22.<I>u</I>
<BR>Reference ID: <TT>PPS</TT>
<BR>Driver ID: <TT>PPS</TT>
<BR>Serial Port: <TT>/dev/pps<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver furnishes an interface for pulse-per-second (PPS) signals produced
by a cesium clock, radio clock or related equipment. It can be used to
remove accumulated jitter and retime a secondary server when synchronized
to a primary server over a congested, wide-area network and before redistributing
the time to local clients.
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 interface
<P>In order for this driver to work, the local clock must be set to within
+-500 ms by another means, such as a radio clock or NTP itself. The PPS
signal is connected via a serial port and <A HREF="gadget.htm">gadget box</A>
consisting of a one-shot and RS232 level converter. When operated at 38.4
kbps with a SPARCstation IPC, this arrangement has a worst-case jitter
less than 26 us.
<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 operates only with the PPSAPI interface
proposed as an IETF standard. Note also that the <tt>pps</tt>
configuration command has been obsoleted by this driver.</p>
<P>There are three ways in which this driver can be used. The first way
uses the <TT>ppsclock</TT> line discipline and works only for the baseboard
serial ports of the Sun SPARCstation running SunOS 4.x. The PPS signal
is connected via the gadget box to the carrier detect (DCD) line of a serial
port. The signal is activated for this port by a <TT>fudge flag3 1</TT>
command following the <TT>server</TT> command in the configuration file.
This causes the <TT>ppsclock</TT> streams module to be configured for that
port and to capture a timestamp at the on-time transition of the PPS signal.
This driver then reads the timestamp directly by a designated <TT>ioctl()</TT>
system call. This provides the most accurate time and least jitter of any
other scheme. There is no need to configure a dedicated device for this
purpose, which ordinarily is the device used for the associated radio clock.
<h4>Description</h4>
<P>The second way uses the <TT>tty_clk</TT> line discipline and works for
any architecture supporting a serial port. If after a few seconds this
driver finds no <TT>ppsclock</TT> module configured, it attempts to open
a serial port device <TT>/dev/pps%d</TT>, where <TT>%d</TT> is the unit
number, and assign the <TT>tty_clk</TT> line discipline to it. If the line
discipline fails, no harm is done except the accuracy is reduced somewhat.
The pulse generator in the gadget box must be adjusted to produce a start
bit of length 26 usec at 38400 bps. Used with the <TT>tty_clk</TT> line
discipline, this produces an ASCII DEL character ('\377') followed by a
timestamp at the on-time transition of the PPS signal.
<p>This driver furnishes an interface for the pulse-per-second
(PPS) produced by a cesium clock, radio clock or related equipment.
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 less than a microsecond.</p>
<P>The third way involves an auxiliary radio clock driver which calls the
PPS driver with a timestamp captured by that driver. This use is documented
in the source code for the driver(s) involved.
<H4>
Fudge Factors</H4>
<p>While this driver can discipline the time and frequency relative
to the PPS source, it cannot number the seconds. For this purpose a
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
is marked as the prefer peer, as described in the <a href=
"prefer.htm">Mitigation Rules and the <tt>prefer</tt> Keyword</a>
page.</p>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<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 FreeBSD and
Linux and proprietary versions for Digital/Compaq Tru64 (Alpha),
Sun Solaris and Sun SunOS. See the <a href="pps.htm">
Pulse-per-second (PPS) Signal Interfacing</a> page for further
information.</p>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0. This parameter can be used to compensate for the UART
and OS delays. Allow about 247 us for UART delays at 38400 bps and about
1 ms for SunOS streams nonsense.</DD>
<p>The PPS source can be connected via a serial or parallel port,
depending on the hardware and operating system. The port can be
dedicated to the PPS source or shared with another device. 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 (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>
<DT>
<TT>time2 <I>time</I></TT></DT>
<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 is 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 and trimmed average
algorithms in the driver interface. As the result, performance with
minpoll and maxpoll configured at the minimum 4 (16s) is generally
better than the kernel PPS clock discipline. However, fudge flag 3
can be used to enable this discipline if necessary.</p>
<DD>
Not used by this driver.</DD>
<p>Note that the PPS source is considered reachable only if the
auxiliary source is the prefer peer, is reachable and is selected
to discipline the system clock. The stratum assigned to the PPS
source is automatically determined. If the auxiliary source is
unreachable or inoperative, the stratum is set to 16; otherwise it
is set to match the stratum of the auxiliary source. Since the
stratum is determined dynamically, it is not possible to assign
another stratum using the <tt>fudge</tt> command as in other
drivers.</p>
<DT>
<TT>stratum <I>number</I></TT></DT>
<h4>Fudge Factors</h4>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<DT>
<TT>refid <I>string</I></TT></DT>
<dd>Specifies the time offset calibration factor, in seconds and
fraction, with default 0.0.dd&gt;</dd>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>PPS</TT>.</DD>
<dt><tt>time2 <i>time</i></tt></dt>
<DT>
<TT>flag1 0 | 1</TT></DT>
<dd>Not used by this driver.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>stratum <i>number</i></tt></dt>
<DT>
<TT>flag2 0 | 1</TT></DT>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 0.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>refid <i>string</i></tt></dt>
<DT>
<TT>flag3 0 | 1</TT></DT>
<dd>Specifies the driver reference identifier, an ASCII string from
one to four characters, with default <tt>PPS</tt>.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>flag1 0 | 1</tt></dt>
<DT>
<TT>flag4 0 | 1</TT></DT>
<dd>Not used by this driver.</dd>
<DD>
Not used by this driver.</DD>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Specifies the PPS signal on-time edge: 0 for assert (default),
1 for clear.</dd>
<P>Additional Information
<dt><tt>flag3 0 | 1</tt></dt>
<P><A HREF="refclock.htm">Reference Clock Drivers</A></DL>
<dd>Controls the kernel PPS discipline: 0 for disable (default), 1
for enable.</dd>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
</dl>
<p>Additional Information</p>
<p><a href="refclock.htm">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>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

239
contrib/ntp/html/driver23.htm
View File

@ -1,87 +1,178 @@
<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>PTB Modem Time Service
</TITLE>
<META NAME="GENERATOR" CONTENT="Adobe PageMill 3.0 per Windows">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>PTB Modem Time Service </TITLE>
</HEAD>
<BODY>
<H3>
PTB Modem Time Service</H3>
<H3>PTB Modem Time Service and other European Laboratories Time
Services</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.23.<I>u</I>
<BR>Reference ID: <TT>PTB</TT>
<BR>Driver ID: <TT>ACTS_PTP</TT>
<BR>Serial Port: <TT>/dev/ptb<I>u</I></TT>; 1200 baud, 8-bits, no parity
<BR>Requires: <TT>/usr/include/sys/termios.h</TT> header file with modem
control
<H4>
Description</H4>
No further information available.
<H4>
Fudge Factors</H4>
<HR ALIGN=LEFT>
<H4>Synopsis</H4>
<P>Address: 127.127.23.<I>u</I> <BR>
Reference ID: <TT>PTB</TT> <BR>
Driver ID: <TT>ACTS_PTB</TT><BR>
Serial Port: <TT>/dev/ptb<I>u</I></TT>; 1200 baud, 8-bits, no
parity <BR>
Requires: <TT>/usr/include/sys/termios.h</TT> header file with
modem control</P>
<H4>Description</H4>
<P>This driver supports the PTB Automated Computer Time Service
(ACTS) and it is a modified version of the NIST ACTS driver so
see it for more informations..</P>
<P>It periodically dials a prespecified telephone number, receives
the PTB timecode data and calculates the local clock correction.
It designed primarily for use when neither a radio clock nor connectivity
to Internet time servers is available. For the best accuracy,
the individual telephone line/modem delay needs to be calibrated
using outside sources.</P>
<P>The only change between this driver and the NIST one is the
data format. Infact PTB data format is the following:</P>
<P><FONT SIZE="-1" FACE="Courier New">Data format<BR>
0000000000111111111122222222223333333333444444444455555555556666666666777777777
7<BR>
0123456789012345678901234567890123456789012345678901234567890123456789012345678
9<BR>
1995-01-23 20:58:51 MEZ 10402303260219950123195849740+40000500
*<BR>
A B C D EF G H IJ K L M N O P Q R S T U V W
XY Z&lt;CR&gt;&lt;LF&gt;<BR>
A year<BR>
B month<BR>
C day<BR>
D hour<BR>
E : normally<BR>
A for DST to ST switch first hour<BR>
B for DST to ST switch second hour if not marked in H<BR>
F minute<BR>
G second<BR>
H timezone<BR>
I day of week<BR>
J week of year<BR>
K day of year<BR>
L month for next ST/DST changes<BR>
M day<BR>
N hour<BR>
O UTC year<BR>
P UTC month<BR>
Q UTC day<BR>
R UTC hour<BR>
S UTC minute<BR>
T modified julian day (MJD)<BR>
U DUT1<BR>
V direction and month if leap second<BR>
W signal delay (assumed/measured)<BR>
X sequence number for additional text line in Y<BR>
Y additional text<BR>
Z on time marker (* - assumed delay / # measured delay)<BR>
&lt;CR&gt;!&lt;LF&gt; ! is second change !<BR>
</FONT><BR>
This format is an ITU-R Recommendation (ITU-R TF583.4) and is now available from the primary
timing centres of the following countries:
Austria, Belgium, Germany, Italy, The Netherlands, Poland, Portugal, Romania, Spain, Sweden,
Switzerland, Turkey, United Kingdom.
Some examples are:
</P>
<UL>
<LI>In Germany by Physikalisch-Technische Bundesanstalt (PTB)'s
timecode service. Phone number: +49 5 31 51 20 38.
</UL>
<BLOCKQUOTE>
<P>For more detail, see <A HREF="http://www.ptb.de/english/org/4/43/433/disse.htm">http://www.ptb.de/english/org/4/43/433/disse.htm</A></P>
</BLOCKQUOTE>
<UL>
<LI>In the UK by National Physical Laboratory (NPL)'s TRUETIME
service. Phone number: 0891 516 333
</UL>
<BLOCKQUOTE>
<P>For more detail, see <A HREF="http://www.npl.co.uk/npl/ctm/truetime.html">http://www.npl.co.uk/npl/ctm/truetime.html</A></P>
</BLOCKQUOTE>
<UL>
<LI>In Italy by Istituto Elettrotecnico Nazionale &quot;Galileo
Ferrais&quot; (IEN)'s CTD service. Phone number: 166 11 46
15
</UL>
<BLOCKQUOTE>
<P>For more detail, see <A HREF="http://www.ien.it/tf/time/Pagina42.html">http://www.ien.it/tf/time/Pagina42.html</A></P>
</BLOCKQUOTE>
<UL>
<LI>In Switzerland by Swiss Federal Office of Metrology 's timecode
service. Phone number: 031 323 32 25
</UL>
<BLOCKQUOTE>
<P>For more detail, see <A HREF="http://www.ofmet.admin.ch/de/labors/4/Zeitvert.html%20">http://www.ofmet.admin.ch/de/labors/4/Zeitvert.html
</A></P>
</BLOCKQUOTE>
<UL>
<LI>In Sweden by SP Swedish National Testing and Research Institute
's timecode service. Phone number: +46 33 415783
</UL>
<BLOCKQUOTE>
<P>For more detail, see <A HREF="http://www.sp.se/pne/ElectricalMetrology/ElMeteng/frameset.htm">http://www.sp.se/pne/ElectricalMetrology/ElMeteng/frameset.htm</A><BR>
<BR>
</P>
</BLOCKQUOTE>
<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 PTB.</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 drivert.</DD>
<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 PTB.
<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.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<P>Additional Information</P>
<P>A keyword in the ntp.conf file permits a direct connection
to a serial port of source of time like IEN CTD signal. It is
sufficient to use the string DIRECT in place of the phone number.</P>
<P>Example:</P>
<P><FONT FACE="Courier New">server 127.127.23.1</FONT></P>
<P><FONT FACE="Courier New">phone DIRECT</FONT></P>
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp; <HR ALIGN=LEFT></P>
<ADDRESS>by Marco Mascarello (masca@tf.ien.it) for David L. Mills
(mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

59
contrib/ntp/html/driver30.htm
View File

@ -17,31 +17,31 @@ Motorola Oncore GPS receiver</H3>
<H4>
Synopsis</H4>
Address: 127.127.30.0<BR>
Address: 127.127.30.<i>u</i><BR>
Reference ID: <TT>GPS</TT><BR>
Driver ID: ONCORE<BR>
Serial Port: <TT>/dev/oncore.serial.0</TT>; &nbsp;9600 baud, 8-bits,
Serial Port: <TT>/dev/oncore.serial.</TT><i>u</i>; &nbsp;9600 baud, 8-bits,
no parity.<BR>
PPS Port: <TT>/dev/oncore.pps.0</TT>;&nbsp; <TT>PPS_CAPTUREASSERT</TT>
required,&nbsp; <TT>PPS_OFFSETASSERT</TT> supported.
PPS Port: <TT>/dev/oncore.pps.</TT><i>u</i>;&nbsp; <TT>PPS_CAPTUREASSERT</TT>
required,&nbsp; <TT>PPS_OFFSETASSERT</TT> supported.<BR>
Configuration File: <TT>/etc/ntp.oncore<TT><i>u</i> or,
<TT>/etc/ntp.oncore.<TT><i>u</i>, or <TT>/etc/ntp.oncore<TT>.
<H4>
Description</H4>
This driver supports various models of the <A
HREF="http://www.mot.com/AECS/PNSB/products">Motorola Oncore GPS
receivers</A> as long as they support the <I>Motorola Binary
Protocol</I>.
This driver supports most models of the
<A HREF="http://www.mot.com/AECS/PNSB/products">Motorola Oncore GPS receivers</A>
(Basic, PVT6, VP, UT, UT+, GT, GT+, SL, M12),
as long as they support the <I>Motorola Binary Protocol</I>.
<P>The three most interesting versions of the Oncore are the "VP",&nbsp;
the "UT+",&nbsp;
and the "Remote" which is a prepackaged "UT+".&nbsp;
The "VP" is no longer available.
<P>The evaluation kit
<P>The three most interesting versions of the Oncore are the VP,
the UT+, and the "Remote" which is a prepackaged UT+.
The VP is no longer available.
The Motorola evaluation kit
can also be recommended, it interfaces to a PC straightaway, using the
serial (DCD) or parallel port for PPS input and packs the
receiver in a nice and sturdy box.
Two less expensive interface kits are available from
<A HREF="http://www.tapr.org">TAPR </A>.
<A HREF="http://www.tapr.org">TAPR</A>.
<BR>&nbsp;
<CENTER><TABLE NOSAVE >
@ -74,17 +74,27 @@ pulse-per-second output from the receiver.&nbsp; The serial data stream alone
does not provide precision time stamps (0-50msec variance, according to
the manual), whereas the PPS output is precise down to 50 nsec (1 sigma)
for the VP/UT models.
If you do not have the PPS signal available, then you should probably be using
the NMEA driver rather than the Oncore driver.
<P>The driver will use the "position hold" mode with
user provided coordinates,
the receivers built-in site-survey,
or a similar algorithm implemented in this driver.
or a similar algorithm implemented in this driver to determine the antenna position.
<H4>
Monitor Data</H4>
The driver is quite chatty on stdout if ntpd is run with
debugging.&nbsp;
A manual will be required though.
Additional information is written to the clockstats file, if configured.
The driver always puts a lot of useful information on the clockstats file,
and when run with debugging can be quite chatty on stdout.
When first starting to use the driver you should definitely review the information
written to the clockstats file to verify that the driver is running correctly.
<P>
In addition, on platforms supporting Shared Memory, all of the messages
received from the Oncore receiver are made available in shared memory for
use by other programs.
See the <A HREF=Oncore-SHMEM.htm> Oncore-SHMEM </A> manual page for
information on how to use this option.
For either debugging or using the SHMEM option, an Oncore Reference Manual
for the specific receiver in use will be required.
<H4>
Fudge Factors</H4>
@ -141,8 +151,9 @@ Not used by this driver.</DD>
Not used by this driver.</DD>
</DL>
<B>Additional Information</B>
<P>The driver has been tested on FreeBSD, Linux and SunOS.
<P>The driver was initially developed on FreeBSD, and has since been tested
on Linux, SunOS and Solaris.
<P><B>Configuration</B>
<P>There is a driver specific configuration file <TT>/etc/ntp.oncore</TT>
that contains information on the startup mode, the location of the GPS
receiver, an offset of the PPS signal from zero, and the cable delay.
@ -165,11 +176,11 @@ to UTC(GPS)&nbsp;with better than 50 nsec (1 sigma) accuracy.&nbsp; The
limiting factor will be the timebase of the computer and the precision
with which you can timestamp the rising flank of the
PPS&nbsp;signal.&nbsp;
Using FreeBSD,&nbsp; a FPGA&nbsp;based Timecounter/PPS&nbsp;interface
Using FreeBSD, a FPGA&nbsp;based Timecounter/PPS&nbsp;interface,
and an ovenized quartz oscillator, that performance has been reproduced.
&nbsp;For more details on this aspect:&nbsp; <A
HREF="http://phk.freebsd.dk/rover.html">Sub-Microsecond
timekeeping under FreeBSD</A>
timekeeping under FreeBSD</A>.
<HR>
<ADDRESS>
Poul-Henning Kamp (phk@FreeBSD.org),

62
contrib/ntp/html/driver34.htm
View File

@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<meta http-equiv="Content-Type" content="text/html; charset=iso8859-1">
<title>Dumb Clock</title>
<title>Ultralink Clock</title>
</head>
<body>
@ -10,18 +10,19 @@
<hr>
<h4>Synopsis</h4>
Address: 127.127.34.<i>u</i><br>
Reference ID: <TT>ULINK</TT><br>
Reference ID: <TT>WWVB</TT><br>
Driver ID: <tt>ULINK</tt><br>
Serial Port: <tt>/dev/ulink<i>u</i></tt>; 9600 bps, 8-bits,
Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 bps, 8-bits,
no parity<br>
<br>Features: <tt>(none)</tt>
<h4>Description</h4>
This driver supports the Ultralink Model 320 RS-232 powered WWVB receiver. PDF specs available on <a href="http://www.linuxfoundary.com">www.linuxfoundary.com</a>. While the unit may support them, this driver does nothing with leap seconds, quality codes, etc. (though it probably should).
This driver supports the Ultralink Model 320 RS-232 powered WWVB receiver. PDF specs available on <a href="http://www.ulio.com">www.ulio.com</a>.
This driver also supports the Model 330,331,332 decoders in both polled or continous time code mode. Leap second and quality are supported.
<P>Most of this code is originally from refclock_wwvb.c with thanks. Any mistakes are mine. Any improvements are welcome.
<hr>
<pre>
The timecode format is:
The Model 320 timecode format is:
<cr><lf>SQRYYYYDDD+HH:MM:SS.mmLT<cr>
@ -40,14 +41,55 @@ This driver supports the Ultralink Model 320 RS-232 powered WWVB receiver. PDF
L = Leap second pending at end of month -- 'I' = inset, 'D'=delete
T = DST <-> STD transition indicators
Note that this driver does not do anything with the L or T flags.
Note that this driver does not do anything with the T flag.
The M320 also has a 'U' command which returns UT1 correction information. It
is not used in this driver.
The M320 also has a 'U' command which returns UT1 correction information.
It is not used in this driver.
</pre>
<hr>
<pre>
The Model 33x timecode format is:
S9+D 00 YYYY+DDDUTCS HH:MM:SSl+5
Where:
S = sync indicator S insync N not in sync
the sync flag is WWVB decoder sync
nothing to do with time being correct
9+ = signal level 0 thru 9+ If over 9 indicated as 9+
D = data bit ( fun to watch but useless ;-)
space
00 = hours since last GOOD WWVB frame sync
space
YYYY = current year
+ = leap year indicator
DDD = day of year
UTC = timezone (always UTC)
S = daylight savings indicator
space
HH = hours
: = This is the REAL in sync indicator (: = insync)
MM = minutes
: = : = in sync ? = NOT in sync
SS = seconds
L = leap second flag
+5 = UT1 correction (sign + digit ))
This driver ignores UT1 correction,DST indicator,Leap year
and signal level.
</pre>
<hr>
<address><a href="mailto:dstrout@linuxfoundary.com">root</a></address>
<pre>
Fudge factors
flag1 polling enable (1=poll 0=no poll)
</pre>
<hr>
<address><a href="mailto:dstrout@linuxfoundary.com">mail</a></address>
<!-- hhmts start -->
Last modified: Tue Sep 14 05:53:08 EDT 1999
<!-- hhmts end -->

46
contrib/ntp/html/driver35.htm
View File

@ -1,4 +1,4 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Conrad parallel port radio clock</title>
@ -13,32 +13,30 @@
<p>Address: 127.127.35.<i>u</i><br>
Reference ID: <tt>PCF</tt><br>
Driver ID: <tt>PCF</tt><br>
Parallel Port: <tt>/dev/pcfclock<i>u</i></tt>
Parallel Port: <tt>/dev/pcfclocks/<i>u</i></tt> or <tt>/dev/pcfclock<i>u</i></tt>
</p>
<h4>Description</h4>
<p>This driver supports the parallel port radio clocks sold by <a
href="http://www.conrad-electronic.com/">Conrad Electronic</a> under
order numbers 967602 and 642002. The battery-powered radio clock is
put between a parallel port and your printer. It receives the legal
German time, which is either CET or CEST, from the DCF77 transmitter
and uses it to set internal quartz clock. The DCF77 transmitter is
located near to Frankfurt/Main and covers a radius of more than 1500
kilometers.
<p>This driver supports the parallel port radio clock sold by
<a href="http://www.conrad-electronic.com/">Conrad Electronic</a> under
order numbers 967602 and 642002. This clock is put between a parallel
port and your printer. It receives the legal German time, which is
either CET or CEST, from the DCF77 transmitter and uses it to set its
internal quartz clock. The DCF77 transmitter is located near to
Frankfurt/Main and covers a radius of more than 1500 kilometers.
<p>The driver requires that the pcfclock device driver be installed.
A device driver for Linux&nbsp;2.2 is available at
<a href="http://home.pages.de/~voegele/pcf.html">the pcfclock driver
page</a>.
<p>The pcfclock device driver is required in order to use this
reference clock driver. Currently device drivers for
<a href="http://home.pages.de/~voegele/pcf.html">Linux</a> and
<a href="http://schumann.cx/pcfclock/">FreeBSD</a> are available.</p>
<p>This driver uses C library functions to convert the received
timecode to UTC and thus requires that the local timezone be CET or
CEST. If your server is not located in Central Europe you have to set
the environment variable TZ to CET before starting <tt>ntpd</tt>.
</p>
<p>The driver uses C library functions to convert the received
timecode to UTC and therefore requires that the local timezone be
CET/CEST. If your server is not located in Central Europe, you have
to set the environment variable TZ to CET before <tt>ntpd</tt> is
started.</p>
<h4>Monitor Data</h4>
<p>Each timecode is written to the <tt>clockstats</tt> file in the format
@ -49,7 +47,7 @@ started.</p>
<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>
with default 0.1725.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
@ -66,7 +64,8 @@ four characters, with default <tt>PCF</tt>.</dd>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dd>If set to 1, the radio clock's synchronisation status bit is
ignored, ie the timecode is used without a check.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
@ -76,7 +75,6 @@ four characters, with default <tt>PCF</tt>.</dd>
</dl>
<hr>
<address>Andreas Voegele (andreas.voegele@gmx.de)</address>
<address>Andreas Voegele &lt;voegelas@users.sourceforge.net&gt;</address>
</body>
</html>

1217
contrib/ntp/html/driver36.htm
View File

File diff suppressed because it is too large Load Diff

191
contrib/ntp/html/driver38.htm Normal file
View File

@ -0,0 +1,191 @@
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>hopf clock drivers by ATLSoft</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" 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>
<hr>
<h2>
<font size=+1>Synopsis</font></h2>
<table border="0" cellpadding cellspacing width="100%">
<tr>
<td>
<table border="0" cellpadding="3" bgcolor="#C0C0C0">
<tr>
<td height="21">
<div align=right><tt>Address:&nbsp;&nbsp;</tt></div>
</td>
<td><b>127.127.38.<i>X</i></b></td>
</tr>
<tr>
<td height="1">
<div align=right><tt>Reference ID:&nbsp;&nbsp;</tt></div>
</td>
<td height="1"><a NAME="REFID"></a><b>.hopf. </b>(default)<b>, GPS, DCF</b></td>
</tr>
<tr>
<td height="21">
<div align=right><tt>Driver ID:&nbsp;&nbsp;</tt></div>
</td>
<td height="21"><b>HOPF_S</b></td>
</tr>
<tr>
<td height="16">
<div align=right><tt>Serial Port:&nbsp;&nbsp;</tt></div>
</td>
<td height="16"><b>/dev/hopfclock<i>X</i></b></td>
</tr>
<tr>
<td height="23">
<div align=right><tt><font size=+1>Serial I/O</font>:&nbsp;&nbsp;</tt></div>
</td>
<td height="23"><b>9600 baud, 8-bits, 1-stop, no parity</b></td>
</tr>
</table>
</td>
<td align="center"><img border="0" src="pic/fg6021.gif" width="238" height="207"></td>
</tr>
</table>
<hr>
<h2>
<font size=+1>Description</font></h2>
The <b>refclock_hopf_serial</b> driver supports <a href="http://www.hopf.com">hopf
electronic receivers</a> with serial Interface kompatibel 6021.
<br>Additional software and information about the software drivers is available
from: <a href="http://www.ATLSoft.de/ntp">http://www.ATLSoft.de/ntp</a>.
<br>Latest NTP driver source, executables and documentation is maintained
at: <a href="http://www.ATLSoft.de/ntp">http://www.ATLSoft.de/ntp</a>
<hr>
<h2>
<font size=+1>Operating System Compatibility</font></h2>
<p align="left">
The hopf clock driver has been tested on the following software and hardware
platforms:
<br>&nbsp;<table bgcolor="#C0C0C0">
<tr>
<td VALIGN=CENTER WIDTH="23%" nowrap>
<p align="left"><b>Platform</b></p>
</td>
<td VALIGN=CENTER nowrap>
<p align="left"><b>Operating System</b></p>
</td>
</tr>
<tr>
<td VALIGN=CENTER WIDTH="23%" nowrap>
<p align="left">i386 (PC)&nbsp;</p>
</td>
<td VALIGN=CENTER nowrap>
<p align="left">Linux</p>
</td>
</tr>
<tr>
<td nowrap>
<p align="left">i386 (PC)&nbsp;</p>
</td>
<td nowrap>
<p align="left">Windows NT</p>
</td>
</tr>
<tr>
<td nowrap>
<p align="left">i386 (PC)&nbsp;</p>
</td>
<center>
<td nowrap>Windows 2000</td>
</tr>
</table></center>
<hr>
<h2>
<font size=+1>O/S Serial Port Configuration</font></h2>
The driver attempts to open the device <b><tt><a href="#REFID">/dev/hopfclock<i>X</i></a></tt></b>
where <i><b>X</b></i> is the NTP refclock unit number as defined by the
LSB of the refclock address.&nbsp; Valid refclock unit numbers are 0 -
3.
<p>The user is expected to provide a symbolic link to an available serial
port device.&nbsp; This is typically performed by a command such as:
<blockquote><tt>ln -s /dev/ttyS0 /dev/hopfclock0</tt></blockquote>
Windows NT does not support symbolic links to device files.&nbsp;<br>
<b> COMx</b>:
is used by the driver, based on the refclock unit number, where <b> unit 1</b>
corresponds to <b> COM1</b>: and <b> unit 3</b> corresponds to <b>COM3</b>:
<br>&nbsp;
<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>
<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.</dd>
<dt>
<tt><font size=+1><a href="#REFID"><b>refid <i>string</i></b></a></font></tt></dt>
<dd>
Specifies the driver reference identifier, <b>GPS </b><i>or</i> <b> DCF</b>.</dd>
<dt>
<tt><font size=+1><b>flag1 0
| 1</b></font></tt></dt>
<dd>
When set to 1, driver sync's even if only crystal driven.</dd>
</dl>
<hr>
<h2>
<a NAME="DataFormat"></a><font size=+1>Data Format</font></h2>
<p>as specified in clock manual under pt. <u>[ <span lang="EN-GB" style="font-size:10.0pt;font-family:
Arial;mso-fareast-font-family:&quot;Times New Roman&quot;;mso-bidi-font-family:&quot;Times New Roman&quot;;
mso-ansi-language:EN-GB;mso-fareast-language:DE;mso-bidi-language:AR-SA"><b>Data
String for NTP</b> ( <b><i>Network Time Protocol </i></b>) </span>]</u></p>
<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’ro f’r Software www.ATLSoft.de</a><p>(last updated 02/28/2001)
<br>&nbsp;
</body>
</html>

162
contrib/ntp/html/driver39.htm Normal file
View File

@ -0,0 +1,162 @@
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>hopf clock drivers by ATLSoft</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" 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>
<hr>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td width="50%">
<h2>
<font size=+1>Synopsis</font></h2>
<table border="0" cellpadding="3" bgcolor="#C0C0C0">
<tr>
<td height="21">
<div align=right><tt>Address:&nbsp;&nbsp;</tt></div>
</td>
<td height="21"><b>127.127.39.<i>X</i></b></td>
</tr>
<tr>
<td height="21">
<div align=right><tt>Reference ID:&nbsp;&nbsp;</tt></div>
</td>
<td height="21"><a NAME="REFID"></a><b>.hopf. </b>(default)<b>, GPS, DCF</b></td>
</tr>
<tr>
<td height="21">
<div align=right><tt>Driver ID:&nbsp;&nbsp;</tt></div>
</td>
<td height="21"><b>HOPF_P</b></td>
</tr>
</table>
</td>
<td valign="middle" align="center"><font face="Arial"><i><blink><font size="5"><img border="0" src="pic/fg6039.jpg" width="141" height="140"></font></blink></i></font></td>
</tr>
</table>
</center>
</div>
<hr>
<h2>
<font size=+1>Description</font></h2>
The <b>refclock_hopf_pci </b>driver supports the <a href="http://www.hopf.com">hopf</a>
PCI-bus interface 6039 GPS/DCF77.
<br>Additional software and information about the software drivers maybe available
from: <a href="http://www.ATLSoft.de/ntp">http://www.ATLSoft.de/ntp</a>.
<br>Latest NTP driver source, executables and documentation is maintained
at: <a href="http://www.ATLSoft.de/ntp">http://www.ATLSoft.de/ntp</a>
<hr>
<h2>
<font size=+1>Operating System Compatibility</font></h2>
<p align="left">
The hopf clock driver has been tested on the following software and hardware
platforms:
<br>&nbsp;<table bgcolor="#C0C0C0">
<tr>
<td VALIGN=CENTER WIDTH="23%" nowrap>
<p align="left"><b>Platform</b></p>
</td>
<td VALIGN=CENTER nowrap>
<p align="left"><b>Operating System</b></p>
</td>
</tr>
<tr>
<td VALIGN=CENTER WIDTH="23%" nowrap>
<p align="left">i386 (PC)&nbsp;</p>
</td>
<td VALIGN=CENTER nowrap>
<p align="left">Linux</p>
</td>
</tr>
<tr>
<td nowrap>
<p align="left">i386 (PC)&nbsp;</p>
</td>
<td nowrap>
<p align="left">Windows NT</p>
</td>
</tr>
<tr>
<td nowrap>
<p align="left">i386 (PC)&nbsp;</p>
</td>
<center>
<td nowrap>Windows 2000</td>
</tr>
</table></center>
<hr>
<h2>
<font size=+1>O/S System Configuration</font></h2>
<p>
<b>UNIX</b></p>
The driver attempts to open the device <b><tt><a href="#REFID">/dev/hopf6039</a></tt></b>
. The device entry will be made by the installation process of the kernel module
for the PCI-bus board. The driver sources belongs to the delivery equipment of
the PCI-board.
<p><b>Windows NT/2000</b>
<p>
The driver attempts to open the device by calling the function &quot;OpenHopfDevice()&quot;.
This function will be installed by the Device Driver for the PCI-bus board. The
driver belongs to the delivery equipment of the PCI-board.</p>
<hr>
<h2>
<font size=+1>Fudge Factors</font></h2>
<dl>
<dt>
<tt><font size=+1><a href="#REFID"><b>refid <i>string</i></b></a></font></tt></dt>
<dd>
Specifies the driver reference identifier, <b>GPS </b><i>or</i> <b> DCF</b>.</dd>
<dt>
<tt><font size=+1><b>flag1 0
| 1</b></font></tt></dt>
<dd>
When set to 1, driver sync's even if only crystal driven.</dd>
</dl>
<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’ro f’r Software www.ATLSoft.de</a><p>(last updated 03/02/2001)
<br>&nbsp;
</body>
</html>

407
contrib/ntp/html/driver6.htm
View File

@ -1,242 +1,271 @@
<html><head><title>
IRIG Audio Decoder
</title></head><body><h3>
IRIG Audio Decoder
</h3><hr>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>IRIG Audio Decoder</title>
</head>
<body>
<h3>IRIG Audio Decoder</h3>
<H4>Synopsis</H4>
<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>
Address: 127.127.6.<i>u</i> <br>
Reference ID: <tt>IRIG</tt> <br>
Driver ID: <tt>IRIG_AUDIO</tt> <br>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<P>Note: This driver supersedes an older one of the same name, address
and ID which required replacing the original kernel audio driver with
another which works only on older Sun SPARCstation systems. The new
driver described here uses the stock kernel audio driver and works in
SunOS 4.1.3 and Solaris 2.6 versions and probably all versions in
between. The new driver requires no modification of the operating
system. While it is generic and likely portable to other systems, it is
somewhat slower than the original, since the extensive signal
conditioning, filtering and decoding is done in user space, not kernel
space.
<p>Note: This driver supersedes an older one of the same name,
address and ID which required replacing the original kernel audio
driver with another which works only on older Sun SPARCstation
systems. The new driver described here uses the stock kernel audio
driver and works in SunOS 4.1.3 and Solaris 2.6 versions and
probably all versions in between. The new driver requires no
modification of the operating system. While it is generic and
likely portable to other systems, it is somewhat slower than the
original, since the extensive signal conditioning, filtering and
decoding is done in user space, not kernel space.</p>
<H4>Description</H4>
<h4>Description</h4>
This driver supports the Inter-Range Instrumentation Group (IRIG)
standard time distribution signal using the audio codec native to some
workstations. This signal is generated by several radio clocks,
including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom
and TrueTime, among others, although it is often an add-on option. The
signal is connected via an optional attenuator box and cable to either
the microphone or line-in port. The driver receives, demodulates and
decodes the IRIG-B and IRIG-E signal formats using internal filters
designed to reduce the effects of noise and interference.
standard time distribution signal using the audio codec native to
some workstations. This signal is generated by several radio
clocks, including those made by Arbiter, Austron, Bancomm, Odetics,
Spectracom and TrueTime, among others, although it is often an
add-on option. The signal is connected via an optional attenuator
box and cable to either the microphone or line-in port. The driver
receives, demodulates and decodes the IRIG-B and IRIG-E signal
formats using internal filters designed to reduce the effects of
noise and interference.
<p>This driver incorporates several features in common with other audio
drivers such as described in the <a href=driver7.htm>Radio CHU Audio
Demodulator/Decoder</a> and the <a href=driver36.htm>Radio WWV/H Audio
Demodulator/Decoder</a> pages. They include automatic gain control
(AGC), selectable audio codec port and signal monitoring capabilities.
For a discussion of these common features, as well as a guide to hookup,
debugging and monitoring, see the <a href=audio.htm>Reference Clock
Audio Drivers</a> page.
<p>This driver incorporates several features in common with other
audio drivers such as described in the <a href="driver7.htm">Radio
CHU Audio Demodulator/Decoder</a> and the <a href="driver36.htm">
Radio WWV/H Audio Demodulator/Decoder</a> pages. They include
automatic gain control (AGC), selectable audio codec port and
signal monitoring capabilities. For a discussion of these common
features, as well as a guide to hookup, debugging and monitoring,
see the <a href="audio.htm">Reference Clock Audio Drivers</a>
page.</p>
<P>The IRIG signal format uses an amplitude-modulated carrier with
pulse-width modulated data bits. For IRIG-B, the carrier frequency is
1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy is 100
Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy,
generally within a few tens of microseconds relative to IRIG time, it
can also generate a significant load on the processor with older
workstations. Generally, the accuracy with IRIG-E is about ten times
worse than IRIG-B, but the processor load is ten times less.
<p>The IRIG signal format uses an amplitude-modulated carrier with
pulse-width modulated data bits. For IRIG-B, the carrier frequency
is 1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy
is 100 Hz and bit rate 10 b/s. While IRIG-B provides the best
accuracy, generally within a few tens of microseconds relative to
IRIG time, it can also generate a significant load on the processor
with older workstations. Generally, the accuracy with IRIG-E is
about ten times worse than IRIG-B, but the processor load is ten
times less.</p>
<P>The program processes 8000-Hz mu-law companded samples using separate
signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector
and automatic threshold corrector. Cycle crossings relative to the
corrected slice level determine the width of each pulse and its value -
zero, one or position identifier. The data encode 20 BCD digits which
determine the second, minute, hour and day of the year and sometimes the
year and synchronization condition. The comb filter exponentially
averages the corresponding samples of successive baud intervals in order
to reliably identify the reference carrier cycle. A type-II phase-lock
loop (PLL) performs additional integration and interpolation to
accurately determine the zero crossing of that cycle, which determines
the reference timestamp. A pulse-width discriminator demodulates the
data pulses, which are then encoded as the BCD digits of the timecode.
The timecode and reference timestamp are updated once each second with
IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved
for later processing. At poll intervals of 64 s, the saved samples are
processed by a trimmed-mean filter and used to update the system clock.
<p>The program processes 8000-Hz mu-law companded samples using
separate signal filters for IRIG-B and IRIG-E, a comb filter,
envelope detector and automatic threshold corrector. Cycle
crossings relative to the corrected slice level determine the width
of each pulse and its value - zero, one or position identifier. The
data encode 20 BCD digits which determine the second, minute, hour
and day of the year and sometimes the year and synchronization
condition. The comb filter exponentially averages the corresponding
samples of successive baud intervals in order to reliably identify
the reference carrier cycle. A type-II phase-lock loop (PLL)
performs additional integration and interpolation to accurately
determine the zero crossing of that cycle, which determines the
reference timestamp. A pulse-width discriminator demodulates the
data pulses, which are then encoded as the BCD digits of the
timecode. The timecode and reference timestamp are updated once
each second with IRIG-B (ten seconds with IRIG-E) and local clock
offset samples saved for later processing. At poll intervals of 64
s, the saved samples are processed by a trimmed-mean filter and
used to update the system clock.</p>
<P>Infinite impulse response (IIR) filters are used with both IRIG-B and
IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a
130-Hz lowpass filter for IRIG-E. These are intended for use with noisy
signals, such as might be received over a telephone line or radio
circuit, or when interfering signals may be present in the audio
passband. The driver determines which IRIG format is in use by sampling
the amplitude of each filter output and selecting the one with maximum
signal. An automatic gain control feature provides protection against
overdriven or underdriven input signal amplitudes. It is designed to
maintain adequate demodulator signal amplitude while avoiding occasional
noise spikes. In order to assure reliable capture, the decompanded input
signal amplitude must be greater than 100 units and the codec sample
frequency error less than 250 PPM (.025 percent).
<p>Infinite impulse response (IIR) filters are used with both
IRIG-B and IRIG-E formats. An 800-Hz highpass filter is used for
IRIG-B and a 130-Hz lowpass filter for IRIG-E. These are intended
for use with noisy signals, such as might be received over a
telephone line or radio circuit, or when interfering signals may be
present in the audio passband. The driver determines which IRIG
format is in use by sampling the amplitude of each filter output
and selecting the one with maximum signal. An automatic gain
control feature provides protection against overdriven or
underdriven input signal amplitudes. It is designed to maintain
adequate demodulator signal amplitude while avoiding occasional
noise spikes. In order to assure reliable capture, the decompanded
input signal amplitude must be greater than 100 units and the codec
sample frequency error less than 250 PPM (.025 percent).</p>
<P>The program performs a number of error checks to protect against
overdriven or underdriven input signal levels, incorrect signal format
or improper hardware configuration. Specifically, if any of the
following errors occur for a timecode, the data are rejected.
<p>The program performs a number of error checks to protect against
overdriven or underdriven input signal levels, incorrect signal
format or improper hardware configuration. Specifically, if any of
the following errors occur for a timecode, the data are rejected.
Secifically, if any of the following errors occur for a time
measurement, the data are rejected.
measurement, the data are rejected.</p>
<OL>
<ol>
<li>The peak carrier amplitude is less than 100 units. This usually
means dead IRIG signal source, broken cable or wrong input
port.</li>
<LI>The peak carrier amplitude is less than 100 units. This usually
means dead IRIG signal source, broken cable or wrong input port.</LI>
<li>The frequency error is greater than &plusmn;250 PPM (.025
percent). This usually means broken codec hardware or wrong codec
configuration.</li>
<LI>The frequency error is greater than &plusmn;250 PPM (.025 percent).
This usually means broken codec hardware or wrong codec
configuration.</LI>
<li>The modulation index is less than 0.5. This usually means
overdriven IRIG signal or wrong IRIG format.</li>
<LI>The modulation index is less than 0.5. This usually means overdriven
IRIG signal or wrong IRIG format.</LI>
<li>A frame synchronization error has occured. This usually means
wrong IRIG signal format or the IRIG signal source has lost
synchronization (signature control).</li>
<LI>A frame synchronization error has occured. This usually means wrong
IRIG signal format or the IRIG signal source has lost synchronization
(signature control).</LI>
<li>A data decoding error has occured. This usually means wrong
IRIG signal format.</li>
<LI>A data decoding error has occured. This usually means wrong IRIG
signal format.</LI>
<li>The current second of the day is not exactly one greater than
the previous one. This usually means a very noisy IRIG signal or
insufficient CPU resources.</li>
<LI>The current second of the day is not exactly one greater than the
previous one. This usually means a very noisy IRIG signal or
insufficient CPU resources.</LI>
<li>An audio codec error (overrun) occured. This usually means
insufficient CPU resources, as sometimes happens with Sun SPARC
IPCs when doing something useful.</li>
</ol>
<LI>An audio codec error (overrun) occured. This usually means
insufficient CPU resources, as sometimes happens with Sun SPARC IPCs
when doing something useful.</LI>
Note that additional checks are done elsewhere in the reference
clock interface routines.
</OL>
<p>Unlike other drivers, which can have multiple instantiations,
this one supports only one. It does not seem likely that more than
one audio codec would be useful in a single machine. More than one
would probably chew up too much CPU time anyway.</p>
Note that additional checks are done elsewhere in the reference clock
interface routines.
<h4>IRIG-B Timecode Format</h4>
<P>Unlike other drivers, which can have multiple instantiations, this
one supports only one. It does not seem likely that more than one audio
codec would be useful in a single machine. More than one would probably
chew up too much CPU time anyway.
The 100 elements of the IRIG timecode are numbered from 0 through
99. Position identifiers occur at elements 0, 9, 19 and every ten
thereafter to 99. The control function (CF) elements begin at
element 50 (CF 1) and extend to element 78 (CF 27). The
straight-binary-seconds (SBS) field, which encodes the seconds of
the UTC day, begins at element 80 (CF 28) and extends to element 97
(CF 44). The encoding of elements 50 (CF 1) through 78 (CF 27) is
device dependent. This driver presently decodes the CF elements,
but does nothing with them.
<H4>IRIG-B Timecode Format</H4>
The 100 elements of the IRIG timecode are numbered from 0 through 99.
Position identifiers occur at elements 0, 9, 19 and every ten thereafter
to 99. The control function (CF) elements begin at element 50 (CF 1) and
extend to element 78 (CF 27). The straight-binary-seconds (SBS) field,
which encodes the seconds of the UTC day, begins at element 80 (CF 28)
and extends to element 97 (CF 44). The encoding of elements 50 (CF 1)
through 78 (CF 27) is device dependent. This driver presently decodes
the CF elements, but does nothing with them.
<P>Where feasible, the IRIG signal source should be operated with
<p>Where feasible, the IRIG signal source should be operated with
signature control so that, if the signal is lost or mutilated, the
source produces an unmodulated signal, rather than possibly random
digits. The driver will automatically reject the data and declare itself
unsynchronized in this case. Some devices, in particular Spectracom
radio/satellite clocks, provide additional year and status indication in
the format:
digits. The driver will automatically reject the data and declare
itself unsynchronized in this case. Some devices, in particular
Spectracom radio/satellite clocks, provide additional year and
status indication in the format:</p>
<PRE> Element CF Function
<pre>
Element CF Function
-------------------------------------
55 6 time sync status
60-63 10-13 BCD year units
65-68 15-18 BCD year tens
</PRE>
</pre>
Other devices set these elements to zero.
Other devices set these elements to zero.
<H4>Performance</H4>
<h4>Performance</h4>
The mu-law companded data format allows considerable latitude in signal
levels; however, an automatic gain control (AGC) function is implemented
to further compensate for varying input signal levels and to avoid
signal distortion. For proper operation, the IRIG signal source should
be configured for analog signal levels, NOT digital TTL levels.
The mu-law companded data format allows considerable latitude in
signal levels; however, an automatic gain control (AGC) function is
implemented to further compensate for varying input signal levels
and to avoid signal distortion. For proper operation, the IRIG
signal source should be configured for analog signal levels, NOT
digital TTL levels.
<P>The accuracy of the system clock synchronized to the IRIG-B source
with this driver and the <TT>ntpd</TT> daemon is 10-20 <font
face=symbol>m</font>s with a Sun UltraSPARC II and maybe twice that with
a Sun SPARC IPC. The processor resources consumed by the daemon can be
significant, ranging from about 1.2 percent on the faster UltraSPARC II
to 38 percent on the slower SPARC IPC. However, the overall timing
accuracy is limited by the resolution and stability of the CPU clock
oscillator and the interval between clock corrections, which is 64 s
with this driver. This performance, while probably the best that can be
achieved by the daemon itself, can be improved with assist from the PPS
discipline as described elsewhere in the documentation.
<p>The accuracy of the system clock synchronized to the IRIG-B
source with this driver and the <tt>ntpd</tt> daemon is 10-20 <font
face="symbol">m</font>s with a Sun UltraSPARC II and maybe twice
that with a Sun SPARC IPC. The processor resources consumed by the
daemon can be significant, ranging from about 1.2 percent on the
faster UltraSPARC II to 38 percent on the slower SPARC IPC.
However, the overall timing accuracy is limited by the resolution
and stability of the CPU clock oscillator and the interval between
clock corrections, which is 64 s with this driver. This
performance, while probably the best that can be achieved by the
daemon itself, can be improved with assist from the PPS discipline
as described elsewhere in the documentation.</p>
<H4>Monitor Data</H4>
<h4>Monitor Data</h4>
The timecode format used for debugging and data recording includes data
helpful in diagnosing problems with the IRIG signal and codec
connections. With debugging enabled (-d on the ntpd command line), the
driver produces one line for each timecode in the following format:
The timecode format used for debugging and data recording includes
data helpful in diagnosing problems with the IRIG signal and codec
connections. With debugging enabled (-d on the ntpd command line),
the driver produces one line for each timecode in the following
format:
<p><tt>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5
3094572411.00027</tt>
3094572411.00027</tt></p>
<p>The first field containes the error flags in hex, where the hex bits
are interpreted as below. This is followed by the IRIG status indicator,
year of century, day of year and time of day. The status indicator and
year are not produced by some IRIG devices. Following these fields are
the signal amplitude (0-8100), codec gain (0-255), field phase (0-79),
time constant (2-20), modulation index (0-1), carrier phase error
(0&plusmn;0.5) and carrier frequency error (PPM). The last field is the
on-time timestamp in NTP format. The fraction part is a good indicator
of how well the driver is doing. With an UltrSPARC 30, this is normally
within a few tens of microseconds relative to the IRIG-B signal and
within a few hundred microseconds with IRIG-E.
<p>The first field containes the error flags in hex, where the hex
bits are interpreted as below. This is followed by the IRIG status
indicator, year of century, day of year and time of day. The status
indicator and year are not produced by some IRIG devices. Following
these fields are the signal amplitude (0-8100), codec gain (0-255),
field phase (0-79), time constant (2-20), modulation index (0-1),
carrier phase error (0&plusmn;0.5) and carrier frequency error
(PPM). The last field is the on-time timestamp in NTP format. The
fraction part is a good indicator of how well the driver is doing.
With an UltrSPARC 30, this is normally within a few tens of
microseconds relative to the IRIG-B signal and within a few hundred
microseconds with IRIG-E.</p>
<H4>Fudge Factors</H4>
<h4>Fudge Factors</h4>
<DL>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<DT><TT>time1 <I>time</I></TT></DT>
<DD>Specifies the time offset calibration factor, in seconds and
fraction, with default 0.0.</DD>
<dd>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>time2 <i>time</i></tt></dt>
<DT><TT>stratum <I>number</I></TT></DT>
<DD>Specifies the driver stratum, in decimal from 0 to 15, with default
0.</DD>
<dd>Not used by this driver.</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>stratum <i>number</i></tt></dt>
<DT><TT>flag1 0 | 1</TT></DT>
<DD>Not used by this driver.</DD>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 0.</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>refid <i>string</i></tt></dt>
<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>
<dd>Specifies the driver reference identifier, an ASCII string from
one to four characters, with default <tt>IRIG</tt>.</dd>
<DT><TT>flag4 0 | 1</TT></DT>
<DD>Enable verbose <TT>clockstats</TT> recording if set.</DD>
</DL>
<dt><tt>flag1 0 | 1</tt></dt>
<H4>Additional Information</H4>
<dd>Not used by this driver.</dd>
<A HREF="refclock.htm">Reference Clock Drivers</A>
<br><A HREF="audio.htm">Reference Clock Audio Drivers</A>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Specifies the microphone port if set to zero or the line-in
port if set to one. It does not seem useful to specify the compact
disc player port.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Enables audio monitoring of the input signal. For this purpose,
the speaker volume must be set before the driver is started.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<h4>Additional Information</h4>
<a href="refclock.htm">Reference Clock Drivers</a> <br>
<a href="audio.htm">Reference Clock Audio Drivers</a>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

770
contrib/ntp/html/driver7.htm
View File

@ -1,362 +1,397 @@
<html><head><title>
Radio CHU Audio Demodulator/Decoder
</title></head><body><h3>
Radio CHU Audio Demodulator/Decoder
</h3><hr>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Radio CHU Audio Demodulator/Decoder</title>
</head>
<body>
<h3>Radio CHU Audio Demodulator/Decoder</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.7.<I>u</I>
<br>Reference ID: <tt>CHU</tt>
<br>Driver ID: <tt>CHU</tt>
<br>Modem Port: <tt>/dev/chu<I>u</I></tt>; 300 baud, 8-bits, no parity
<br>Autotune Port: <tt>/dev/icom</tt>; 9600 baud, 8-bits, no parity
<br>Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
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/chu_audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
This driver synchronizes the computer time using data encoded in radio
transmissions from Canadian time/frequency station CHU in Ottawa,
Ontario. Transmissions are made continuously on 3330 kHz, 7335 kHz and
14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave
receiver can be tuned manually to one of these frequencies or, in the
case of ICOM receivers, the receiver can be tuned automatically as
propagation conditions change throughout the day and night. The
performance of this driver when tracking the station is ordinarily
better than 1 ms in time with frequency drift less than 0.5 PPM when not
tracking the station.
<p>This driver synchronizes the computer time using data encoded in
radio transmissions from Canadian time/frequency station CHU in
Ottawa, Ontario. It replaces an earlier one, built by Dennis
Ferguson in 1988, which required a special line discipline to
preprocessed the signal. The new driver includes more powerful
algorithms implemented directly in the driver and requires no
preprocessing.</p>
<p>While there are currently no known commercial CHU receivers, a simple
but effective receiver/demodulator can be constructed from an ordinary
shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip,
as described in the <a href=pps.htm>Pulse-per-second (PPS) Signal
Interfacing</a> page. The driver can be compiled to use a modem to
receive the radio signal and demodulate the data. Alternatively, the
driver can be compiled to use the audio codec of the Sun workstation or
another with compatible audio interface. In the latter case, the driver
implements the modem using DSP routines, so the radio can be connected
directly to either the microphone on line input port.
<p>CHU transmissions are made continuously on 3330 kHz, 7335 kHz
and 14670 kHz in upper sideband, compatible AM mode. An ordinary
shortwave receiver can be tuned manually to one of these
frequencies or, in the case of ICOM receivers, the receiver can be
tuned automatically as propagation conditions change throughout the
day and night. The performance of this driver when tracking the
station is ordinarily better than 1 ms in time with frequency drift
less than 0.5 PPM when not tracking the station.</p>
<p>The driver replaces an earlier one built by Dennis Ferguson in 1988.
The earlier driver required a special line discipline which preprocessed
the signal in order to improve accuracy and avoid errors. The new driver
includes more powerful algorithms implemented directly in the driver and
requires no line discipline. It decodes the data using a
maximum-likelihood technique which exploits the considerable degree of
redundancy available to maximize accuracy and minimize errors.
<p>While there are currently no known commercial CHU receivers, a
simple but effective receiver/demodulator can be constructed from
an ordinary shortwave receiver and Bell 103 compatible, 300-b/s
modem or modem chip, as described in the <a href="gadget.htm">
Gadget Box PPS Level Converter and CHU Modem</a> page. The driver
can use the modem to receive the radio signal and demodulate the
data or, if available, the driver can use the audio codec of the
Sun workstation or another with compatible audio interface. In the
latter case, the driver implements the modem using DSP routines, so
the radio can be connected directly to either the microphone on
line input port.</p>
<p>This driver incorporates several features in common with other audio
drivers such as described in the <a href=driver36.htm>Radio WWV/H Audio
Demodulator/Decoder</a> and the <a href=driver6.htm>IRIG Audio
Decoder</a> pages. They include automatic gain control (AGC), selectable
audio codec port and signal monitoring capabilities. For a discussion of
these common features, as well as a guide to hookup, debugging and
monitoring, see the <a href=audio.htm>Reference Clock Audio Drivers</a>
page.
<p>This driver incorporates several features in common with other
audio drivers such as described in the <a href="driver36.htm">Radio
WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.htm">
IRIG Audio Decoder</a> pages. They include automatic gain control
(AGC), selectable audio codec port and signal monitoring
capabilities. For a discussion of these common features, as well as
a guide to hookup, debugging and monitoring, see the <a href=
"audio.htm">Reference Clock Audio Drivers</a> page.</p>
<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h),
although this can be changed with configuration commands. As long as the
clock is set or verified at least once during this interval, the NTP
algorithms will consider the source reachable and selectable to
discipline the system clock. However, if this does not happen for eight
poll intervals, the algorithms will consider the source unreachable and
some other source will be chosen (if available) to discipline the system
clock.
although this can be changed with configuration commands. As long
as the clock is set or verified at least once during this interval,
the NTP algorithms will consider the source reachable and
selectable to discipline the system clock. However, if this does
not happen for eight poll intervals, the algorithms will consider
the source unreachable and some other source will be chosen (if
available) to discipline the system clock.</p>
<p>The decoding algorithms take advantage of all the redundancy
available in each broadcast message or burst. In each burst described in
the next section, every character is sent twice and, in the case of
format A bursts, the burst is sent eight times every minute. In the case
of format B bursts, which are sent once each minute, the burst is
considered correct only if every character matches its repetition in the
burst. In the case of format A messages, a majority decoder requires at
least six repetitions for each digit in the timecode and more than
half of the repetitions decode to the same digit. Every character in
every burst provides an independent timestamp upon arrival with a
potential total of over 60 timestamps for each minute.
<p>The decoding algorithms process the data 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. In the
case of format B bursts, which are sent once each minute, the burst
is considered correct only if every character matches its
repetition in the burst. In the case of format A messages, a
majority decoder requires at least six repetitions for each digit
in the timecode and more than half of the repetitions decode to the
same digit. Every character in every burst provides an independent
timestamp upon arrival with a potential total of over 60 timestamps
for each minute.</p>
<p>A timecode in the format described below is assembled when all bursts
have been received in the minute. The timecode is considered valid and
the clock set when at least one valid format B burst has been decoded
and the above requirements are met. The <tt>yyyy</tt> year field in the
timecode indicates whether a valid format B burst has been received.
Upon startup, this field is initialized at zero; when a valid format B
burst is received, it will be set to the correct Gregorian year. The
<tt>q</tt> quality character field in the timecode indicates whether a
valid timecode has been determined. If any of the high order three bits
of this character are set, the timecode is invalid.
<p>A timecode in the format described below is assembled when all
bursts have been received in the minute. The timecode is considered
valid and the clock set when at least one valid format B burst has
been decoded and the above requirements are met. The <tt>yyyy</tt>
year field in the timecode indicates whether a valid format B burst
has been received. Upon startup, this field is initialized at zero;
when a valid format B burst is received, it is set to the current
Gregorian year. The <tt>q</tt> quality character field in the
timecode indicates whether a valid timecode has been determined. If
any of the high order three bits of this character are set, the
timecode is invalid.</p>
<p>Once the clock has been set for the first time, it will appear
reachable and selectable to discipline the system clock, even if the
broadcast signal is lost. Since the signals are almost always available
during some period of the day and the NTP clock discipline algorithms
are designed to work well even in this case, it is unlikely that the
system clock could drift more than a few tens of milliseconds during
periods of signal loss. To protect against this most unlikely situation,
if after four days with no signals, the clock is considered unset and
resumes the synchronization procedure from the beginning.
reachable and selectable to discipline the system clock, even if
the broadcast signal is lost. Since the signals are almost always
available during some period of the day and the NTP clock
discipline algorithms are designed to work well even in this case,
it is unlikely that the system clock could drift more than a few
tens of milliseconds during periods of signal loss. To protect
against this most unlikely situation, if after four days with no
signals, the clock is considered unset and resumes the
synchronization procedure from the beginning.</p>
<p>The last three fields in the timecode are useful in assessing the
quality of the radio channel during the most recent minute bursts were
received. The <tt>bcnt</tt> field shows the number of format A bursts in
the range 1-8. The <tt>dist</tt> field shows the majority decoder
distance, or the minimum number of sample repetitions for each digit of
the timecode in the range 0-16. The <tt>tsmp</tt> field shows the number
of timestamps determined in the range 0-60. For a valid timecode,
<tt>bcnt</tt> must be at least 3, <tt>dist</tt> must be greater than
<tt>bcnt</tt> and <tt>tsmp</tt> must be at least 20.
<p>The last three fields in the timecode are useful in assessing
the quality of the radio channel during the most recent minute
bursts were received. The <tt>bcnt</tt> field shows the number of
format A bursts in the range 1-8. The <tt>dist</tt> field shows the
majority decoder distance, or the minimum number of sample
repetitions for each digit of the timecode in the range 0-16. The
<tt>tsmp</tt> field shows the number of timestamps determined in
the range 0-60. For a valid timecode, <tt>bcnt</tt> must be at
least 3, <tt>dist</tt> must be greater than <tt>bcnt</tt> and <tt>
tsmp</tt> must be at least 20.</p>
<h4>Program Operation</h4>
<p>The program consists of four major parts: the DSP modem, maximum
likelihood UART, burst assembler and majority decoder. The DSP modem
demodulates Bell 103 modem answer-frequency signals; that is, frequency-
shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz (space). This is
done using a 4th-order IIR filter and limiter/discriminator with 500-Hz
bandpass centered on 2125 Hz and followed by a FIR raised-cosine lowpass
filter optimized for the 300-b/s data rate. Alternately, the driver can
be compiled to delete the modem and input 300 b/s data directly from an
external modem via a serial port.
likelihood UART, burst assembler and majority decoder. The DSP
modem demodulates Bell 103 modem answer-frequency signals; that is,
frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz
(space). This is done using a 4th-order IIR filter and
limiter/discriminator with 500-Hz bandpass centered on 2125 Hz and
followed by a FIR raised-cosine lowpass filter optimized for the
300-b/s data rate. Alternately, the driver can be compiled to
delete the modem and input 300 b/s data directly from an external
modem via a serial port.</p>
<p>The maximum likelihood UART is implemented using a set of eight
11-stage shift registers, one for each of eight phases of the 300-b/s
bit clock. At each phase a new baseband signal value from the DSP modem
is shifted into the corresponding register and the maximum and minimum
over all 11 samples computed. This establishes a slice level midway
between the maximum and minimum over all stages. For each stage, a
signal level above this level is a mark (1) and below is a space (0). A
quality metric is calculated for each register with respect to the slice
level and the a-priori signal consisting of a mark bit (previous stop
bit), space (start) bit, eight arbitrary information bits and the first
of the two mark (stop) bits.
<p>The shift registers are processed in round-robin order as each modem
value arrives until one of them shows a valid framing pattern consisting
of a mark bit, space bit, eight arbitrary data bits and a mark bit. When
found, the data bits from the register with the best metric is chosen as
the maximum likelihood character and the UART begins to process the next
character.
11-stage shift registers, one for each of eight phases of the
300-b/s bit clock. At each phase a new baseband signal value from
the DSP modem is shifted into the corresponding register and the
maximum and minimum over all 11 samples computed. This establishes
a slice level midway between the maximum and minimum over all
stages. For each stage, a signal level above this level is a mark
(1) and below is a space (0). A quality metric is calculated for
each register with respect to the slice level and the a-priori
signal consisting of a mark bit (previous stop bit), space (start)
bit, eight arbitrary information bits and the first of the two mark
(stop) bits.</p>
<p>The shift registers are processed in round-robin order as each
modem value arrives until one of them shows a valid framing pattern
consisting of a mark bit, space bit, eight arbitrary data bits and
a mark bit. When found, the data bits from the register with the
best metric is chosen as the maximum likelihood character and the
UART begins to process the next character.</p>
<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.
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. A format B block contains the year and other
information in ten hexadecimal digits. A format A block contains the
timecode in ten decimal digits, the first of which is a framing code
(6). The burst assembler must deal with cases where the first character
of a format A burst is lost or is noise. This is done using the framing
code to correct the phase, either one character early or one character
late.
information in ten hexadecimal digits. A format A block contains
the timecode in ten decimal digits, the first of which is a framing
code (6). The burst assembler must deal with cases where the first
character of a format A burst is lost or is noise. This is done
using the framing code to correct the phase, either one character
early or one character late.</p>
<p>The burst distance is incremented by one for each bit in the first
block that matches the corresponding bit in the second block and
decremented by one otherwise. In a format B burst the second block is
bit-inverted relative to the first, so a perfect burst of five 8-bit
characters has distance -40. In a format A block the two blocks are
identical, so a perfect burst has distance +40. Format B bursts must be
perfect to be acceptable; however, format A bursts, which are further
processed by the majority decoder, are acceptable if the distance is at
least 28.
<p>The burst distance is incremented by one for each bit in the
first block that matches the corresponding bit in the second block
and decremented by one otherwise. In a format B burst the second
block is bit-inverted relative to the first, so a perfect burst of
five 8-bit characters has distance -40. In a format A block the two
blocks are identical, so a perfect burst has distance +40. Format B
bursts must be perfect to be acceptable; however, format A bursts,
which are further processed by the majority decoder, are acceptable
if the distance is at least 28.</p>
<p>Each minute of transmission includes eight format A bursts containing
two timecodes for each second from 31 through 39. The majority decoder
uses a decoding matrix of ten rows, one for each digit position in the
timecode, and 16 columns, one for each 4-bit code combination that might
be decoded at that position. In order to use the character timestamps,
it is necessary to reliably determine the second number of each burst.
In a valid burst, the last digit of the two timecodes in the block must
match and the value must be in the range 2-9 and greater than in the
previous burst.
<p>Each minute of transmission includes eight format A bursts
containing two timecodes for each second from 31 through 39. The
majority decoder uses a decoding matrix of ten rows, one for each
digit position in the timecode, and 16 columns, one for each 4-bit
code combination that might be decoded at that position. In order
to use the character timestamps, it is necessary to reliably
determine the second number of each burst. In a valid burst, the
last digit of the two timecodes in the block must match and the
value must be in the range 2-9 and greater than in the previous
burst.</p>
<p>As each hex digit of a valid burst is processed, the value at the row
corresponding to the digit position in the timecode and column
corresponding to the code found at that position is incremented. At the
end of each minute of transmission, each row of the decoding matrix
encodes the number of occurrences of each code found at the
corresponding position of the timecode. However, the first digit
(framing code) is always 6, the ninth (second tens) is always 3 and the
last (second units) changes for each burst, so are not used.
<p>As each hex digit of a valid burst is processed, the value at
the row corresponding to the digit position in the timecode and
column corresponding to the code found at that position is
incremented. At the end of each minute of transmission, each row of
the decoding matrix encodes the number of occurrences of each code
found at the corresponding position of the timecode. However, the
first digit (framing code) is always 6, the ninth (second tens) is
always 3 and the last (second units) changes for each burst, so are
not used.</p>
<p>The maximum over all occurrences at each timecode digit position is
the distance for that position and the corresponding code is the maximum
likelihood candidate. If the distance is zero, the decoder assumes a
miss; if the distance is not more than half the total number of
occurrences, the decoder assumes a soft error; if two different codes
with the same distance are found, the decoder assumes a hard error. In
all these cases the decoder encodes a non-decimal character which will
later cause a format error when the timecode is reformatted. The
decoding distance is defined as the minimum distance over the first nine
digits; the tenth digit varies over the seconds and is uncounted.
<p>The maximum over all occurrences at each timecode digit position
is the distance for that position and the corresponding code is the
maximum likelihood candidate. If the distance is zero, the decoder
assumes a miss; if the distance is not more than half the total
number of occurrences, the decoder assumes a soft error; if two
different codes with the same distance are found, the decoder
assumes a hard error. In all these cases the decoder encodes a
non-decimal character which will later cause a format error when
the timecode is reformatted. The decoding distance is defined as
the minimum distance over the first nine digits; the tenth digit
varies over the seconds and is uncounted.</p>
<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.
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 timestamp offsets accumulated over
the minute. A perfect set of nine bursts could generate as many as 90
timestamps, but the maximum the interface can handle is 60. These are
processed by the interface using a median filter and trimmed-mean
average, so the resulting system clock correction is usually much better
than would otherwise be the case with radio noise, UART jitter and
occasional burst errors.
interface along with the backdated timestamp offsets accumulated
over the minute. A perfect set of nine bursts could generate as
many as 90 timestamps, but the maximum the interface can handle is
60. These are processed by the interface using a median filter and
trimmed-mean average, so the resulting system clock correction is
usually much better than would otherwise be the case with radio
noise, UART jitter and occasional burst errors.</p>
<h4>Autotune</h4>
<p>The driver includes provisions to automatically tune the radio in
response to changing radio propagation conditions throughout the day and
night. The radio interface is compatible with the ICOM CI-V standard,
which is a bidirectional serial bus operating at TTL levels. The bus can
be connected to a standard serial port using a level converter such as
the CT-17. The serial port speed is presently compiled in the program,
but can be changed in the <tt>icom.h</tt> header file.
<p>The driver includes provisions to automatically tune the radio
in response to changing radio propagation conditions throughout the
day and night. The radio interface is compatible with the ICOM CI-V
standard, which is a bidirectional serial bus operating at TTL
levels. The bus can be connected to a standard serial port using a
level converter such as the CT-17. The serial port speed is
presently compiled in the program, but can be changed in the <tt>
icom.h</tt> header file.</p>
<p>Each ICOM radio is assigned a unique 8-bit ID select code, usually
expressed in hex format. To activate the CI-V interface, the
<tt>mode</tt> keyword of the <tt>server</tt> configuration command
specifies a nonzero select code in decimal format. A table of ID select
codes for the known ICOM radios is given below. A missing <tt>mode</tt>
keyword or a zero argument leaves the interface disabled. The driver
will attempt to open the device <tt>/dev/icom</tt> and, if successful
will tune the radio to 3.330 MHz. If after five minutes at this
frequency not more than two format A bursts have been received for any
minute, the driver will tune to 7.335 MHz, then to 14.670 MHz, then
return to 3.330 MHz and continue in this cycle.
<p>Each ICOM radio is assigned a unique 8-bit ID select code,
usually expressed in hex format. To activate the CI-V interface,
the <tt>mode</tt> keyword of the <tt>server</tt> configuration
command specifies a nonzero select code in decimal format. A table
of ID select codes for the known ICOM radios is given below. Since
all ICOM select codes are less than 128, the high order bit of the
code is used by the driver to specify the baud rate. If this bit is
not set, the rate is 9600 bps for the newer radios; if set, the
rate is 1200 bps for the older radios. A missing <tt>mode</tt>
keyword or a zero argument leaves the interface disabled.</p>
<p>The driver is liberal in what it assumes of the configuration. If the
<tt>/dev/icom</tt> link is not present or the open fails or the CI-V bus
or radio is inoperative, the driver quietly gives up with no harm done.
<p>If specified, the driver will attempt to open the device <tt>
/dev/icom</tt> and, if successful will tune the radio to 3.330 MHz.
If after five minutes at this frequency not more than two format A
bursts have been received for any minute, the driver will tune to
7.335 MHz, then to 14.670 MHz, then return to 3.330 MHz and
continue in this cycle. However, the driver is liberal in what it
assumes of the configuration. If the <tt>/dev/icom</tt> link is not
present or the open fails or the CI-V bus or radio is inoperative,
the driver quietly gives up with no harm done.</p>
<h4>Radio Broadcast Format</h4>
<p>The CHU time broadcast includes an audio signal compatible with the
Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It consist of
nine, ten-character bursts transmitted at 300 b/s and beginning each
second from second 31 to second 39 of the minute. Each character
consists of eight data bits plus one start bit and two stop bits to
encode two hex digits. The burst data consist of five characters (ten
hex digits) followed by a repeat of these characters. In format A, the
characters are repeated in the same polarity; in format B, the
characters are repeated in the opposite polarity.
<p>The CHU time broadcast includes an audio signal compatible with
the Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It
consist of nine, ten-character bursts transmitted at 300 b/s and
beginning each second from second 31 to second 39 of the minute.
Each character consists of eight data bits plus one start bit and
two stop bits to encode two hex digits. The burst data consist of
five characters (ten hex digits) followed by a repeat of these
characters. In format A, the characters are repeated in the same
polarity; in format B, the characters are repeated in the opposite
polarity.</p>
<p>Format A bursts are sent at seconds 32 through 39 of the minute in
hex digits
<p>Format A bursts are sent at seconds 32 through 39 of the minute
in hex digits</p>
<p><tt>6dddhhmmss6dddhhmmss</tt>
<p>The first ten digits encode a frame marker (<tt>6</tt>) followed by
the day (<tt>ddd</tt>), hour (<tt>hh</tt>), minute (<tt>mm</tt>) and
second (<tt>ss</tt>). Since format A bursts are sent during the
third decade of seconds the tens digit of <tt>ss</tt> is always 3. The
driver uses this to determine correct burst synchronization. These
digits are then repeated with the same polarity.
<p>Format B bursts are sent at second 31 of the minute in hex digits
<p><tt>6dddhhmmss6dddhhmmss</tt></p>
<p><tt>xdyyyyttaaxdyyyyttaa</tt>
<p>The first ten digits encode a frame marker (<tt>6</tt>) followed
by the day (<tt>ddd</tt>), hour (<tt>hh</tt>), minute (<tt>mm</tt>)
and second (<tt>ss</tt>). Since format A bursts are sent during the
third decade of seconds the tens digit of <tt>ss</tt> is always 3.
The driver uses this to determine correct burst synchronization.
These digits are then repeated with the same polarity.</p>
<p>Format B bursts are sent at second 31 of the minute in hex
digits</p>
<p><tt>xdyyyyttaaxdyyyyttaa</tt></p>
<p>The first ten digits encode a code (<tt>x</tt> described below)
followed by the DUT1 (<tt>d</tt> in deciseconds), Gregorian year
(<tt>yyyy</tt>), difference TAI - UTC (<tt>tt</tt>) and daylight time
indicator (<tt>aa</tt>) peculiar to Canada. These digits are then
repeated with inverted polarity.
(<tt>yyyy</tt>), difference TAI - UTC (<tt>tt</tt>) and daylight
time indicator (<tt>aa</tt>) peculiar to Canada. These digits are
then repeated with inverted polarity.</p>
<p>The <tt>x</tt> is coded
<p>The <tt>x</tt> is coded</p>
<dl>
<dt><tt>1</tt></dt>
<dt><tt>1</tt>
<dd>Sign of DUT (0 = +)/dd>
<dd>Sign of DUT (0 = +)/dd&gt;</dd>
<dt><tt>2</tt></dt>
<dt><tt>2</tt>
<dd>Leap second warning. One second will be added.</dd>
<dt><tt>4</tt>
<dt><tt>4</tt></dt>
<dd>Leap second warning. One second will be subtracted. This is not
likely to happen in our universe.</dd>
<dt><tt>8</tt>
<dd>Even parity bit for this nibble.</dd>
<dt><tt>8</tt></dt>
<dd>Even parity bit for this nibble.</dd>
</dl>
<p>By design, the last stop bit of the last character in the burst
coincides with 0.5 second. Since characters have 11 bits and are
transmitted at 300 b/s, the last stop bit of the first character
coincides with 0.5 - 10 * 11/300 = 0.133 second. Depending on the UART,
character interrupts can vary somewhere between the beginning of bit 9
and end of bit 11. These eccentricities can be corrected along with the
radio propagation delay using the <tt>fudge time1</tt> variable.
coincides with 0.5 - 10 * 11/300 = 0.133 second. Depending on the
UART, character interrupts can vary somewhere between the beginning
of bit 9 and end of bit 11. These eccentricities can be corrected
along with the radio propagation delay using the <tt>fudge
time1</tt> variable.</p>
<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.
<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:
<p>With debugging enabled the driver produces messages in the
following formats:</p>
<p>A format <tt>chuA</tt> message is produced for each format A burst
received in seconds 32 through 39 of the minute:
<p>A format <tt>chuA</tt> message is produced for each format A
burst received in seconds 32 through 39 of the minute:</p>
<p><tt>chuA n b s code</tt>
<p><tt>chuA n b s code</tt></p>
<p>where <tt>n</tt> is the number of characters in the burst (0-11),
<tt>b</tt> the burst distance (0-40), <tt>s</tt> the synchronization
distance (0-40) and <tt>code</tt> the burst characters as received. Note
that the hex digits in each character are reversed and the last ten
digits inverted, so the burst
<p><tt>11 40 1091891300ef6e76ecff</tt>
<p>is interpreted as containing 11 characters with burst distance 40.
The nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI -
UTC 31 seconds.
<p>where <tt>n</tt> is the number of characters in the burst
(0-11), <tt>b</tt> the burst distance (0-40), <tt>s</tt> the
synchronization distance (0-40) and <tt>code</tt> the burst
characters as received. Note that the hex digits in each character
are reversed and the last ten digits inverted, so the burst</p>
<p>A format <tt>chuB</tt> message is produced for each format B burst
received in second 31 of the minute:
<p><tt>11 40 1091891300ef6e76ecff</tt></p>
<p><tt>chuB n b f s m code</tt>
<p>is interpreted as containing 11 characters with burst distance
40. The nibble-swapped timecode shows DUT1 +0.1 second, year 1998
and TAI -UTC 31 seconds.</p>
<p>where <tt>n</tt> is the number of characters in the burst (0-11),
<tt>b</tt> the burst distance (0-40), <tt>f</tt> the field alignment (-
1, 0, 1), <tt>s</tt>the synchronization distance (0-16), <tt>m</tt>the
burst number (2-9) and <tt>code</tt> the burst characters as received.
Note that the hex digits in each character are reversed, so the burst
<p>A format <tt>chuB</tt> message is produced for each format B
burst received in second 31 of the minute:</p>
<p><tt>10 38 0 16 9 06851292930685129293</tt>
<p><tt>chuB n b f s m code</tt></p>
<p>is interpreted as containing 11 characters with burst distance 38,
field alignment 0, synchronization distance 16 and burst number 9. The
nibble-swapped timecode shows day 58, hour 21, minute 29 and second 39.
<p>where <tt>n</tt> is the number of characters in the burst
(0-11), <tt>b</tt> the burst distance (0-40), <tt>f</tt> the field
alignment (-1, 0, 1), <tt>s</tt>the synchronization distance
(0-16), <tt>m</tt>the burst number (2-9) and <tt>code</tt> the
burst characters as received. Note that the hex digits in each
character are reversed, so the burst</p>
<p><tt>10 38 0 16 9 06851292930685129293</tt></p>
<p>is interpreted as containing 11 characters with burst distance
38, field alignment 0, synchronization distance 16 and burst number
9. The nibble-swapped timecode shows day 58, hour 21, minute 29 and
second 39.</p>
<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.
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:
When enabled by the <tt>filegen</tt> facility, every received
timecode is written to the <tt>clockstats</tt> file in the
following format:
<pre>
sq yy ddd hh:mm:ss.fff ld dut lset agc rfrq bcnt dist tsmp
@ -380,84 +415,103 @@ is written to the <tt>clockstats</tt> file in the following format:
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
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.
following driver-dependent fields, are in variable-length format.
<dl>
<dt><tt>s</tt></dt>
<dt><tt>s</tt>
<dd>The sync indicator is initially <tt>?</tt> before the clock is set,
but turns to space when the clock is correctly set.</dd>
<dd>The sync indicator is initially <tt>?</tt> before the clock is
set, but turns to space when the clock is correctly set.</dd>
<dt><tt>q</tt>
<dd>The quality character is a four-bit hexadecimal code showing which
alarms have been raised during the most recent minute. Each bit is
associated with a specific alarm condition according to the following:
<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>
<dd>Decoder alarm. A majority of repetitions for at least one digit of
the timecode fails to agree.
</dd>
<dt><tt>8</tt></dt>
<dt><tt>4</tt>
<dd>Timestamp alarm. Fewer than 20 timestamps have been determined.</dd>
<dd>Decoder alarm. A majority of repetitions for at least one digit
of the timecode fails to agree.</dd>
<dt><tt>4</tt></dt>
<dd>Timestamp alarm. Fewer than 20 timestamps have been
determined.</dd>
<dt><tt>2</tt></dt>
<dt><tt>2</tt>
<dd>Format alarm. The majority timecode contains invalid bit
combinations.</dd>
<dt><tt>1</tt>
<dt><tt>1</tt></dt>
<dd>Frame alarm. A framing or format error occurred on at least one
burst during the minute.</dd>
</dl>
It is important to note that one or more of the above alarms does not
necessarily indicate a clock error, but only that the decoder has
detected a condition that may in future result in an error.
It is important to note that one or more of the above alarms does
not necessarily indicate a clock error, but only that the decoder
has detected a condition that may in future result in an
error.</dd>
<dt><tt>yyyy ddd hh:mm:ss.fff</tt></dt>
<dt><tt>yyyy ddd hh:mm:ss.fff</tt></tt>
<dd>The timecode format itself is self explanatory. Note that the
Gregorian year is decoded directly from the transmitted timecode.</dd>
<dt><tt>l</tt>
<dd>The leap second warning is normally space, but changes to <tt>L</tt>
if a leap second is to occur at the end of the month of June or
December.</dd>
Gregorian year is decoded directly from the transmitted
timecode.</dd>
<dt><tt>d</tt>
<dd>The DST code for Canada encodes the state for all provinces.</dd>
<dt><tt>l</tt></dt>
<dt><tt>dut</tt>
<dd>The DUT sign and magnitude shows the current UT1 offset relative to
the displayed UTC time, in deciseconds.</dd>
<dd>The leap second warning is normally space, but changes to <tt>
L</tt> if a leap second is to occur at the end of the month of June
or December.</dd>
<dt><tt>lset</tt>
<dd>Before the clock is set, the interval since last set is the number
of minutes since the program was started; after the clock is set, this
is number of minutes since the time was last verified relative to the
broadcast signal.</dd>
<dt><tt>d</tt></dt>
<dt><tt>agc</tt>
<dd>The audio gain shows the current codec gain setting in the range 0
to 255. Ordinarily, the receiver audio gain control or IRIG level
control should be set for a value midway in this range.
<dd>The DST code for Canada encodes the state for all
provinces.</dd>
<dt><tt>rfrq</tt>
<dd>The current radio frequency, if the CI-V interface is active, or 'X'
if not.</dd>
<dt><tt>dut</tt></dt>
<dt><tt>bcnt</tt>
<dd>The number of format A bursts received during the most recent minute
bursts were received.</dd>
<dd>The DUT sign and magnitude shows the current UT1 offset
relative to the displayed UTC time, in deciseconds.</dd>
<dt><tt>lset</tt></dt>
<dd>Before the clock is set, the interval since last set is the
number of minutes since the program was started; after the clock is
set, this is number of minutes since the time was last verified
relative to the broadcast signal.</dd>
<dt><tt>agc</tt></dt>
<dd>The audio gain shows the current codec gain setting in the
range 0 to 255. Ordinarily, the receiver audio gain control or IRIG
level control should be set for a value midway in this range.</dd>
<dt><tt>rfrq</tt></dt>
<dd>The current radio frequency, if the CI-V interface is active,
or 'X' if not.</dd>
<dt><tt>bcnt</tt></dt>
<dd>The number of format A bursts received during the most recent
minute bursts were received.</dd>
<dt><tt>dist</tt></dt>
<dt><tt>dist</tt>
<dd>The minimum decoding distance determined during the most recent
minute bursts were received.</dd>
<dt><tt>tsmp</tt>
<dt><tt>tsmp</tt></dt>
<dd>The number of timestamps determined during the most recent
minute bursts were received.</dd>
</dl>
@ -465,12 +519,11 @@ minute bursts were received.</dd>
<h4>Modes</h4>
<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration
command specifies the ICOM ID select code. A missing or zero argument
disables the CI-V interface. Following are the ID select codes for the
known radios.
<p><table cols=6 width=100%>
command specifies the ICOM ID select code. A missing or zero
argument disables the CI-V interface. Following are the ID select
codes for the known radios.</p>
<table cols="6" width="100%">
<tr>
<td>Radio</td>
<td>Hex</td>
@ -542,50 +595,63 @@ known radios.
<td>0x2a</td>
<td>42</td>
</tr>
</table>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dt><tt>time1 <I>time</I></tt></dt>
<dd>Specifies the propagation delay for CHU (45:18N 75:45N), in seconds
and fraction, with default 0.0.</dd>
<dd>Specifies the propagation delay for CHU (45:18N 75:45N), in
seconds and fraction, with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<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>stratum <i>number</i></tt></dt>
<dt><tt>refid <I>string</I></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from one
to four characters, with default <tt>CHU</tt>.</dd>
<dd>Specifies the driver 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>
<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>
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>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<h4>Additional Information</h4>
<A HREF="refclock.htm">Reference Clock Drivers</A>
<br><A HREF="audio.htm">Reference Clock Audio Drivers</A>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<a href="refclock.htm">Reference Clock Drivers</a> <br>
<a href="audio.htm">Reference Clock Audio Drivers</a>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

38
contrib/ntp/html/driver9.htm
View File

@ -2,24 +2,21 @@
<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>Magnavox MX4200 GPS Receiver
</TITLE>
<TITLE>Magnavox MX4200 GPS Receiver</TITLE>
</HEAD>
<BODY>
<H3>
Magnavox MX4200 GPS Receiver</H3>
<H3>Magnavox MX4200 GPS Receiver</H3>
<HR>
<H4>
Synopsis</H4>
<H4>Synopsis</H4>
Address: 127.127.9.<I>u</I>
<BR>Reference ID: <TT>GPS</TT>
<BR>Driver ID: <TT>GPS_MX4200</TT>
<BR>Serial Port: <TT>/dev/gps<I>u</I></TT>; 4800 baud, 8-bits, no parity
<BR>Features: <TT>ppsclock</TT> (required)
<H4>
Description</H4>
<H4>Description</H4>
This driver supports the Magnavox MX4200 Navigation Receiver adapted to
precision timing applications. It requires the <TT>ppsclock</TT> line
discipline or streams module described in the <A HREF="ldisc.htm">Line
@ -32,8 +29,9 @@ Interfacing</A> page.
MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.
<P>
<A HREF="http://www.leica-gps.com/">
<IMG SRC="pic/9400n.jpg" ALT="Leica MX9400N Navigator" ALIGN=LEFT></A>
<A HREF="http://www.leica-gps.com/"><IMG align=left HEIGHT=143 WIDTH=180
SRC="pic/9400n.jpg" ALT="Leica MX9400N Navigator"></A>
<A HREF="http://www.leica-gps.com/">Leica Geosystems</A> acquired
the Magnavox commercial GPS technology business in February of 1994.
They now market and support former Magnavox GPS products such as the
@ -44,32 +42,30 @@ Leica MX9400N Navigator.
<P>
<H4>
Operating Modes</H4>
<H4>Operating Modes</H4>
This driver supports two modes of operation, static and mobile, controlled
by clock flag 2.
<P>In static mode (the default) the driver assumes that the GPS antenna
is in a fixed location. The receiver is initially placed in a "Static,
3D Nav" mode, where latitude, longitude, elevation and time are calculated
for a fixed station. A DOP-weighted running average position is calculated
from this data. After 24 hours, the receiver is placed into a "Known Position"
mode, initialized with the calculated position, and then solves only for
time.
3D Nav" mode, where latitude, longitude, elevation and time are
calculated for a fixed station. An average position is calculated from
this data. After 24 hours, the receiver is placed into a "Known
Position" mode, initialized with the calculated position, and then
solves only for time.
<P>In mobile mode, the driver assumes the GPS antenna is mounted on a moving
platform such as a car, ship, or aircraft. The receiver is placed in "Dynamic,
3D Nav" mode and solves for position, altitude and time while moving. No
position averaging is performed.
<H4>
Monitor Data</H4>
<H4>Monitor Data</H4>
The driver writes each timecode as received to the <TT>clockstats</TT>
file. Documentation for the <CITE>NMEA-0183</CITE> proprietary
sentences produced by the MX4200 can be found in
<A HREF="mx4200data.htm">MX4200 Receiver Data Format</A>.
<H4>
Fudge Factors</H4>
<H4>Fudge Factors</H4>
<DL>
<DT>

575
contrib/ntp/html/exec.htm
View File

@ -1,292 +1,393 @@
<html><head><title>
Executive Summary - Computer Network Time Synchronization
</title></head><body><H3>
Executive Summary - Computer Network Time Synchronization
</h3>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" &amp;lt;html>
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Executive Summary - Computer Network Time
Synchronization</title>
</head>
<body>
<h3>Executive Summary - Computer Network Time Synchronization</h3>
<img align=left src=pic/alice12.gif>
from <i>Alice's Adventures in Wonderland</i>, by Lewis Carroll,
illustrations by Sir John Tenniel
<img align="left" src="pic/alice12.gif" alt="gif"><a href=
"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
Carroll</a>
<p>The executive is the one on the left.
<br clear=left><hr>
<p>The executive is the one on the left.<br clear="left">
</p>
<hr>
<h4>Introduction</h4>
<p>The standard timescale used by most nations of the world is Universal
Coordinated Time (UTC), which is based on the Earth's rotation about its
axis, and the Gregorian Calendar, which is based on the Earth's rotation
about the Sun. The UTC timescale is disciplined with respect to
International Atomic Time (TAI) by inserting leap seconds at intervals
of about 18 months. UTC time is disseminated by various means, including
radio and satellite navigation systems, telephone modems and portable
clocks.
<p>The standard timescale used by most nations of the world is
Coordinated UniversalTime (UTC), which is based on the Earth's
rotation about its axis, and the Gregorian Calendar, which is based
on the Earth's rotation about the Sun. The UTC timescale is
disciplined with respect to International Atomic Time (TAI) by
inserting leap seconds at intervals of about 18 months. UTC time is
disseminated by various means, including radio and satellite
navigation systems, telephone modems and portable clocks.</p>
<p>Special purpose receivers are available for many time-dissemination
services, including the Global Position System (GPS) and other services
operated by various national governments. For reasons of cost and
convenience, it is not possible to equip every computer with one of
these receivers. However, it is possible to equip some number of
computers acting as primary time servers to synchronize a much larger
number of secondary servers and clients connected by a common network.
In order to do this, a distributed network clock synchronization
protocol is required which can read a server clock, transmit the reading
to one or more clients and adjust each client clock as required.
Protocols that do this include the Network Time Protocol (NTP), Digital
Time Synchronization Protocol (DTSS) and others found in the literature
(See "Further Reading" at the end of this article.)
<p>Special purpose receivers are available for many
time-dissemination services, including the Global Position System
(GPS) and other services operated by various national governments.
For reasons of cost and convenience, it is not possible to equip
every computer with one of these receivers. However, it is possible
to equip some number of computers acting as primary time servers to
synchronize a much larger number of secondary servers and clients
connected by a common network. In order to do this, a distributed
network clock synchronization protocol is required which can read a
server clock, transmit the reading to one or more clients and
adjust each client clock as required. Protocols that do this
include the Network Time Protocol (NTP), Digital Time
Synchronization Protocol (DTSS) and others found in the literature
(See "Further Reading" at the end of this article.)</p>
<h4>Protocol Design Issues</h4>
<p>The synchronization protocol determines the time offset of the server
clock relative to the client clock. The various synchronization
protocols in use today provide different means to do this, but they all
follow the same general model. On request, the server sends a message
including its current clock value or <i>timestamp</i> and the client
records its own timestamp upon arrival of the message. For the best
accuracy, the client needs to measure the server-client propagation
delay to determine its clock offset relative to the server. Since it is
not possible to determine the one-way delays, unless the actual clock
offset is known, the protocol measures the total roundtrip delay and
assumes the propagation times are statistically equal in each direction.
In general, this is a useful approximation; however, in the Internet of
today, network paths and the associated delays can differ significantly
due to the individual service providers.
<p>The synchronization protocol determines the time offset of the
server clock relative to the client clock. The various
synchronization protocols in use today provide different means to
do this, but they all follow the same general model. On request,
the server sends a message including its current clock value or <i>
timestamp</i> and the client records its own timestamp upon arrival
of the message. For the best accuracy, the client needs to measure
the server-client propagation delay to determine its clock offset
relative to the server. Since it is not possible to determine the
one-way delays, unless the actual clock offset is known, the
protocol measures the total roundtrip delay and assumes the
propagation times are statistically equal in each direction. In
general, this is a useful approximation; however, in the Internet
of today, network paths and the associated delays can differ
significantly due to the individual service providers.</p>
<p>The community served by the synchronization protocol can be very
large. For instance, the NTP community in the Internet of 1998 includes
over 230 primary time servers, synchronized by radio, satellite and
modem, and well over 100,000 secondary servers and clients. In addition,
there are many thousands of private communities in large government,
corporate and institution networks. Each community is organized as a
tree graph or <i>subnet</i>, with the primary servers at the root and
secondary servers and clients at increasing hop count, or stratum level,
in corporate, department and desktop networks. It is usually necessary
at each stratum level to employ redundant servers and diverse network
paths in order to protect against broken software, hardware and network
links.
large. For instance, the NTP community in the Internet of 1998
includes over 230 primary time servers, synchronized by radio,
satellite and modem, and well over 100,000 secondary servers and
clients. In addition, there are many thousands of private
communities in large government, corporate and institution
networks. Each community is organized as a tree graph or <i>
subnet</i>, with the primary servers at the root and secondary
servers and clients at increasing hop count, or stratum level, in
corporate, department and desktop networks. It is usually necessary
at each stratum level to employ redundant servers and diverse
network paths in order to protect against broken software, hardware
and network links.</p>
<p>Synchronization protocols work in one or more association modes,
depending on the protocol design. Client/server mode, also called
master/slave mode, is supported in both DTSS and NTP. In this mode, a
client synchronizes to a stateless server as in the conventional RPC
model. NTP also supports symmetric mode, which allows either of two peer
servers to synchronize to the other, in order to provide mutual backup.
DTSS and NTP support a broadcast mode which allows many clients to
synchronize to one or a few servers, reducing network traffic when large
numbers of clients are involved. In NTP, IP multicast can be used when
the subnet spans multiple networks.
master/slave mode, is supported in both DTSS and NTP. In this mode,
a client synchronizes to a stateless server as in the conventional
RPC model. NTP also supports symmetric mode, which allows either of
two peer servers to synchronize to the other, in order to provide
mutual backup. DTSS and NTP support a broadcast mode which allows
many clients to synchronize to one or a few servers, reducing
network traffic when large numbers of clients are involved. In NTP,
IP multicast can be used when the subnet spans multiple
networks.</p>
<p>Configuration management can be a serious problem in large subnets.
Various schemes which index public databases and network directory
services are used in DTSS and NTP to discover servers. Both protocols
use broadcast modes to support large client populations; but, since
listen-only clients cannot calibrate the delay, accuracy can suffer. In
NTP, clients determine the delay at the time a server is first
discovered by polling the server in client/server mode and then
reverting to listen-only mode. In addition, NTP clients can broadcast a
special "manycast" message to solicit responses from nearby servers and
continue in client/server mode with the respondents.
<p>Configuration management can be a serious problem in large
subnets. Various schemes which index public databases and network
directory services are used in DTSS and NTP to discover servers.
Both protocols use broadcast modes to support large client
populations; but, since listen-only clients cannot calibrate the
delay, accuracy can suffer. In NTP, clients determine the delay at
the time a server is first discovered by polling the server in
client/server mode and then reverting to listen-only mode. In
addition, NTP clients can broadcast a special "manycast" message to
solicit responses from nearby servers and continue in client/server
mode with the respondents.</p>
<h4>Security Issues</h4>
<p>A reliable network time service requires provisions to prevent
accidental or malicious attacks on the servers and clients in the
network. Reliability requires that clients can determine that
received messages are authentic; that is, were actually sent by the
intended server and not manufactured or modified by an intruder.
Ubiquity requires that any client can verify the authenticity of
any server using only public information. This is especially
important in such ubiquitous network services as directory
services, cryptographic key management and time
synchronization.</p>
<p>NTP includes provisions to cryptographically authenticate
individual servers using symmetric-key cryptography in which
clients authenticate servers using shared secret keys. However, the
secret keys must be distributed in advance using secure means
beyond the scope of the protocol. This can be awkward and fragile
with a large population of potential clients, possibly intruding
hackers.</p>
<p>Modern public-key cryptography provides means to reliably bind
the server identification credentials and related public values
using public directory services. However, these means carry a high
computing cost, especially when large numbers of time-critical
clients are involved as often the case with NTP servers. In
addition, there are problems unique to NTP in the interaction
between the authentication and synchronization functions, since
each requires the other for success.</p>
<p>The recent NTP Version 4 includes a revised security model and
authentication scheme supporting both symmetric and public-key
cryptography. The public-key variant is specially crafted to reduce
the risk of intrusion, minimize the consumption of processor
resources and minimize the vulnerability to hacker attack.</p>
<h4>Computer Clock Modelling and Error Analysis</h4>
Most computers include a quartz resonator-stabilized oscillator and
hardware counter that interrupts the processor at intervals of a few
milliseconds. At each interrupt, a quantity called <i>tick</i> is added
to a system variable representing the clock time. The clock can be read
by system and application programs and set on occasion to an external
reference. Once set, the clock readings increment at a nominal rate,
depending on the value of <i>tick</i>. Typical Unix system kernels
provide a programmable mechanism to increase or decrease the value of
<i>tick</i> by a small, fixed amount in order to amortize a given time
adjustment smoothly over multiple <i>tick</i> intervals.
hardware counter that interrupts the processor at intervals of a
few milliseconds. At each interrupt, a quantity called <i>tick</i>
is added to a system variable representing the clock time. The
clock can be read by system and application programs and set on
occasion to an external reference. Once set, the clock readings
increment at a nominal rate, depending on the value of <i>tick</i>.
Typical Unix system kernels provide a programmable mechanism to
increase or decrease the value of <i>tick</i> by a small, fixed
amount in order to amortize a given time adjustment smoothly over
multiple <i>tick</i> intervals.
<p>Clock errors are due to variations in network delay and latencies in
computer hardware and software (jitter), as well as clock oscillator
instability (wander). The time of a client relative to its server can be
expressed
<p>Clock errors are due to variations in network delay and
latencies in computer hardware and software (jitter), as well as
clock oscillator instability (wander). The time of a client
relative to its server can be expressed</p>
<p><center><i>T</i>(<i>t</i>) = <i>T</i>(<i>t</i><sub>0</sub>) +
<i>R</i>(<i>t - t</i><sub>0</sub>) + 1/2 <i>D</i>(<i>t -
T</i><sub>0</sub>)<sup>2</sup>,</center>
<center><i>T</i>(<i>t</i>) = <i>T</i>(<i>t</i><sub>0</sub>) + <i>
R</i>(<i>t - t</i><sub>0</sub>) + 1/2 <i>D</i>(<i>t -
t</i><sub>0</sub>)<sup>2</sup>,</center>
<p>where <i>t</i> is the current time, <i>T</i> is the time offset at
the last measurement update <i>t</i><sub>0</sub>, <i>R</i> is the
frequency offset and <i>D</i> is the drift due to resonator ageing. All
three terms include systematic offsets that can be corrected and random
variations that cannot. Some protocols, including DTSS, estimate only
the first term in this expression, while others, including NTP, estimate
the first two terms. Errors due to the third term, while important to
model resonator aging in precision applications, are neglected, since
they are usually dominated by errors in the first two terms.
<p>where <i>t</i> is the current time, <i>T</i> is the time offset
at the last measurement update <i>t</i><sub>0</sub>, <i>R</i> is
the frequency offset and <i>D</i> is the drift due to resonator
ageing. All three terms include systematic offsets that can be
corrected and random variations that cannot. Some protocols,
including DTSS, estimate only the first term in this expression,
while others, including NTP, estimate the first two terms. Errors
due to the third term, while important to model resonator aging in
precision applications, are neglected, since they are usually
dominated by errors in the first two terms.</p>
<p>The synchronization protocol estimates <i>T</i>(<i>t</i><sub>0</sub>)
(and <i>R</i>(<i>t</i><sub>0</sub>), where relevant) at regular
intervals <font face="symbol">t</font> and adjusts the clock to minimize
<i>T</i>(<i>t</i>) in future. In common cases, <i>R</i> can have
systematic offsets of several hundred parts-per-million (PPM) with
random variations of several PPM due to ambient temperature changes. If
not corrected, the resulting errors can accumulate to seconds per day.
In order that these errors do not exceed a nominal specification, the
protocol must periodically re-estimate <i>T</i> and <i>R</i> and
compensate for variations by adjusting the clock at regular intervals.
As a practical matter, for nominal accuracies of tens of milliseconds,
this requires clients to exchange messages with servers at intervals in
the order of tens of minutes.
<p>The synchronization protocol estimates <i>
T</i>(<i>t</i><sub>0</sub>) (and <i>R</i>(<i>t</i><sub>0</sub>),
where relevant) at regular intervals <font face="symbol">t</font>
and adjusts the clock to minimize <i>T</i>(<i>t</i>) in future. In
common cases, <i>R</i> can have systematic offsets of several
hundred parts-per-million (PPM) with random variations of several
PPM due to ambient temperature changes. If not corrected, the
resulting errors can accumulate to seconds per day. In order that
these errors do not exceed a nominal specification, the protocol
must periodically re-estimate <i>T</i> and <i>R</i> and compensate
for variations by adjusting the clock at regular intervals. As a
practical matter, for nominal accuracies of tens of milliseconds,
this requires clients to exchange messages with servers at
intervals in the order of tens of minutes.</p>
<p>Analysis of quartz-resonator stabilized oscillators show that errors
are a function of the averaging time, which in turn depends on the
interval between corrections. At correction intervals less than a few
hundred seconds, errors are dominated by jitter, while, at intervals
greater than this, errors are dominated by wander. As explained later,
the characteristics of each regime determine the algorithm used to
discipline the clock. These errors accumulate at each stratum level from
the root to the leaves of the subnet tree. It is possible to quantify
these errors by statistical means, as in NTP. This allows real-time
applications to adjust audio or video playout delay, for example.
However, the required statistics may be different for various classes of
applications. Some applications need absolute error bounds guaranteed
never to exceeded, as provided by the following correctness principles.
<p>Analysis of quartz-resonator stabilized oscillators show that
errors are a function of the averaging time, which in turn depends
on the interval between corrections. At correction intervals less
than a few hundred seconds, errors are dominated by jitter, while,
at intervals greater than this, errors are dominated by wander. As
explained later, the characteristics of each regime determine the
algorithm used to discipline the clock. These errors accumulate at
each stratum level from the root to the leaves of the subnet tree.
It is possible to quantify these errors by statistical means, as in
NTP. This allows real-time applications to adjust audio or video
playout delay, for example. However, the required statistics may be
different for various classes of applications. Some applications
need absolute error bounds guaranteed never to exceeded, as
provided by the following correctness principles.</p>
<h4>Correctness Principles</h4>
<p>Applications requiring reliable time synchronization such as air
traffic control must have confidence that the local clock is correct
within some bound relative to a given timescale such as UTC. There is a
considerable body of literature that studies these issues with respect
to various failure models such as fail-stop and Byzantine disagreement.
While these models inspire much confidence in a theoretical setting,
most require multiple message rounds for each measurement and would be
impractical in a large computer network such as the Internet. However,
it can be shown that the worst-case error in reading a remote server
clock cannot exceed one-half the roundtrip delay measured by the client.
This is a valuable insight, since it permits strong statements about the
correctness of the timekeeping system.
traffic control must have confidence that the local clock is
correct within some bound relative to a given timescale such as
UTC. There is a considerable body of literature that studies these
issues with respect to various failure models such as fail-stop and
Byzantine disagreement. While these models inspire much confidence
in a theoretical setting, most require multiple message rounds for
each measurement and would be impractical in a large computer
network such as the Internet. However, it can be shown that the
worst-case error in reading a remote server clock cannot exceed
one-half the roundtrip delay measured by the client. This is a
valuable insight, since it permits strong statements about the
correctness of the timekeeping system.</p>
<p>In the Probabilistic Clock Synchronization (PCS) scheme devised by
Cristian, a maximum error tolerance is established in advance and time
value samples associated with roundtrip delays that exceed twice this
value are discarded. By the above argument, the remaining samples must
represent time values within the specified tolerance. As the tolerance
is decreased, more samples fail the test until a point where no samples
survive. The tolerance can be adjusted for the best compromise between
the highest accuracy consistent with acceptable sample survival rate.
<p>In the Probabilistic Clock Synchronization (PCS) scheme devised
by Cristian, a maximum error tolerance is established in advance
and time value samples associated with roundtrip delays that exceed
twice this value are discarded. By the above argument, the
remaining samples must represent time values within the specified
tolerance. As the tolerance is decreased, more samples fail the
test until a point where no samples survive. The tolerance can be
adjusted for the best compromise between the highest accuracy
consistent with acceptable sample survival rate.</p>
<p>In a scheme devised by Marzullo and exploited in NTP and DTSS, the
worst-case error determined for each server determines a correctness
interval. If each of a number of servers are in fact synchronized to a
common timescale, the actual time must be contained in the intersection
of their correctness intervals. If some intervals do not intersect, then
the clique containing the maximum number of intersections is assumed
correct <i>truechimers</i> and the others assumed incorrect
<i>false<i>tick</i>ers</i>. Only the truechimers are used to adjust the
system
clock.
<p>In a scheme devised by Marzullo and exploited in NTP and DTSS,
the worst-case error determined for each server determines a
correctness interval. If each of a number of servers are in fact
synchronized to a common timescale, the actual time must be
contained in the intersection of their correctness intervals. If
some intervals do not intersect, then the clique containing the
maximum number of intersections is assumed correct <i>
truechimers</i> and the others assumed incorrect <i>
falsetickers</i>. Only the truechimers are used to adjust the
system clock.</p>
<h4>Data Grooming Algorithms</h4>
By its very nature, clock synchronization is a continuous process,
resulting in a sequence of measurements with each of possibly several
servers and resulting in a clock adjustment. In some protocols, crafted
algorithms are used to improve the time and frequency estimates and
refine the clock adjustment. Algorithms described in the literature are
based on trimmed-mean and median filter methods. The clock filter
algorithm used in NTP is based on the above observation that the
correctness interval depends on the roundtrip delay. The algorithm
accumulates offset/delay samples in a window of several samples and
selects the offset sample associated with the minimum delay. In general,
larger window sizes provide better estimates; however, stability
considerations limit the window size to about eight.
<p>The same principle could be used when selecting the best subset of
servers and combining their offsets to determine the clock adjustment.
However, different servers often show different systematic offsets, so
the best statistic for the central tendency of the server population may
not be obvious. Various kinds of clustering algorithms have been found
useful for this purpose. The one used in NTP sorts the offsets by a
quality metric, then calculates the variance of all servers relative to
each server separately. The algorithm repeatedly discards the outlyer
with the largest variance until further discards will not improve the
residual variance or until a minimum number of servers remain. The final
clock adjustment is computed as a weighted average of the survivors.
resulting in a sequence of measurements with each of possibly
several servers and resulting in a clock adjustment. In some
protocols, crafted algorithms are used to improve the time and
frequency estimates and refine the clock adjustment. Algorithms
described in the literature are based on trimmed-mean and median
filter methods. The clock filter algorithm used in NTP is based on
the above observation that the correctness interval depends on the
roundtrip delay. The algorithm accumulates offset/delay samples in
a window of several samples and selects the offset sample
associated with the minimum delay. In general, larger window sizes
provide better estimates; however, stability considerations limit
the window size to about eight.
<p>At the heart of the synchronization protocol is the algorithm used to
adjust the system clock in accordance with the final adjustment
determined by the above algorithms. This is called the clock discipline
algorithm or simply the discipline. Such algorithms can be classed
according to whether they minimize the time offset or frequency offset
or both. For instance, the discipline used in DTSS minimizes only the
time offset, while the one used in NTP minimizes both time and frequency
offsets. While the DTSS algorithm cannot remove residual errors due to
systematic frequency errors, the NTP algorithm is more complicated and
less forgiving of design and implementation mistakes.
<p>The same principle could be used when selecting the best subset
of servers and combining their offsets to determine the clock
adjustment. However, different servers often show different
systematic offsets, so the best statistic for the central tendency
of the server population may not be obvious. Various kinds of
clustering algorithms have been found useful for this purpose. The
one used in NTP sorts the offsets by a quality metric, then
calculates the variance of all servers relative to each server
separately. The algorithm repeatedly discards the outlyer with the
largest variance until further discards will not improve the
residual variance or until a minimum number of servers remain. The
final clock adjustment is computed as a weighted average of the
survivors.</p>
<p>At the heart of the synchronization protocol is the algorithm
used to adjust the system clock in accordance with the final
adjustment determined by the above algorithms. This is called the
clock discipline algorithm or simply the discipline. Such
algorithms can be classed according to whether they minimize the
time offset or frequency offset or both. For instance, the
discipline used in DTSS minimizes only the time offset, while the
one used in NTP minimizes both time and frequency offsets. While
the DTSS algorithm cannot remove residual errors due to systematic
frequency errors, the NTP algorithm is more complicated and less
forgiving of design and implementation mistakes.</p>
<p>All clock disciplines function as a feedback loop, with measured
offsets used to adjust the clock oscillator phase and frequency to match
the external synchronization source. The behavior of feedback loops is
well understood and modelled by mathematical analysis. The significant
design parameter is the time constant, or responsiveness to external or
internal variations in time or frequency. Optimum selection of time
constant depends on the interval between update messages. In general,
the longer these intervals, the larger the time constant and vice versa.
In practice and with typical network configurations the optimal poll
intervals vary between one and twenty minutes for network paths to some
thousands of minutes for modem paths.
offsets used to adjust the clock oscillator phase and frequency to
match the external synchronization source. The behavior of feedback
loops is well understood and modelled by mathematical analysis. The
significant design parameter is the time constant, or
responsiveness to external or internal variations in time or
frequency. Optimum selection of time constant depends on the
interval between update messages. In general, the longer these
intervals, the larger the time constant and vice versa. In practice
and with typical network configurations the optimal poll intervals
vary between one and twenty minutes for network paths to some
thousands of minutes for modem paths.</p>
<h4>Further Reading</h4>
<ol>
<li>
<p>Cristian, F. Probabilistic clock synchronization. In Distributed
Computing 3, Springer Verlag, 1989, 146-158.</p>
</li>
<p><li>Cristian, F. Probabilistic clock synchronization. In Distributed
Computing 3, Springer Verlag, 1989, 146-158.</li>
<li>
<p>Digital Time Service Functional Specification Version T.1.0.5.
DigitalEquipment Corporation, 1989.</p>
</li>
<p><li>Digital Time Service Functional Specification Version T.1.0.5.
DigitalEquipment Corporation, 1989.</li>
<p><li>Gusella, R., and S. Zatti. TEMPO - A network time controller for
<li>
<p>Gusella, R., and S. Zatti. TEMPO - A network time controller for
a distributed Berkeley UNIX system. IEEE Distributed Processing
Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in:
Proc. Summer 1984 USENIX (Salt Lake City, June 1984).</li>
Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also
in: Proc. Summer 1984 USENIX (Salt Lake City, June 1984).</p>
</li>
<p><li>Kopetz, H., and W. Ochsenreiter. Clock synchronization in
distributed real-time systems. IEEE Trans. Computers C-36, 8 (August
1987), 933-939.</li>
<li>
<p>Kopetz, H., and W. Ochsenreiter. Clock synchronization in
distributed real-time systems. IEEE Trans. Computers C-36, 8
(August 1987), 933-939.</p>
</li>
<p><li>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
presence of faults. JACM 32, 1 (January 1985), 52-78.</li>
<li>
<p>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
presence of faults. JACM 32, 1 (January 1985), 52-78.</p>
</li>
<p><li>Marzullo, K., and S. Owicki. Maintaining the time in a
distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-
54.</li>
<li>
<p>Marzullo, K., and S. Owicki. Maintaining the time in a
distributed system. ACM Operating Systems Review 19, 3 (July 1985),
44-54.</p>
</li>
<p><li>Mills, D.L. Internet time synchronization: the Network Time
Protocol. IEEE Trans. Communications COM-39, 10 (October 1991), 1482-
1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global States and
Time in Distributed Systems, IEEE Press, Los Alamitos, CA, 91-102.</li>
<p><li>Mills, D.L. Modelling and analysis of computer network clocks.
Electrical Engineering Department Report 92-5-2, University of Delaware,
May 1992, 29 pp.</li>
<li>
<p>Mills, D.L. Adaptive hybrid clock discipline algorithm for the
Network Time Protocol. <i>IEEE/ACM Trans. Networking 6, 5</i>
(October 1998), 505-514.</p>
</li>
<p><li>NIST Time and Frequency Dissemination Services. NBS Special
<li>
<p>Mills, D.L. Improved algorithms for synchronizing computer
network clocks. <i>IEEE/ACM Trans. Networks 3, 3</i> (June 1995),
245-254.</p>
</li>
<li>
<p>Mills, D.L. Internet time synchronization: the Network Time
Protocol. IEEE Trans. Communications COM-39, 10 (October 1991),
1482-1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global
States and Time in Distributed Systems, IEEE Press, Los Alamitos,
CA, 91-102.</p>
</li>
<li>
<p>Mills, D.L. Modelling and analysis of computer network clocks.
Electrical Engineering Department Report 92-5-2, University of
Delaware, May 1992, 29 pp.</p>
</li>
<li>
<p>NIST Time and Frequency Dissemination Services. NBS Special
Publication432 (Revised 1990), National Institute of Science and
Technology, U.S. Department of Commerce, 1990.</li>
Technology, U.S. Department of Commerce, 1990.</p>
</li>
<p><li>Schneider, F.B. A paradigm for reliable clock synchronization.
<li>
<p>Schneider, F.B. A paradigm for reliable clock synchronization.
Department of Computer Science Technical Report TR 86-735, Cornell
University, February 1986.</li>
University, February 1986.</p>
</li>
<p><li>Srikanth, T.K., and S. Toueg. Optimal clock synchronization. JACM
34, 3 (July 1987), 626-645.</li>
<p><li>Stein, S.R. Frequency and time - their measurement and
characterization (Chapter 12). In: E.A. Gerber and A. Ballato (Eds.).
Precision Frequency Control, Vol. 2, Academic Press, New York 1985, 191-
232, 399-416. Also in: Sullivan, D.B., D.W. Allan, D.A. Howe and F.L.
Walls (Eds.). Characterization of Clocks and Oscillators. National
Institute of Standards and Technology Technical Note 1337, U.S.
Government Printing Office (January, 1990), TN61-TN119.</li>
<li>
<p>Srikanth, T.K., and S. Toueg. Optimal clock synchronization.
JACM 34, 3 (July 1987), 626-645.</p>
</li>
<li>
<p>Stein, S.R. Frequency and time - their measurement and
characterization (Chapter 12). In: E.A. Gerber and A. Ballato
(Eds.). Precision Frequency Control, Vol. 2, Academic Press, New
York 1985, 191-232, 399-416. Also in: Sullivan, D.B., D.W. Allan,
D.A. Howe and F.L. Walls (Eds.). Characterization of Clocks and
Oscillators. National Institute of Standards and Technology
Technical Note 1337, U.S. Government Printing Office (January,
1990), TN61-TN119.</p>
</li>
</ol>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"home"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

124
contrib/ntp/html/extern.htm
View File

@ -1,40 +1,108 @@
<HTML><HEAD><TITLE>
External Clock Discipline and the Local Clock Driver
</TITLE></HEAD><BODY><H3>
External Clock Discipline and the Local Clock Driver
</H3><HR>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>External Clock Discipline and the Local Clock Driver</title>
</head>
<body>
<h3>External Clock Discipline and the Local Clock Driver</h3>
<p>The NTPv4 implementation includes provisions for an external clock, where the system clock is implemented by some external hardware device. One implementation might take the form of a bus peripheral with a high resolution counter disciplined by a GPS receiver, for example. Another implementation might involve another synchronization protocol, such as the Digital Time Synchronization Service (DTSS), where the system time is disciplined to this protocol and NTP clients of the server obtain synchronization indirectly via the server. A third implementation might be a completely separate clock discipline algorithm and synchronization protocol, such as the Lockclock algorithm used with NIST Automated Computer Time Service (ACTS) modem synchronized time.
<hr>
<p>The NTPv4 implementation includes provisions for an external
clock, where the system clock is implemented by some external
hardware device. One implementation might take the form of a bus
peripheral with a high resolution counter disciplined by a GPS
receiver, for example. Another implementation might involve another
synchronization protocol, such as the Digital Time Synchronization
Service (DTSS), where the system time is disciplined to this
protocol and NTP clients of the server obtain synchronization
indirectly via the server. A third implementation might be a
completely separate clock discipline algorithm and synchronization
protocol, such as the Lockclock algorithm used with NIST Automated
Computer Time Service (ACTS) modem synchronized time.</p>
<p>When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon <tt>ntpd</tt> to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail 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>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 Local Clock (type 1) driver 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, Digital Unix, 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. 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>Control and monitoring functions for the external clock and
driver are implemented using the <a href="driver1.htm">Local Clock
(type 1) driver</a> and the <tt>ntp_adjtime()</tt> system call.
This system call is implemented by special kernel provisions
included in the kernel of several operating systems, including
Solaris, Tru64, FreeBSD and Linux, and possibly others. When the
external clock is disabled or not implemented, the system call is
used to pass time and frequency information, as well as error
statistics, to the kernel. Besides disciplining the system time,
the same interface can be used by other applications to determine
the operating parameters of the discipline.</p>
<p>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>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>ntp__enable. set/reset by enable command. enables ntp clock discipline
<p>In order to implement a reliable mitigation between ordinary NTP
sources and the external clock source, a protocol is necessary
between the local clock driver and the external clock driver. This
is implemented using Boolean variables and certain bits in the
kernel clock status word. The Boolean variables include the
following:</p>
<p>ntp_control. set during initial configuration if kernel support is available
<p>ntp__enable. set/reset by enable command. enables ntp clock
discipline</p>
kern_enable
Set/reset by enable commandexit
<p>ntp_control. set during initial configuration if kernel support
is available kern_enable Set/reset by enable commandexit If this
switch is set, the daemon computes the offset, frequency, maximum
error, estimated error, time constand and status bits, then
provides them to the kernel via ntp_adjtime(). If this switch is
set, these values are not passed to the kernel; however, the daemon
retrieves their present values and uses them in place of the values
computed by the daemon. pps_update set in the protocol routine if
the prefer peer has survived and has offset less than 128 ms;
otherwise set to zero. pps_control Updated to the current time by
kernel support if the PPS signal is enabled and working correctly.
Set to zero in the adjust routine if the interval since the last
update exceeds 120 s.</p>
If this switch is set, the daemon computes the offset, frequency, maximum error, estimated error, time constand and status bits, then provides them to the kernel via ntp_adjtime(). If this switch is set, these values are not passed to the kernel; however, the daemon retrieves their present values and uses them in place of the values computed by the daemon.
<p>The ntp_enable and kern_enable are set by the configuration
module. Normally, both switches default on, so the daemon can
control the time and the kernel discipline can be used, if
available. The pps_update switch is set by the protocol module when
it believes the PPS provider source is legitimate and operating
within nominals. The ntp_control switch is set during configuration
by interrogating the kernel. If both the kern_enable and
ntp_control siwitches are set, the daemon disciplines the clock via
the kernel and the internal daemon discipline is disabled.</p>
pps_update
set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.
<p>The external clock driver controls the system time and clock
selection in the following way. Normally, the driver adjusts the
kernel time using the ntp_adjtime() system call in the same way as
the daemon. In the case where the kernel discipline is to be used
intact, the clock offset is provided in this call and the loop
operates as specified. In the case where the driver steers only the
frequency, the offset is specified as zero.</p>
pps_control
Updated to the current time by kernel support if the PPS signal is enabled and working correctly. Set to zero in the adjust routine if the interval since the last update exceeds 120 s.
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<p>The ntp_enable and kern_enable are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The pps_update switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The ntp_control switch is set during configuration by interrogating the kernel. If both the kern_enable and ntp_control siwitches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.
<p>The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the ntp_adjtime() system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero
d PLL/
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href="mailto:mills@udel.edu"> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></body></html>

109
contrib/ntp/html/gadget.htm
View File

@ -8,104 +8,41 @@ Gadget Box PPS Level Converter and CHU Modem
<br clear=left><hr>
<p><h4>Introduction</h4>
<h4>Introduction</h4>
<p>Many radio clocks used as a primary reference source for NTP servers
produce a pulse-per-second (PPS) signal that can be used to improve
accuracy to a high degree. However, the signals produced are usually
incompatible with the modem interface signals on the serial ports used
to connect the signal to the host. The gadget box consists of a handful
of electronic components assembled in a small aluminum box. It includes
level converters and a optional radio modem designed to decode the radio
timecode signals transmitted by the Canadian time and frequency station
CHU. A complete set of schematics, PCB artwork, drill templates can be
obrtained via the web as the distribution <a href=
"http://www.eecis.udel.edu/~mills/ntp/ntp">gadget.tar.Z</a>, or by
anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
<p>Many radio clocks used as a primary reference source for NTP servers produce a pulse-per-second (PPS) signal that can be used to improve accuracy to a high degree. However, the signals produced are usually incompatible with the modem interface signals on the serial ports used to connect the signal to the host. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional radio modem designed to decode the radio timecode signals transmitted by the Canadian time and frequency station CHU. A complete set of schematics, PCB artwork, drill templates can be obrtained via the web as the distribution <a href= "http://www.eecis.udel.edu/~mills/ntp/ntp">gadget.tar.Z</a>, or by anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
<p>The gadget box is assembled in a 5&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 <code>tty_clk</code> and <code>chu_tty</code> line disciplines in
the ntp3 distribution.
<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=driver7.htm>Radio CHU Audio Demodulator/Decoder</a> driver.
<p>This archive contains complete construction details for the gadget
box, including schematic, parts list and artwork for a two-sided,
printed-circuit board. All files are in PostScript, with the exception
of this file and an information file, which are in ASCII. The artwork is
in the 1:1 scale and is suitable for direct printing on photographic
resist for each side of the board. While a plated-through-holes process
is most convenient, it is possible to bridge the two sides using
soldered wires where necessary.
<p>This archive contains complete construction details for the gadget box, including schematic, parts list and artwork for a two-sided, printed-circuit board. All files are in PostScript, with the exception of this file and an information file, which are in ASCII. The artwork is in the 1:1 scale and is suitable for direct printing on photographic resist for each side of the board. While a plated-through-holes process is most convenient, it is possible to bridge the two sides using soldered wires where necessary.
<p><h4>Circuit Description</h4>
<h4>Circuit Description</h4>
<p>Following is a brief functional description of the device. See the
schematic diagram gadget.s01 for reference. The audio output of a
shortwave radio tuned to CHU at 3330, 7335 or 14670 kHz is connected to
J2. A level of at least 30 mV peak-peak is required, such as provided by
the recorder output on many receivers. The input level is adjusted by
potentiometer R8 so that the timecode modulation broadcast at 31-39
seconds past the minute reliably lights green LED1, but the signals
broadcast during other seconds of the minute do not.
<p>Following is a brief functional description of the device. See the schematic diagram gadget.s01 for reference. The audio output of a shortwave radio tuned to CHU at 3330, 7335 or 14670 kHz is connected to J2. A level of at least 30 mV peak-peak is required, such as provided by the recorder output on many receivers. The input level is adjusted by potentiometer R8 so that the timecode modulation broadcast at 31-39 seconds past the minute reliably lights green LED1, but the signals broadcast during other seconds of the minute do not.
<p>Opamp U4A provides low-impedance drive for the bridged-tee bandpass
filter U4B. The filter has a bandpass of about 600 Hz at the 6-dB points
and a center frequency of about 2150 Hz. It is designed to avoid
aliasing effects with receivers of relatively wide bandpass
characteristics. The modem itself is implemented by U2 and its
associated circuitry. Resistors R4 and R1 are a 40-dB pad which matches
the filter output to the modem input. U2 is a TTL/EIA level converter
with integral power supply for bipolar signals. The modem output is
available at pin 3 (receive data) of DB25 connector J1.
<p>Opamp U4A provides low-impedance drive for the bridged-tee bandpass filter U4B. The filter has a bandpass of about 600 Hz at the 6-dB points and a center frequency of about 2150 Hz. It is designed to avoid aliasing effects with receivers of relatively wide bandpass characteristics. The modem itself is implemented by U2 and its associated circuitry. Resistors R4 and R1 are a 40-dB pad which matches the filter output to the modem input. U2 is a TTL/EIA level converter with integral power supply for bipolar signals. The modem output is available at pin 3 (receive data) of DB25 connector J1.
<p>The TTL PPS signal is connected via J3 to a retriggerable one-shot
U3A, which generates a TTL pulse of width determined by potentiometer
R7. The pulse width is determined by the bit rate of the attached serial
port. In the common case the width is one bit-time, such as 26 us for
38.4 kbps, for example. This appears to the port as a single start bit
of zero followed by eight bits of ones and a stop bit of one. The second
one-shot U3B generates a 200-ms pulse suitable for driving the amber
LED3 as a visual monitor. The output of U3A is converted to EIA levels
by U1 and appears at pin 12 (secondary receive data) of J1.
<p>The TTL PPS signal is connected via J3 to a retriggerable one-shot U3A, which generates a TTL pulse of width determined by potentiometer R7. The pulse width is determined by the bit rate of the attached serial port. In the common case the width is one bit-time, such as 26 us for 38.4 kbps, for example. This appears to the port as a single start bit of zero followed by eight bits of ones and a stop bit of one. The second one-shot U3B generates a 200-ms pulse suitable for driving the amber LED3 as a visual monitor. The output of U3A is converted to EIA levels by U1 and appears at pin 12 (secondary receive data) of J1.
<p>If only the PPS circuit is required, U2 and U4 can be deleted and the
gadget box powered from the EIA modem-control signal at pin 20 (terminal
ready) of J1, assuming this signal is placed in the on (positive
voltage) condition by the computer program. J1 is wired to keep most
finicky UARTs and terminal-driver programs happy. If the CHU circuit is
required, an external 12-volt AC transformer or 9-12-volt DC supply
connected to J4 is required. Red LED2 indicates power is supplied to the
box.
<p>If only the PPS circuit is required, U2 and U4 can be deleted and the gadget box powered from the EIA modem-control signal at pin 20 (terminal ready) of J1, assuming this signal is placed in the on (positive voltage) condition by the computer program. J1 is wired to keep most finicky UARTs and terminal-driver programs happy. If the CHU circuit is required, an external 12-volt AC transformer or 9-12-volt DC supply
connected to J4 is required. Red LED2 indicates power is supplied to the box.
<p>Files
<p>Following is a list of files included in this archive. All files are
in PostScript, except the <code>README</code> and
<code>gadget.lst</code> files, which are in ASCII. The files
<code>gadget.s01, gadget.s02</code> and <code>gadget.lst</code> were
generated using the Schema schematic-capture program from Omation. The
printed-circuit files <code>*.lpr</code> were generated using Schema-
PCB, also from Omation.
<p>Following is a list of files included in this archive. All files are in PostScript, except the <tt>README</tt> and <tt>gadget.lst</tt> files, which are in ASCII. The files <tt>gadget.s01, gadget.s02</tt> and <tt>gadget.lst</tt> were generated using the Schema schematic-capture program from Omation. The printed-circuit files <tt>*.lpr</tt> were generated using Schema-PCB, also from Omation.
<p>Files
<p><code>README</code> - helpful information
<br><code>gadget.s01</code> - circuit schematic
<br><code>gadget.s02</code> - minibox assembly drawing
<br><code>gadget.lst</code> - net list, pin list, parts list, etc.
<br><code>gen0102.lpr</code> - pcb x-ray diagram
<br><code>art01.lpr</code> - pcb artword side 1
<br><code>art02.lpr</code> - pcb artwork side 2
<br><code>adt0127.lpr</code> - pcb assembly drawing
<br><code>dd0124.lpr</code> - pcb drill drawing
<br><code>sm0228.lpr</code> - pcb solder mask (side 2)
<br><code>sst0126.lpr</code> - pcb silkscreen mask (side 1)
<p><tt>README</tt> - helpful information
<br><tt>gadget.s01</tt> - circuit schematic
<br><tt>gadget.s02</tt> - minibox assembly drawing
<br><tt>gadget.lst</tt> - net list, pin list, parts list, etc.
<br><tt>gen0102.lpr</tt> - pcb x-ray diagram
<br><tt>art01.lpr</tt> - pcb artword side 1
<br><tt>art02.lpr</tt> - pcb artwork side 2
<br><tt>adt0127.lpr</tt> - pcb assembly drawing
<br><tt>dd0124.lpr</tt> - pcb drill drawing
<br><tt>sm0228.lpr</tt> - pcb solder mask (side 2)
<br><tt>sst0126.lpr</tt> - pcb silkscreen mask (side 1)
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a></address></a></body></html>

181
contrib/ntp/html/genkeys.htm Normal file
View File

@ -0,0 +1,181 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntp-genkeys - generate public and private keys</title>
</head>
<body>
<h3><tt>ntp-genkeys</tt> - generate public and private keys</h3>
<img align="left" src="pic/alice23.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Alice holds the key.<br clear="left">
</p>
<hr>
<h4>Synopsis</h4>
<tt>ntp-genkeys</tt>
<h4>Description</h4>
<p>This program generates random keys used by either or both the
NTPv3/NTPv4 symmetric key or the NTPv4 public key (Autokey)
cryptographic authentication schemes. By default the program
generates the <tt>ntp.keys</tt> file containing 16 random symmetric
keys. In addition, if the <tt>rsaref20</tt> package is configured
for the software build, the program generates cryptographic values
used by the Autokey scheme. These values are incorporated as a set
of three files, <tt>ntpkey</tt> containing the RSA private key,
<tt>ntpkey_<i>host</i></tt> containing the RSA public key, where
<tt><i>host</i></tt> is the DNS name of the generating machine, and
<tt>ntpkey_dh</tt> containing the parameters for the Diffie-Hellman
key-agreement algorithm. All files and are in printable ASCII
format. A timestamp in NTP seconds is appended to each. Since the
algorithms are seeded by the system clock, each run of this program
produces a different file and file name.</p>
<p>The <tt>ntp.keys</tt> file contains 16 MD5 keys. Each key
consists of 16 characters randomized over the ASCII 95-character
printing subset. The file is read by the daemon at the location
specified by the <tt>keys</tt> configuration file command and made
visible only to root. An additional key consisting of a easily
remembered password should be added by hand for use with the <tt>
ntpq</tt> and <tt>ntpdc</tt> programs. The file must be distributed
by secure means to other servers and clients sharing the same
security compartment. While the key identifiers for MD5 and DES
keys must be in the range 1-65534, inclusive, the <tt>
ntp-genkeys</tt> program uses only the identifiers from 1 to 16.
The key identifier for each association is specified as the key
argument in the <tt>server</tt> or peer configuration file
command.</p>
<p>The <tt>ntpkey</tt> file contains the RSA private key. It is
read by the daemon at the location specified by the <tt>
privatekey</tt> argument of the <tt>crypto</tt> configuration file
command and made visible only to root. This file is useful only to
the machine that generated it and never shared with any other
daemon or application program.</p>
<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public
key, where <tt><i>host</i></tt> is the DNS name of the host that
generated it. The file is read by the daemon at the location
specified by the <tt>publickey</tt> argument to the <tt>server</tt>
or <tt>peer</tt> configuration file command. This file can be
widely distributed and stored without using secure means, since the
data are public values.</p>
<p>The <tt>ntp_dh</tt> file contains two Diffie-Hellman parameters:
the prime modulus and the generator. The file is read by the daemon
at the location specified by the <tt>dhparams</tt> argument of the
<tt>crypto</tt> configuration file command. The file can be
distributed by insecure means to other servers and clients sharing
the same key agreement compartment, since the data are public
values.</p>
<p>The file formats begin with two lines, the first containing the
generating system DNS name and the second the datestamp. Lines
beginning with <tt>#</tt> are considered comments and ignored by
the daemon. In the <tt>ntp.keys</tt> file, the next 16 lines
contain the MD5 keys in order. If necessary, this file can be
further customized by an ordinary text editor. The format is
described in the following section. In the <tt>ntpkey</tt> and <tt>
ntpkey_<i>host</i></tt> files, the next line contains the modulus
length in bits followed by the key as a PEM encoded string. In the
<tt>ntpkey_dh</tt> file, the next line contains the prime length in
bytes followed by the prime as a PEM encoded string, and the next
and final line contains the generator length in bytes followed by
the generator as a PEM encoded string.</p>
<p>Note: See the file <tt>./source/rsaref.h</tt> in the <tt>
rsaref20</tt> package for explanation of return values, if
necessary.</p>
<h4>Symmetric Key File Format</h4>
In the case of DES, the keys are 56 bits long with, depending on
type, a parity check on each byte. In the case of MD5, the keys are
64 bits (8 bytes). <tt>ntpd</tt> reads its keys from a file
specified using the <tt>-k</tt> command line option or the <tt>
keys</tt> statement in the configuration file. While key number 0
is fixed by the NTP standard (as 56 zero bits) and may not be
changed, one or more of the keys numbered 1 through 15 may be
arbitrarily set in the keys file.
<p>The key file uses the same comment conventions as the
configuration file. Key entries use a fixed format of the form</p>
<p><i><tt>keyno type key</tt></i></p>
<p>where <i><tt>keyno</tt></i> is a positive integer, <i><tt>
type</tt></i> is a single character which defines the key format,
and <i><tt>key</tt></i> is the key itself.</p>
<p>The key may be given in one of three different formats,
controlled by the <i><tt>type</tt></i> character. The three key
types, and corresponding formats, are listed following.</p>
<dl>
<dt><tt>S</tt></dt>
<dd>The key is a 64-bit hexadecimal number in the format specified
in the DES specification; that is, the high order seven bits of
each octet are used to form the 56-bit key while the low order bit
of each octet is given a value such that odd parity is maintained
for the octet. Leading zeroes must be specified (i.e., the key must
be exactly 16 hex digits long) and odd parity must be maintained.
Hence a zero key, in standard format, would be given as <tt>
0101010101010101</tt>.</dd>
<dt><tt>N</tt></dt>
<dd>The key is a 64-bit hexadecimal number in the format specified
in the NTP standard. This is the same as the DES format, except the
bits in each octet have been rotated one bit right so that the
parity bit is now the high order bit of the octet. Leading zeroes
must be specified and odd parity must be maintained. A zero key in
NTP format would be specified as <tt>8080808080808080</tt>.</dd>
<dt><tt>A</tt></dt>
<dd>The key is a 1-to-8 character ASCII string. A key is formed
from this by using the low order 7 bits of each ASCII character in
the string, with zeroes added on the right when necessary to form a
full width 56-bit key, in the same way that encryption keys are
formed from Unix passwords.</dd>
<dt><tt>M</tt></dt>
<dd>The key is a 1-to-8 character ASCII string, using the MD5
authentication scheme. Note that both the keys and the
authentication schemes (DES or MD5) must be identical between a set
of peers sharing the same key number.</dd>
</dl>
<p>Note that the keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt>
programs are checked against passwords requested by the programs
and entered by hand, so it is generally appropriate to specify
these keys in ASCII format.</p>
<h4>Files</h4>
The RSA Laboratories package <tt>rsaref20</tt> of cryptographic
routines is necessary in order to build and use this program.
<h4>Bugs</h4>
It can take quite a while to generate the RSA public/private key
pair and Diffie-Hellman parameters, from a few seconds on a modern
workstation to several minutes on older machines.
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

10
contrib/ntp/html/hints.htm
View File

@ -2,7 +2,13 @@
Hints and Kinks
</title></head><body><h3>
Hints and Kinks
</h3><hr>
</h3>
<img align=left src=pic/alice35.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Mother in law has all the answers.
<br clear=left><hr>
<p>This is an index for a set of troubleshooting notes contained in
individual text files in the <tt>./hints</tt> directory. They were
@ -19,7 +25,7 @@ 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. Bash <a href=http:hints>here</a> for a directory listing.
advise. See the <a href=http:hints>directory listing</a>.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>

15
contrib/ntp/html/hints/freebsd Normal file
View File

@ -0,0 +1,15 @@
If you are compiling under FreeBSD and see messages in the syslogs that
indicate that the ntpd process is trying to use unavailable sched_
calls, it means you are running a kernel that does not have the POSIX
scheduling calls enabled.
You have two choices:
- Ignore the messages
- Generate a new kernel, where the kernel configuration file contains
the lines:
options "P1003_1B"
options "_KPOSIX_PRIORITY_SCHEDULING"
options "_KPOSIX_VERSION=199309L"

153
contrib/ntp/html/hints/vxworks.htm Normal file
View File

@ -0,0 +1,153 @@
<HTML>
<HEAD>
<TITLE>vxWorks Port of NTP</TITLE>
</HEAD>
<BODY LINK="#00008B" VLINK="#8B0000">
<H1>VxWorks port of NTP </H1>
<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 main() is not allowed, and where the configure
scripts need to be altered. </P>
<H1><B>Configuration issues</B></H1>
<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>
<P>Where I have 386 you will need to put in your target type. The vxWorks
tree entry point is /usr/wind. If these are the same for your system, you
should be able to cut and paste the changes. </P>
<P><BLINK>WARNING: Check you are not overwriting files, before entering
the following: there should be no conflict, but check first... </BLINK></P>
<P>export CC=&quot;cc386 -nostdlib -m486 -DCPU=I80486 -I/usr/wind/target/h&quot;
<BR>
export RANLIB=ranlib386 <BR>
export AR=ar386 <BR>
export VX_KERNEL=/usr/wind/target/config/ims_std_bsp/vxWorks <BR>
cd /usr/wind/target/sys <BR>
ln -s ../signal.h <BR>
ln -s ../time.h <BR>
ln -s socket.h sockio.h <BR>
ln -s ../selectLib.h select.h <BR>
ln -s ../timers.h <BR>
touch file.h param.h resource.h utsname.h var.h ../netdb.h ../a.out.h ../termios.h
<BR>
echo &quot; ******ADD #include \&quot;sys/times.h\&quot; to sys/time.h
&quot; </P>
<P>The configure script must be changed in the following way to get the
linking tests to work, once in the correct directory issue the following
commands: <BR>
sed -e 's%main.*()%vxmain()%' configure &gt; configure.vxnew <BR>
mv configure.vxnew configure <BR>
chmod 755 configure </P>
<P>The new version 4 of NTP requires some maths functions so it links in the
maths library (-lm) in the ntpd <a href="../ntpd/Makefile.am">Makefile.am</a>
change the line "ntpd_LDADD = $(LDADD) -lm" by removing the "-lm".<BR>
You are now ready to compile</P>
<P><BR>
The <A HREF="../configure.in">configure.in </A>file needed to be altered
to allow for a host-target configuration to take place. </P>
<UL>
<LI>The define SYS_VXWORKS was added to the compilation flags. </LI>
<LI>Little endianess is set if the target is of type iX86. </LI>
<LI>The size of char, integer, long values are all set. If Wind River ever
changes these values they will need to be updated. </LI>
<LI>clock_settime() is defined to be used for setting the clock. </LI>
<LI>The Linking flags have -r added to allow for relinking into the vxWorks
kernel </LI>
</UL>
<P>Unfortunately I have had to make use of the <A HREF="../include/ntp_machine.h">ntp_machine.h
</A>file to add in the checks that would have been checked at linking stage
by autoconf, a better method should be devised. </P>
<UL>
<LI>There is now a NO_MAIN_ALLOWED define that simulates command line args,
this allows the use of the normal startup sysntax. </LI>
<LI>POSIX timers have been added. </LI>
<LI>Structures normally found in netdb.h have been added with, the corresponding
code is in <A HREF="../libntp/machines.c">machines.c </A>. Where possible
the defines for these have been kept non-vxWorks specific.</LI>
</UL>
<P>Unfortunately there are still quite a few SYS_VXWORKS type defines in
the source, but I have eliminated as many as possible. You have the choice
of using the usrtime.a library avaliable from the vxworks archives or forgoing
adjtime() and using the clock_[get|set]time().The <A HREF="../include/ntp_machine.h">ntp_machine.h
</A>file clearly marks how to do this. </P>
<H1><B>Compilation issues</B> </H1>
<P>You will need autoconf and automake ... available free from the gnu
archives worldwide. </P>
<P>The variable arch is the target architecture (e.g. i486) </P>
<P>mkdir A.vxworks (or whatever....) <BR>
cd A.vxworks <BR>
../configure --target=arch-wrs-vxworks [any other options] <BR>
make </P>
<P>Options I normally use are the --disable-all-clocks --enable-LOCAL-CLOCK flags.
The program should proceed to compile without problem. The daemon ntpd,
ntpdate, ntptrace, ntpdc, ntpq programs and of course the libraries are
all fully ported. The other utilities are not, but they should be easy
to port. </P>
<H1>Running the software </H1>
<P>Load in the various files, call them in the normal vxWorks function
type manner. Here are some examples. Refer to the man pages for further
information. </P>
<P>ld &lt; ntpdate/ntpdate <BR>
ld &lt; ntpd/ntpd <BR>
ld &lt; ntptrace/ntptrace <BR>
ld &lt; ntpq/ntpq <BR>
ld &lt; ntpdc/ntpdc <BR>
ntpdate (&quot;-b&quot;, &quot;192.168.0.245&quot;) <BR>
sp(ntpd, &quot;-c&quot;, &quot;/export/home/casey/ntp/ntp.conf&quot;)
<BR>
ntpdc(&quot;-c&quot;, &quot;monlist&quot;, &quot;192.168.0.244&quot;)
<BR>
ntpq(&quot;-c&quot;, &quot;peers&quot;, &quot;192.168.0.244&quot;) <BR>
ntptrace(&quot;192.168.0.244&quot;) <BR>
</P>
<H1>Bugs and such </H1>
<P>Should you happen across any bugs, please let me know, or better yet
fix them and submit a patch. Remember to make you patch general for Vxworks,
not just for your particular architecture.
<A HREF="http://www.ccii.co.za">CCII Systems
(Pty) Ltd</A>, my ex employers, sponsored the time to this port.
Please let me know how it goes, I would be most interested in offsets
and configurations. </P>
<P><BR>
</P>
<P>Casey Crellin</A> <BR>
<A HREF="mailto:casey@csc.co.za">casey@csc.co.za</A> </P>
<P><BR>
</P>
</BODY>
</HTML>

43
contrib/ntp/html/hints/winnt.htm
View File

@ -1,5 +1,8 @@
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.7 [en] (WinNT; I) [Netscape]">
<title>NTP on Windows NT</title>
</head>
<body>
@ -7,11 +10,23 @@
<h1>
NTP 4.x for Windows NT</h1>
<h2>
Do not try to compile NTP-4.0.99i under WINNT, it will not work.
Fixed NTP-4.0.99i; look for next release to be functional.
Sven - May 11 2000
</h2>
<h2>
Download NTP-4.0.99g for the last stable WINNT port.
I am working on adapting the major changes starting with 99i
and getting things running again. Sven - April 25 2000
</h2>
<h2>
Introduction</h2>
The NTP 4 distribution runs as service on (i386) Windows NT 4.0 and Windows
2000. The binaries now work on all dual processor systems (mostly Dell)
that have been tested. This port has not been tested on the Alpha platform.
2000. The binaries work on dual processor systems. This port has not been
tested on the Alpha platform.
<p>Refer to System Requirements and Instructions for how to compile the
program.
<h2>
@ -71,9 +86,6 @@ Compiling Requirements</h2>
<li>
<tt>Microsoft Visual C++ 6.0</tt></li>
<li>
<tt>Perl5 </tt><a href="http://www.perl.org">http://www.perl.org</a></li>
<li>
Some version of the archiving program <tt>ZIP</tt>.</li>
</ul>
@ -82,10 +94,6 @@ Some version of the archiving program <tt>ZIP</tt>.</li>
Compiling Instructions</h2>
<ol>
<li>
Install Perl and set the PERL environment variable to your Perl directory
(e.g. C:\PERL)</li>
<li>
Unpack the NTP-4.x.tar.gz</li>
@ -144,9 +152,9 @@ is no reason that the system clock should be that much off during bootup
if 'ntpd' was running before, you may wish to override this default and/or
pass other command line directives.
<p>Use the registry editor to edit the value for the ntpd executable under
LocalMachine\System\CurrentControlSet\Services\NetworkTimeProtocol.
<p>Add the -g option behind "%INSTALLDIR>\ntpd". This will force NTP to
accept large time errors (including 1.1.1980 00:00)
LocalMachine\System\CurrentControlSet\Services\NTP.
<p>Add the -g option to the ImagePath key, behind "%INSTALLDIR>\ntpd.exe".
This will force NTP to accept large time errors (including 1.1.1980 00:00)
<h2>
Bug Reports</h2>
Send bug reports to <a href="news://comp.protocols.time.ntp">news://comp.protocols.time.ntp</a>
@ -154,6 +162,17 @@ and Sven_Dietrich@Trimble.COM
<h2>
Change Log</h2>
<h3>
Last revision 16 February 1999&nbsp; Version 4.0.99e.</h3>
<b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
<p><b>Significant Changes:</b>
<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.</li>
</ul>
<h3>
Last revision 15 November 1999&nbsp; Version 4.0.98f.</h3>
<b>by Sven Dietrich (sven_dietrich@trimble.com)</b>

7
contrib/ntp/html/howto.htm
View File

@ -2,7 +2,12 @@
How to Write a Reference Clock Driver
</title></head><body><h3>
How to Write a Reference Clock Driver
</h3><hr>
</h3>
<img align=left src=pic/pogo4.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
<p>You need a little magic.
<br clear=left><hr>
<h4>Description</h4>

390
contrib/ntp/html/index.htm
View File

@ -1,201 +1,261 @@
<html><head><title>
The Network Time Protocol (NTP) Distribution
</title></head><body><h3>
The Network Time Protocol (NTP) Distribution
</h3>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>The Network Time Protocol (NTP) Distribution</title>
</head>
<body>
<h3>The Network Time Protocol (NTP) Distribution</h3>
<IMG align=left SRC=pic/barnstable.gif>From <i>pogo</i>, Walt Kelly
<img align="left" src="pic/barnstable.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm"><i>P.T. Bridgeport
Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
<p>Pleased to meet you.
<BR clear=left><HR>
<p>Pleased to meet you.<br clear="left">
</p>
<H4>Introduction</H4>
<hr>
<h4>Introduction</h4>
Note: The software contained in this distribution is available without
charge under the conditions set forth in the <A
HREF=copyright.htm>Copyright Notice</A>.
Note: The software contained in this distribution is available
without charge under the conditions set forth in the <a href=
"copyright.htm">Copyright Notice</a>.
<P>The Network Time Protocol (NTP) is used to synchronize the time of a
computer client or server to another server or reference time source,
such as a radio or satellite receiver or modem. It provides client
accuracies typically within a millisecond on LANs and up to a few tens
of milliseconds on WANs relative to a primary server synchronized to
Coordinated Universal Time (UTC) via a Global Positioning Service (GPS)
receiver, for example. Typical NTP configurations utilize multiple
redundant servers and diverse network paths, in order to achieve high
accuracy and reliability. Some configurations include cryptographic
authentication to prevent accidental or malicious protocol attacks.
<p>The Network Time Protocol (NTP) is used to synchronize the time
of a computer client or server to another server or reference time
source, such as a radio or satellite receiver or modem. It provides
accuracies typically within a millisecond on LANs and up to a few
tens of milliseconds on WANs relative to Coordinated Universal Time
(UTC) via a Global Positioning Service (GPS) receiver, for example.
Typical NTP configurations utilize multiple redundant servers and
diverse network paths in order to achieve high accuracy and
reliability. Some configurations include cryptographic
authentication to prevent accidental or malicious protocol attacks
and some provide automatic server discovery using IP multicast.</p>
<P>Background information on computer network time synchronization can
be found on the <A HREF=exec.htm>Executive Summary - Computer Network
Time Synchronization</A> page. Discussion on protocol conformance issues
and interoperability with previous NTP versions can be found in the <A
HREF=biblio.htm>Protocol Conformance Statement</A> page. Discussion on
year-2000 issues can be found in the <A HREF=y2k.htm>Year 2000
Conformance Statement page</A>. Background information, bibliography and
briefing slides suitable for presentations can be found in the <A
HREF=http://www.eecis.udel.edu/~mills/ntp.htm> Network Time
Synchronization Project</A> page.
<p>Background information on computer network time synchronization
can be found on the <a href="exec.htm">Executive Summary - Computer
Network Time Synchronization</a> page. Discussion on protocol
conformance issues and interoperability with previous NTP versions
can be found in the <a href="biblio.htm">Protocol Conformance
Statement</a> page. Discussion on how NTP reckons the time can be
found in the <a href="leap.htm">NTP Timescale and Leap Seconds</a>
page. Background information, bibliography and briefing slides
suitable for presentations can be found in the <a href=
"http://www.eecis.udel.edu/~mills/ntp.htm">Network Time
Synchronization Project</a> page. Additional information can be
found at the NTP web site <a href="http://www.ntp.org">
www.ntp.org</a>. Please send bug reports to <a href=
"mailto:bugs@mail.ntp.org">&lt;bugs@mail.ntp.org&gt;</a>.</p>
<H4>Building and Installing NTP</H4>
<h4>Building and Installing NTP</h4>
The <A HREF=build.htm>Building and Installing the Distribution
</A>page presents an overview of the procedures for compiling the
distribution and installing it on a typical client or server. The build
procedures inspect the system hardware and software environment and
automatically select the appropriate options for that environment. While
these procedures work with most computers and operating systems marketed
today, exceptions requiring manual intervention do exist, as documented
in the <A HREF=config.htm>Configuration Options </A>and <A
HREF=release.htm>Release Notes </A>pages.
NTP supports Unix and Windows (NT4 and 2000) systems. The <a href=
"build.htm">Building and Installing the Distribution</a> page
presents an overview of the procedures for compiling the
distribution and installing it on a typical client or server. The
build procedures inspect the system hardware and software
environment and automatically select the appropriate options for
that environment. While these procedures work with most computers
and operating systems marketed today, exceptions requiring manual
intervention do exist, as documented in the <a href="config.htm">
Configuration Options</a> and <a href="release.htm">Release
Notes</a> pages. Note that support for strong cryptography requires
cryptographic libraries not included in this distribution.
<P>Bringing up a NTP primary server requires a radio or satellite
receiver or modem. The distribution includes hardware drivers for over
two dozen radio clocks and modem services. A list of the particular
receivers and modem drivers supported in the distribution is given in
the <A HREF=refclock.htm>Reference Clock Drivers </A>page. For most
popular workstations marketed by Digital, Sun and Hewlett Packard, as
well as widely available Unix clones such as FreeBSD and Linux, the
automatic build procedures select all drivers that run on the target
machine. While this increases the size of the executable binary
somewhat, individual drivers can be included or excluded using the
configure utility documented in the Configuration Options page.
<p>Bringing up a NTP primary server requires a radio or satellite
receiver or modem. It is also possible to configure a machine on an
isolated network with the local clock driver and have other
machines synchronize to it. The distribution includes hardware
drivers for the local clock and over three dozen radio clocks and
modem services. A list of supported drivers is given in the <a
href="refclock.htm">Reference Clock Drivers</a> page. For most
popular workstations marketed by Digital/Compaq, Sun and Hewlett
Packard, as well as widely available Unix clones such as FreeBSD
and Linux, the automatic build procedures select all drivers that
run on the target machine. While this increases the size of the
executable binary somewhat, individual drivers can be included or
excluded using the configure utility documented in the
Configuration Options page.</p>
<H4>Configuring Clients and Servers</H4>
<p>NTP is by its very nature a complex distributed network application
and can be configured and used for a great many widely divergent
timekeeping scenarios. The documentation presented on these pages
attempts to cover the entire suite of configuration, operation and
maintenance facilities which this distribution supports. However, most
applications will need only a few of these facilities. If this is the
case, the <a href=quick.htm>Quick Start</a> page may be useful to get a
simple workstation on the air with an existing server.
<h4>Configuring Clients and Servers</h4>
<p>However, in order to participate in the existing NTP synchronization
subnet and obtain accurate, reliable time, it is usually necessary to
construct an appropriate configuration file, commonly called
<TT>ntp.conf</TT>, which establishes the servers and/or external
receivers or modems to be used by this particular machine. Directions
for constructing this file are in the <A HREF=notes.htm>Notes on
Configuring NTP and Setting up a NTP Subnet </A>page. However, in many
common cases involving simple network topologies and workstations, the
file data can be specified entirely on the command line.
<p>NTP is by its very nature a complex distributed network
application and can be configured and used for a great many widely
divergent timekeeping scenarios. The documentation presented on
these pages attempts to cover the entire suite of configuration,
operation and maintenance facilities which this distribution
supports. However, most applications will need only a few of these
facilities. If this is the case, the <a href="quick.htm">Quick
Start</a> page may be useful to get a simple workstation on the air
with an existing server.</p>
<P>The most important factor in providing accurate, reliable time is the
selection of modes and servers to be used in the configuration file. NTP
support for one or more computers is normally engineered as part of the
existing NTP synchronization subnet. The existing NTP subnet consists of
a multiply redundant hierarchy of servers and clients, with each level
in the hierarchy identified by stratum number. Primary servers operate
at stratum one and provide synchronization to secondary servers
operating at stratum two and so on to higher strata. In this hierarchy,
clients are simply servers that have no dependents.
<p>However, in order to participate in the existing NTP
synchronization subnet and obtain accurate, reliable time, it is
usually necessary to construct an appropriate configuration file,
commonly called <tt>ntp.conf</tt>, which establishes the servers
and/or external receivers or modems to be used by this particular
machine. Directions for constructing this file are in the <a href=
"notes.htm">Notes on Configuring NTP and Setting up a NTP
Subnet</a> page. However, in many common cases involving simple
network topologies and workstations, the configuration data can be
specified entirely on the command line for the <a href="ntpd.htm">
<tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>.</p>
<P>The NTP subnet in early 1998 includes 70 public primary (stratum 1)
servers synchronized directly to UTC by radio, satellite or modem and
located in every continent of the globe, except Antarctica (soon).
Normally, client workstations and servers with a relatively small number
of clients do not synchronize to primary servers. There are 106 public
secondary (stratum 2) servers synchronized to the primary servers and
providing synchronization to a total in excess of 100,000 clients and
servers in the Internet. The current lists are maintained in the <A
HREF=http://www.eecis.udel.edu/~mills/ntp/index.htm>Information on Time
and Frequency Services</A> page, which is updated frequently. There are
numerous private primary and secondary servers not normally available to
the public as well. You are strongly discouraged from using these
servers, since they sometimes hide in little ghettos behind dinky links
to the outside world and your traffic can bring up expensive ISDN lines,
causing much grief and frustration.
<p>The most important factor in providing accurate, reliable time
is the selection of modes and servers to be used in the
configuration file. A discussion on the available modes is on the
<a href="assoc.htm">Association Management</a> page. NTP support
for one or more computers is normally engineered as part of the
existing NTP synchronization subnet. The existing NTP subnet
consists of a multiply redundant hierarchy of servers and clients,
with each level in the hierarchy identified by stratum number.
Primary servers operate at stratum one and provide synchronization
to secondary servers operating at stratum two and so on to higher
strata. In this hierarchy, clients are simply servers that have no
dependents.</p>
<H4>Resolving Problems</H4>
<p>The NTP subnet in late 2000 includes over a hundred public
primary (stratum 1) servers synchronized directly to UTC by radio,
satellite or modem and located in every continent of the globe,
including Antarctica. Normally, client workstations and servers
with a relatively small number of clients do not synchronize to
primary servers. There are over a hundred public secondary (stratum
2) servers synchronized to the primary servers and providing
synchronization to a total in excess of 100,000 clients and servers
in the Internet. The current lists are maintained in the <a href=
"http://www.eecis.udel.edu/~mills/ntp/index.htm">Information on
Time and Frequency Services</a> page, which is updated frequently.
There are numerous private primary and secondary servers not
normally available to the public as well. You are strongly
discouraged from using these servers, since they sometimes hide in
little ghettos behind dinky links to the outside world and your
traffic can bring up expensive ISDN lines, causing much grief and
frustration.</p>
Like other things Internet, the NTP synchronization subnets tend to be
large and devilishly intricate, with many opportunities for
<h4>Resolving Problems</h4>
Like other things Internet, the NTP synchronization subnets tend to
be large and devilishly intricate, with many opportunities for
misconfiguration and network problems. The NTP engineering model is
specifically designed to help isolate and repair such problems using an
integrated management protocol, together with a suite of monitoring and
debugging tools. There is an optional data recording facility which can
be used to record normal and aberrant operation, log problems to the
system log facility, and retain records of client access. The <A
HREF=debug.htm>NTP Debugging Techniques </A>and <A
HREF=hints.htm>Hints and Kinks </A>pages contain useful information
for identifying problems and devising solutions.
specifically designed to help isolate and repair such problems
using an integrated management protocol, together with a suite of
monitoring and debugging tools. There is an optional data recording
facility which can be used to record normal and aberrant operation,
log problems to the system log facility, and retain records of
client access. The <a href="debug.htm">NTP Debugging Techniques</a>
and <a href="hints.htm">Hints and Kinks</a> pages contain useful
information for identifying problems and devising solutions.
<P>Users are requested to report bugs, offer suggestions and contribute
additions to this distribution. The <A HREF=patches.htm>Patching
Procedures </A>page suggests procedures which greatly simplify
distribution updates, while the <A HREF=porting.htm>Porting Hints
</A>page suggest ways to make porting this code to new hardware and
operating systems easier. Additional information on reference clock
driver construction and debugging can be found in the <A
HREF=refclock.htm>Reference Clock Drivers </A>page. Further
information on NTP in the Internet can be found in the <A
HREF=http://www.eecis.udel.edu/~ntp>NTP
web page</A>.
<p>Users are requested to report bugs, offer suggestions and
contribute additions to this distribution. The <a href=
"patches.htm">Patching Procedures</a> page suggests procedures
which greatly simplify distribution updates, while the <a href=
"porting.htm">Porting Hints</a> page suggest ways to make porting
this code to new hardware and operating systems easier. Additional
information on reference clock driver construction and debugging
can be found in the <a href="refclock.htm">Reference Clock
Drivers</a> page. Further information on NTP in the Internet can be
found in the <a href="http://www.eecis.udel.edu/~ntp">NTP web
page</a>.</p>
<H4>Program Manual Pages</H4>
<h4>Program Manual Pages</h4>
<ul>
<li><a href="ntpd.htm"><tt>ntpd</tt> - Network Time Protocol (NTP)
daemon</a></li>
<li><A HREF=ntpd.htm><TT>ntpd</TT> - Network Time Protocol (NTP)
daemon</A></LI>
<LI><A HREF=ntpq.htm><TT>ntpq</TT> - standard NTP query
program</A></LI>
<LI><A HREF=ntpdc.htm><TT>ntpdc</TT> - special NTP query
program</A></LI>
<LI><A HREF=ntpdate.htm><TT>ntpdate</TT> - set the date and time via
NTP</A></LI>
<LI><A HREF=ntptrace.htm><TT>ntptrace</TT> - trace a chain of NTP
servers back to the primary source</A></LI>
<LI><A HREF=tickadj.htm><TT>tickadj</TT> - set time-related kernel
variables</A></LI>
<LI><A HREF=ntptime.htm><TT>ntptime</TT> - read kernel time
variables</A></LI>
<li><a href="ntpq.htm"><tt>ntpq</tt> - standard NTP query
program</a></li>
<li><a href="ntpdc.htm"><tt>ntpdc</tt> - special NTP query
program</a></li>
<li><a href="ntpdate.htm"><tt>ntpdate</tt> - set the date and time
via NTP</a></li>
<li><a href="ntptrace.htm"><tt>ntptrace</tt> - trace a chain of NTP
servers back to the primary source</a></li>
<li><a href="tickadj.htm"><tt>tickadj</tt> - set time-related
kernel variables</a></li>
<li><a href="ntptime.htm"><tt>ntptime</tt> - read kernel time
variables</a></li>
<li><a href="genkeys.htm"><tt>ntp-genkeys</tt> - generate public
and private keys</a></li>
</ul>
<H4>Supporting Documentation</H4>
<h4>Supporting Documentation</h4>
<ul>
<li><a href="http://www.eecis.udel.edu/~mills/ntp.htm">NTP Project
and Reference Library</a></li>
<LI<A HREF=ntp.htm>NTP Reference Library</A></LI>
<LI><A HREF=copyright.htm>Copyright Notice</A></LI>
<LI><A HREF=exec.htm>Executive Summary - Computer Network Time
Synchronization</A></LI>
<LI><A HREF=biblio.htm>Protocol Conformance Statement</A></LI>
<LI><A HREF=y2k.htm>Year 2000 Conformance Statement</A></LI>
<LI><A HREF=notes.htm>Notes on Configuring NTP and Setting up a NTP
Subnet</A></LI>
<LI><A HREF=release.htm>NTP Version 4 Release Notes</A></LI>
<LI><A HREF=build.htm>Building and Installing the
Distribution</A></LI>
<LI><A HREF=config.htm>Configuration Options</A></LI>
<LI><A HREF=debug.htm>NTP Debugging Techniques</A></LI>
<LI><A HREF=refclock.htm>Reference Clock Drivers</A></LI>
<LI><A HREF=patches.htm>Patching Procedures</A></LI>
<LI><A HREF=hints.htm>Hints and Kinks</A></LI>
<LI><A HREF=porting.htm>Porting Hints</A></LI>
<li><a href="copyright.htm">Copyright Notice</a></li>
<li><a href="exec.htm">Executive Summary - Computer Network Time
Synchronization</a></li>
<li><a href="biblio.htm">Protocol Conformance Statement</a></li>
<li><a href="leap.htm">NTP Timescale and Leap Seconds</a></li>
<li><a href="notes.htm">Notes on Configuring NTP and Setting up a
NTP Subnet</a></li>
<li><a href="release.htm">NTP Version 4 Release Notes</a></li>
<li><a href="build.htm">Building and Installing the
Distribution</a></li>
<li><a href="config.htm">Configuration Options</a></li>
<li><a href="debug.htm">NTP Debugging Techniques</a></li>
<li><a href="refclock.htm">Reference Clock Drivers</a></li>
<li><a href="patches.htm">Patching Procedures</a></li>
<li><a href="hints.htm">Hints and Kinks</a></li>
<li><a href="porting.htm">Porting Hints</a></li>
</ul>
<H4>Application Notes</H4>
<h4>Application Notes</h4>
<ul>
<li><a href="prefer.htm">Mitigation Rules and the <tt>prefer</tt>
Keyword</a></li>
<LI><A HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT>
Keyword</A></LI>
<LI><A HREF=assoc.htm>Association Management</A></LI>
<LI><A HREF=pps.htm>Pulse-per-second (PPS) Signal Interfacing</A></LI>
<LI><A HREF=gadget.htm>Gadget Box PPS Level Converter and CHU
Modem</A></LI>
<LI><A HREF=measure.htm>Time and Time Interval Measurement with
Application to Computer and Network Performance Evaluation</A></LI>
<LI><A HREF=kern.htm>A Kernel Model for Precision Timekeeping</A></LI>
<LI><A HREF=kernpps.htm>A Kernel Programming Interface for Precision
Time Signals</A></LI>
<li><a href="assoc.htm">Association Management</a></li>
<li><a href="pps.htm">Pulse-per-second (PPS) Signal
Interfacing</a></li>
<li><a href="gadget.htm">Gadget Box PPS Level Converter and CHU
Modem</a></li>
<li><a href="measure.htm">Time and Time Interval Measurement with
Application to Computer and Network Performance Evaluation</a></li>
<li><a href="kern.htm">Kernel Model for Precision
Timekeeping</a></li>
<li><a href="kernpps.htm">Kernel Programming Interface for
Precision Time Signals</a></li>
</ul>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<hr>
<center><img src="pic/pogo1a.gif" alt="gif"></center>
<br>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

163
contrib/ntp/html/kern.htm
View File

@ -1,51 +1,122 @@
<HTML><HEAD><TITLE>
A Kernel Model for Precision Timekeeping
</TITLE></HEAD><BODY><H3>
A Kernel Model for Precision Timekeeping
</H3><HR>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Kernel Model for Precision Timekeeping</title>
</head>
<body>
<h3>Kernel Model for Precision Timekeeping</h3>
<P>The technical memorandum: <I>A Kernel Model for Precision
Timekeeping</I><A
HREF="http://www.eecis.udel.edu/~mills/database/memos/memo96b.ps">
(PostScript) </A>describes an engineering model which implements a
precision time-of-day function for a generic operating system. The model
is based on the principles of disciplined oscillators using phase-lock
loops (PLL) and frequency-lock loops (FLL) often found in the
engineering literature. The model uses a hybrid PLL/FLL discipline
algorithm implemented in the kernel. The hybrid loop provides automatic
time and frequency steering with update intervals from a few seconds to
over one day.
<hr>
<img align="left" src="pic/alice61.gif" alt="gif"> <a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<P>The hybrid PLL/FLL has been implemented in the Unix kernels for
several workstations, including those made by Sun Microsystems, Digital
and Hewlett Packard. Currently, the modifications are in licensed
kernels for Digital Unix 4.0 and Sun Solaris 2.6. Since these specific
implementations involve modifications to licensed code, they cannot be
provided directly. Inquiries should be directed to the manufacturer's
representatives. In addition to the licensed kernels, the hybrid PLL/FLL
has been implemented in the nonlicensed kernels for Linux and FreeBSD.
The engineering model for these implementations, including a simulator
with code segments almost identical to the implementations, but not
involving licensed code, is available via the web at <A
HREF="http://www.eecis.udel.edu/~mills/ntp/ntp">kernel.tar.Z</A> or by
anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
<p>Exploding kernel<br clear="left">
</p>
<P>The model changes the way the system clock is adjusted in time and
frequency, as well as provides mechanisms to discipline its time and
frequency to an external precision timing source, such as a pulse-per-
second (PPS) signal. The model incorporates a generic system-call
interface for use with the Network Time Protocol (NTP) or similar time
synchronization protocol. The NTP software daemons for Version 3
<TT>xntpd</TT> and Version 4&nbsp; <TT>ntpd</TT> operate with this model
to provide synchronization limited in principle only by the accuracy and
stability of the external timing source. There are two new system calls
defined in the model, <TT>ntp_gettime()</TT>, which returns a structure
<hr>
<p>The technical report [2], which is a major revision and update
of an earlier report [3], describes an engineering model for a
precision time-of-day function for a generic operating system. The
model is based on the principles of disciplined oscillators using
phase-lock loops (PLL) and frequency-lock loops (FLL) often found
in the engineering literature. The model uses a hybrid PLL/FLL
discipline algorithm implemented in the kernel. The hybrid loop
provides automatic time and frequency steering with update
intervals from a few seconds to over one day.</p>
<p>The hybrid PLL/FLL has been implemented in the Unix kernels for
several operating systems, including FreeBSD and Linux and those
made by Sun Microsystems, Digital/Compaq and Hewlett Packard. The
modifications are currently included in the licensed kernels for
Digital Unix 4.0 (aka Tru64) and Sun Solaris 2.8. Since the
modifications involve proprietary kernel interface code, they
cannot be provided for other licensed kernels directly. Inquiries
should be directed to the manufacturer's representatives. The
software and documentation, including a simulator with code
segments almost identical to the implementations, but not involving
licensed code, is called <tt>nanokernel.tar.gz</tt> and available
via the web at <a href="http://www.ntp.org">www.ntp.org</a> or by
anonymous FTP from ftp.udel.edu in the <tt>pub/ntp/software</tt>
directory.</p>
<p>Recently [1], the model has been re-implemented to support a
nanosecond system clock. The <tt>/usr/include/sys/timex.h</tt>
header file defines the applications programming interface (API)
routines and data structures. Implementations are available for
Linux, FreeBSD, SunOS and Tru64; however, only the Linux and
FreeBSD implementations, which are included in recent system
versions, are directly available. The software and documentation,
including a simulator with code segments almost identical to the
implementations, but not involving licensed code, is called <tt>
nanokernel.tar.gz</tt> and available via the web at <a href=
"http://www.ntp.org">www.ntp.org</a> or by anonymous FTP from
ftp.udel.edu in the <tt>pub/ntp/software</tt> directory.</p>
<p>The model changes the way the system clock is adjusted in time
and frequency, as well as provides mechanisms to discipline its
time and frequency to an external precision timing source, such as
described in the <a href="pps.htm">Pulse-per-second (PPS) Signal
Interfacing</a> page. The model incorporates a generic system call
interface for use with the NTP or similar time synchronization
protocol. The NTP software daemons for Version 3 <tt>xntpd</tt> and
Version 4 <tt>ntpd</tt> use this API to provide synchronization
limited in principle only by the accuracy and stability of the
external timing source. There are two new system calls defined in
<tt>timex.h</tt>, <tt>ntp_gettime()</tt>, which returns a structure
including the current time, estimated error and maximum error, and
<TT>ntp_adjtime()</TT>, which provides a means to adjust kernel
variables, including the current time and frequency offsets. Further
information on the calling sequences and variable definitions are in the
<TT>/usr/include/sys/timex.h</TT> file.&nbsp;
<tt>ntp_adjtime()</tt>, which provides a means to adjust kernel
variables, including the current time and frequency offsets.</p>
<p>These kernel modifications are normally used in conjunction with
a kernel hardware interface such as described in the <a href=
"kernpps.htm">Kernel Programming Interface for Precision Time
Signals</a> page.</p>
<h4>References</h4>
<ol>
<li><p>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision
Time and Time Interval (PTTI) Applications and Planning Meeting</i>
(Reston VA, November 2000). Paper: <a href=
"database/papers/nano/nano2.ps">PostScript</a> | <a href=
"http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf">
PDF</a>, Slides: <a href=
"http://www.eecis.udel.edu/~mills/database/brief/nano/nano.htm">
HTML</a> | <a href=
"http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ps">
PostScript</a> | <a href=
"http://www.eecis.udel.edu/~mills/database/brief/nano/nano.pdf">
PDF</a> | <a href=
"http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ppt">
PowerPoint</a></p></li>
<li><p>Mills, D.L. Unix kernel modifications for precision time
synchronization. Electrical Engineering Department Report 94-10-1,
University of Delaware, October 1994, 24 pp. Abstract: <a href=
"http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps">
PostScript</a> | <a href="database/reports/kern/kerna.pdf">PDF</a>,
Body: <a href=
"http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps">
PostScript</a> | <a href=
"http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf">
PDF</a></p></li>
<li><p>Mills, D.L. A kernel model for precision timekeeping. Network
Working Group Report RFC-1589, University of Delaware, March 1994.
31 pp. <a href=
"http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt">
ASCII</a></p></li>
</ol>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

30
contrib/ntp/html/kernpps.htm
View File

@ -1,25 +1,23 @@
<html><head><title>
A Kernel Programming Interface for Precision Time Signals
Kernel Programming Interface for Precision Time Signals
Network Performance Evaluation
</title></head><body><h3>
A Kernel Programming Interface for Precision Time Signals
Kernel Programming Interface for Precision Time Signals
</h3><hr>
<p>The technical memorandum: <cite>A Kernel Programming Interface for
Precision Time Signals</cite><a
href="http://www.eecis.udel.edu/~mills/database/memos/memo96c.ps">
(PostScript) </a> describes a proposed programming interface for
external precision time signals, such as the pulse-per-second (PPS)
signal generated by some radio clocks and cesium oscillators.
<p>The technical report [1] describes a proposed application programming interface (API) for external precision time signals, such as the pulse-per-second (PPS) signal generated by some radio clocks and cesium oscillators. The report argues for a generic capability in the ubiquitous Unix kernel, which could be used for a wide variety of measurement applications, including network time synchronization and experiments involving performance measurement and evaluation of computer networks and transmission systems. The hardware to do this requires only a serial port and a modem control lead, such as the data carrier detect (DCD) lead, which can be driven by an external source via a level converter/pulse generator.
<p>The memorandum argues for a generic capability in the ubiquitous Unix
kernel, which could be used for a wide variety of measurement
applications, including network time synchronization and experiments
involving performance measurement and evaluation of computer networks
and transmission systems. The hardware to do this requires only a serial
port and a modem control lead, such as the data carrier detect (DCD)
lead, which can be driven by an external source via a level
converter/pulse generator.
<p>Support for this API has been implemented in the NTP Version 4 software distribution. The <tt>/usr/include/sys/timepps.h</tt> header file defines the API interface routines and data structures. The API obsoletes previous APIs based on the <tt>tty_clock</tt> and <tt>ppsclock</tt> line disciplines and streams modules, which are no longer supported. The API used by the <a href=driver22.htm>PPS Clock Discipline</a> driver (type 22) to support PPS signals via either a serial port or parallel port, depending on the operating system. The API is supported in stock FreeBSD from 3.4 and with the addition of the <tt>PPSkit</tt> kernel software in Linux. Limited support for Solaris from 2.8 is available using the <tt>timepps.h.solaris</tt> header file included in this distribution. Copy this file to <tt>/usr/include/sys</tt> before configuring the distributution.
<p>The API is normally used in conjunction with the precision time kernel modifications described in the <a href=kern.htm>Kernel Model for Precision Timekeeping</a> page.
<h4>Reference</h4>
<ol>
<p><li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2783.txt>ASCII</a>
</ol>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>

180
contrib/ntp/html/ldisc.htm
View File

@ -1,4 +1,3 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<html><head><title>
Line Disciplines and Streams Modules
</title></head><body><h3>
@ -7,125 +6,66 @@ Line Disciplines and Streams Modules
<p><h4>Description</h4>
<p>Most radio and modem clocks used for a primary (stratum-1) NTP server
utilize serial ports operating at speeds of 9600 baud or greater. The
timing jitter contributed by the serial port hardware and software
driver can accumulate to several milliseconds on a typical Unix
workstation. In order to reduce these errors, a set of special line
disciplines and stream modules can be configured in the Unix kernel.
These routines intercept special characters or signals provided by the
radio or modem clock and save a local timestamp for later processing.
<p>Most radio and modem clocks used for a primary (stratum-1) NTP server utilize serial ports operating at speeds of 9600 baud or greater. The intrinsic delay and jitter contributed by the serial port hardware and software driver can accumulate up to a millisecond in newer Unix systems and tens of milliseconds in older ones. In order to reduce the effects of delay and jitter, a set of special line disciplines, stream modules and operating system calls (ioctls) can be configured in some Unix kernels. These routines intercept special characters or signals provided by the radio or modem clock and save a timestamp for later processing.
<p>The routines can be compiled in the kernel in older BSD-derived
systems, or installed as System V streams modules and either compiled in
the kernel or dynamically loaded when required. In either case, they
require minor changes in some kernel files and in the NTP daemon
<code>ntpd</code>. The streams modules can be pushed and popped from
the streams stack using conventional System V streams program
primitives. Note that not all Unix kernels support line disciplines and
of those that do, not all support System V streams. The disciplines here
are known to work correctly with SunOS 4.x kernels, but have not been
tested for other kernels.
<p>The routines provide two important functions. Some insert a timestamp in the receive data stream upon occurance of a designated character or characters at the serial interface. This can be used to timestamp an on-time character produced by a radio clock, for example. Other routines support an application program interface for pulse-per-second (PPS) signals generated by some radio clocks and laboratory instruments. These routines are normally accessed through the PPSAPI application program interface described below.
<p>There are two line disciplines and a special streams module included
in the distribution. Support for each in <code>ntpd</code> is enabled
by adding flags to the <code>DEFS_LOCAL</code> line of the
<code>ntpd</code> configuration file <code>./Config.local</code>. This
can be done automatically by the autoconfiguration build procedures, or
can be inserted/deleted after the process has completed.
<p>The routines can be compiled in the kernel in older BSD-derived systems, or installed as System V streams modules and either compiled in the kernel or dynamically loaded when required. In either case, they require minor changes in some kernel files and in the NTP daemon <tt>ntpd</tt>. The streams modules can be pushed and popped from the streams stack using conventional System V streams program primitives. Note that some Unix kernels do not support line disciplines and some do not support System V streams. The routines described here are known to work correctly with the Unix kernels called out in the descriptions, but have not been tested for other kernels.
<h4>PPSAPI Application Program Interface</h4>
<p>Pulse-per-second (PPS) signals are normally processed as described in the <a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a> page. The <a href=driver22.htm>PPS Clock Discipline</a> driver uses the PPSAPI application program interface to capture PPS signal transitions used to fine-tune the system clock. This interface, defined in RFC-2783, is the only PPS interface supported in NTP. While older PPS interfaces based on the ioctls described below continue to be supported, they are used only in the special header file <t>/usr/include/sys/timepps.h</tt>, which implements the PPSAPI specific to each archeticture and operating system.
<p>It is the intent of the evolving design to remove all PPS support from the various clock drivers and utilize only the PPS driver for PPS support. This allows the required sanity checks and signal grooming to be provided and maintained in one place and avoids cluttering up the drivers with duplicate functionality. Since the PPS signal samples are processed by the entire suite of NTP grooming, selection and clustering algorithms, noisy PPS signals and signals outside specific time and frequency tolerances are excluded.
<p>The PPSAPI interface provides the following functions:
<dl>
<dt><code>tty_clk</code>
<dd>This routine intercepts characters received from the serial port and
passes unchanged all except a set of designated characters to the
generic serial port discipline. For each of the exception characters,
the character is inserted in the receiver buffer followed by a local
timestamp in Unix <code>timeval</code> format. Both
<code>select()</code> and <code>SIGIO</code> are supported by the
routine. The <code>-DTTYCLK</code> flag is used to compile support for
this discipline in <code>ntpd</code>. This flag is automatically
included if the <code>clkdefs.h</code> file is found in the
<code>/usr/include/sys</code> directory, or it can be added (or deleted)
manually. This module must be configured in the kernel during the kernel
build process, as described in the <code>README</code> file in the
<code>./kernel</code> directory.
<dt><tt>time_pps_create</tt>
<dd>Creates a PPS interface instance and returns a handle to it.</dd>
<p><dt><code>tty_chu</code>
<dd>This routine is a special purpose line discipline for receiving a
special timecode broadcast by Canadian time and frequency standard
station CHU. The radio signal is first demodulated by the 300-baud modem
included in the gadget box, then processed by the discipline and finally
processed by the CHU modem driver (type 7) described in the <a href =
"refclock.htm"> Reference Clock Drivers </a> page. This discipline
should be used in raw mode. The <code>-DCHUCLK</code> flag is used to
compile support for this discipline in <code>ntpd</code>. This flag is
automatically included if the <code>chudefs.h</code> file is found in
the <code>/usr/include/sys</code> directory, or it can be added (or
deleted) manually. This module must be configured in the kernel during
the kernel build process, as described in the <code>README</code> file
in the <code>./kernel</code> directory.
<p><dt><code>ppsclock</code>
<dd>This routine is a special purpose streams module which monitors the
state of the data carrier detect (DCD) modem interface signal. It is
normally used in connection with a pulse-per-second (PPS) signal
generated by some radio clocks, which requires a hardware level
converter/pulse generator, such as described in the <a href =
"gadget.htm"> Gadget Box PPS Level Converter and CHU Modem </a> page.
For each positive-going edge of the DCD signal, the
<code>ppsclock</code> module captures a timestamp in Unix
<code>timeval</code> format for later retrieval using a special
<code>ioctl()</code> system call. The <code>-DPPS</code> flag is used to
compile support for this module in <code>ntpd</code>. This flag is
automatically included if the <code>ppsclock.h</code> file is found in
the <code>/sys/sys</code> directory, or it can be added (or deleted)
manually. This module must also be configured in the kernel during the
kernel build process, as described in the <code>README</code> file in
the <code>./kernel</code> directory.
<dt><tt>time_pps_destroy</tt>
<dd>Destroys a PPS interface and returns the resources used.</dd>
<dt><tt>time_pps_setparams</tt>
<dd>Sets the parameters associated with a PPS interface instance, including offsets to be automatically added to captured timestamps.</dd>
<dt><tt>time_pps_getparams</tt>
<dd>Returns the parameters associated with a PPS interface instance.</dd>
<dt><tt>time_pps_getcap</tt>
<dd>Returns the capabilities of the current interface and kernel implementation.</dd>
<dt><tt>time_pps_fetch</tt>
<dd>Returns the current timestamps associated with a PPS interface instance in either nanoseconds and nanoseconds (Unix <tt>timespec</tt>) or seconds and fraction (NTP) format.</dd>
<dt><tt>time_pps_kcbind</tt>
<dd>If kernel PPS processing is supported, this binds the support to the associated PPS interface instance.</dd>
</dl>
<p>There are two versions of both the <code>tty_clk</code> and
<code>chu_clk</code> programs. The <code>tty_clk.c</code> and
<code>chu_clk.c</code> are designed for use with older BSD systems and
are compiled in the kernel. The <code>tty_clk_STREAMS.c</code> and
<code>chu_clk_STREAMS.c</code> are designed for use with System V
streams, in which case they can be either compiled in the kernel or
dynamically loaded. Since these programs are small, unobtrusive, and do
nothing unless specifically enabled by an application program, it
probably doesn't matter which version is chosen. Instructions on how to
configure and build a kernel supporting either or both of these line
disciplines is in the <code>README</code> file in the
<code>./kernel</code> directory.
<p>The entire PPS interface functionality is currently provided by inline code in the <tt>timepps.h</tt> header files implemented for SunOS, Solaris, FreeBSD, Linux and Tru64. While not all implementations support the full PPSAPI specification, they do support all the functions required for the PPS driver. The FreeBSD, Linux and Solaris implementations can be used with the stock kernels provided with those systems; however, the Tru64 and SunOS kernels require additional functions not provided in the stock kernels. Solaris users are cautioned that these ioctls function improperly in Solaris versions prior to 2.8 with patch Generic_108528-02.
<p><h4>How to Use the <code>tty_clk</code> Line Discipline</h4>
<h4><tt>tty_clk</tt> Line Discipline/Streams Module</h4>
<p>The tty_clk line discipline defines a new <code>ioctl()</code>,
<code>CLK_SETSTR</code>, which takes a pointer to a string of no more
than 32 characters. Until the first <code>CLK_SETSTR</code> is
performed, the discipline will simply pass through characters. Once it
is passed a string by <code>CLK_SETSTR</code>, any character in that
string will be immediately followed by a timestamp in Unix
<code>timeval</code> format. You can change the string whenever you want
by doing another <code>CLK_SETSTR</code>. The character must be an
exact, 8 bit match. The character '\000' cannot, be used, as it is the
string terminator. Passing an empty string to <code>CLK_SETSTR</code>
turns off timestamping. Passing <code>NULL</code> will produce undefined
results.
<p>This routine intercepts characters received from the serial port and passes unchanged all except a set of designated characters to the generic serial port discipline. For each of the exception characters, the character is inserted in the receiver buffer followed by a local timestamp in Unix <tt>timeval</tt> format. Both <tt>select()</tt> and <tt>SIGIO</tt> are supported by the routine. Support for this routine is automatically detected during the NTP build process and interface code compiled as necessary.
<p><h4>How to Use the <code>tty_chu</code> Line Discipline</h4>
<p>There are two versions of the <tt>tty_clk</tt> routine. The <tt>tty_clk.c</tt> line discipline is designed for older BSD systems and is compiled in the kernel. The <tt>tty_clk_STREAMS.c</tt> is designed for System V streams, in which case it can be either compiled in the kernel or dynamically loaded. Since these programs are small, unobtrusive, and do nothing unless specifically enabled by an application program, it probably doesn't matter which version is chosen. Instructions on how to configure and build a kernel supporting either of these routines is in the <tt>README</tt> file in the <tt>./kernel</tt> directory.
<p>The tty_chu line discipline translates data received from the CHU
modem and returns <code>chucode</code> structures, as defined in
chudefs.h, and expected by the Scratchbuilt CHU Receiver reference clock
driver. Depending on the settings of <code>PEDANTIC</code> and
<code>ANAL_RETENTIVE</code> used when compiling the kernel, some
checking of the data may or may not be necessary.
<p>The <tt>tty_clk</tt> routine defines a new ioctl <tt>CLK_SETSTR</tt>, which takes a pointer to a string of no more than 32 characters. Until the first <tt>CLK_SETSTR</tt> is performed, the routine will simply pass through characters. Once it is passed a string by <tt>CLK_SETSTR</tt>, any character in that string will be immediately followed by a timestamp in Unix <tt>timeval</tt> format. You can change the string whenever you want by doing another <tt>CLK_SETSTR</tt>. The character must be an exact, 8 bit match. The character '\000' cannot, be used, as it is the string terminator. Passing an empty string to <tt>CLK_SETSTR</tt> turns off timestamping. Passing <tt>NULL</tt> may produce surprising results.
<p><h4>How to Use the <code>ppsclock</code> Stream Module</h4>
<p><h4><tt>TIOCDCDTIMESTAMP</tt> ioctl in FreeBSD</h4>
<p>The ppsclock streams module implements an <code>ioctl()
CIOGETEV</code>, which takes a pointer to the structure
<p>This ioctl is included in FreeBSD 2.2 and later. It causes a timestamp to be inserted in the serial port receive data stream when the data carrier detect (DCD) signal is asserted. This is useful for those radio clocks that indicate the on-time epoch by means of a modem control signal. It is not recommended that this be used for PPS timestamps, as this function is available using the PPS application program interface included in FreeBSD 3.4 and later.
<p>The <tt>TIOCDCDTIMESTAMP</tt> ioctl() is detected and compiled automatically on FreeBSD systems if available. With FreeBSD 2.2 the measured delay between activation of the DCD signal and the time the timestamp is captured on a 66MHz 486DX2 is 19 <font face=Symbol>m</font>s and on a 100MHz Pentium is 6 <font face=Symbol>m</font>s.
<h4><tt>ppsclock</tt>Streams Module</h4>
<p>This routine is a streams module which causes a timestamp to be captured when the DCD signal is asserted. It is normally used in connection with a PPS signal generated by some radio clocks. However, it is normally used only by the PPSAPI interface and should be avoided in other contexts. Instructions on how to configure and build a kernel supporting either of these routines is in the <tt>README</tt> file in the <tt>./kernel</tt> directory.
<p>The ppsclock streams module implements the <tt>CIOGETEV</tt> ioctl, which takes a pointer to the structure
<pre>
struct ppsclockev {
@ -134,28 +74,16 @@ struct ppsclockev {
};
</pre>
<p>The ppsclock module is pushed on the streams stack of the serial port
connected to the PPS signal. The port must be configured for local
operation, rather than remote (modem) operation. At each positive-going
edge of the DCD signal, the routine latches the current local timestamp
and increments a counter. At each <code>CIOGETEV ioctl()</code> call,
the current values of the timestamp and counter are returned in the
<code>ppsclockev</code> structure.
<p>The <tt>ppsclock</tt> module is pushed on the streams stack of the serial port connected to the DCD line. At each positive-going edge of the PPS signal, the routine latches the current local timestamp and increments a counter. At each <tt>CIOGETEV</tt> ioctl call, the current values of the timestamp and counter are returned in the <tt>ppsclockev</tt> structure.
<p><h4>TIOCDCDTIMESTAMP timestamping</h4>
<p><h4><tt>TIOCSPPS</tt> and <tt>TIOCGETPPSEV</tt> ioctls in Solaris</h4>
<p>On FreeBSD 2.2 and later systems the TIOCDCDTIMESTAMP ioctl is used
to read the timestamp when the DCD serial go active. To use this the
PPS signal must be tied to the serial port DCD signal through the
appropriate level converters and pulse stretch circuitry if necessary.
This enhances the accuracy of the driver to a few microseconds. Using
FreeBSD 2.2 the measured delay between activation of the PPS signal and
the time the timestamp is made on a 66MHz 486DX2 is 19us and on a
100MHz Pentium is 6us. The driver does NOT compensate for this.
<p>These ioctls are included in Solaris 2.4 and later. They implement the same function as the <tt>ppsclock</tt> streams module, but are implemented as integrated system calls independent of the streams facility. They are normally used in connection with a pulse-per-second (PPS) signal generated by some radio clocks. However, these ioctls are normally used only by the PPSAPI interface and should be avoided in other contexts. See the Sun documentation for the calling sequence and return values.
<p>The TIOCDCDTIMESTAMP timestamping ioctl() is used automatically
on FreeBSD systems if available. It is integrated into the
refclock_gtlin() function so any driver using it will benefit from
the enhanced accuracy.
<p>Users are cautioned that these ioctls function improperly in Solaris versions prior to 2.8 with patch Generic_108528-02.
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>
<h4><tt>tty_chu</tt> Line Discipline/Streams Module (depredated)</h4>
<p>This routine is a special purpose line discipline for receiving a special timecode broadcast by Canadian time and frequency standard station CHU. It has been removed from the distribution since its function has been replaced by the <a href=driver7.htm>Radio CHU Audio Demodulator/Decoder (type 7)</a> clock driver.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a></address></a></body></html>

250
contrib/ntp/html/leap.htm Normal file
View File

@ -0,0 +1,250 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>NTP Timescale and Leap Seconds</title>
</head>
<body>
<h3>NTP Timescale and Leap Seconds</h3>
<img align="left" src="pic/alice15.gif" alt="gif"><a href=
"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
Carroll</a>
<p>The Mad Hatter and the March Hare are discussing whether the
Teapot serial number should have two or four digits.<br clear=
"left">
</p>
<hr>
<h4>Introduction</h4>
<p>In the year 2001 the Network Time Protocol (NTP) has been in use
for over two decades and remains the longest running, continuously
operating application protocol in the Internet. There was some
concern, especially in government and financial institutions, that
NTP might cause Internet applications to misbehave in terrible ways
on the epoch of the new century, but this didn't happen. However,
how NTP reckons the time is important when considering the
relationship between NTP time and conventional civil time.</p>
<p>This document presents an analysis of the NTP timescale, in
particular the metrication relative to the conventional civil
timescale and when the NTP timescale rolls over in 2036. These
issues are also important with respect to the Unix timescale, but
that rollover will not happen until 2038. This document does not
establish a standard, nor does it present specific algorithms which
metricate the NTP timescale with respect to other timescales.</p>
<h4>The NTP Timescale</h4>
<p>It will be helpful in understanding the issues raised in this
document to consider the concept of a universal timescale. The
conventional civil timescale used in most parts of the world is
based on Coordinated Universal Time (UTC) (sic), formerly known as
Greenwich Mean Time (GMT). UTC is based on International Atomic
Time (TAI sic), which is derived from hundreds of cesium clocks in
the national standards laboratories of many countries. Deviations
of UTC from TAI are implemented in the form of leap seconds, which
occur on average every eighteen months.</p>
<p>For almost every computer application today, UTC represents the
universal timescale extending into the indefinite past and
indefinite future. We know of course that the UTC timescale did not
exist prior to 1972, the Gregorian calendar did not exist prior to
1582, the Julian calendar did not exist prior to 54 BC and we
cannot predict exactly when the next leap second will occur.
Nevertheless, most folks would prefer that, even if we can't get
future seconds numbering right beyond the next leap second, at
least we can get the days numbering right until the end of
reason.</p>
<p>The universal timescale can be implemented using a binary
counter of indefinite width and with the unit seconds bit placed
somewhere in the middle. The counter is synchronized to UTC such
that it runs at the same rate (also the rate of TAI) and the units
increment coincides with the UTC seconds tick. The NTP timescale is
constructed from 64 bits of this counter, of which 32 bits number
the seconds and 32 bits represent the fraction. With this design,
the counter runs in 136-year cycles, called eras, the latest of
which began with a counter value of zero at 0h 1 January 1900. The
next era will begin when the seconds counter rolls over sometime in
2036. The design assumption is that further low order bits, if
required, are provided by local interpolation, while further high
order bits, when required, are provided by external means.</p>
<p>The important point to be made here is that the high order bits
must ultimately be provided by astronomers and disseminated to the
population by international means. Ultimately, should a need exist
to align a particular NTP era to the current calendar, the
operating system in which NTP is embedded must provide the
necessary high order bits, most conveniently from the file system
or flash memory.</p>
<p>With respect to the recent year 2000 issue, the most important
thing to observe about the NTP timescale is that it knows nothing
about days, years or centuries, only the seconds since the
beginning of the current era which began on 1 January 1900. On 1
January 1970 when Unix life began, the NTP timescale showed
2,208,988,800 and on 1 January 1972 when UTC life began, it showed
2,272,060,800. On the last second of the year 1999, the NTP
timescale showed 3,155,673,599 and one second later on the first
second of the next century showed 3,155,673,600. Other than this
observation, the NTP timescale has no knowledge of or provision for
any of these eclectic seconds.</p>
<h4>Conversion to Other Timescales</h4>
<p>The NTP timescale is almost never used directly by system or
application programs. The generic Unix kernel keeps time in seconds
and microseconds (or nanoseconds) to provide both time of day and
interval timer functions. In order to synchronize the Unix clock,
NTP must convert to and from NTP representation and Unix
representation. Unix kernels implement the time of day function
using two 32-bit counters, one representing the signed seconds
since Unix life began and the other the microseconds or nanoseconds
of the second. In principle, the seconds counter will change sign
in 2038. How the particular Unix semantics interprets the counter
values is of concern, but is beyond the scope of discussion
here.</p>
<p>While incorrect NTP time values are unlikely in a properly
configured subnet using strong cryptography, redundant sources and
diverse network paths, hazards remain due to incorrect software
external to NTP. These include the Unix kernel and library routines
which convert NTP time to and from Unix time and to and from
conventional civil time in seconds, minutes, hours, days and years.
Although NTP uses these routines to format monitoring data
displays, they are not used to read or set the NTP clock. They may
in fact cause problems with certain application programs, but this
is not an issue which concerns NTP correctness.</p>
<p>It is possible that some external source to which NTP
synchronizes may produce a discontinuity which could then induce a
NTP discontinuity. The NTP primary (stratum 1) time servers, which
are the ultimate time references for the entire NTP population,
obtain time from various sources, including radio and satellite
receivers and telephone modems. Not all sources provide year
information and not all of these provide time in four-digit form.
In point of fact, the NTP reference implementation does not use the
year information, even if available. Instead, the year information
is provided from the file system, which itself depends on the Unix
clock.</p>
<p>Most computers include a time-of-year (TOY) clock chip which
maintains the time when the power is off. When the operating system
is booted, the system clock is set from the chip. As the chip does
not record the year, this value is determined from the datestamp on
a system configuration file. For this to be correct, the filestamp must by updated at least once each year. The NTP protocol specification
requires the apparent NTP time derived from external servers to be
compared to the system time before the clock is set. If the
discrepancy is over 1000 seconds, an error alarm is raised
requiring manual intervention. This makes it very unlikely that
even a clique of seriously corrupted NTP servers will result in
grossly incorrect time values. When the system clock is synchronized to
NTP, the TOY chip is corrected to system time on a regular
basis.</p>
<h4>Timescale Resolution and the Tick Interval</h4>
<p>Modern computer clocks use a hardware counter to generate processor interrupts at tick intervals in the order of a few milliseconds. At each tick the processor increments the software system clock by the number of microseconds or nanoseconds in the tick. The software resolution of the system clock is defined as the tick interval. Most modern processors implement some kind of high resolution hardware counter that can be used to interpolate the interval between the most recent tick and the actual clock reading. The hardware resolution of the system clock is defined as the time between increments of this counter. However, the actual reading latency due to the kernel interface and interpolation code can range from a few tens of microseconds in older processors to under a microsecond in modern processors.</p>
<p>System clock correctness principles require that clock readings must be always monotonically increasing, so that no two clock readings will be the same. As long as the reading latency exceeds the hardware resolution, this behavior is guaranteed. With reading latencies dropping below the microsecond in modern processors, the system clock in modern operating systems runs in nanoseconds, rather than the microseconds used in the original Unix kernel. With processor speeds exceeding 1 GHz, this assumption may be in jeopardy.
<h4>Leap Seconds</h4>
<p>The International Earth Rotation Service (IERS) uses
astronomical observations provided by USNO and other observatories
to determine UTC, which is syntonic (identical frequency) with TAI
but offset by a integral number of seconds. Starting from apparent
mean solar time as observed, the UT0 timescale is determined using
corrections for Earth orbit and inclination (the Equation of Time,
as used by sundials), the UT1 (navigator's) timescale by adding
corrections for polar migration and the UT2 timescale by adding
corrections for known periodicity variations. UTC is based on UT1,
which is presently fast relative to TAI by a fraction of a second
per year. Since the UTC timescale runs at the TAI rate, when the
magnitude of the UT1 correction approaches 0.5 second, a leap
second is inserted or deleted in the UTC timescale on the last day
of June or December.</p>
<p>For the most precise coordination and timestamping of events
since 1972, it is necessary to know when leap seconds are
implemented in UTC and how the seconds are numbered. The insertion
of leap seconds into UTC is currently the responsibility of the
IERS, which is located at the Paris Observatory. As specified in
CCIR Report 517, a leap second is inserted following second
23:59:59 on the last day of June or December and becomes second
23:59:60 of that day. A leap second would be deleted by omitting
second 23:59:59 on one of these days, although this has never
happened. A table of historic leap seconds and the NTP time when
each occurred is available via FTP from any NIST NTP server.</p>
<p>The UTC timescale thus ticks in standard (atomic) seconds and
was set to an initial offset of 10 seconds relative to TAI at 0h
MJD 41,318.0 according to the Julian calendar or 0h on 1 January
1972 according to the Gregorian calendar. This established the
first tick of the UTC era and its reckoning with these calendars.
Subsequently, the UTC timescale has marched backward relative to
the TAI timescale exactly one second on scheduled occasions
recorded in the institutional memory of our civilization. Note in
passing that leap second adjustments affect the number of seconds
per day and thus the number of seconds per year. Apparently, should
we choose to worry about it, the UTC clock, Gregorian calendar and
various cosmic oscillators will inexorably drift apart with time
until rationalized by some future papal bull.</p>
<h4>Reckoning with NTP and UTC Leap seconds</h4>
<p>The NTP timescale is based on the UTC timescale, but not
necessarily always coincident with it. At the first tick of the UTC
Era, which began at 0h on 1 January 1972 (MJD 41,318.0) the NTP
clock read 2,272,060,800, representing the number of standard
seconds since the beginning of the NTP era at 0h on 1 January 1900
(MJD 15,021.0) according to the Gregorian calendar. The insertion
of leap seconds in UTC and subsequently into NTP does not affect
the UTC or NTP oscillator frequency, only the conversion between
NTP network time and UTC civil time. However, since the only
institutional memory available to NTP are the UTC broadcast
services, the NTP timescale is in effect reset to UTC as each
broadcast timecode is received. Thus, when a leap second is
inserted in UTC and subsequently in NTP, knowledge of all previous
leap seconds is lost.</p>
<p>Another way to describe this is to say there are as many NTP
timescales as historic leap seconds. In effect, a new timescale is
established after each new leap second. Thus, all previous leap
seconds, not to mention the apparent origin of the timescale
itself, lurch forward one second as each new timescale is
established. If a clock synchronized to NTP in early 2001 was used
to establish the UTC epoch of an event that occurred in early 1972
without correction, the event would appear 22 seconds late.
However, NTP primary time servers resolve the epoch using the
broadcast timecode, so that the NTP clock is set to the broadcast
value on the current timescale. As a result, for the most precise
determination of epoch relative to the historic Gregorian calendar
and UTC timescale, the user must subtract from the apparent NTP
epoch the offsets derived from the NIST table. This is a feature of
almost all present day time distribution mechanisms.</p>
<p>The obvious question raised by this scenario is what happens
during the leap second when NTP time stops and the clock remains
unchanged. If the precision time kernel modifications have been
implemented, the kernel includes a state machine that implements
the actions required by the scenario. At the exact instant of the
leap, the logical clock is stepped backward one second. However,
the routine that actually reads the clock is constrained never to
step backwards, unless the step is significantly larger than one
second, which might occur due to explicit operator direction.</p>
<p>In this design time stands still during the leap second, but is correct commencing with the next second. Since clock readings must be positive monotonic, the apparent time will increase by one nanosecond for each reading. At the end of the second the apparent time may be ahead of the actual time depending on how many times the clocks was read during the second. Eventually, the actual time will catch up with the apparent time and operation continues normally.</p>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

43
contrib/ntp/html/measure.htm
View File

@ -6,45 +6,12 @@ Time and Time Interval Measurement with Application to Computer and
Network Performance Evaluation
</h3><hr>
<p>The technical memorandum: <cite>Time and Time Interval Measurement
with Application to Computer and Network Performance Evaluation</cite><a
href="http://www.eecis.udel.edu/~mills/database/memos/memo96a.ps">
(PostScript) </a> describes a number of techniques for conducting
experiments typical of computer network and transmission systems
engineering.
<p>The technical memorandum: <cite>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</cite><a href="http://www.eecis.udel.edu/~mills/database/memos/memo96a.ps">(PostScript) </a> describes a number of techniques for conducting experiments typical of computer network and transmission systems engineering.
<p>In most experiments in which time is involved, it is necessary to
develop estimates of time, frequency and measurement errors from a
series of time measurements between the clocks of a number of computers
and ancillary devices interconnected by some kind of computer network.
However, time is not a physical quantity, such as mass, nor can it be
measured relative to an absolute frame of reference, such as velocity.
The only way to measure time in our universe is to compare the reading
of one clock, which runs according to its own timescale, with another
clock, which runs according to a given timescale, at some given instant
or epoch. The errors arise from the precision of time comparisons and
the accuracy of frequency estimates between the timescales involved.
<p>In most experiments in which time is involved, it is necessary to develop estimates of time, frequency and measurement errors from a series of time measurements between the clocks of a number of computers and ancillary devices interconnected by some kind of computer network. However, time is not a physical quantity, such as mass, nor can it be measured relative to an absolute frame of reference, such as velocity. The only way to measure time in our universe is to compare the reading of one clock, which runs according to its own timescale, with another clock, which runs according to a given timescale, at some given instant or epoch. The errors arise from the precision of time comparisons and the accuracy of frequency estimates between the timescales involved.
<p>The usual data collected during a performance run of some experiment
might include time offsets, time delays, frequency offsets and various
error statistics. While time offsets between two clocks can be measured
directly, frequency offsets can be estimated only from two or more time
offsets made over some time interval in the experiment. In practice, a
sequence of time comparisons can be performed over the lifetime of the
experiment and the instantaneous frequency estimated either in real time
with a recurrence relation, or retrospectively with a polynomial fit to
the data.
<p>The usual data collected during a performance run of some experiment might include time offsets, time delays, frequency offsets and various error statistics. While time offsets between two clocks can be measured directly, frequency offsets can be estimated only from two or more time offsets made over some time interval in the experiment. In practice, a sequence of time comparisons can be performed over the lifetime of the experiment and the instantaneous frequency estimated either in real time with a recurrence relation, or retrospectively with a polynomial fit to the data.
<p>Estimating time and frequency errors in real time has been studied by
a distinct subspecies of physicists who have made a career of the
technology involved. Various means including autoregressive models,
Kalman filters and simple weighted-average algorithms are used
extensively by national standards laboratories to model cesium-clock
ensembles. These techniques have been adapted to computer network and
transmission engineering problems as well. This memorandum explores
issues in performing experiments of this type and summarizes various
techniques found useful in practice.
<p>Estimating time and frequency errors in real time has been studied by a distinct subspecies of physicists who have made a career of the technology involved. Various means including autoregressive models, Kalman filters and simple weighted-average algorithms are used extensively by national standards laboratories to model cesium-clock ensembles. These techniques have been adapted to computer network and transmission engineering problems as well. This memorandum explores issues in performing experiments of this type and summarizes various techniques found useful in practice.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a></address></a></body></html>

381
contrib/ntp/html/miscopt.htm
View File

@ -1,162 +1,279 @@
<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>Miscellaneous Options
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Miscellaneous Options</title>
</head>
<body>
<h3>Miscellaneous Options</h3>
<H3>
Miscellaneous Options</H3>
<img align="left" src="pic/boom3.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<HR>
<DL>
<DT>
<TT>broadcastdelay <I>seconds</I></TT></DT>
<p>We have three, now looking for more.<br clear="left">
</p>
<DD>
The broadcast and multicast modes require a special calibration to determine
the network delay between the local and remote servers. Ordinarily, this
is done automatically by the initial protocol exchanges between the local
and remote servers. In some cases, the calibration procedure may fail due
to network or server access controls, for example. This command specifies
the default delay to be used under these circumstances. Typically (for
Ethernet), a number between 0.003 and 0.007 seconds is appropriate. The
default when this command is not used is 0.004 seconds.</DD>
<hr>
<dl>
<dt><tt>broadcastdelay <i>seconds</i></tt></dt>
<DD>
&nbsp;</DD>
<dd>The broadcast and multicast modes require a special calibration
to determine the network delay between the local and remote
servers. Ordinarily, this is done automatically by the initial
protocol exchanges between the client and server. In some cases,
the calibration procedure may fail due to network or server access
controls, for example. This command specifies the default delay to
be used under these circumstances. Typically (for Ethernet), a
number between 0.003 and 0.007 seconds is appropriate. The default
when this command is not used is 0.004 seconds.</dd>
<DT>
<TT>trap <I>host_address</I> [port <I>port_number</I>] [interface <I>interface_address</I>]</TT></DT>
<dt><tt>driftfile <i>driftfile</i></tt></dt>
<DD>
This command configures a trap receiver at the given host address and port
number for sending messages with the specified local interface address.
If the port number is unspecified. a value of 18447 is used. If the interface
address is not specified, the message is sent with a source address of
the local interface the message is sent through. Note that on a multihomed
host the interface used may vary from time to time with routing changes.</DD>
<dd>This command specifies the name of the file used to record the
frequency offset of the local clock oscillator. If the file exists,
it is read at startup in order to set the initial frequency offset
and then updated once per hour with the current frequency offset
computed by the daemon. If the file does not exist or this command
is not given, the initial frequency offset is assumed zero. In this
case, it may take some hours for the frequency to stabilize and the
residual timing errors to subside.
<DD>
The trap receiver will generally log event messages and other information
from the server in a log file. While such monitor programs may also request
their own trap dynamically, configuring a trap receiver will ensure that
no messages are lost when the server is started.</DD>
<p>The file format consists of a single line containing a single
floating point number, which records the frequency offset measured
in parts-per-million (PPM). The file is updated by first writing
the current drift value into a temporary file and then renaming
this file to replace the old version. This implies that <tt>
ntpd</tt> must have write permission for the directory the drift
file is located in, and that file system links, symbolic or
otherwise, should be avoided.</p>
</dd>
<DD>
&nbsp;</DD>
<dt><tt>enable [auth | bclient | calibrate | kernel | monitor | ntp
| stats]</tt><br>
<tt>disable [auth | bclient | calibrate | kernel | monitor | ntp |
stats</tt></dt>
<DT>
<TT>setvar <I>variable</I> [default]</TT></DT>
<dd>Provides a way to enable or disable various server options.
Flags not mentioned are unaffected. Note that all of these flags
can be controlled remotely using the <a href="ntpdc.htm"><tt>
ntpdc</tt></a> utility program.</dd>
<DD>
This command adds an additional system variable. These variables can be
used to distribute additional information such as the access policy. If
the variable of the form <TT><I>name</I> = <I>value</I></TT> is followed
by the <TT>default</TT> keyword, the variable will be listed as part of
the default system variables (<TT>ntpq rv</TT> command). These additional
variables serve informational purposes only. They are not related to the
protocol other that they can be listed. The known protocol variables will
always override any variables defined via the <TT>setvar</TT> mechanism.
There are three special variables that contain the names of all variable
of the same group. The <TT>sys_var_list</TT> holds the names of all system
variables. The <TT>peer_var_list</TT> holds the names of all peer variables
and the <TT>clock_var_list</TT> holds the names of the reference clock
variables.</DD>
<dd>
<dl>
<dt><tt>bclient</tt></dt>
<DD>
&nbsp;</DD>
<dd>When enabled, this is identical to the <tt>broadcastclient</tt>
command. The default for this flag is <tt>disable</tt>.</dd>
<DT>
<TT>logfile <I>logfile</I></TT></DT>
<dt><tt>calibrate</tt></dt>
<DD>
This command specifies the location of an alternate log file to be used
instead of the default system <TT>syslog</TT> facility.</DD>
<dd>Enables the calibration facility, which automatically adjusts
the <tt>time1</tt> values for each clock driver to display the same
offset as the currently selected source or kernel discipline
signal. See the <a href="refclock.htm">Reference Clock Drivers</a>
for further information. The default for this flag is <tt>
disable</tt>.</dd>
<DD>
&nbsp;</DD>
<dt><tt>kernel</tt></dt>
<DT>
<TT>logconfig <I>configkeyword</I></TT></DT>
<dd>Enables the precision-time kernel support for the <tt>
ntp_adjtime()</tt> system call, if implemented. Ordinarily, support
for this routine is detected automatically when the NTP daemon is
compiled, so it is not necessary for the user to worry about this
flag. It flag is provided primarily so that this support can be
disabled during kernel development. The default for this flag is
<tt>enable</tt>.</dd>
<DD>
This command controls the amount and type of output written to the system
<TT>syslog</TT> facility or the alternate <TT>logfile</TT> log file. By
default, all output is turned on. All <I><TT>configkeyword</TT></I> keywords
can be prefixed with <TT>=</TT>, <TT>+</TT> and <TT>-</TT>, where <TT>=</TT>
sets the <TT>syslogmask</TT>, <TT>+</TT> adds and <TT>-</TT> removes messages.
<TT>syslog messages</TT> can be controlled in four classes (, <TT>peer</TT>,
<TT>sys</TT> and <TT>sync</TT>). Within these classes four types of messages
can be controlled.</DD>
<dt><tt>monitor</tt></dt>
<DD>
Informational messages (<TT>info</TT>) control configuration information.
Event messages (<TT>events</TT>) control logging of events (reachability,
synchronization, alarm conditions). Statistical output is controlled with
the <TT>statistics</TT> keyword. The final message group is the status
messages. This describes mainly the synchronizations status. Configuration
keywords are formed by concatenating the message class with the event class.
The <TT>allprefix</TT> can be used instead of a message class. A message
class may also be followed by the <TT>all</TT> keyword to enable/disable
all messages of the respective message class.</DD>
<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program
and the <tt>monlist</tt> command or further information. The
default for this flag is <tt>enable</tt>.</dd>
<DD>
Thus, a minimal log configuration could look like this:</DD>
<dt><tt>ntp</tt></dt>
<DD>
<TT>logconfig = syncstatus +sysevents</TT></DD>
<dd>Enables the server to adjust its local clock by means of NTP.
If disabled, the local clock free-runs at its intrinsic time and
frequency offset. This flag is useful in case the local clock is
controlled by some other device or protocol and NTP is used only to
provide synchronization to other clients. In this case, the local
clock driver can be used to provide this function and also certain
time variables for error estimates and leap-indicators. See the <a
href="refclock.htm">Reference Clock Drivers</a> page for further
information. The default for this flag is <tt>enable</tt>.</dd>
<DD>
This would just list the synchronizations state of <TT>ntpd</TT> and the
major system events. For a simple reference server, the following minimum
message configuration could be useful:</DD>
<dt><tt>stats</tt></dt>
<DD>
<TT>logconfig = syncall +clockall</TT></DD>
<dd>Enables the statistics facility. See the <a href="monopt.htm">
Monitoring Options</a> page for further information. The default
for this flag is <tt>enable</tt>.</dd>
</dl>
</dd>
<DD>
This configuration will list all clock information and synchronization
information. All other events and messages about peers, system events and
so on is suppressed.</DD>
</DL>
<dt><tt>logconfig <i>configkeyword</i></tt></dt>
<H4>
Variables</H4>
Most variables used by the NTP protocol can be examined with the <TT>ntpdc</TT>
(mode 7 messages) and the <TT>ntpq</TT> (mode 6 messages). Currently, very
few variables can be modified via mode 6 messages. These variables are
either created with the <TT>setvar</TT> directive or the leap warning bits.
The leap warning bits can be set in the <TT>leapwarning</TT> variable up
to one month ahead. Both the <TT>leapwarning</TT> and <TT>leapindication</TT>
variables have a slightly different encoding than the usual leap bits interpretation:
<DL>
<DT>
<TT>00</TT></DT>
<dd>This command controls the amount and type of output written to
the system <tt>syslog</tt> facility or the alternate <tt>
logfile</tt> log file. By default, all output is turned on. All <i>
<tt>configkeyword</tt></i> keywords can be prefixed with <tt>
=</tt>, <tt>+</tt> and <tt>-</tt>, where <tt>=</tt> sets the <tt>
syslogmask</tt>, <tt>+</tt> adds and <tt>-</tt> removes messages.
<tt>syslog messages</tt> can be controlled in four classes
(<tt>clock</tt>, <tt>peer</tt>, <tt>sys</tt> and <tt>sync</tt>).
Within these classes four types of messages can be controlled.</dd>
<DD>
The daemon passes the leap bits of its synchronization source (usual mode
of operation).</DD>
<dd>Informational messages (<tt>info</tt>) control configuration
information. Event messages (<tt>events</tt>) control logging of
events (reachability, synchronization, alarm conditions).
Statistical output is controlled with the <tt>statistics</tt>
keyword. The final message group is the status messages. This
describes mainly the synchronizations status. Configuration
keywords are formed by concatenating the message class with the
event class. The <tt>all</tt> prefix can be used instead of a
message class. A message class may also be followed by the <tt>
all</tt> keyword to enable/disable all messages of the respective
message class.</dd>
<DT>
<TT>01/10</TT></DT>
<dd>Thus, a minimal log configuration could look like this:
<DD>
A leap second is added/deleted (operator forced leap second).</DD>
<p><tt>logconfig=syncstatus +sysevents</tt></p>
<DT>
<TT>11</TT></DT>
<p>This would just list the synchronizations state of <tt>ntpd</tt>
and the major system events. For a simple reference server, the
following minimum message configuration could be useful:</p>
<DD>
Leap information from the synchronizations source is ignored (thus <TT>LEAP_NOWARNING</TT>
is passed on).</DD>
</DL>
<p><tt>logconfig=syncall +clockall</tt></p>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<p>This configuration will list all clock information and
synchronization information. All other events and messages about
peers, system events and so on is suppressed.</p>
</dd>
<dt><tt>logfile <i>logfile</i></tt></dt>
<dd>This command specifies the location of an alternate log file to
be used instead of the default system <tt>syslog</tt>
facility.</dd>
<dt><tt>setvar <i>variable</i> [default]</tt></dt>
<dd>This command adds an additional system variable. These
variables can be used to distribute additional information such as
the access policy. If the variable of the form <tt><i>name</i> =
<i>value</i></tt> is followed by the <tt>default</tt> keyword, the
variable will be listed as part of the default system variables
(<tt>ntpq rv</tt> command). These additional variables serve
informational purposes only. They are not related to the protocol
other that they can be listed. The known protocol variables will
always override any variables defined via the <tt>setvar</tt>
mechanism. There are three special variables that contain the names
of all variable of the same group. The <tt>sys_var_list</tt> holds
the names of all system variables. The <tt>peer_var_list</tt> holds
the names of all peer variables and the <tt>clock_var_list</tt>
holds the names of the reference clock variables.</dd>
<dt><tt>tinker [ step <i>step</i> | panic <i>panic</i> | dispersion
<i>dispersion</i> | stepout <i>stepout</i> | minpoll <i>minpoll</i>
]</tt></dt>
<dd>This command can be used to alter several system variables in
very exceptional circumstances. It should occur in the
configuration file before any other configuration options. The
default values of these variables have been carefully optimized for
a wide range of network speeds and reliability expectations. In
general, they interact in intricate ways that are hard to predict
and some combinations can result in some very nasty behavior. Very
rarely is it necessary to change the default values; but, some
folks can't resist twisting the knobs anyway and this command is
for them. Emphasis added: twisters are on their own and can expect
no help from the support group.
<p>All arguments are in floating point seconds or seconds per
second. The <tt>minpoll</tt> argument is an integer in seconds to
the power of two. The variables operate as follows:</p>
</dd>
<dd>
<dl>
<dt><tt>step <i>step</i></tt></dt>
<dd>The argument becomes the new value for the step threshold,
normally 0.128 s. If set to zero, step adjustments will never
occur. In general, if the intent is only to avoid step adjustments,
the step threshold should be left alone and the <tt>-x</tt> command
line option be used instead.</dd>
<dt><tt>panic <i>panic</i></tt></dt>
<dd>The argument becomes the new value for the panic threshold,
normally 1000 s. If set to zero, the panic sanity check is disabled
and a clock offset of any value will be accepted.</dd>
<dt><tt>dispersion <i>dispersion</i></tt></dt>
<dd>The argument becomes the new value for the dispersion increase
rate, normally .000015.</dd>
<dt><tt>stepout <i>stepout</i></tt></dt>
<dd>The argument becomes the new value for the watchdog timeout,
normally 900 s.</dd>
<dt><tt>minpoll <i>minpoll</i></tt></dt>
<dd>The argument becomes the new value for the minimum poll
interval used when configuring multicast client, manycast client
and , symmetric passive mode association. The value defaults to 6
(64 s) and has a lower limit of 4 (16 s).</dd>
<dt><tt>allan <i>allan</i></tt></dt>
<dd>The argument becomes the new value for the minimum Allan
intercept, which is a parameter of the PLL/FLL clock discipline
algorithm. The value defaults to 1024 s, which is also the lower
limit.</dd>
<dt><tt>huffpuff <i>huffpuff</i></tt></dt>
<dd>The argument becomes the new value for the experimental
huff-n'-puff filter span, which determines the most recent interval
the algorithm will search for a minimum delay. The lower limit is
900 s (15 m), but a more reasonable value is 7200 (2 hours). There
is no default, since the filter is not enabled unless this command
is given.</dd>
</dl>
</dd>
<dt><tt>trap <i>host_address</i> [port <i>port_number</i>]
[interface <i>interface_address</i>]</tt></dt>
<dd>This command configures a trap receiver at the given host
address and port number for sending messages with the specified
local interface address. If the port number is unspecified, a value
of 18447 is used. If the interface address is not specified, the
message is sent with a source address of the local interface the
message is sent through. Note that on a multihomed host the
interface used may vary from time to time with routing changes.
<p>The trap receiver will generally log event messages and other
information from the server in a log file. While such monitor
programs may also request their own trap dynamically, configuring a
trap receiver will ensure that no messages are lost when the server
is started.</p>
</dd>
</dl>
<h4>Files</h4>
<tt>ntp.drift</tt> frequency compensation (PPM)
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

9
contrib/ntp/html/monopt.htm
View File

@ -2,7 +2,12 @@
Monitoring Options
</title></head><body><h3>
Monitoring Options
</h3><hr>
</h3>
<img align=left src=pic/pogo8.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
<p>The pig watches the logs.
<br clear=left><hr>
<h4>Monitoring Support</h4>
@ -117,7 +122,7 @@ running at a remote location.</dd>
<dt><I><tt>name</tt></I></dt>
<dd>This is the type of the statistics records, as shown in the
<tt>statististics</tt> command.</dd>
<tt>statistics</tt> command.</dd>
</dl>

198
contrib/ntp/html/mx4200data.htm
View File

@ -1,7 +1,8 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<HTML>
<HEAD>
<TITLE>MX4200 Receiver Data Format</TITLE>
<TITLE>MX4200 Receiver Data Format</TITLE>
</HEAD>
<BODY>
<h1>MX4200 Receiver Data Format</h1>
@ -10,23 +11,23 @@
<ul>
<li><a href="#control">Control Port Sentences</a></li>
<li><a href="#input">Control Port Input Sentences</a>
<li><a href="#input">Control Port Input Sentences</a></li>
<ul>
<li> <a href="#input_000">$PMVXG,000</a> Initialization/Mode Control - Part A</li>
<li> <a href="#input_001">$PMVXG,001</a> Initialization/Mode Control - Part B</li>
<li> <a href="#input_007">$PMVXG,007</a> Control Port Configuration</li>
<li> <a href="#input_023">$PMVXG,023</a> Time Recovery Configuration</li>
<li> <a href="#input_gpq">$CDGPQ,YYY</a> Query From a Remote Device / Request to Output a Sentence</li>
<li><a href="#input_000">$PMVXG,000</a> Initialization/Mode Control - Part A</li>
<li><a href="#input_001">$PMVXG,001</a> Initialization/Mode Control - Part B</li>
<li><a href="#input_007">$PMVXG,007</a> Control Port Configuration</li>
<li><a href="#input_023">$PMVXG,023</a> Time Recovery Configuration</li>
<li><a href="#input_gpq">$CDGPQ,YYY</a> Query From a Remote Device / Request to Output a Sentence</li>
</ul>
<li><a href="#output">Control Port Output Sentences</a>
<li><a href="#output">Control Port Output Sentences</a></li>
<ul>
<li> <a href="#output_000">$PMVXG,000</a> Receiver Status
<li> <a href="#output_021">$PMVXG,021</a> Position, Height, Velocity
<li> <a href="#output_022">$PMVXG,022</a> DOPs
<li> <a href="#output_030">$PMVXG,030</a> Software Configuration
<li> <a href="#output_101">$PMVXG,101</a> Control Sentence Accept/Reject
<li> <a href="#output_523">$PMVXG,523</a> Time Recovery Configuration
<li> <a href="#output_830">$PMVXG,830</a> Time Recovery Results
<li><a href="#output_000">$PMVXG,000</a> Receiver Status</li>
<li><a href="#output_021">$PMVXG,021</a> Position, Height, Velocity</li>
<li><a href="#output_022">$PMVXG,022</a> DOPs</li>
<li><a href="#output_030">$PMVXG,030</a> Software Configuration</li>
<li><a href="#output_101">$PMVXG,101</a> Control Sentence Accept/Reject</li>
<li><a href="#output_523">$PMVXG,523</a> Time Recovery Configuration</li>
<li><a href="#output_830">$PMVXG,830</a> Time Recovery Results</li>
</ul>
</ul>
@ -38,8 +39,8 @@
the receiver. The structure of the control port sentences is based on
the <cite>NMEA-0183</cite> Standard for Interfacing Marine Electronics
Navigation Devices (version 1.5). For more details, please refer to
the <cite>NMEA-0183</cite> Specification available from the <a
href="http://www.nmea.org/"> National Marine Electronics
the <cite>NMEA-0183</cite> Specification available from the
<a href="http://www.nmea.org/">National Marine Electronics
Association</a>.</p>
<p>Reserved characters are used to indicate the beginning and the end
@ -50,10 +51,7 @@ characters and defines their usage. <a href="#table_1">Table 1</a>
illustrates the general Magnavox proprietary NMEA sentence format.
</p>
<h4><a name="table_1">Table 1. Magnavox Proprietary NMEA Sentence
Format</a></h4>
<p>
<h4><a name="table_1">Table 1. Magnavox Proprietary NMEA Sentence Format</a></h4>
<code>
$PMVXG,XXX,...................*CK
</code>
@ -135,16 +133,16 @@ Initializes the time, position and antenna height of the MX4200.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Default <th>Range
<tr> <td>1 <td>Day <td> <td>Int <td> <td>1-31
<tr> <td>2 <td>Month <td> <td>Int <td> <td>1-12
<tr> <td>3 <td>Year <td> <td>Int <td> <td>1991-9999
<tr> <td>4 <td>GMT Time <td>HHMMSS <td>Int <td> <td>000000-235959
<tr> <td>1 <td>Day <td>&nbsp <td>Int <td>&nbsp <td>1-31
<tr> <td>2 <td>Month <td>&nbsp <td>Int <td>&nbsp <td>1-12
<tr> <td>3 <td>Year <td>&nbsp <td>Int <td>&nbsp <td>1991-9999
<tr> <td>4 <td>GMT Time <td>HHMMSS <td>Int <td>&nbsp <td>000000-235959
<tr> <td>5 <td>WGS-84 Latitude <td>DDMM.MMMM<td>Float<td>0.0 <td>0 - 8959.9999
<tr> <td>6 <td>North/South Indicator <td> <td>Char <td>N <td>N,S
<tr> <td>6 <td>North/South Indicator <td>&nbsp <td>Char <td>N <td>N,S
<tr> <td>7 <td>WGS-84 Longitude <td>DDDMM.MMMM<td>Float<td>0.0 <td>0 - 17959.9999
<tr> <td>8 <td>East/West Indicator <td> <td>Char <td>E <td>E,W
<tr> <td>8 <td>East/West Indicator <td>&nbsp <td>Char <td>E <td>E,W
<tr> <td>9 <td>Altitude (height above Mean Sea Level) in meters (WGS-84) <td>Meters<td>Float<td>0.0<td>+/-99999.0
<tr> <td>10 <td>Not Used <td> <td> <td> <td>
<tr> <td>10 <td>Not Used <td>&nbsp <td>&nbsp <td>&nbsp <td>&nbsp
</table>
Example:<br>
<code>$PMVXG,000,,,,,,,,,,*48</code><br>
@ -160,14 +158,14 @@ DOP limits, and satellite elevation limits.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Default <th>Range
<tr> <td>*1 <td>Constrain Altitude <td> <td>Int <td>1 <td>0=3D Only<br>1=Auto<br>2=2D Only
<tr> <td>2 <td>Not Used <td> <td> <td> <td>
<tr> <td>*1 <td>Constrain Altitude <td>&nbsp <td>Int <td>1 <td>0=3D Only<br>1=Auto<br>2=2D Only
<tr> <td>2 <td>Not Used <td>&nbsp <td>&nbsp<td>&nbsp <td>&nbsp
<tr> <td>*3 <td>Horizontal Acceleration Factor<td>m/sec^2 <td>Float <td>1.0 <td>0.5-10.0
<tr> <td>*4 <td>Not Used <td> <td> <td> <td>
<tr> <td>*5 <td>VDOP Limit <td> <td>Int <td>10 <td>1-9999
<tr> <td>*6 <td>HDOP Limit <td> <td>Int <td>10 <td>1-9999
<tr> <td>*4 <td>Not Used <td>&nbsp <td>&nbsp<td>&nbsp <td>&nbsp
<tr> <td>*5 <td>VDOP Limit <td>&nbsp <td>Int <td>10 <td>1-9999
<tr> <td>*6 <td>HDOP Limit <td>&nbsp <td>Int <td>10 <td>1-9999
<tr> <td>7 <td>Elevation Limit <td>Deg <td>Int <td>5 <td>0-90
<tr> <td>8 <td>Time Output Mode <td> <td>Char <td>U <td>U=UTC<br>L=Local Time
<tr> <td>8 <td>Time Output Mode <td>&nbsp <td>Char <td>U <td>U=UTC<br>L=Local Time
<tr> <td>9 <td>Local Time Offset <td>HHMM <td>Int <td>0 <td>+/- 0-2359
</table>
Example:<br>
@ -185,14 +183,14 @@ that the receiver is to output.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Default <th>Range
<tr> <td>1 <td>Control Port Output Block Label<td> <td>Char <td> <td>
<tr> <td>2 <td>Clear Current Output List<td> <td>Int <td> <td>0=No<br>1=Yes
<tr> <td>3 <td>Add/Delete Sentence from List<td> <td>Int <td> <td>1=Append<br>2=Delete
<tr> <td>4 <td>Not Used <td> <td> <td> <td>
<tr> <td>5 <td>Sentence Output Rate <td>Sec <td>Int <td> <td>1-9999
<tr> <td>6 <td># digits of Precision for CGA and GLL sentences<td> <td>Int <td>2 <td>2-4
<tr> <td>7 <td>Not Used <td> <td> <td> <td>
<tr> <td>8 <td>Not Used <td> <td> <td> <td>
<tr> <td>1 <td>Control Port Output Block Label<td>&nbsp<td>Char <td>&nbsp <td>&nbsp
<tr> <td>2 <td>Clear Current Output List<td>&nbsp<td>Int <td>&nbsp <td>0=No<br>1=Yes
<tr> <td>3 <td>Add/Delete Sentence from List<td>&nbsp<td>Int <td>&nbsp <td>1=Append<br>2=Delete
<tr> <td>4 <td>Not Used <td>&nbsp <td>&nbsp <td>&nbsp <td>&nbsp
<tr> <td>5 <td>Sentence Output Rate <td>Sec <td>Int <td>&nbsp <td>1-9999
<tr> <td>6 <td># digits of Precision for CGA and GLL sentences<td>&nbsp <td>Int <td>2 <td>2-4
<tr> <td>7 <td>Not Used <td>&nbsp <td>&nbsp <td>&nbsp <td>&nbsp
<tr> <td>8 <td>Not Used <td>&nbsp <td>&nbsp <td>&nbsp <td>&nbsp
</table>
Example:<br>
<code>$PMVXG,007,022,0,1,,1,,,*4F</code>
@ -212,13 +210,13 @@ unit.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Default <th>Range
<tr> <td>*1 <td>Time Recovery Mode <td> <td>Char <td>D <td>D=Dynamic<br>S=Static<br>K=Known Position<br>N=No Time Recovery
<tr> <td>2 <td>Time Synchronization <td> <td>Char <td>G <td>U=UTC<br>G=GPS
<tr> <td>3 <td>Time Mark Mode <td> <td>Char <td>A <td>A=Always<br>V=Valid Pulses Only
<tr> <td>*1 <td>Time Recovery Mode <td>&nbsp <td>Char <td>D <td>D=Dynamic<br>S=Static<br>K=Known Position<br>N=No Time Recovery
<tr> <td>2 <td>Time Synchronization <td>&nbsp <td>Char <td>G <td>U=UTC<br>G=GPS
<tr> <td>3 <td>Time Mark Mode <td>&nbsp <td>Char <td>A <td>A=Always<br>V=Valid Pulses Only
<tr> <td>4 <td>Maximum Time Error <td>Nsec <td>Int <td>100 <td>50-1000
<tr> <td>5 <td>User Time Bias <td>Nsec <td>Int <td>0 <td>+/- 99999
<tr> <td>6 <td>ASCII Time Message Control<td> <td>Int <td>0 <td>0=No Output<br>1=830 to Control Port<br>2=830 to Equipment Port
<tr> <td>7 <td>Known Pos PRN <td> <td>Int <td>0 <td>1-32<br>0=Track All Sats
<tr> <td>6 <td>ASCII Time Message Control<td>&nbsp<td>Int <td>0 <td>0=No Output<br>1=830 to Control Port<br>2=830 to Equipment Port
<tr> <td>7 <td>Known Pos PRN <td>&nbsp <td>Int <td>0 <td>1-32<br>0=Track All Sats
</table>
Example:<br>
<code>$PMVXG,023,S,U,A,500,0,1,*16</code>
@ -235,10 +233,10 @@ sentence <a href="#input_007">$PMVXG,007</a>.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Default <th>Range
<tr> <td>1:CD <td>ID of Remote Device <td> <td>Char <td> <td>(See <cite>NMEA-0183</cite>)
<tr> <td>2:GP <td>GPS <td> <td>Char <td> <td>(See <cite>NMEA-0183</cite>)
<tr> <td>3:Q <td>Query <td> <td>Char <td> <td>(See <cite>NMEA-0183</cite>)
<tr> <td>4:YYY <td>Label of Desired Sentence<td> <td>Char <td> <td>Any Valid NMEA or Magnavox Sentence Type
<tr> <td>1:CD <td>ID of Remote Device <td>&nbsp <td>Char <td>&nbsp <td>(See <cite>NMEA-0183</cite>)
<tr> <td>2:GP <td>GPS <td>&nbsp <td>Char <td>&nbsp <td>(See <cite>NMEA-0183</cite>)
<tr> <td>3:Q <td>Query <td>&nbsp <td>Char <td>&nbsp <td>(See <cite>NMEA-0183</cite>)
<tr> <td>4:YYY <td>Label of Desired Sentence<td>&nbsp<td>Char <td>&nbsp <td>Any Valid NMEA or Magnavox Sentence Type
</table>
Example:<br>
<code>$CDGPQ,030*5E</code>
@ -261,11 +259,11 @@ tracked.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<tr> <td>1 <td>Current Receiver Status <td> <td>Char <td>ACQ=Reacquisition<br>ALT=Constellation Selection<br>IAC=Initial Acquisition<br>IDL=Idle, No Satellites<br>NAV=Navigating<br>STS=Search The Sky<br>TRK=Tracking
<tr> <td>2 <td>Number of Satellites that should be Visible <td> <td>Int <td>0-12
<tr> <td>3 <td>Number of Satellites being Tracked <td> <td>Int <td>0-12
<tr> <td>1 <td>Current Receiver Status <td>&nbsp <td>Char <td>ACQ=Reacquisition<br>ALT=Constellation Selection<br>IAC=Initial Acquisition<br>IDL=Idle, No Satellites<br>NAV=Navigating<br>STS=Search The Sky<br>TRK=Tracking
<tr> <td>2 <td>Number of Satellites that should be Visible <td>&nbsp<td>Int <td>0-12
<tr> <td>3 <td>Number of Satellites being Tracked <td>&nbsp <td>Int <td>0-12
<tr> <td>4 <td>Time since Last Navigation <td>HHMM <td>Int <td>0-2359
<tr> <td>5 <td>Initialization Status <td> <td>Int <td>0=Waiting for Initialization<br>1=Initialization Complete
<tr> <td>5 <td>Initialization Status <td>&nbsp <td>Int <td>0=Waiting for Initialization<br>1=Initialization Complete
</table>
Example:<br>
<code>$PMVXG,000,TRK,3,3,0122,1*19</code>
@ -283,14 +281,14 @@ applications.</em>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<tr> <td>1 <td>UTC Measurement Time <td>Seconds into the week<td>Float<td>0-604800.00
<tr> <td>2 <td>WGS-84 Latitude <td>DDMM.MMMM<td>Float <td>0-89.9999
<tr> <td>3 <td>North/South Indicator <td> <td>Char <td>N, S
<tr> <td>3 <td>North/South Indicator <td>&nbsp <td>Char <td>N, S
<tr> <td>4 <td>WGS-84 Longitude <td>DDDMM.MMMM <td>Float <td>0-179.9999
<tr> <td>5 <td>East/West Indicator <td> <td>Char <td>E, W
<tr> <td>6 <td>Altitude (MSL) <td>Meters <td>Float <td>
<tr> <td>7 <td>Geoidal Height <td>Meters <td>Float <td>
<tr> <td>8 <td>Velocity East <td>M/Sec <td>Float <td>
<tr> <td>9 <td>Velocity North <td>M/Sec <td>Float <td>
<tr> <td>10 <td>Navigation Mode <td> <td>Int <td><em>Navigating</em><br>
<tr> <td>5 <td>East/West Indicator <td>&nbsp <td>Char <td>E, W
<tr> <td>6 <td>Altitude (MSL) <td>Meters <td>Float <td>&nbsp
<tr> <td>7 <td>Geoidal Height <td>Meters <td>Float <td>&nbsp
<tr> <td>8 <td>Velocity East <td>M/Sec <td>Float <td>&nbsp
<tr> <td>9 <td>Velocity North <td>M/Sec <td>Float <td>&nbsp
<tr> <td>10 <td>Navigation Mode <td>&nbsp <td>Int <td><em>Navigating</em><br>
1=Position From a Remote Device<br>
2=2D<br>
3=3D<br>
@ -321,21 +319,21 @@ listed. The satellites are listed in receiver channel order. Fields
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<tr> <td>1 <td>UTC Measurement Time <td>Seconds into the week<td>Float<td>0-604800.00
<tr> <td>2 <td>East DOP (EDOP) <td> <td>Float <td>
<tr> <td>3 <td>North DOP (NDOP) <td> <td>Float <td>
<tr> <td>4 <td>Vertical DOP (VDOP) <td> <td>Float <td>
<tr> <td>5 <td>PRN on Channel #1 <td> <td>Int <td>1-32
<tr> <td>6 <td>PRN on Channel #2 <td> <td>Int <td>1-32
<tr> <td>7 <td>PRN on Channel #3 <td> <td>Int <td>1-32
<tr> <td>8 <td>PRN on Channel #4 <td> <td>Int <td>1-32
<tr> <td>9 <td>PRN on Channel #5 <td> <td>Int <td>1-32
<tr> <td>10 <td>PRN on Channel #6 <td> <td>Int <td>1-32
<tr> <td>11 <td>PRN on Channel #7 <td> <td>Int <td>1-32
<tr> <td>12 <td>PRN on Channel #8 <td> <td>Int <td>1-32
<tr> <td>13 <td>PRN on Channel #9 <td> <td>Int <td>1-32
<tr> <td>14 <td>PRN on Channel #10 <td> <td>Int <td>1-32
<tr> <td>15 <td>PRN on Channel #11 <td> <td>Int <td>1-32
<tr> <td>16 <td>PRN on Channel #12 <td> <td>Int <td>1-32
<tr> <td>2 <td>East DOP (EDOP) <td>&nbsp <td>Float <td>&nbsp
<tr> <td>3 <td>North DOP (NDOP) <td>&nbsp <td>Float <td>&nbsp
<tr> <td>4 <td>Vertical DOP (VDOP) <td>&nbsp <td>Float <td>&nbsp
<tr> <td>5 <td>PRN on Channel #1 <td>&nbsp <td>Int <td>1-32
<tr> <td>6 <td>PRN on Channel #2 <td>&nbsp <td>Int <td>1-32
<tr> <td>7 <td>PRN on Channel #3 <td>&nbsp <td>Int <td>1-32
<tr> <td>8 <td>PRN on Channel #4 <td>&nbsp <td>Int <td>1-32
<tr> <td>9 <td>PRN on Channel #5 <td>&nbsp <td>Int <td>1-32
<tr> <td>10 <td>PRN on Channel #6 <td>&nbsp <td>Int <td>1-32
<tr> <td>11 <td>PRN on Channel #7 <td>&nbsp <td>Int <td>1-32
<tr> <td>12 <td>PRN on Channel #8 <td>&nbsp <td>Int <td>1-32
<tr> <td>13 <td>PRN on Channel #9 <td>&nbsp <td>Int <td>1-32
<tr> <td>14 <td>PRN on Channel #10 <td>&nbsp <td>Int <td>1-32
<tr> <td>15 <td>PRN on Channel #11 <td>&nbsp <td>Int <td>1-32
<tr> <td>16 <td>PRN on Channel #12 <td>&nbsp <td>Int <td>1-32
</table>
Example:<br>
<code>$PMVXG,022,142243.00,00.7,00.8,01.9,27,26,10,09,13,23*77</code>
@ -350,8 +348,8 @@ version numbers.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<tr> <td>1 <td>Nav Processor Version Number <td> <td>Char <td>
<tr> <td>2 <td>Baseband Firmware Version Number <td> <td>Char <td>
<tr> <td>1 <td>Nav Processor Version Number <td>&nbsp <td>Char <td>&nbsp
<tr> <td>2 <td>Baseband Firmware Version Number <td>&nbsp <td>Char <td>&nbsp
</table>
Example:<br>
<code>$PMVXG,030,DA35,015</code>
@ -367,16 +365,16 @@ received.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<tr> <td>1 <td>Sentence ID <td> <td>Char <td>
<tr> <td>2 <td>Accept/Reject Status <td> <td>Int <td>0=Sentence Accepted<br>
<tr> <td>1 <td>Sentence ID <td>&nbsp <td>Char <td>&nbsp
<tr> <td>2 <td>Accept/Reject Status <td>&nbsp <td>Int <td>0=Sentence Accepted<br>
1=Bad Checksum<br>
2=Illegal Value<br>
3=Unrecognized ID<br>
4=Wrong # of fields<br>
5=Required Data Field Missing<br>
6=Requested Sentence Unavailable
<tr> <td>3 <td>Bad Field Index <td> <td>Int <td>
<tr> <td>4 <td>Requested Sentence ID (If field #1 = GPQ) <td> <td>Char <td>
<tr> <td>3 <td>Bad Field Index <td>&nbsp <td>Int <td>&nbsp
<tr> <td>4 <td>Requested Sentence ID (If field #1 = GPQ) <td>&nbsp <td>Char <td>&nbsp
</table>
Example:<br>
<code>$PMVXG,101,GPQ,0,,030*0D</code>
@ -391,13 +389,13 @@ of the receiver.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<tr> <td>1 <td>Time Recovery Mode <td> <td>Char <td>D=Dynamic<br>S=Static<br>K=Known Position<br>N=No Time Recovery
<tr> <td>2 <td>Time Synchronization <td> <td>Char <td>U=UTC Time<br>G=GPS Time
<tr> <td>3 <td>Time Mark Mode <td> <td>Char <td>A=Always Output Time Pulse<br>V=Only when Valid
<tr> <td>4 <td>Maximum Time Error for which a time mark will be considered valid <td>Nsec <td>Int <td>
<tr> <td>5 <td>User Time Bias <td>Nsec <td>Int <td>
<tr> <td>6 <td>Time Message Control <td> <td>Int <td>0=No Message<br>1=830 to Control Port<br>2=830 to Equipment Port
<tr> <td>7 <td>Not Used <td> <td> <td>
<tr> <td>1 <td>Time Recovery Mode <td>&nbsp <td>Char <td>D=Dynamic<br>S=Static<br>K=Known Position<br>N=No Time Recovery
<tr> <td>2 <td>Time Synchronization <td>&nbsp <td>Char <td>U=UTC Time<br>G=GPS Time
<tr> <td>3 <td>Time Mark Mode <td>&nbsp <td>Char <td>A=Always Output Time Pulse<br>V=Only when Valid
<tr> <td>4 <td>Maximum Time Error for which a time mark will be considered valid <td>Nsec <td>Int <td>&nbsp
<tr> <td>5 <td>User Time Bias <td>Nsec <td>Int <td>&nbsp
<tr> <td>6 <td>Time Message Control <td>&nbsp <td>Int <td>0=No Message<br>1=830 to Control Port<br>2=830 to Equipment Port
<tr> <td>7 <td>Not Used <td>&nbsp <td>&nbsp <td>&nbsp
</table>
Example:<br>
<code>$PMVXG,523,S,U,A,0500,000000,1,0*23</code>
@ -417,23 +415,23 @@ receivers.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<tr> <td>1 <td>Time Mark Valid <td> <td>Char <td>T=Valid<br>F=Not Valid
<tr> <td>2 <td>Year <td> <td>Int <td>1993-
<tr> <td>3 <td>Month <td> <td>Int <td>1-12
<tr> <td>1 <td>Time Mark Valid <td>&nbsp <td>Char <td>T=Valid<br>F=Not Valid
<tr> <td>2 <td>Year <td>&nbsp <td>Int <td>1993-
<tr> <td>3 <td>Month <td>&nbsp <td>Int <td>1-12
<tr> <td>4 <td>Day <td>Nsec <td>Int <td>1-31
<tr> <td>5 <td>Time <td>HH:MM:SS<td>Int <td>00:00:00-23:59:59
<tr> <td>6 <td>Time Synchronization <td> <td>Char <td>U=UTC<br>G=GPS
<tr> <td>7 <td>Operating Mode <td> <td>Char <td>D=Dynamic<br>S=Static<br>K=Known Position
<tr> <td>8 <td>Oscillator Offset - estimate of oscillator frequency error <td>PPB <td>Int <td>
<tr> <td>9 <td>Time Mark Error of last pulse <td>Nsec <td>Int <td>
<tr> <td>10 <td>User Time Bias <td>Nsec <td>Int <td>
<tr> <td>6 <td>Time Synchronization <td>&nbsp <td>Char <td>U=UTC<br>G=GPS
<tr> <td>7 <td>Operating Mode <td>&nbsp <td>Char <td>D=Dynamic<br>S=Static<br>K=Known Position
<tr> <td>8 <td>Oscillator Offset - estimate of oscillator frequency error <td>PPB <td>Int <td>&nbsp
<tr> <td>9 <td>Time Mark Error of last pulse <td>Nsec <td>Int <td>&nbsp
<tr> <td>10 <td>User Time Bias <td>Nsec <td>Int <td>&nbsp
<tr> <td>11 <td>Leap Second Flag - indicates that a leap second will occur.
This value is usually zero except during the week
prior to a leap second occurence, when this value
will be set to +/-1. A value of +1 indicates
that GPS time will be 1 second further ahead of
UTC time.
<td> <td>Int <td>-1,0,1
<td>&nbsp <td>Int <td>-1,0,1
</table>
Example:<br>
<code>$PMVXG,830,T,1998,10,12,15:30:46,U,S,000298,00003,000000,01*02</code>

2
contrib/ntp/html/notes.htm
View File

@ -724,7 +724,7 @@ for the original NTP specification, once called NTP Version 0.
<H4>
Traffic Monitoring</H4>
<TT>ntpd</TT> handles peers whose stratum is higher than the stratum of
the local server and pollers using client mode by a fast path which
the local server and polls using client mode by a fast path which
minimizes
the work done in responding to their polls, and normally retains no
memory

562
contrib/ntp/html/ntpd.htm
View File

@ -1,183 +1,457 @@
<HTML><HEAD><TITLE>
<TT>ntpd</TT> - Network Time Protocol (NTP) daemon
</TITLE></HEAD><BODY><H3>
<TT>ntpd</TT> - Network Time Protocol (NTP) daemon
</H3><HR>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntpd - Network Time Protocol (NTP) daemon</title>
</head>
<body>
<h3><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</h3>
<H4>Synopsis</H4>
<img align="left" src="pic/alice47.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
Adventures in Wonderland</i>, Lewis Carroll</a>
<TT>ntpd [ -aAbdm ] [ -c <I>conffile</I> ] [ -f <I>driftfile</I> ] [ -g
] [ -k <I>keyfile</I> ] [ -l <I>logfile</I> ] [ -p <I>pidfile</I> ] [ -r
<I>broadcastdelay</I> ] [ -s <I>statsdir</I> ] [ -t <I>key</I> ] [ -v
<I>variable</I> ] [ -V <I>variable</I> ] [ -x ]</TT>
<p>The mushroom knows all the command line options.<br clear=
"left">
</p>
<H4>Description</H4>
<hr>
<h4>Synopsis</h4>
<TT>ntpd</TT> is an operating system daemon which sets and maintains the
system time-of-day in synchronism with Internet standard time servers.
<TT>ntpd</TT> is a complete implementation of the Network Time Protocol
(NTP) version 4, but also retains compatibility with version 3, as
defined by RFC-1305, and version 1 and 2, as defined by RFC-1059 and
RFC-1119, respectively. <TT>ntpd</TT> does most computations in 64-bit
floating point arithmetic and does relatively clumsy 64-bit fixed point
operations only when necessary to preserve the unltimate precision,
about 232 picoseconds. While the ultimate precision, is not achievable
with ordinary workstations and networks of today, it may be required
with future nanosecond CPU clocks and gigabit LANs.
<tt>ntpd [ -aAbdgLmNPqx ] [ -c <i>conffile</i> ] [ -f <i>
driftfile</i> ] [ -g ] [ -k <i>keyfile</i> ] [ -l <i>logfile</i> ]
[ -N high ] [ -p <i>pidfile</i> ] [ -r <i>broadcastdelay</i> ] [ -s
<i>statsdir</i> ] [ -t <i>key</i> ] [ -v <i>variable</i> ] [ -V <i>
variable</i> ] [ -x ]</tt>
<P>The daemon can operate in any of several modes, including symmetric
active/passive, client/server broadcast/multicast and manycast. A
<h4>Description</h4>
The <tt>ntpd</tt> program is an operating system daemon which sets
and maintains the system time of day in synchronism with Internet
standard time servers. It is a complete implementation of the
Network Time Protocol (NTP) version 4, but also retains
compatibility with version 3, as defined by RFC-1305, and version 1
and 2, as defined by RFC-1059 and RFC-1119, respectively. <tt>
ntpd</tt> does most computations in 64-bit floating point
arithmetic and does relatively clumsy 64-bit fixed point operations
only when necessary to preserve the ultimate precision, about 232
picoseconds. While the ultimate precision, is not achievable with
ordinary workstations and networks of today, it may be required
with future gigahertz CPU clocks and gigabit LANs.
<h4>How NTP Operates</h4>
<p>The <tt>ntpd</tt> program operates by exchanging messages with
one or more configured servers at designated poll intervals. When
started, whether for the first or subsequent times, the program
requires several exahanges from the majority of these servers so
the signal processing and mitigation algorithms can accumulate and
groom the data and set the clock. In order to protect the network
from bursts, the initial poll interval for each server is delayed
an interval randomized over 0-16s. At the default initial poll
interval of 64s, several minutes can elapse before the clock is
set. The initial delay to set the clock can be reduced using the
<tt>iburst</tt> keyword with the <tt>server</tt> configuration
command, as described on the <a href="confopt.htm">Configuration
Options</a> page.</p>
<p>Most operating systems and hardware of today incorporate a
time-of-year (TOY) chip to maintain the time during periods when
the power is off. When the machine is booted, the chip is used to
initialize the operating system time. After the machine has
synchronized to a NTP server, the operating system corrects the
chip from time to time. In case there is no TOY chip or for some
reason its time is more than 1000s from the server time, <tt>
ntpd</tt> assumes something must be terribly wrong and the only
reliable action is for the operator to intervene and set the clock
by hand. This causes <tt>ntpd</tt> to exit with a panic message to
the system log. The <tt>-g</tt> option overrides this check and the
clock will be set to the server time regardless of the chip time.
However, and to protect against broken hardware, such as when the
CMOS battery fails or the clock counter becomes defective, once the
clock has been set, an error greater than 1000s will cause <tt>
ntpd</tt> to exit anyway.</p>
<p>Under ordinariy conditions, <tt>ntpd</tt> adjusts the clock in
small steps so that the timescale is effectively continuous and
without discontinuities. Under conditions of extreme network
congestion, the roundtrip delay jitter can exceed three seconds and
the synchronization distance, which is equal to one-half the
roundtrip delay plus error budget terms, can become very large. The
<tt>ntpd</tt> algorithms discard sample offsets exceeding 128 ms,
unless the interval during which no sample offset is less than 128
ms exceeds 900s. The first sample after that, no matter what the
offset, steps the clock to the indicated time. In practice this
reduces the false alarm rate where the clock is stepped in error to
a vanishingly low incidence.</p>
<p>As the result of this behavior, once the clock has been set, it
very rarely strays more than 128 ms, even under extreme cases of
network path congestion and jitter. Sometimes, in particular when
<tt>ntpd</tt> is first started, the error might exceed 128 ms. This
may on occasion cause the clock to be set backwards if the local
clock time is more than 128 s in the future relative to the server.
In some applications, this behavior may be unacceptable. If the
<tt>-x</tt> option is included on the command line, the clock will
never be stepped and only slew corrections will be used.</p>
<p>The issues should be carefully explored before deciding to use
the <tt>-x</tt> option. The maximum slew rate possible is limited
to 500 parts-per-million (PPM) as a consequence of the correctness
principles on which the NTP protocol and algorithm design are
based. As a result, the local clock can take a long time to
converge to an acceptable offset, about 2,000 s for each second the
clock is outside the acceptable range. During this interval the
local clock will not be consistent with any other network clock and
the system cannot be used for distributed applications that require
correctly synchronized network time.</p>
<p>In spite of the above precautions, sometimes when large
frequency errors are present the resulting time offsets stray
outside the 128-ms range and an eventual step or slew time
correction is required. If following such a correction the
frequency error is so large that the first sample is outside the
acceptable range, <tt>ntpd</tt> enters the same state as when the
<tt>ntp.drift</tt> file is not present. The intent of this behavior
is to quickly correct the frequency and restore operation to the
normal tracking mode. In the most extreme cases
(<tt>time.ien.it</tt> comes to mind), there may be occasional
step/slew corrections and subsequent frequency corrections. It
helps in these cases to use the <tt>burst</tt> keyword when
configuring the server.</p>
<h4>Frequency Discipline</h4>
<p>The <tt>ntpd</tt> behavior at startup depends on whether the
frequency file, usually <tt>ntp.drift</tt>, exists. This file
contains the latest estimate of clock frequency error. When the
<tt>ntpd</tt> is started and the file does not exist, the <tt>
ntpd</tt> enters a special mode designed to quickly adapt to the
particular system clock oscillator time and frequency error. This
takes approximately 15 minutes, after which the time and frequency
are set to nominal values and the <tt>ntpd</tt> enters normal mode,
where the time and frequency are continuously tracked relative to
the server. After one hour the frequency file is created and the
current frequency offset written to it. When the <tt>ntpd</tt> is
started and the file does exist, the <tt>ntpd</tt> frequency is
initialized from the file and enters normal mode immediately. After
that the current frequency offset is written to the file at hourly
intervals.</p>
<h4>Operating Modes</h4>
<p><tt>ntpd</tt> can operate in any of several modes, including
symmetric active/passive, client/server broadcast/multicast and
manycast, as described in the <a href="assoc.htm">Association
Management</a> page. It normally operates continuously while
monitoring for small changes in frequency and trimming the clock
for the ultimate precision. However, it can operate in a one-time
mode where the time is set from an external server and frequency is
set from a previously recorded frequency file. A
broadcast/multicast or manycast client can discover remote servers,
compute server-client propagation delay correction factors and configure
itself automatically. This makes it possible to deploy a fleet of
workstations without specifying configuration details specific to the
local environment.
compute server-client propagation delay correction factors and
configure itself automatically. This makes it possible to deploy a
fleet of workstations without specifying configuration details
specific to the local environment.</p>
<P>Ordinarily, <TT>ntpd</TT> reads the <TT>ntp.conf</TT> configuration
file at startup time in order to determine the synchronization sources
and operating modes. It is also possible to specify a working, although
limited, configuration entirely on the command line, obviating the need
for a configuration file. This may be particularly appropriate when the
local host is to be configured as a broadcast/multicast client or
manycast client, with all peers being determined by listening to
broadcasts at run time.
<p>By default, <tt>ntpd</tt> runs in continuous mode where each of
possibly several external servers is polled at intervals determined
by an intricate state machine. The state machine measures the
incidental roundtrip delay jitter and oscillator frequency wander
and determines the best poll interval using a heuristic algorithm.
Ordinarily, and in most operating environments, the state machine
will start with 64s intervals and eventually increase in steps to
1024s. A small amount of random variation is introduced in order to
avoid bunching at the servers. In addition, should a server become
unreachable for some time, the poll interval is increased in steps
to 1024s in order to reduce network overhead.</p>
<P>If NetInfo support is built into <TT>ntpd</TT>, then <TT>ntpd</TT>
will attempt to read its configuration from the NetInfo if the default
ntp.conf file cannot be read and no file is specified by the <TT>-c</TT>
option.
<p>In some cases it may not be practical for <tt>ntpd</tt> to run
continuously. A common workaround has been to run the <tt>
ntpdate</tt> program from a <tt>cron</tt> job at designated times.
However, this program does not have the crafted signal processing,
error checking and mitigation algorithms of <tt>ntpd</tt>. The <tt>
-q</tt> option is intended for this purpose. Setting this option
will cause <tt>ntpd</tt> to exit just after setting the clock for
the first time. The procedure for initially setting the clock is
the same as in continuous mode; most applications will probably
want to specify the <tt>iburst</tt> keyword with the <tt>
server</tt> configuration command. With this keyword a volley of
messages are exchanged to groom the data and the clock is set in
about a minute. If nothing is heard after a couple of minutes, the
daemon times out and exits. After a suitable period of mourning,
the <tt>ntpdate</tt> program may be retired.</p>
<P>Various internal <TT>ntpd</TT> variables can be displayed and
configuration options altered while the daemon is running using the
<TT><A HREF="ntpq.htm">ntpq</A></TT> and <TT><A
HREF="ntpdc.htm">ntpdc</A></TT> utility programs.
<p>When kernel support is available to discipline the clock
frequency, which is the case for stock Solaris, Tru64, Linux and
FreeBSD, a useful feature is available to discipline the clock
frequency. First, <tt>ntpd</tt> is run in continuous mode with
selected servers in order to measure and record the intrinsic clock
frequency offset in the frequency file. It may take some hours for
the frequency and offset to settle down. Then the <tt>ntpd</tt> is
stopped and run in one-time mode as required. At each startup, the
frequency is read from the file and initializes the kernel
frequency.</p>
<P>When <TT>ntpd</TT> starts it looks at the value of <TT>umask</TT>,
and if it's zero <TT>ntpd</TT> will set the <TT>umask</TT> to
<TT>022</TT>.
<h4>Poll Interval Control</h4>
<H4>Command Line Options</H4>
<p>This version of NTP includes an intricate state machine to
reduce the network load while maintaining a quality of
synchronization consistent with the observed jitter and wander.
There are a number of ways to tailor the operation in order enhance
accuracy by reducing the interval or to reduce network overhead by
increasing it. However, the user is advised to carefully consider
the consequenses of changing the poll adjustment range from the
default minimum of 64 s to the default maximum of 1,024 s. The
default minimum can be changed with the <tt>tinker minpoll</tt>
command to a value not less than 16 s. This value is used for all
configured associations, unless overriden by the <tt>minpoll</tt>
option on the configuration command. Note that most device drivers
will not operate properly if the poll interval is less than 64 s
and that the broadcast server and manycast client associations will
also use the default, unless overriden.</p>
<DL>
<p>In some cases involving dial up or toll services, it may be
useful to increase the minimum interval to a few tens of minutes
and maximum interval to a day or so. Under normal operation
conditions, once the clock discipline loop has stabilized the
interval will be increased in steps from the minumum to the
maximum. However, this assumes the intrinsic clock frequency error
is small enough for the discipline loop correct it. The capture
range of the loop is 500 PPM at an interval of 64s decreasing by a
factor of two for each doubling of interval. At a minimum of 1,024
s, for example, the capture range is only 31 PPM. If the intrinsic
error is greater than this, the drift file <tt>ntp.drift</tt> will
have to be specially tailored to reduce the residual error below
this limit. Once this is done, the drift file is automatically
updated once per hour and is available to initialize the frequency
on subsequent daemon restarts.</p>
<DT><TT>-a</TT></DT>
<DD>Enable authentication mode (default).</DD>
<h4>The huff-n'-puff filter</h4>
<DT><TT>-A</TT></DT>
<DD>Disable authentication mode.</DD>
<p>In scenarios where a considerable amount of data are to be
downloaded or uploaded over telephone modems, timekeeping quality
can be seriously degraded. This occurs because the differential
delays on the two directions of transmission can be quite large. In
many cases the apparent time errors are so large as to exceed the
step threshold and a step correction can occur during and after the
data transfer is in progress.</p>
<DT><TT>-b</TT></DT>
<DD>Synchronize using NTP broadcast messages.</DD>
<p>The huff-n'-puff filter is designed to correct the apparent time
offset in these cases. It depends on knowledge of the propagation
delay when no other traffic is present. In common scenarios this
occurs during other than work hours. The filter maintains a shift
register that remembers the minimum delay over the most recent
interval measured usually in hours. Under conditions of severe
delay, the filter corrects the apparent offset using the sign of
the offset and the difference between the apparent delay and
minimum delay. The name of the filter reflects the negative (huff)
and positive (puff) correction, which depends on the sign of the
offset.</p>
<DT><TT>-c <I>conffile</I></TT></DT>
<DD>Specify the name and path of the configuration file.</DD>
<p>The filter is activated by the <tt>tinker</tt> command and <tt>
huffpuff</tt> keyword, as described in the <a href="miscopt.htm">
Miscellaneous Options</a> page.</p>
<DT><TT>-d</TT></DT>
<DD>Specify debugging mode. This flag may occur multiple times, with
each occurrence indicating greater detail of display.</DD>
<h4>Notes</h4>
<DT><TT>-D <I>level</I></TT></DT>
<DD>Specify debugging level directly.</DD>
<p>If NetInfo support is built into <tt>ntpd</tt>, then <tt>
ntpd</tt> will attempt to read its configuration from the NetInfo
if the default ntp.conf file cannot be read and no file is
specified by the <tt>-c</tt> option.</p>
<DT><TT>-f <I>driftfile</I></TT></DT>
<DD>Specify the name and path of the drift file.</DD>
<p>Various internal <tt>ntpd</tt> variables can be displayed and
configuration options altered while the <tt>ntpd</tt> is running
using the <tt><a href="ntpq.htm">ntpq</a></tt> and <tt><a href=
"ntpdc.htm">ntpdc</a></tt> utility programs.</p>
<DT><TT>-g</TT></DT>
<DD>Normally, the daemon exits if the offset exceeds a 1000-s sanity
limit. This option overrides this limit and allows the time to be set to
any value without restriction; however, this can happen only once. After
that, the daemon will exit of the limit is exceeded.
<p>When <tt>ntpd</tt> starts it looks at the value of <tt>
umask</tt>, and if zero <tt>ntpd</tt> will set the <tt>umask</tt>
to <tt>022</tt>.</p>
<DT><TT>-k <I>keyfile</I></TT></DT>
<DD>Specify the name and path of the file containing the NTP
authentication keys.</DD>
<h4>Command Line Options</h4>
<DT><TT>-l <I>logfile</I></TT></DT>
<DD>Specify the name and path of the log file. The default is the system
log facility.</DD>
<dl>
<dt><tt>-a</tt></dt>
<DT><TT>-m</TT></DT>
<DD>Synchronize using NTP multicast messages on the IP multicast group
address 224.0.1.1 (requires multicast kernel).</DD>
<dd>Enable authentication mode (default).</dd>
<DT><TT>-p <I>pidfile</I></TT></DT>
<DD>Specify the name and path to record the daemon's process ID.</DD>
<dt><tt>-A</tt></dt>
<DT><TT>-P</TT></DT>
<DD>Override the priority limit set by the operating system. Not
recommended for sissies.</DD>
<dd>Disable authentication mode.</dd>
<DT><TT>-r <I>broadcastdelay</I></TT></DT>
<DD>Specify the default propagation delay from the broadcast/multicast
server and this computer. This is necessary only if the delay cannot be
computed automatically by the protocol.</DD>
<dt><tt>-b</tt></dt>
<DT><TT>-s <I>statsdir</I></TT></DT>
<DD>Specify the directory path for files created by the statistics
facility.</DD>
<dd>Synchronize using NTP broadcast messages.</dd>
<DT><TT>-t <I>key</I></TT></DT>
<DD>Add a key number to the trusted key list.</DD>
<dt><tt>-c <i>conffile</i></tt></dt>
<DT><TT>-v <I>variable</I></TT></DT>
<DT><TT>-V <I>variable</I></TT></DT>
<DD>Add a system variable listed by default.</DD>
<dd>Specify the name and path of the configuration file. (Disable
netinfo?)</dd>
<DT><TT>-x</TT></DT>
<DD>Ordinarily, if the time is to be adjusted more than 128 ms, it is
stepped, not gradually slewed. This option forces the time to be slewed
in all cases. Note: Since the slew rate is limited to 0.5 ms/s, each
second of adjustment requires an amortization interval of 2000 s. Thus,
an adjustment of many seconds can take hours or days to amortize.</DD>
</DL>
<dt><tt>-d</tt></dt>
<H4>The Configuration File</H4>
<dd>Specify debugging mode. This flag may occur multiple times,
with each occurrence indicating greater detail of display.</dd>
The <TT>ntpd</TT> configuration file is read at initial startup in order
to specify the synchronization sources, modes and other related
information. Usually, it is installed in the <TT>/etc</TT> directory,
but could be installed elsewhere (see the <TT>-c <I>conffile</I></TT>
command line option). The file format is similar to other Unix
configuration files - comments begin with a <TT>#</TT> character and
extend to the end of the line; blank lines are ignored. Configuration
commands consist of an initial keyword followed by a list of arguments,
some of which may be optional, separated by whitespace. Commands may not
be continued over multiple lines. Arguments may be host names, host
addresses written in numeric, dotted-quad form, integers, floating
point numbers (when specifying times in seconds) and text strings.
Optional arguments are delimited by <TT>[ ]</TT> in the following
descriptions, while alternatives are separated by <TT>|</TT>. The
notation <TT>[ ... ]</TT> means an optional, indefinite repetition of
the last item before the <TT>[ ... ]</TT>.
<dt><tt>-D <i>level</i></tt></dt>
<P>See the following pages for configuration and control options. While
there is a rich set of options available, the only required option is
one or more <TT>server, peer,</TT> <TT>broadcast</TT> or
<TT>manycastclient </TT>commands described in the Configuration Options
page. The <A HREF="notes.htm">Notes on Configuring NTP and Setting up a
NTP Subnet </A>page contains an extended discussion of these options.
<dd>Specify debugging level directly.</dd>
<P><A HREF="confopt.htm">Configuration Options</A>
<BR><A HREF="authopt.htm">Authentication Options</A>
<BR><A HREF="monopt.htm">Monitoring Options</A>
<BR><A HREF="accopt.htm">Access Control Options</A>
<BR><A HREF="clockopt.htm">Reference Clock Options</A>
<BR><A HREF="miscopt.htm">Miscellaneous Options</A>
<dt><tt>-f <i>driftfile</i></tt></dt>
<H4>Files</H4>
<dd>Specify the name and path of the drift file.</dd>
<TT>/etc/ntp.conf</TT> - the default name of the configuration file
<BR><TT>/etc/ntp.drift</TT> - the default name of the drift file
<BR><TT>/etc/ntp.keys</TT> - the default name of the key file
<dt><tt>-g</tt></dt>
<H4>Bugs</H4>
<dd>Normally, <tt>ntpd</tt> exits if the offset exceeds the sanity
limit, which is 1000 s by default. If the sanity limit is set to
zero, no sanity checking is performed and any offset is acceptable.
This option overrides the limit and allows the time to be set to
any value without restriction; however, this can happen only once.
After that, <tt>ntpd</tt> will exit if the limit is exceeded. This
option can be used with the <tt>-q</tt> option.</dd>
<TT>ntpd</TT> has gotten rather fat. While not huge, it has gotten
larger than might be desireable for an elevated-priority daemon running
on a workstation, particularly since many of the fancy features which
consume the space were designed more with a busy primary server, rather
than a high stratum workstation, in mind.
<dt><tt>-k <i>keyfile</i></tt></dt>
<dd>Specify the name and path of the file containing the NTP
authentication keys.</dd>
<dt><tt>-l <i>logfile</i></tt></dt>
<dd>Specify the name and path of the log file. The default is the
system log facility.</dd>
<dt><tt>-L</tt></dt>
<dd>Listen to virtual IPs.</dd>
<dt><tt>-m</tt></dt>
<dd>Synchronize using NTP multicast messages on the IP multicast
group address 224.0.1.1 (requires multicast kernel).</dd>
<dt><tt>-n</tt></dt>
<dd>Don't fork.</dd>
<dt><tt>-N <i>priority</i></tt></dt>
<dd>To the extent permitted by the operating system, run the <tt>
ntpd</tt> at a high priority.</dd>
<dt><tt>-p <i>pidfile</i></tt></dt>
<dd>Specify the name and path to record the <tt>ntpd</tt>'s process
ID.</dd>
<dt><tt>-P</tt></dt>
<dd>Override the priority limit set by the operating system. Not
recommended for sissies.</dd>
<dt><tt>-q</tt></dt>
<dd>Exit the <tt>ntpd</tt> just after the first time the clock is
set. This behavior mimics that of the <tt>ntpdate</tt> program,
which is to be retired. The <tt>-g</tt> and <tt>-x</tt> options can
be used with this option.</dd>
<dt><tt>-r <i>broadcastdelay</i></tt></dt>
<dd>Specify the default propagation delay from the
broadcast/multicast server and this computer. This is necessary
only if the delay cannot be computed automatically by the
protocol.</dd>
<dt><tt>-s <i>statsdir</i></tt></dt>
<dd>Specify the directory path for files created by the statistics
facility.</dd>
<dt><tt>-t <i>key</i></tt></dt>
<dd>Add a key number to the trusted key list.</dd>
<dt><tt>-v <i>variable</i></tt></dt>
<dt><tt>-V <i>variable</i></tt></dt>
<dd>Add a system variable listed by default.</dd>
<dt><tt>-x</tt></dt>
<dd>Normally, the time is slewed if the offset is less than the
step threshold, which is 128 ms by default, and stepped if above
the threshold. This option forces the time to be slewed in all
cases. If the step threshold is set to zero, all offsets are
stepped, regardless of value and regardless of the <tt>-x</tt>
option. In general, this is not a good idea, as it bypasses the
clock state machine which is designed to cope with large time and
frequency errors Note: Since the slew rate is limited to 0.5 ms/s,
each second of adjustment requires an amortization interval of 2000
s. Thus, an adjustment of many seconds can take hours or days to
amortize. This option can be used with the <tt>-q</tt> option.</dd>
</dl>
<h4>The Configuration File</h4>
<p>Ordinarily, <tt>ntpd</tt> reads the <tt>ntp.conf</tt>
configuration file at startup time in order to determine the
synchronization sources and operating modes. It is also possible to
specify a working, although limited, configuration entirely on the
command line, obviating the need for a configuration file. This may
be particularly useful when the local host is to be configured as a
broadcast/multicast client, with all peers being determined by
listening to broadcasts at run time.</p>
<p>Usually, the configuration file is installed in the <tt>
/etc</tt> directory, but could be installed elsewhere (see the <tt>
-c <i>conffile</i></tt> command line option). The file format is
similar to other Unix configuration files - comments begin with a
<tt>#</tt> character and extend to the end of the line; blank lines
are ignored.</p>
<p>Configuration commands consist of an initial keyword followed by
a list of arguments, some of which may be optional, separated by
whitespace. Commands may not be continued over multiple lines.
Arguments may be host names, host addresses written in numeric,
dotted-quad form, integers, floating point numbers (when specifying
times in seconds) and text strings. Optional arguments are
delimited by <tt>[ ]</tt> in the following descriptions, while
alternatives are separated by <tt>|</tt>. The notation <tt>[ ...
]</tt> means an optional, indefinite repetition of the last item
before the <tt>[ ... ]</tt>.</p>
<p><a href="confopt.htm">Configuration Options</a><br>
<a href="authopt.htm">Authentication Options</a><br>
<a href="monopt.htm">Monitoring Options</a><br>
<a href="accopt.htm">Access Control Options</a><br>
<a href="clockopt.htm">Reference Clock Options</a><br>
<a href="miscopt.htm">Miscellaneous Options</a></p>
<h4>Files</h4>
<tt>/etc/ntp.conf</tt> - the default name of the configuration file
<br>
<tt>/etc/ntp.drift</tt> - the default name of the drift file <br>
<tt>/etc/ntp.keys</tt> - the default name of the key file
<h4>Bugs</h4>
<tt>ntpd</tt> has gotten rather fat. While not huge, it has gotten
larger than might be desirable for an elevated-priority <tt>
ntpd</tt> running on a workstation, particularly since many of the
fancy features which consume the space were designed more with a
busy primary server, rather than a high stratum workstation in
mind.
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

301
contrib/ntp/html/ntpdate.htm
View File

@ -1,185 +1,186 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>ntpdate - set the date and time via NTP
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntpdate - set the date and time via NTP</title>
</head>
<body>
<h3><tt>ntpdate</tt> - set the date and time via NTP</h3>
<H3>
<TT>ntpdate</TT> - set the date and time via NTP</H3>
<img align="left" src="pic/rabbit.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
Adventures in Wonderland</i>, Lewis Carroll</a>
<HR>
<H4>
Synopsis</H4>
<TT>ntpdate [ -bBdoqsuv ] [ -a <I>key</I> ] [ -e <I>authdelay</I> ] [ -k
<I>keyfile</I> ] [ -o <I>version</I> ] [ -p <I>samples</I> ] [ -t <I>timeout</I>
] <I>server</I> [ ... ]</TT>
<H4>
Description</H4>
<TT>ntpdate</TT> sets the local date and time by polling the Network Time
Protocol (NTP) server(s) given as the <I>server</I> arguments to determine
the correct time. It must be run as root on the local host. A number of
samples are obtained from each of the servers specified and a subset of
the NTP clock filter and selection algorithms are applied to select the
best of these. Note that the accuracy and reliability of <TT>ntpdate</TT>
depends on the number of servers, the number of polls each time it is run
and the interval between runs.
<p>I told you it was eyeball and wristwatch.<br clear="left">
</p>
<P><TT>ntpdate</TT> can be run manually as necessary to set the host clock,
or it can be run from the host startup script to set the clock at boot
time. This is useful in some cases to set the clock initially before starting
the NTP daemon <TT>ntpd</TT>. It is also possible to run <TT>ntpdate</TT>
from a <TT>cron</TT> script. However, it is important to note that <TT>ntpdate</TT>
with contrived <TT>cron</TT> scripts is no substitute for the NTP daemon,
which uses sophisticated algorithms to maximize accuracy and reliability
while minimizing resource use. Finally, since <TT>ntpdate</TT> does not
discipline the host clock frequency as does <TT>ntpd</TT>, the accuracy
using <TT>ntpdate</TT> is limited.
<hr>
<p>Disclaimer: The functionality of this program is now available
in the <tt>ntpd</tt> program. See the <tt>-q</tt> command line
option in the <a href="ntpd.htm"><tt>ntpd</tt> - Network Time
Protocol (NTP) daemon</a> page. After a suitable period of
mourning, the <tt>ntpdate</tt> program is to be retired from this
distribution</p>
<P>Time adjustments are made by <TT>ntpdate</TT> in one of two ways. If
<TT>ntpdate</TT> determines the clock is in error more than 0.5 second
it will simply step the time by calling the system <TT>settimeofday()</TT>
routine. If the error is less than 0.5 seconds, it will slew the time by
calling the system <TT>adjtime()</TT> routine. The latter technique is
less disruptive and more accurate when the error is small, and works quite
well when <TT>ntpdate</TT> is run by <TT>cron</TT> every hour or two.
<h4>Synopsis</h4>
<P><TT>ntpdate</TT> will decline to set the date if an NTP server daemon
(e.g., <TT>ntpd</TT>) is running on the same host. When running <TT>ntpdate</TT>
on a regular basis from <TT>cron</TT> as an alternative to running a daemon,
doing so once every hour or two will result in precise enough timekeeping
to avoid stepping the clock.
<tt>ntpdate [ -bBdoqsuv ] [ -a <i>key</i> ] [ -e <i>authdelay</i> ]
[ -k <i>keyfile</i> ] [ -o <i>version</i> ] [ -p <i>samples</i> ] [
-t <i>timeout</i> ] <i>server</i> [ ... ]</tt>
<P>If NetInfo support is compiled into <TT>ntpdate</TT>, then the
<TT>server</TT> argument is optional if <TT>ntpdate</TT> can find a time
server in the NetInfo configuration for <TT>ntpd</TT>.
<h4>Description</h4>
<H4>
Command Line Options</H4>
<tt>ntpdate</tt> sets the local date and time by polling the
Network Time Protocol (NTP) server(s) given as the <i>server</i>
arguments to determine the correct time. It must be run as root on
the local host. A number of samples are obtained from each of the
servers specified and a subset of the NTP clock filter and
selection algorithms are applied to select the best of these. Note
that the accuracy and reliability of <tt>ntpdate</tt> depends on
the number of servers, the number of polls each time it is run and
the interval between runs.
<DL>
<DT>
<TT>-a <I>key</I></TT></DT>
<p><tt>ntpdate</tt> can be run manually as necessary to set the
host clock, or it can be run from the host startup script to set
the clock at boot time. This is useful in some cases to set the
clock initially before starting the NTP daemon <tt>ntpd</tt>. It is
also possible to run <tt>ntpdate</tt> from a <tt>cron</tt> script.
However, it is important to note that <tt>ntpdate</tt> with
contrived <tt>cron</tt> scripts is no substitute for the NTP
daemon, which uses sophisticated algorithms to maximize accuracy
and reliability while minimizing resource use. Finally, since <tt>
ntpdate</tt> does not discipline the host clock frequency as does
<tt>ntpd</tt>, the accuracy using <tt>ntpdate</tt> is limited.</p>
<DD>
Enable the authentication function and specify the key identifier to be
used for authentication as the argument <I>key</I><TT>ntpdate</TT>. The
keys and key identifiers must match in both the client and server key files.
The default is to disable the authentication function.</DD>
<p>Time adjustments are made by <tt>ntpdate</tt> in one of two
ways. If <tt>ntpdate</tt> determines the clock is in error more
than 0.5 second it will simply step the time by calling the system
<tt>settimeofday()</tt> routine. If the error is less than 0.5
seconds, it will slew the time by calling the system <tt>
adjtime()</tt> routine. The latter technique is less disruptive and
more accurate when the error is small, and works quite well when
<tt>ntpdate</tt> is run by <tt>cron</tt> every hour or two.</p>
<DT>
<TT>-B</TT></DT>
<p><tt>ntpdate</tt> will decline to set the date if an NTP server
daemon (e.g., <tt>ntpd</tt>) is running on the same host. When
running <tt>ntpdate</tt> on a regular basis from <tt>cron</tt> as
an alternative to running a daemon, doing so once every hour or two
will result in precise enough timekeeping to avoid stepping the
clock.</p>
<DD>
Force the time to always be slewed using the adjtime() system call, even
if the measured offset is greater than +-128 ms. The default is to step
the time using settimeofday() if the offset is greater than +-128 ms. Note
that, if the offset is much greater than +-128 ms in this case, that it
can take a long time (hours) to slew the clock to the correct value. During
this time. the host should not be used to synchronize clients.</DD>
<p>If NetInfo support is compiled into <tt>ntpdate</tt>, then the
<tt>server</tt> argument is optional if <tt>ntpdate</tt> can find a
time server in the NetInfo configuration for <tt>ntpd</tt>.</p>
<DT>
<TT>-b</TT></DT>
<h4>Command Line Options</h4>
<DD>
Force the time to be stepped using the settimeofday() system call, rather
than slewed (default) using the adjtime() system call. This option should
be used when called from a startup file at boot time.</DD>
<dl>
<dt><tt>-a <i>key</i></tt></dt>
<DT>
<TT>-d</TT></DT>
<dd>Enable the authentication function and specify the key
identifier to be used for authentication as the argument <i>
key</i><tt>ntpdate</tt>. The keys and key identifiers must match in
both the client and server key files. The default is to disable the
authentication function.</dd>
<DD>
Enable the debugging mode, in which <TT>ntpdate</TT> will go through all
the steps, but not adjust the local clock. Information useful for general
debugging will also be printed.</DD>
<dt><tt>-B</tt></dt>
<DT>
<TT>-e <I>authdelay</I></TT></DT>
<dd>Force the time to always be slewed using the adjtime() system
call, even if the measured offset is greater than +-128 ms. The
default is to step the time using settimeofday() if the offset is
greater than +-128 ms. Note that, if the offset is much greater
than +-128 ms in this case, that it can take a long time (hours) to
slew the clock to the correct value. During this time. the host
should not be used to synchronize clients.</dd>
<DD>
Specify the processing delay to perform an authentication function as the
value <I>authdelay</I>, in seconds and fraction (see <TT>ntpd</TT> for
details). This number is usually small enough to be negligible for most
purposes, though specifying a value may improve timekeeping on very slow
CPU's.</DD>
<dt><tt>-b</tt></dt>
<DT>
<TT>-k <I>keyfile</I></TT></DT>
<dd>Force the time to be stepped using the settimeofday() system
call, rather than slewed (default) using the adjtime() system call.
This option should be used when called from a startup file at boot
time.</dd>
<DD>
Specify the path for the authentication key file as the string <I>keyfile</I>.
The default is <TT>/etc/ntp.keys</TT>. This file should be in the format
described in <TT>ntpd</TT>.</DD>
<dt><tt>-d</tt></dt>
<DT>
<TT>-o <I>version</I></TT></DT>
<dd>Enable the debugging mode, in which <tt>ntpdate</tt> will go
through all the steps, but not adjust the local clock. Information
useful for general debugging will also be printed.</dd>
<DD>
Specify the NTP version for outgoint packets as the integer <I>version</I>,
which can be 1 or 2. The default is 3. This allows <TT>ntpdate</TT> to
be used with older NTP versions.</DD>
<dt><tt>-e <i>authdelay</i></tt></dt>
<DT>
<TT>-p <I>samples</I></TT></DT>
<dd>Specify the processing delay to perform an authentication
function as the value <i>authdelay</i>, in seconds and fraction
(see <tt>ntpd</tt> for details). This number is usually small
enough to be negligible for most purposes, though specifying a
value may improve timekeeping on very slow CPU's.</dd>
<DD>
Specify the number of samples to be acquired from each server as the integer
<I>samples</I>, with values from 1 to 8 inclusive. The default is 4.</DD>
<dt><tt>-k <i>keyfile</i></tt></dt>
<DT>
<I><TT>-q</TT></I></DT>
<dd>Specify the path for the authentication key file as the string
<i>keyfile</i>. The default is <tt>/etc/ntp.keys</tt>. This file
should be in the format described in <tt>ntpd</tt>.</dd>
<DD>
Query only - don't set the clock.</DD>
<dt><tt>-o <i>version</i></tt></dt>
<DT>
<TT>-s</TT></DT>
<dd>Specify the NTP version for outgoint packets as the integer <i>
version</i>, which can be 1 or 2. The default is 3. This allows
<tt>ntpdate</tt> to be used with older NTP versions.</dd>
<DD>
Divert logging output from the standard output (default) to the system
<TT>syslog</TT> facility. This is designed primarily for convenience of
<TT>cron</TT> scripts.</DD>
<dt><tt>-p <i>samples</i></tt></dt>
<DT>
<TT>-t <I>timeout</I></TT></DT>
<dd>Specify the number of samples to be acquired from each server
as the integer <i>samples</i>, with values from 1 to 8 inclusive.
The default is 4.</dd>
<DD>
Specify the maximum time waiting for a server response as the value <I>timeout</I>,
in seconds and fraction. The value is is rounded to a multiple of 0.2 seconds.
The default is 1 second, a value suitable for polling across a LAN.</DD>
<dt><i><tt>-q</tt></i></dt>
<DT>
<TT>-u</TT></DT>
<dd>Query only - don't set the clock.</dd>
<DD>
Direct <TT>ntpdate</TT> to use an unprivileged port or outgoing packets.
This is most useful when behind a firewall that blocks incoming traffic
to privileged ports, and you want to synchronise with hosts beyond the
firewall. Note that the <TT>-d</TT> option always uses unprivileged ports.</DD>
<dt><tt>-s</tt></dt>
<DT>
<TT>-<I>v</I></TT></DT>
<dd>Divert logging output from the standard output (default) to the
system <tt>syslog</tt> facility. This is designed primarily for
convenience of <tt>cron</tt> scripts.</dd>
<DD>
Be verbose. This option will cause <TT>ntpdate</TT>'s version identification
string to be logged.</DD>
</DL>
<dt><tt>-t <i>timeout</i></tt></dt>
<H4>
Files</H4>
<TT>/etc/ntp.keys</TT> - encryption keys used by <TT>ntpdate</TT>.
<H4>
Bugs</H4>
The slew adjustment is actually 50% larger than the measured offset, since
this (it is argued) will tend to keep a badly drifting clock more accurate.
This is probably not a good idea and may cause a troubling hunt for some
values of the kernel variables <TT>tick</TT> and <TT>tickadj</TT>.&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<dd>Specify the maximum time waiting for a server response as the
value <i>timeout</i>, in seconds and fraction. The value is is
rounded to a multiple of 0.2 seconds. The default is 1 second, a
value suitable for polling across a LAN.</dd>
<dt><tt>-u</tt></dt>
<dd>Direct <tt>ntpdate</tt> to use an unprivileged port or outgoing
packets. This is most useful when behind a firewall that blocks
incoming traffic to privileged ports, and you want to synchronise
with hosts beyond the firewall. Note that the <tt>-d</tt> option
always uses unprivileged ports.</dd>
<dt><tt>-<i>v</i></tt></dt>
<dd>Be verbose. This option will cause <tt>ntpdate</tt>'s version
identification string to be logged.</dd>
</dl>
<h4>Files</h4>
<tt>/etc/ntp.keys</tt> - encryption keys used by <tt>ntpdate</tt>.
<h4>Bugs</h4>
The slew adjustment is actually 50% larger than the measured
offset, since this (it is argued) will tend to keep a badly
drifting clock more accurate. This is probably not a good idea and
may cause a troubling hunt for some values of the kernel variables
<tt>tick</tt> and <tt>tickadj</tt>.&nbsp;
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

1181
contrib/ntp/html/ntpdc.htm
View File

File diff suppressed because it is too large Load Diff

1399
contrib/ntp/html/ntpq.htm
View File

File diff suppressed because it is too large Load Diff

128
contrib/ntp/html/ntptime.htm
View File

@ -1,96 +1,80 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>ntptime - read kernel time variables
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntptime - read kernel time variables</title>
</head>
<body>
<h3><tt>ntptime</tt> - read kernel time variables</h3>
<H3>
<TT>ntptime</TT> - read kernel time variables</H3>
<img align="left" src="pic/pogo5.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<HR>
<H4>
Synopsis</H4>
<TT>ntptime [ -chr ] [ -e <I>est_error</I> ] [ -f <I>frequency</I> ] [
-m <I>max_error</I> ] [ -o <I>offset</I> ] [ -s <I>status</I> ] [ -t <I>time_constant</I>
]</TT>
<H4>
Description</H4>
This program is useful only with special kernels described in the <A HREF="kern.htm">A
Kernel Model for Precision Timekeeping </A>page. It reads and displays
time-related kernel variables using the <TT>ntp_gettime()</TT> system call.
A similar display can be obtained using the <TT>ntpdc</TT> program and
<TT>kerninfo</TT> command.
<H4>
Options</H4>
<p>The turtle is been swimming in the kernel.<br clear="left">
</p>
<DL>
<DT>
<TT>-c</TT></DT>
<hr>
<h4>Synopsis</h4>
<DD>
Display the execution time of <TT>ntptime</TT> itself.</DD>
<tt>ntptime [ -chr ] [ -e <i>est_error</i> ] [ -f <i>frequency</i>
] [ -m <i>max_error</i> ] [ -o <i>offset</i> ] [ -s <i>status</i> ]
[ -t <i>time_constant</i>]</tt>
<DT>
<TT>-e <I>est_error</I></TT></DT>
<h4>Description</h4>
<DD>
Specify estimated error, in microseconds.</DD>
This program is useful only with special kernels described in the
<a href="kern.htm">A Kernel Model for Precision Timekeeping</a>
page. It reads and displays time-related kernel variables using the
<tt>ntp_gettime()</tt> system call. A similar display can be
obtained using the <tt>ntpdc</tt> program and <tt>kerninfo</tt>
command.
<DT>
<TT>-f <I>frequency</I></TT></DT>
<h4>Options</h4>
<DD>
Specify frequency offset, in parts per million.</DD>
<dl>
<dt><tt>-c</tt></dt>
<DT>
<TT>-h</TT></DT>
<dd>Display the execution time of <tt>ntptime</tt> itself.</dd>
<DD>
Display times in Unix timeval format. Default is NTP format.</DD>
<dt><tt>-e <i>est_error</i></tt></dt>
<DT>
<TT>-l</TT></DT>
<dd>Specify estimated error, in microseconds.</dd>
<DD>
Specify the leap bits as a code from 0 to 3.</DD>
<dt><tt>-f <i>frequency</i></tt></dt>
<DT>
<TT>-m <I>max_error</I></TT></DT>
<dd>Specify frequency offset, in parts per million.</dd>
<DD>
Display help information.</DD>
<dt><tt>-h</tt></dt>
<DT>
<TT>-o <I>offset</I></TT></DT>
<dd>Display help information.</dd>
<DD>
Specify clock offset, in microseconds.</DD>
<dt><tt>-m <i>max_error</i></tt></dt>
<DT>
<TT>-r</TT></DT>
<dd>Specify max possible errors, in microseconds.</dd>
<DD>
Display Unix and NTP times in raw format.</DD>
<dt><tt>-o <i>offset</i></tt></dt>
<DT>
<TT>-s <I>status</I></TT></DT>
<dd>Specify clock offset, in microseconds.</dd>
<DD>
Specify clock status. Better know what you are doing.</DD>
<dt><tt>-r</tt></dt>
<DT>
<TT>-t <I>time_constant</I></TT></DT>
<dd>Display Unix and NTP times in raw format.</dd>
<DD>
Specify time constant, an integer in the range 0-4.</DD>
</DL>
<dt><tt>-s <i>status</i></tt></dt>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<dd>Specify clock status. Better know what you are doing.</dd>
<dt><tt>-t <i>time_constant</i></tt></dt>
<dd>Specify time constant, an integer in the range 0-10.</dd>
</dl>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

139
contrib/ntp/html/ntptrace.htm
View File

@ -1,82 +1,91 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>ntptrace - trace a chain of NTP servers back to the primary
source
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntptrace - trace a chain of NTP servers back to the primary
source</title>
</head>
<body>
<h3><tt>ntptrace</tt> - trace a chain of NTP servers back to the
primary source</h3>
<H3>
<TT>ntptrace</TT> - trace a chain of NTP servers back to the primary source</H3>
<img align="left" src="pic/alice13.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
Adventures in Wonderland</i>, Lewis Carroll</a>
<HR>
<H4>
Synopsis</H4>
<TT>ntptrace [ -vdn ] [ -r <I>retries</I> ] [ -t <I>timeout</I> ] [ <I>server</I>
]</TT>
<H4>
Description</H4>
<TT>ntptrace</TT> determines where a given Network Time Protocol (NTP)
server gets its time from, and follows the chain of NTP servers back to
their master time source. If given no arguments, it starts with <TT>localhost</TT>.
Here is an example of the output from <TT>ntptrace</TT>:
<PRE>% ntptrace
<p>The rabbit knows the way back.<br clear="left">
</p>
<hr>
<h4>Synopsis</h4>
<tt>ntptrace [ -vdn ] [ -r <i>retries</i> ] [ -t <i>timeout</i> ] [
<i>server</i> ]</tt>
<h4>Description</h4>
<p><tt>ntptrace</tt> determines where a given Network Time Protocol
(NTP) server gets its time from, and follows the chain of NTP
servers back to their master time source. If given no arguments, it
starts with <tt>localhost</tt>. Here is an example of the output
from <tt>ntptrace</tt>:</p>
<pre>
% ntptrace
localhost: stratum 4, offset 0.0019529, synch distance 0.144135
server2ozo.com: stratum 2, offset 0.0124263, synch distance 0.115784
usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid
'WWVB'</PRE>
On each line, the fields are (left to right): the host name, the host stratum,
the time offset between that host and the local host (as measured by <TT>ntptrace</TT>;
this is why it is not always zero for "<TT>localhost</TT>"), the host synchronization
distance, and (only for stratum-1 servers) the reference clock ID. All
times are given in seconds. Note that the stratum is the server hop count
to the primary source, while the synchronization distance is the estimated
error relative to the primary source. These terms are precisely defined
in RFC-1305.
<H4>
Options</H4>
'WWVB'
</pre>
<DL>
<DT>
<TT>-d</TT></DT>
On each line, the fields are (left to right): the host name, the
host stratum, the time offset between that host and the local host
(as measured by <tt>ntptrace</tt>; this is why it is not always
zero for "<tt>localhost</tt>"), the host synchronization distance,
and (only for stratum-1 servers) the reference clock ID. All times
are given in seconds. Note that the stratum is the server hop count
to the primary source, while the synchronization distance is the
estimated error relative to the primary source. These terms are
precisely defined in RFC-1305.
<DD>
Turns on some debugging output.</DD>
<h4>Options</h4>
<DT>
<TT>-n</TT></DT>
<dl>
<dt><tt>-d</tt></dt>
<DD>
Turns off the printing of host names; instead, host IP addresses are given.
This may be useful if a nameserver is down.</DD>
<dd>Turns on some debugging output.</dd>
<DT>
<TT>-r <I>retries</I></TT></DT>
<dt><tt>-n</tt></dt>
<DD>
Sets the number of retransmission attempts for each host (default = 5).</DD>
<dd>Turns off the printing of host names; instead, host IP
addresses are given. This may be useful if a nameserver is
down.</dd>
<DT>
<TT>-t <I>timeout</I></TT></DT>
<dt><tt>-r <i>retries</i></tt></dt>
<DD>
Sets the retransmission timeout (in seconds) (default = 2).</DD>
<dd>Sets the number of retransmission attempts for each host
(default = 5).</dd>
<DT>
<TT>-v</TT></DT>
<dt><tt>-t <i>timeout</i></tt></dt>
<DD>
Prints verbose information about the NTP servers.</DD>
</DL>
<dd>Sets the retransmission timeout (in seconds) (default =
2).</dd>
<H4>
Bugs</H4>
This program makes no attempt to improve accuracy by doing multiple samples.&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<dt><tt>-v</tt></dt>
<dd>Prints verbose information about the NTP servers.</dd>
</dl>
<h4>Bugs</h4>
This program makes no attempt to improve accuracy by doing multiple
samples.
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

60
contrib/ntp/html/patches.htm
View File

@ -4,67 +4,39 @@ Patching Procedures
Patching Procedures
</h3>
<IMG align=left SRC=pic/rabbit.gif>From <i>pogo</i>, Walt Kelly
<img align=left src=pic/alice38.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The Mad Hatter needs patches.
<br clear=left><hr>
<p>A distribution so widely used as this one eventually develops
numerous barnacles as the result of <a href=porting.htm>porting</a>
to new systems, idiosyncratic new features and just plain bugs. In order
to help keep order and make maintenance bearable, we ask that proposed
changes to the distribution be submitted in the following form.
<p>A distribution so widely used as this one eventually develops numerous barnacles as the result of <a href=porting.htm>porting</a> to new systems, idiosyncratic new features and just plain bugs. In order to help keep order and make maintenance bearable, we ask that proposed changes to the distribution be submitted in the following form.
<ol>
<p><li>Please submit patches to <a href=mailto:mills@udel.edu>David L.
Mills &lt;mills@udel.edu&gt;</a> in the form of either unified-diffs
(<tt>diff -u</tt>) or context-diffs (<tt>diff -c</tt>).</li>
<p><li>Please submit patches to <a href=mailto:bugs@mail.ntp.org>Bugs &lt;bugs@mail.ntp.org&gt;</a> in the form of either unified-diffs (<tt>diff -u</tt>) or context-diffs (<tt>diff -c</tt>).</li>
<p><li>Please include the <strong>output</strong> from
<tt>config.guess</tt> in the description of your patch. If
<tt>config.guess</tt> does not produce any output for your machine,
please fix that, too!</li>
<p><li>Please include the <strong>output</strong> from <tt>config.guess</tt> in the description of your patch. If <tt>config.guess</tt> does not produce any output for your machine, please fix that, too!</li>
<p><li>Please base the patch on the root directory of the distribution.
The preferred procedure here is to copy your patch to the root directory
and mumble</li>
<p><li>Please base the patch on the root directory of the distribution. The preferred procedure here is to copy your patch to the root directory and mumble</li>
<p><tt>patch -p &lt;your_patch&gt;</tt></li>
<p><li>Please avoid patching the RCS subdirectories; better yet, clean
them out before submitting patches.</li>
<p><li>Please avoid patching the RCS subdirectories; better yet, clean them out before submitting patches.</li>
<p><li>If you have whole new files, as well as patches, wrap the files
and patches in a shell script. If you need to compress it, use either
GNU zip or the stock Unix compress utility.</li>
<p><li>If you have whole new files, as well as patches, wrap the files and patches in a shell script. If you need to compress it, use either GNU zip or the stock Unix <tt>compress</tt> utility.</li>
<p><li>Don't forget the documentation that may be affected by the patch.
Send us patches for the <tt>./html</tt> files as well. See the <a
href=htmlprimer.htm>A Beginner's Guide to HTML</a> page for a
tutorial.</li>
<p><li>Don't forget the documentation that may be affected by the patch. Send us patches for the <tt>./htm</tt> files as well. See the <a href=htmlprimer.htm>A Beginner's Guide to HTML</a> page for a tutorial.</li>
<p><li>We would be glad to include your name, electric address and
descriptive phrase in the <a href=copyright.htm>Copyright</a> page,
if you wish.</li>
<p><li>We would be glad to include your name, electric address and descriptive phrase in the <a href=copyright.htm>Copyright</a> page, if you wish.</li>
</ol>
<p>Prior to ntp3-5.83 (releases up to and including ntp3.5f) a
complete patch history back to the dark ages was kept in the
<tt>./patches</tt> directory, which might have been helpful to see
if the same problem occured in another port, etc. Patches were saved in
that directory with file name in the form <tt>patch.<i>nnn</i></tt>,
where <i>nnn</i> was approaching 200. All patches in that directory have
been made; so, if yours was there, it was in the distribution.
<p>Prior to ntp3-5.83 (releases up to and including ntp3.5f) a complete patch history back to the dark ages was kept in the <tt>./patches</tt> directory, which might have been helpful to see if the same problem occured in another port, etc. Patches were saved in that directory with file name in the form <tt>patch.<i>nnn</i></tt>, where <i>nnn</i> was approaching 200. All patches in that directory have been made; so, if yours was there, it was in the distribution.
<p>Since we have been getting multple patches for some bugs, plus many
changes are implemented locally, no two maintainers here use the same
tools, and since we're not using any bug-tracking software or even
source code control, there is currently no tracking of specific changes.
<p>Since we have been getting multple patches for some bugs, plus many changes are implemented locally, no two maintainers here use the same tools, and since we're not using any bug-tracking software or even source code control, there is currently no tracking of specific changes.
<p>The best way to see what's changed between two distributions is to run a <tt>diff</tt> against them.
<p>The best way to see what's changed between two distributions is to
run a <tt>diff</tt> against them.
<p>Thanks for your contribution and happy chime.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a></address></a></body></html>

8
contrib/ntp/html/porting.htm
View File

@ -2,7 +2,13 @@
Porting Hints
</title></head><body><h3>
Porting Hints
</h3><hr>
</h3>
<img align=left src=pic/wingdorothy.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>The
Wizard of Oz</i>, L. Frank Baum</a>
<p>Porting Dorothy in Oz.
<br clear=left><hr>
<p>NOTE: The following procedures have been replaced by GNU automake and
autoconfigure. This page is to be updated in the next release.

174
contrib/ntp/html/pps.htm
View File

@ -1,84 +1,106 @@
<html><head><title>
Pulse-per-second (PPS) Signal Interfacing
</title></head><body><h3>
Pulse-per-second (PPS) Signal Interfacing
</h3><hr>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Pulse-per-second (PPS) Signal Interfacing</title>
</head>
<body>
<h3>Pulse-per-second (PPS) Signal Interfacing</h3>
<P>Some radio clocks and related timekeeping gear have a
pulse-per-second (PPS) signal that can be used to discipline the local
clock oscillator to a high degree of precision, typically to the order
less than 20 <font face=Symbol>m</font>s in time and 0.01 PPM in
frequency. The PPS signal can be connected in either of two ways: via
the data leads of a serial port or via the modem control leads. Either
way requires conversion of the PPS signal, usually at TTL levels, to
RS232 levels, which can be done using a circuit such as described in the
<A HREF=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</A>
page.
<img align="left" src="pic/alice32.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
Adventures in Wonderland</i>, Lewis Carroll</a>
<P>The data leads interface requires regenerating the PPS pulse and
converting to RS232 signal levels, so that the pulse looks like a
legitimate ASCII character to a serial port. The <TT>tty_clk</TT> line
discipline/streams module inserts a timestamp following this character
in the input data stream. The <A HREF=driver22.htm>PPS Clock
Discipline</A> driver uses this timestamp to determine the time of
arrival of the PPS pulse to within 26 us at 38.4 kbps while eliminating
error due to operating system queues and service times.
<p>Alice is trying to find the PPS signal connector.<br clear=
"left">
</p>
<P>The modem control leads interface requires converting to RS232 levels
and connecting to the data carrier detect (DCD) lead of a serial port.
The <TT>ppsclock</TT> and <TT>ppsapi</TT> streams modules capture a
timestamp upon transition of the DCD signal. Note that the
<TT>ppsclock</TT> module functionality has been subsumed by the new
<TT>ppsapi</TT> interface specification, which is supported by the NTP
daemon. As the latter is expected to become an IETF cross-platform
standard, it should be used in new configurations. The PPS Clock
Discipline driver reads the latest timestamp with a designated system
call or interface routine to determine the time of arrival of the PPS
pulse to within a few microseconds. Alternatively, if provisions have
been made in the kernel for PPS signals, the signal is captured directly
by the kernel serial driver without using the PPS driver.
<hr>
<p>Some radio clocks and related timekeeping gear have a
pulse-per-second (PPS) signal that can be used to discipline the
local clock oscillator to a high degree of precision, typically to
the order less than 10 <font face="Symbol">m</font>s in time and
0.01 parts-per-million (PPM) in frequency. The PPS signal can be
connected in either of two ways: via the data carrier detector
(DCD) pin of a serial port or via the acknowledge (ACK) pin of a
parallel port, depending on the hardware and operating system.
Connection via a serial port may require signal conversion and
regeneration to RS232 levels, which can be done using a circuit
such as described in the <a href="gadget.htm">Gadget Box PPS Level
Converter and CHU Modem</a> page. Note that NTP no longer supports
connection via the data leads of a serial port.</p>
<P>The <TT>tty_clk</TT> module is included in the NTP software
distribution, while the <A
HREF=http://www.eecis.udel.edu/~mills/ntp/ntp/ppsclock.tar.Z><TT>
ppsclock</TT></A> module can be obtained via the web at that link or by
anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory. Both
the <TT>tty_clk</TT> and <TT>ppsclock</TT> modules are described in the
<A HREF=ldisc.htm>Line Disciplines and Streams Drivers</A> page.
Directions for building the modules themselves are in the
<TT>./kernel</TT> directory. Directions on how to configure
<TT>ntpd</TT> to operate with these modules is described in <A
HREF=build.htm>Building and Installing the Distribution </A>page.
<p>Both the serial and parallel port connection require operating
system support, which is available in only a few operating systems,
including Linux, FreeBSD and latest Solaris beginning with 2.7.
Support on an experimental basis is available for several older
systems, including SunOS, Digital Ultrix and HP-UX, and in current
Digital Tru64 (Alpha). The PPS application program interface
defined in RFC-2783 (PPSAPI) is the only interface currently
supported. Older PPS interfaces based on the <tt>ppsclock</tt> and
<tt>tty_clk</tt> streams modules are no longer supported. As the
PPSAPI is expected to become an IETF cross-platform standard, it
should be used by new applications.</p>
<P>The PPS driver is operates in conjunction with another reference
clock driver that produces the PPS pulse, as described in the <A
HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT> Keyword
</A>page. One of the drivers described in the <A
HREF=refclock.htm>Reference Clock Drivers</A> page furnishes
the coarse timecode used to disambiguate the seconds numbering of the
PPS pulse itself. The NTP daemon mitigates between the radio clock
driver and <TT>PPS</TT> driver as described in that page in order to
provide the most accurate time, while respecting the various types of
equipment failures that could happen.
<p>The PPSAPI inerface requires a <tt>
/usr/include/sys/ppstime.h</tt> header file. This file is included
in Linux and FreeBSD distributions, but not in other distributions
or standard workstation products at this time. Header files for
other systems, including Solaris, can be found in the <tt>
nanokernel.tar.gz</tt> distribution, which can be found via the
Collaboration Resources link at www.ntp.org. The top level
directory contains a number of subdirectories for each
architecture, including Solaris. The <tt>ppstime.h</tt> file for
each architecture can be found in the subdirectory of the same
name.</p>
<P>For the utmost time quality, some Unix system kernels support a PPS
signal directly, as described in the <A HREF=kern.htm>A Kernel Model
for Precision Timekeeping </A>page. Specifically, the ppsclock module
can be used to interface the PPS signal directly to the kernel for use
as discipline sources for both time and frequency. These sources can be
separately enabled and monitored using the <TT>ntp_adjtime()</TT> system
call described in that page and the <TT>/usr/include/sys/timex.h</TT>
header file. The presence of these kernel provisions is automatically
detected and supporting code compiled.
<p>In the preferred mode of operation, PPS signals are processed by
the <a href="driver22.htm">PPS Clock Discipline</a> driver and
other clock drivers which might be involved need not know or care
about them. In some cases where there is no other driver, time
might be obtained from remote NTP servers via the network and local
PPS signals, for instance from a calibrated cesium oscillator, used
to stabilize the frequency and remove network jitter. Note that the
<tt>pps</tt> configuration command has been obsoleted by this
driver.</p>
<P>In some configurations may have multiple radio clocks, each with PPS
outputs, as well as a kernel provisions for the PPS signal. In order to
provide the highest degree of redundancy and survivability, the kernel
PPS discipline, <TT>tty_clk</TT> module, <TT>ppsclock</TT> module and
kernel modifications may all be in use at the same time, each backing up
the other. The sometimes complicated mitigation rules are described in
the Mitigation Rules and the <TT>prefer</TT> Keyword page.
<p>The PPS driver operates in conjunction with a preferred peer, as
described in the <a href="prefer.htm">Mitigation Rules and the <tt>
prefer</tt> Keyword</a> page. One of the drivers described in the
<a href="refclock.htm">Reference Clock Drivers</a> page or another
NTP server furnishes the coarse timing and disambiguates the
seconds numbering of the PPS signal itself. The NTP daemon
mitigates between the clock driver or NTP server and the PPS driver
as described in that page in order to provide the most accurate
time, while respecting the various types of equipment failures that
could happen.</p>
<p>Some Unix system kernels support a PPS signal directly, as
described in the <a href="kern.htm">A Kernel Model for Precision
Timekeeping</a> page. Specifically, the PPS driver can be used to
direct the PPS signal to the kernel for use as a discipline source
for both time and frequency. The presence of the kernel support is
automatically detected during the NTP build process and supporting
code automatically compiled. Note that the PPS driver does not
normally enable the PPS kernel code, since performance is generally
better without it. However, this code can be enabled by a driver
fudge flag if necessary.</p>
<p>Some configurations may include multiple radio clocks with
individual PPS outputs. In some PPSAPI designs multiple PPS signals
can be connected to multiple instances of the PPS driver. In such
cases the NTP mitigation and grooming algorithms operate with all
the radio timecodes and PPS signals to develop the highest degree
of redundancy and survivability.</p>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a><br>
<br>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

373
contrib/ntp/html/prefer.htm
View File

@ -1,332 +1,93 @@
<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>Mitigation Rules and the ``prefer'' Keyword
</TITLE>
</HEAD>
<BODY>
<html><head><title>
Mitigation Rules and the <tt>prefer</tt> Keyword
</title></head><body><h3>
Mitigation Rules and the <tt>prefer</tt> Keyword
</h3>
<H3>
Mitigation Rules and the <TT>prefer</TT> Keyword</H3>
<img align=left src=pic/alice11.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<HR>
<H4>
Introduction</H4>
The mechanics of the NTP algorithms which select the best data sample from
each available peer and the best subset of the peer population have been
finely crafted to resist network jitter, faults in the network or peer
operations, and to deliver the best possible accuracy. Most of the time
these algorithms do a good job without requiring explicit manual tailoring
of the configuration file. However, there are times when the accuracy can
be improved by some careful tailoring. The following sections explain how
to do this using explicit configuration items and special signals, when
available, that are generated by some radio clocks.
<p>Listen carefully to what I say; it is very complicated.
<br clear=left><hr>
<P>In order to provide robust backup sources, primary (stratum-1) servers
are usually operated in a diversity configuration, in which the server
operates with a number of remote peers in addition to one or more radio
or modem clocks operating as local peers. In these configurations the suite
of algorithms used in NTP to refine the data from each peer separately
and to select and weight the data from a number of peers are used with
the entire ensemble of remote peers and local peers. As the result of these
algorithms, a set of <I>survivors</I> are identified which can presumably
provide the most reliable and accurate time. Ordinarily, the individual
clock offsets of the survivors are combined on a weighted average basis
to produce an offset used to control the system clock.
<h4>Introduction</h4>
<P>However, because of small but significant systematic time offsets between
the survivors, it is in general not possible to achieve the lowest jitter
and highest stability in these configurations. This happens because the
selection algorithm tends to <I>clockhop</I> between survivors of substantially
the same quality, but showing small systematic offsets between them. In
addition, there are a number of configurations involving pulse-per-second
(PPS) signals, modem backup services and other special cases, so that a
set of mitigation rules becomes necessary to select a single peer from
among the survivors. These rules are based on a set of special characteristics
of the various peers and reference clock drivers specified in the configuration
file.
<H4>
The <TT>prefer</TT> Peer</H4>
The mitigation rules are designed to provide an intelligent selection between
various peers of substantially the same statistical quality. They is designed
to provide the best quality time without compromising the normal operation
of the NTP algorithms. The mitigation scheme in its present form is not
an integral component of the NTP Version 3 specification RFC- 1305. but
is to be included in the version 4 specification when it is published.
The scheme is based on the concept of <I>prefer peer</I>, which is specified
by including the <TT>prefer</TT> keyword with the associated <TT>server</TT>
or <TT>peer</TT> command in the configuration file. This keyword can be
used with any peer or server, but is most commonly used with a radio clock.
While the scheme does not forbid it, it does not seem useful to designate
more than one peer as preferred, since the additional complexities to mitigate
among them do not seem justified from on-air experience.
The mechanics of the NTP algorithms which select the best data sample from each available server and the best subset of the server population have been finely crafted to resist network jitter, faults in the network or server operations, and to deliver the best possible accuracy. Most of the time these algorithms do a good job without requiring explicit manual tailoring of the configuration file. However, there are times when the accuracy can be improved by some careful tailoring. The following sections explain how to do this using explicit configuration items and special signals, when available, that are generated by some radio clocks and laboratory instruments.
<P>The prefer scheme works on the set of peers that have survived the sanity
checks and intersection algorithms of the clock selection procedures. Ordinarily,
the members of this set can be considered <I>truechimers</I> and any one
of them could in principle provide correct time; however, due to various
error contributions, not all can provide the most accurate and stable time.
The job of the clustering algorithm, which is invoked at this point, is
to select the best subset of the survivors providing the least variance
in the combined ensemble average, compared to the variance in each member
of the subset separately. The detailed operation of the clustering algorithm,
which is given in the specification, is not important here, other than
to point out it operates in rounds, where a survivor, presumably the worst
of the lot, is discarded in each round until one of several termination
conditions is met.
<p>In order to provide robust backup sources, primary (stratum-1) servers are usually operated in a diversity configuration, in which the server operates with a number of remote servers in addition to one or more radio or modem clocks. In these configurations the suite of algorithms used in NTP to refine the data from each peer separately and to select and combine the data from a number of servers and clocks. As the result of these algorithms, a set of <i>survivors</i> are identified which can presumably provide the most reliable and accurate time. Ordinarily, the individual clock offsets of the survivors are combined on a weighted average basis to produce an offset used to control the system clock.
<P>In the prefer scheme the clustering algorithm is modified so that the
prefer peer is never discarded; on the contrary, its potential removal
becomes a termination condition. If the original algorithm were about to
toss out the prefer peer, the algorithm terminates right there. The prefer
peer can still be discarded by the sanity checks and intersection algorithms,
of course, but it will always survive the clustering algorithm. If it does
not survive or for some reason it fails to provide updates, it will eventually
become unreachable and the clock selection will remitigate to select the
next best source.
<p>However, because of small but significant systematic time offsets between the survivors, it is in general not possible to achieve the lowest jitter and highest stability in these configurations. This happens because the selection algorithm tends to <i>clockhop</i> between survivors of substantially the same quality, but showing small systematic offsets between them. In addition, there are a number of configurations involving pulse-per-second (PPS) signals, modem backup services and other special cases, so that a set of mitigation rules becomes necessary to select a single peer from among the survivors. These rules are based on a set of special characteristics of the various remote servers and reference clock drivers specified in the configuration file.
<P>Along with this behavior, the clock selection procedures are modified
so that the combining algorithm is not used when a prefer peer is present.
Instead, the offset of the prefer peer is used exclusively as the synchronization
source. In the usual case involving a radio clock and a flock of remote
stratum-1 peers, and with the radio clock designated a prefer peer, the
result is that the high quality radio time disciplines the server clock
as long as the radio itself remains operational and with valid time, as
determined from the remote peers, sanity checks and intersection algorithm.
<H4>
Peer Classification</H4>
In order to understand the effects of the various intricate schemes involved,
it is necessary to understand some arcane details on how the algorithms
decide on a synchronization source, when more than one source is available.
This is done on the basis of a set of explicit mitigation rules, which
define special classes of remote and local peers as a function of configuration
declarations and reference clock driver type:
<OL>
<LI>
The prefer peer is designated using the <TT>prefer</TT> keyword with the
<TT>server</TT> or <TT>peer</TT> commands. All other things being equal,
this peer will be selected for synchronization over all other survivors
of the clock selection procedures.</LI>
<h4>The <tt>prefer</tt> Peer</h4>
<BR>&nbsp;
<LI>
When a PPS signal is connected via the PPS Clock Discipline driver (type
22), this is called the <I>PPS peer</I>. This driver provides precision
clock corrections only within one second, so is always operated in conjunction
with another peer or reference clock driver, which provides the seconds
numbering. The PPS peer is active only under conditions explained below.</LI>
The mitigation rules are designed to provide an intelligent selection between various sources of substantially the same statistical quality without compromising the normal operation of the NTP algorithms. While they have been implemented in NTP Version 4 and will be incorporated in the NTP Version 4 specification when published, they are not in the NTP Version 3 specification RFC-1305. The rules are based on the concept of <i>prefer peer</i>, which is specified by including the <tt>prefer</tt> keyword with the associated <tt>server</tt> or <tt>peer</tt> command in the configuration file. This keyword can be used with any server or peer, but is most commonly used with a radio clock. While the rules do not forbid it, it does not seem useful to designate more than one peer as preferred, since the additional complexities to mitigate among them do not seem justified from on-air experience.
<BR>&nbsp;
<LI>
When the Undisciplined Local Clock driver (type 1) is configured, this
is called the <I>local clock peer</I>. This is used either as a backup
reference source (stratum greater than zero), should all other synchronization
sources fail, or as the primary reference source (stratum zero) in cases
where the kernel time is disciplined by some other means of synchronization,
such as the NIST <TT>lockclock</TT> scheme, or another synchronization
protocol, such as the Digital Time Synchronization Service (DTSS).</LI>
<p>The prefer scheme works on the set of peers that have survived the sanity checks and intersection algorithms of the clock selection procedures. Ordinarily, the members of this set can be considered <i>truechimers</i> and any one of them could in principle provide correct time; however, due to various error contributions, not all can provide the most accurate and stable time. The job of the clustering algorithm, which is invoked at this point, is to select the best subset of the survivors providing the least variance in the combined ensemble average, compared to the variance in each member of the subset separately. The detailed operation of the clustering algorithm, which is given in the RFC-1305, is beyond the scope of discussion here. It operates in rounds, where a survivor, presumably the worst of the lot, is discarded in each round until one of several termination conditions is met. An example terminating condition is when the number of survivors is about to be reduced below three.
<BR>&nbsp;
<LI>
When a modem driver such as the Automated Computer Time Service driver
(type 18) is configured, this is called the <I>modem peer</I>. This is
used either as a backup reference source, should all other primary sources
fail, or as the (only) primary reference source.</LI>
<p>In the prefer scheme the clustering algorithm is modified so that the prefer peer is never discarded; on the contrary, its potential removal becomes a termination condition. If the original algorithm were about to toss out the prefer peer, the algorithm terminates immediately. The prefer peer can still be discarded by the sanity checks and intersection algorithms, of course, but it will always survive the clustering algorithm. If it does not survive or for some reason it fails to provide updates, it will eventually become unreachable and the clock selection will remitigate to select the next best source.
<BR>&nbsp;
<LI>
Where support is available, the PPS signal may be processed directly by
the kernel, as described in the <A HREF="kern.htm">A Kernel Model for Precision
Timekeeping</A> page. This is called the <I>kernel discipline</I>. The
PPS signal can discipline the kernel in both frequency and time. The frequency
discipline is active as long as the PPS interface device and signal itself
is operating correctly, as determined by the kernel algorithms. The time
discipline is active only under conditions explained below.</LI>
</OL>
Reference clock drivers operate in the manner described in the <A HREF="refclock.htm">Reference
Clock Drivers</A> page and its dependencies. The drivers are ordinarily
operated at stratum zero, so that as the result of ordinary NTP operations,
the server itself operates at stratum one, as required by the NTP specification.
In some cases described below, the driver is intentionally operated at
an elevated stratum, so that it will be selected only if no other survivor
is present with a lower stratum. In the case of the PPS peer or kernel
time discipline, these sources appear active only if the prefer peer has
survived the intersection and clustering algorithms, as described below,
and its clock offset relative to the current local clock is less than a
specified value, currently 128 ms.
<p>Along with this behavior, the clock selection procedures are modified so that the combining algorithm is not used when a prefer peer is present. Instead, the offset of the prefer peer is used exclusively as the synchronization source. In the usual case involving a radio clock and a flock of remote stratum-1 peers, and with the radio clock designated a prefer peer, the result is that the high quality radio time disciplines the server clock as long as the radio itself remains operational and with valid time, as determined from the remote peers, sanity checks and intersection algorithm.
<P>The modem clock drivers are a special case. Ordinarily, the update interval
between modem calls to synchronize the system clock is many times longer
than the interval between polls of either the remote or local peers. In
order to provide the best stability, the operation of the clock discipline
algorithm changes gradually from a phase-lock mode at the shorter update
intervals to a frequency-lock mode at the longer update intervals. If both
remote or local peers together with a modem peer are operated in the same
configuration, what can happen is that first the clock selection algorithm
can select one or more remote/local peers and the clock discipline algorithm
will optimize for the shorter update intervals. Then, the selection algorithm
can select the modem peer, which requires a much different optimization.
The intent in the design is to allow the modem peer to control the system
clock either when no other source is available or, if the modem peer happens
to be marked as prefer, then it always controls the clock, as long as it
passes the sanity checks and intersection algorithm. There still is room
for suboptimal operation in this scheme, since a noise spike can still
cause a clockhop either way. Nevertheless, the optimization function is
slow to adapt, so that a clockhop or two does not cause much harm.
<h4>Peer Classification</h4>
<P>The local clock driver is another special case. Normally, this driver
is eligible for selection only if no other source is available. When selected,
vernier adjustments introduced via the configuration file or remotely using
the <TT><A HREF="ntpdc.htm">ntpdc</A> </TT>program can be used to trim
the local clock frequency and time. However, if the local clock driver
is designated the prefer peer, this driver is always selected and all other
sources are ignored. This behavior is intended for use when the kernel
time is controlled by some means external to NTP, such as the NIST <TT>lockclock</TT>
algorithm or&nbsp; another time synchronization protocol such as DTSS.
In this case the only way to disable the local clock driver is to mark
it unsynchronized using the leap indicator bits. In the case of modified
kernels with the <TT>ntp_adjtime()</TT> system call, this can be done automatically
if the external synchronization protocol uses it to discipline the kernel
time.
<H4>
Mitigation Rules</H4>
The mitigation rules apply in the intersection and clustering algorithms
described in the NTP specification. The intersection algorithm first scans
all peers with a persistent association and includes only those that satisfy
specified sanity checks. In addition to the checks required by the specification,
the mitigation rules require either the local-clock peer or modem peer
to be included only if marked as the prefer peer. The intersection algorithm
operates on the included population to select only those peers believed
to represent the correct time. If one or more peers survive the operation,
processing continues in the clustering algorithm. Otherwise, if there is
a modem peer, it is declared the only survivor; otherwise, if there is
a local-clock peer, it is declared the only survivor. Processing then continues
in the clustering algorithm.
In order to understand the effects of the various intricate schemes involved, it is necessary to understand some arcane details on how the algorithms decide on a synchronization source when more than one source is available. This is done on the basis of a set of explicit mitigation rules, which define special classes of remote serves and local radio clocks as a function of configuration declarations and clock driver type:
<P>The clustering algorithm repeatedly discards outlyers in order to reduce
the residual jitter in the survivor population. As required by the NTP
specification, these operations continue until either a specified minimum
number of survivors remain or the minimum select dispersion of the population
is greater than the maximum peer dispersion of any member. The mitigation
rules require an additional terminating condition which stops these operations
at the point where the prefer peer is about to be discarded.
<ol>
<P>The mitigation rules establish the choice of <I>system peer</I>, which
determine the stratum, reference identifier and several other system variables
which are visible to clients of the local server. In addition, they establish
which source or combination of sources control the local clock.
<OL>
<LI>
If there is a prefer peer and it is the local-clock peer or the modem peer;
or, if there is a prefer peer and the kernel time discipline is active,
choose the prefer peer as the system peer and its offset as the system
clock offset. If the prefer peer is the local-clock peer, an offset can
be calculated by the driver to produce a frequency offset in order to correct
for systematic frequency errors. In case a source other than NTP is controlling
the system clock, corrections determined by NTP can be ignored by using
the <TT>disable pll</TT> in the configuration file. If the prefer peer
is the modem peer, it must be the primary source for the reasons noted
above. If the kernel time discipline is active, the system clock offset
is ignored and the corrections handled directly by the kernel.</LI>
<li>The prefer peer is designated using the <tt>prefer</tt> keyword with the <tt>server</tt> or <tt>peer</tt> commands. All other things being equal, this peer will be selected for synchronization over all other survivors of the clock selection procedures.</li>
<LI>
If the above is not the case and there is a PPS peer, then choose it as
the system peer and its offset as the system clock offset.</LI>
<li>When a PPS signal is connected via the PPS Clock Discipline driver (type 22), this is called the <i>PPS peer</i>. This driver provides precision clock corrections only within one second, so is always operated in conjunction with another server or radio clock driver, which provides the seconds numbering. The PPS peer is active only under conditions explained below.</li>
<LI>
If the above is not the case and there is a prefer peer (not the local-clock
or modem peer in this case), then choose it as the system peer and its
offset as the system clock offset.</LI>
<li>When the Undisciplined Local Clock driver (type 1) is configured, this is called the <i>local clock peer</i>. This is used either as a backup reference source (stratum greater than zero), should all other synchronization sources fail, or as the primary reference source (stratum zero) in cases where the kernel time is disciplined by some other means of synchronization, such as the NIST <tt>lockclock</tt> scheme, or another synchronization protocol, such as the Digital Time Synchronization Service (DTSS).</li>
<LI>
If the above is not the case and the peer previously chosen as the system
peer is in the surviving population, then choose it as the system peer
and average its offset along with the other survivors to determine the
system clock offset. This behavior is designed to avoid excess jitter due
to clockhopping, when switching the system peer would not materially improve
the time accuracy.</LI>
<li>When a modem driver such as the Automated Computer Time Service driver (type 18) is configured, this is called the <i>modem peer</i>. This is used either as a backup reference source, should all other primary sources fail, or as the (only) primary reference source.</li>
<LI>
If the above is not the case, then choose the first candidate in the list
of survivors ranked in order of synchronization distance and average its
offset along with the other survivors to determine the system clock offset.
This is the default case and the only case considered in the current NTP
specification.</LI>
</OL>
<li>Where support is available, the PPS signal may be processed directly by the kernel, as described in the <A HREF="kern.htm">A Kernel Model for Precision Timekeeping</A> page. This is called the <i>kernel discipline</i>. The PPS signal can discipline the kernel in both frequency and time. The frequency discipline is active as long as the PPS interface device and signal itself is operating correctly, as determined by the kernel algorithms. The time discipline is active only under conditions explained below.</li>
<H4>
Using the Pulse-per-Second (PPS) Signal</H4>
Most radio clocks are connected using a serial port operating at speeds
of 9600 bps or higher. The accuracy using typical timecode formats, where
the on-time epoch is indicated by a designated ASCII character, like carriage-return
<TT>&lt;cr></TT>, is limited to a millisecond at best and a few milliseconds
in typical cases. However, some radios produce a PPS signal which can be
used to improve the accuracy with typical workstation servers to the order
of a few tens of microseconds. The details of how this can be accomplished
are discussed in the <A HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A>
page. The following paragraphs discuss how the PPS signal is affected by
the mitigation rules.
</ol>
<P>First, it should be pointed out that the PPS signal is inherently ambiguous,
in that it provides a precise seconds epoch, but does not provide a way
to number the seconds. In principle and most commonly, another source of
synchronization, either the timecode from an associated radio clock, or
even one or more remote NTP servers, is available to perform that function.
In all cases, a specific, configured peer or server must be designated
as associated with the PPS signal. This is done using the <TT>prefer</TT>
keyword as described previously. The PPS signal can be associated in this
way with any peer, but is most commonly used with the radio clock generating
the PPS signal.
<p>Reference clock drivers operate in the manner described in the <A HREF="refclock.htm">Reference Clock Drivers</A> page and its dependencies. The drivers are ordinarily operated at stratum zero, so that as the result of ordinary NTP operations, the server itself operates at stratum one, as required by the NTP specification. In some cases described below, the driver is intentionally operated at an elevated stratum, so that it will be selected only if no other survivor is present with a lower stratum. In the case of the PPS peer or kernel time discipline, these sources appear active only if the prefer peer has survived the intersection and clustering algorithms, as described below, and its clock offset relative to the current local clock is less than a specified value, currently 128 ms.
<P>The PPS signal can be used in two ways to discipline the local clock,
one using a special PPS driver described in the <A HREF="driver22.htm">PPS
Clock Discipline</A> page, the other using PPS signal support in the kernel,
as described in the <A HREF="kern.htm">A Kernel Model for Precision Timekeeping</A>
page. In either case, the signal must be present and within nominal jitter
and wander error tolerances. In addition, the associated prefer peer must
have survived the sanity checks and intersection algorithms and the dispersion
settled below 1 s. This insures that the radio clock hardware is operating
correctly and that, presumably, the PPS signal is operating correctly as
well. Second, the absolute offset of the local clock from that peer must
be less than 128 ms, or well within the 0.5-s unambiguous range of the
PPS signal itself. In the case of the PPS driver, the time offsets generated
from the PPS signal are propagated via the clock filter to the clock selection
procedures just like any other peer. Should these pass the sanity checks
and intersection algorithms, they will show up along with the offsets of
the prefer peer itself. Note that, unlike the prefer peer, the PPS peer
samples are not protected from discard by the clustering algorithm. These
complicated procedures insure that the PPS offsets developed in this way
are the most accurate, reliable available for synchronization.
<p>The modem clock drivers are a special case. Ordinarily, the update interval between modem calls to synchronize the system clock is many times longer than the interval between polls of either a remote server or local radio clock. In order to provide the best stability, the operation of the clock discipline algorithm changes gradually from a phase-lock mode at the shorter update intervals to a frequency-lock mode at the longer update intervals. If remote servers or local radio clocks together with a modem peer operate in the same client, the following things can happen.
<P>The PPS peer remains active as long as it survives the intersection
algorithm and the prefer peer is reachable; however, like any other clock
driver, it runs a reachability algorithm on the PPS signal itself. If for
some reason the signal fails or displays gross errors, the PPS peer will
either become unreachable or stray out of the survivor population. In this
case the clock selection remitigates as described above.
<p>First the clock selection algorithm can select one or more remote servers or radio clocks and the clock discipline algorithm will optimize for the shorter update intervals. Then, the selection algorithm can select the modem peer, which requires a much different optimization. The intent in the design is to allow the modem peer to control the system clock either when no other source is available or, if the modem peer happens to be marked as prefer, then it always controls the clock, as long as it passes the sanity checks and intersection algorithm. There still is room for suboptimal operation in this scheme, since a noise spike can still cause a clockhop either way. Nevertheless, the optimization function is slow to adapt, so that a clockhop or two does not cause much harm.
<P>When kernel support for the PPS signal is available, the PPS signal
is interfaced to the kernel serial driver code via a modem control lead.
As the PPS signal is derived from external equipment, cables, etc., which
sometimes fail, a good deal of error checking is done in the kernel to
detect signal failure and excessive noise. The way in which the mitigation
rules affect the kernel discipline is as follows.
<p>The local clock driver is another special case. Normally, this driver is eligible for selection only if no other source is available. When selected, vernier adjustments introduced via the configuration file or remotely using the <tt><a href="ntpdc.htm">ntpdc</a> </tt>program can be used to trim the local clock frequency and time. However, if the local clock driver is designated the prefer peer, this driver is always selected and all other sources are ignored. This behavior is intended for use when the kernel time is controlled by some means external to NTP, such as the NIST <tt>lockclock</tt> algorithm or another time synchronization protocol such as DTSS. In this case the only way to disable the local clock driver is to mark it unsynchronized using the leap indicator bits. In the case of modified kernels with the <tt>ntp_adjtime()</tt> system call, this can be done automatically if the external synchronization protocol uses it to discipline the kernel time.
<P>In order to operate, the kernel support must be enabled by the <TT>enable
pll </TT>command in the configuration file and the signal must be present
and within nominal jitter and wander error tolerances. In the NTP daemon,
the PPS discipline is active only when the prefer peer is among the survivors
of the clustering algorithm, and its absolute offset is within 128 ms,
as in the PPS driver. Under these conditions the kernel disregards updates
produced by the NTP daemon and uses its internal PPS source instead. The
kernel maintains a watchdog timer for the PPS signal; if the signal has
not been heard or is out of tolerance for more than some interval, currently
two minutes, the kernel discipline is declared inoperable and operation
continues as if it were not present.&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<h4>Mitigation Rules</h4>
</BODY>
</HTML>
The mitigation rules apply in the intersection and clustering algorithms described in the NTP specification. The intersection algorithm first scans all peers with a persistent association and includes only those that satisfy specified sanity checks. In addition to the checks required by the specification, the mitigation rules require either the local-clock peer or modem peer to be included only if marked as the prefer peer. The intersection algorithm operates on the included population to select only those peers believed to represent the correct time. If one or more peers survive the operation, processing continues in the clustering algorithm. Otherwise, if there is a modem peer, it is declared the only survivor; otherwise, if there is a local-clock peer, it is declared the only survivor. Processing then continues in the clustering algorithm.
<p>The clustering algorithm repeatedly discards outlyers in order to reduce the residual jitter in the survivor population. As required by the NTP specification, these operations continue until either a specified minimum number of survivors remain or the minimum select dispersion of the population is greater than the maximum peer dispersion of any member. The mitigation rules require an additional terminating condition which stops these operations at the point where the prefer peer is about to be discarded.
<p>The mitigation rules establish the choice of <i>system peer</i>, which determine the stratum, reference identifier and several other system variables which are visible to clients of the local server. In addition, they establish which source or combination of sources control the local clock.
<ol>
<li>If there is a prefer peer and it is the local-clock peer or the modem peer; or, if there is a prefer peer and the kernel time discipline is active, choose the prefer peer as the system peer and its offset as the system clock offset. If the prefer peer is the local-clock peer, an offset can be calculated by the driver to produce a frequency offset in order to correct for systematic frequency errors. In case a source other than NTP is controlling the system clock, corrections determined by NTP can be ignored by using the <tt>disable pll</tt> in the configuration file. If the prefer peer is the modem peer, it must be the primary source for the reasons noted above. If the kernel time discipline is active, the system clock offset is ignored and the corrections handled directly by the kernel.</li>
<li>If the above is not the case and there is a PPS peer, then choose it as the system peer and its offset as the system clock offset.</li>
<li>If the above is not the case and there is a prefer peer (not the local-clock or modem peer in this case), then choose it as the system peer and its offset as the system clock offset.</li>
<li>If the above is not the case and the peer previously chosen as the system peer is in the surviving population, then choose it as the system peer and average its offset along with the other survivors to determine the system clock offset. This behavior is designed to avoid excess jitter due to clockhopping, when switching the system peer would not materially improve the time accuracy.</li>
<li>If the above is not the case, then choose the first candidate in the list of survivors ranked in order of synchronization distance and average its offset along with the other survivors to determine the system clock offset. This is the default case and the only case considered in the current NTP specification.</li>
</ol>
<h4>Using the Pulse-per-Second (PPS) Signal</h4>
Most radio clocks are connected using a serial port operating at speeds of 9600 bps or higher. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character, like carriage-return <tt>&lt;cr></tt>, is limited to a millisecond at best and a few milliseconds in typical cases. However, some radios produce a PPS signal which can be used to improve the accuracy with typical workstation servers to the order of a few tens of microseconds. The details of how this can be accomplished are discussed in the <A HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A> page. The following paragraphs discuss how the PPS signal is affected by the mitigation rules.
<p>First, it should be pointed out that the PPS signal is inherently ambiguous, in that it provides a precise seconds epoch, but does not provide a way to number the seconds. In principle and most commonly, another source of synchronization, either the timecode from an associated radio clock, or even one or more remote NTP servers, is available to perform that function. In all cases, a specific, configured peer or server must be designated as associated with the PPS signal. This is done using the <tt>prefer</tt> keyword as described previously. The PPS signal can be associated in this way with any peer, but is most commonly used with the radio clock generating the PPS signal.
<p>The PPS signal can be used in two ways to discipline the local clock, one using a special PPS driver described in the <A HREF="driver22.htm">PPS Clock Discipline</A> page, the other using PPS signal support in the kernel, as described in the <A HREF="kern.htm">A Kernel Model for Precision Timekeeping</A> page. In either case, the signal must be present and within nominal jitter and wander error tolerances. In addition, the associated prefer peer must have survived the sanity checks and intersection algorithms and the dispersion settled below 1 s. This insures that the radio clock hardware is operating correctly and that, presumably, the PPS signal is operating correctly as well. Second, the absolute offset of the local clock from that peer must be less than 128 ms, or well within the 0.5-s unambiguous range of the PPS signal itself. In the case of the PPS driver, the time offsets generated from the PPS signal are propagated via the clock filter to the clock selection procedures just like any other peer. Should these pass the sanity checks and intersection algorithms, they will show up along with the offsets of the prefer peer itself. Note that, unlike the prefer peer, the PPS peer samples are not protected from discard by the clustering algorithm. These complicated procedures insure that the PPS offsets developed in this way are the most accurate, reliable available for synchronization.
<p>The PPS peer remains active as long as it survives the intersection algorithm and the prefer peer is reachable; however, like any other clock driver, it runs a reachability algorithm on the PPS signal itself. If for some reason the signal fails or displays gross errors, the PPS peer will either become unreachable or stray out of the survivor population. In this case the clock selection remitigates as described above.
<p>When kernel support for the PPS signal is available, the PPS signal is interfaced to the kernel serial driver code via a modem control lead. As the PPS signal is derived from external equipment, cables, etc., which sometimes fail, a good deal of error checking is done in the kernel to detect signal failure and excessive noise. The way in which the mitigation rules affect the kernel discipline is as follows.
<p>PPS support requires the PPS driver (type 22) and PPSAPI interface described in the <a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing></a> page. In order to operate, the prefer peer must be designated and the kernel support enabled by the <tt>enable pps</tt> command in the configuration file and the signal must be present and within nominal jitter and wander error tolerances. In the NTP daemon, the PPS discipline is active only when the prefer peer is among the survivors of the clustering algorithm, and its absolute offset is within 128 ms, as determined by the PPS driver. Under these conditions the kernel disregards updates produced by the NTP daemon and uses its internal PPS source instead. The kernel maintains a watchdog timer for the PPS signal; if the signal has not been heard or is out of tolerance for more than some interval, currently two minutes, the kernel discipline is declared inoperable and operation continues as if it were not present.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a></address></a></body></html>

173
contrib/ntp/html/quick.htm
View File

@ -1,99 +1,100 @@
<HTML><HEAD><TITLE>
Quick Start
</TITLE></HEAD><BODY><H3>
Quick Start
</H3>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Quick Start</title>
</head>
<body>
<h3>Quick Start</h3>
<img align=left src=pic/panda.gif>FAX test image for SATNET (1979).
<img align="left" src="pic/panda.gif" alt="gif">FAX test image for
SATNET (1979).
<p>The baby panda was scanned at University College London and used
as a FAX test image for a demonstration of the DARPA Atlantic
SATNET Program and the first transatlantic Internet connection in 1978.
The computing system used for that demonstration was called the <A
HREF="http://www.eecis.udel.edu/~mills/database/papers/fuzz.ps">Fuzzball
</A>. As it happened, this was also the first Internet multimedia
presentation and the first to use NTP in regular operation. The image
was widely copied and used for testing purpose throughout much of the
1980s.
<br clear=left>
SATNET Program and the first transatlantic Internet connection in
1978. The computing system used for that demonstration was called
the <a href=
"http://www.eecis.udel.edu/~mills/database/papers/fuzz.ps">
Fuzzball</a> . As it happened, this was also the first Internet
multimedia presentation and the first to use NTP in regular
operation. The image was widely copied and used for testing purpose
throughout much of the 1980s.<br clear="left">
</p>
<H4>Introduction</H4>
<hr>
<p>For the rank amateur the sheer volume of the documentation
collection must be intimidating. However, it doesn't take much to
fly the <tt>ntpd</tt> daemon with a simple configuration where a
workstation needs to synchronize to some server elsewhere in the
Internet. The first thing that needs to be done is to build the
distribution for the particular workstation and install in the
usual place. The <a href="build.htm">Building and Installing the
Distribution</a> page describes how to do this.</p>
<p>This page describes what to expect when the NTP daemon <tt>ntpd</tt>
is started for the first time. The discussion presumes the programs in
this distribution have been compiled and installed as described in the
<a href=build.htm>Building and Installing the Distribution</a> page.
<p>While it is possible that certain configurations do not need a
configuration file, most do require one. Strictly speaking, the
file need only contain one line specifying a remote server, for
instance</p>
<p>When the daemon is started, whether for the first or subsequent
times, a number of roundtrip samples are required to accumulate reliable
measurements of network path delay and clock offset relative to the
server. Normally, this takes about four minutes, after which the local
clock is synchronized to the server. The daemon behavior at startup
depends on whether a drift file <tt>ntp.drift</tt> exists. This file
contains the latest estimate of local clock frequency error. When the
daemon is started for the first time, it is created after about one hour
of operation and updated once each hour after that. When the daemon is
started and the file does not exist, the daemon enters a special mode
designed to quickly adapt to the particular system clock oscillator time
and frequency error. This takes approximately 15 minutes, after which
the time and frequency are set to nominal values and the daemon enters
normal mode, where the time and frequency are continuously tracked
relative to the server.
<p><tt>server foo.bar.com</tt></p>
<p>As a practical matter, once the local clock has been set, it very
rarely strays more than 128 ms relative to the server, even under
extreme cases of network path congestion and jitter. Sometimes, in
particular when the daemon is first started, the relative clock offset
exceeds 128 ms. In such cases the normal behavior of the daemon is to
set the clock directly, rather than rely on gradual corrections. This
may cause the clock to be set backwards, if the local clock time is more
than 128 s in the future relative to the server. In some applications,
this behavior may be unacceptable. If the <tt>-x</tt> option is included
on the command line that starts the daemon, the clock will never be
stepped and only slew corrections will be used.
<p>Choosing an appropriate remote server is somewhat of a black
art, but a suboptimal choice is seldom a problem. Links to public
time servers operated by National Institutes of Science and
Technology (NIST), US Naval Observatory (USNO), Canadian Metrology
Centre (CMC) and many others are given in the home page of this
document collection. The lists are sorted by country and, in the
case of the US, by state. Usually, the best choice is the nearest
in geographical terms, but the terms of engagement specified in
each list entry should be carefully respected.</p>
<p>The issues should be carefully explored before deciding to use the
<tt>-x</tt> option. The maximum slew rate possible is limited to 500
parts-per-million (PPM) as a consequence of the correctness principles
on which the NTP protocol and algorithm design are based. As a result,
the local clock can take a long time to converge to an acceptable
offset, about 2000 s for each second the clock is outside the acceptable
range. During this interval the local clock will not be consistent with
any other network clock and the system cannot be used for distributed
applications that require correctly synchronized network time.
<p>During operation <tt>ntpd</tt> measures and corrects for
incidental clock frequency error and writes the current value to a
file if enabled. If the <tt>ntpd</tt> is stopped and restarted, it
initializes the frequency from this file. In this way the
potentially lengthy interval to relearn the frequency error is
avoided. Thus, for most applications an additional line should be
added to the file of the form</p>
<p>There may be an occasional outlyer, where an individual measurement
exceeds 128 ms. When the frequency of occurrence of these outlyers is
low, the measurement is discarded and operation continues with the next
one. However, if the outlyers persist for an interval longer than about
15 minutes, the next value is believed and the clock stepped or slewed
as determined by the <tt>-x</tt> option. The usual reason for this
behavior is when a leap second has occurred, but the reference clock
receiver has not synchronized to it. When leap second support is
implemented in the kernel, the kernel implements it as directed by the
NTP daemon. If this happens and the reference clock source
resynchronizes correctly within 15 minutes, the transient misbehavior of
the source is transparent.
<p><tt>driftfile /etc/ntp.drift</tt></p>
<p>It has been observed that, as the result of extreme network
congestion, the roundtrip delays can exceed three seconds and the
synchronization distance, which is equal to one-half the roundtrip delay
plus the error budget terms, can become very large. When the
synchronization distance exceeds one second, the offset measurement is
discarded. If this condition persists for several poll intervals, the
server may be declared unreachable. Sometimes the large jitter results
in large frequency errors which result in straying outside the
acceptable offset range and an eventual step or slew time correction. If
following such a correction the frequency error is so large that the
first sample is outside the acceptable range, the daemon enters the same
state as when the <tt>ntp.drift</tt> file is not present. The intent of
this behavior is to quickly correct the frequency and restore operation
to the normal tracking mode. In the most extreme cases
(<tt>time.ien.it</tt> comes to mind), there may be occasional step/slew
corrections and subsequent frequency corrections. It helps in these
cases to use burst mode when configuring the server.
<p>That's all there is to it, unless some problem in network
connectivity or local operating system configuration occurs. The
most common problem is some firewall between the workstation and
server. System administrators should understand NTP uses UDP port
123 as both the source and destination port and that NTP does not
involve any operating system interaction other than to set the
system clock. While almost all modern Unix systems have included
NTP and UDP port 123 defined in the services file, this should be
checked if <tt>ntpd</tt> fails to come up at all.</p>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>
<p>The best way to confirm NTP is working is using the <a href=
"ntpq.htm"><tt>ntpq</tt></a> utility, although the <a href=
"ntpdc.htm"><tt>ntpdc</tt></a> utility may be useful in extreme
cases. See the documentation pages for further information. In the
most extreme cases the <tt>-d</tt> option on the <tt>ntpd</tt>
command line results in a blow-by-blow trace of the daemon
operations. While the trace output can be cryptic, to say the
least, it gives a general idea of what the program is doing and, in
particular, details the arriving and departing packets and detected
errors, if present.</p>
<p>Sometimes the <tt>ntpd</tt>. behavior may seem to violate the
Principle of Least Astonishment, but there are good reasons for
this. See the <a href="ntpd.htm">Network Time Protocol (NTP)
daemon</a> page for revealing insights. See this page and its
dependencies for additional configuration and control options. The
<a href="notes.htm">Notes on Configuring NTP and Setting up a NTP
Subnet</a> page contains an extended discussion of these
options.</p>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

72
contrib/ntp/html/rdebug.htm
View File

@ -1,67 +1,25 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<html><head><title>
Debugging Hints for Reference Clock Drivers
</title></head><body><h3>
Debugging Hints for Reference Clock Drivers
</h3><hr>
</h3>
<p>The <a href = "ntpq.htm"> <code>ntpq</code></a> and <a href =
"ntpdc.htm"> <code>ntpdc</code> </a>utility programs can be used to
debug reference clocks, either on the server itself or from another
machine elsewhere in the network. The server is compiled, installed and
started using the command-line switches described in the <a href =
"ntpd.htm"> <code>ntpd</code> </a> page. The first thing to look for
are error messages on the system log. If none occur, the daemon has
started, opened the devices specified and waiting for peers and radios
to come up.
<img align=left src=pic/oz2.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>The
Wizard of Oz</i>, L. Frank Baum</a>
<p>The next step is to be sure the RS232 messages, if used, are getting
to and from the clock. The most reliable way to do this is with an RS232
tester and to look for data flashes as the driver polls the clock and/or
as data arrive from the clock. Our experience is that the overwhelming
fraction of problems occurring during installation are due to problems
such as miswired connectors or improperly configured device links at
this stage.
<p>Call the girls and the'll sweep your bugs.
<br clear=left><hr>
<p>If RS232 messages are getting to and from the clock, the variables of
interest can be inspected using the <code>ntpq</code> program and
various commands described on the documentation page. First, use the
<code>pe</code> and <code>as</code> commands to display billboards
showing the peer configuration and association IDs for all peers,
including the radio clock peers. The assigned clock address should
appear in the <code>pe</code> billboard and the association ID for it at
the same relative line position in the <code>as</code> billboard. If
things are operating correctly, after a minute or two samples should
show up in the <code>pe</code> display line for the clock.
<p>The <a href=ntpq.htm><tt>ntpq</tt></a> and <a href=ntpdc.htm><tt>ntpdc</tt></a> utility programs can be used to debug reference clocks, either on the server itself or from another machine elsewhere in the network. The server is compiled, installed and started using the configuration file described in the <a href=ntpd.htm><tt>ntpd</tt></a> page and its dependencies. If the clock appears in the <tt>ntpq</tt> utility and <tt>pe</tt> command, no errors have occured and the daemon has started, opened the devices specified and waiting for peers and radios to come up. If not, the first thing to look for are error messages on the system log. These are usually due to improper configuration, missing links or multiple instances of the daemon.
<p>Additional information is available with the <code>rv</code> and
<code>clockvar</code> commands, which take as argument the association
ID shown in the <code>as</code> billboard. The <code>rv</code> command
with no argument shows the system variables, while the <code>rv</code>
command with association ID argument shows the peer variables for the
clock, as well as any other peers of interest. The <code>clockvar</code>
command with argument shows the peer variables specific to reference
clock peers, including the clock status, device name, last received
timecode (if relevant), and various event counters. In addition, a
subset of the <code>fudge</code> parameters is included.
<p>It normally takes a minute or so for evidence to appear that the clock is running and the driver is operating correctly. The first indication is a nonzero value in the <tt>reach</tt> column in the <tt>pe</tt> billboard. If nothing appears after a few minutes, the next step is to be sure the RS232 messages, if used, are getting to and from the clock. The most reliable way to do this is with an RS232 tester and to look for data flashes as the driver polls the clock and/or as data arrive from the clock. Our experience is that the overwhelming fraction of problems occurring during installation are due to problems such as miswired connectors or improperly configured device links at this stage.
<p>The <code>ntpdc</code> utility program can be used for detailed
inspection of the clock driver status. The most useful are the
<code>clockstat</code> and <code>clkbug</code> commands described in the
document page. While these commands permit getting quite personal with
the particular driver involved, their use is seldom necessary, unless an
implementation bug shows up.
<p>If RS232 messages are getting to and from the clock, the variables of interest can be inspected using the <tt>ntpq</tt> program and various commands described on the documentation page. First, use the <tt>pe</tt> and <tt>as</tt> commands to display billboards showing the peer configuration and association IDs for all peers, including the radio clock. The assigned clock address should appear in the <tt>pe</tt> billboard and the association ID for it at the same relative line position in the <tt>as</tt> billboard.
<p>Most drivers write a message to the <code>clockstats</code> file as
each timecode or surrogate is received from the radio clock. By
convention, this is the last ASCII timecode (or ASCII gloss of a binary-
coded one) received from the radio clock. This file is managed by the
<code>filegen</code> facility described in the <code>ntpd</code> page
and requires specific commands in the configuration file. This forms a
highly useful record to discover anomalies during regular operation of
the clock. The scripts included in the <code>./scripts/stats</code>
directory can be run from a <code>cron</code> job to collect and
summarize these data on a daily or weekly basis. The summary files have
proven invaluable to detect infrequent misbehavior due to clock
implementation bugs in some radios.
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>
<p>Additional information is available with the <tt>rv</tt> and <tt>clockvar</tt> commands, which take as argument the association ID shown in the <tt>as</tt> billboard. The <tt>rv</tt> command with no argument shows the system variables, while the <tt>rv</tt> command with association ID argument shows the peer variables for the clock, as well as other peers of interest. The <tt>clockvar</tt> command with argument shows the peer variables specific to reference clock peers, including the clock status, device name, last received timecode (if relevant), and various event counters. In addition, a subset of the <tt>fudge</tt> parameters is included. The poll and error counters in the <tt>clockvar</tt> billboard are useful debugging aids. The <tt>poll</tt> counts the poll messages sent to the clock, while the <tt>noreply</tt>, <tt>badformat</tt> and <tt>baddate</tt> count various errors. Check the timecode to be sure it matches what the driver expects. This may require consulting the clock hardware reference manual, which is probably pretty dusty at this stage.
<p>The <tt>ntpdc</tt> utility program can be used for detailed inspection of the clock driver status. The most useful are the <tt>clockstat</tt> and <tt>clkbug</tt> commands described in the document page. While these commands permit getting quite personal with the particular driver involved, their use is seldom necessary, unless an implementation bug shows up. If all else fails, turn on the debugging trace using two <tt>-d</tt> flags in the <tt>ntpd</tt> startup command line. Most drivers will dump status at every received message in this case. While the displayed trace can be intimidating, this provides the most detailed and revealing indicator of how the driver and clock are performing and where bugs might lurk.
<p>Most drivers write a message to the <tt>clockstats</tt> file as each timecode or surrogate is received from the radio clock. By convention, this is the last ASCII timecode (or ASCII gloss of a binary-coded one) received from the radio clock. This file is managed by the <tt>filegen</tt> facility described in the <tt>ntpd</tt> page and requires specific commands in the configuration file. This forms a highly useful record to discover anomalies during regular operation of the clock. The scripts included in the <tt>./scripts/stats</tt> directory can be run from a <tt>cron</tt> job to collect and summarize these data on a daily or weekly basis. The summary files have proven inspirational to detect infrequent misbehavior due to clock implementation bugs in some radios.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills &lt;mills@udel.edu&gt;</a></address></a></body></html>

383
contrib/ntp/html/refclock.htm
View File

@ -1,157 +1,250 @@
<html><head><title>
Reference Clock Drivers
</title></head><body><h3>
Reference Clock Drivers
</H3>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Reference Clock Drivers</title>
</head>
<body>
<h3>Reference Clock Drivers</h3>
<IMG ALIGN=LEFT SRC=pic/tardisa.gif>From top:
<UL>
<LI>Austron 2100A GPS Receiver with LORAN-C assist</LI>
<LI>Austron 2000 LORAN-C Receiver></LI>
<LI>Spectracom 8170 WWVB Receiver</LI>
<LI>Hewlett Packard 5061A Cesium Beam Standard</LI>
</UL>
<br clear=left>
The Tardis
<img align="left" src="pic/stack1a.jpg" alt="gif">Master Time
Facility at the <a href="http://www.eecis.udel.edu/~mills/lab.htm">
UDel Internet Research Laboratory</a>: <br clear="left">
<hr>
<p>Support for most of the commonly available radio and modem
reference clocks is included in the default configuration of the
NTP daemon for Unix <tt>ntpd</tt>. Individual clocks can be
activated by configuration file commands, specifically the <tt>
server</tt> and <tt>fudge</tt> commands described in the <a href=
"ntpd.htm"><tt>ntpd</tt> program manual page</a>. The following
discussion presents Information on how to select and configure the
device drivers in a running Unix system.</p>
Support for most of the commonly available radio and modem reference
clocks is included in the default configuration of the NTP daemon for
Unix <TT>ntpd</TT>. Individual clocks can be activated by configuration
file commands, specifically the <TT>server</TT> and <TT>fudge</TT>
commands described in the <A HREF=ntpd.htm><TT>ntpd</TT> program manual
page</A>. The following discussion presents Information on how to select
and configure the device drivers in a running Unix system.
<p>Many radio reference clocks can be set to display local time as
adjusted for timezone and daylight saving mode. For use with NTP
the clock must be set for Coordinated Universal Time (UTC) only.
Ordinarily, these adjustments are performed by the kernel, so the
fact that the clock runs on UTC will be transparent to the
user.</p>
<P>Radio and modem clocks by convention have addresses in the form
127.127.<I>t.u</I>, where <I>t</I> is the clock type and <I>u</I> is a
unit number in the range 0-3 used to distinguish multiple instances of
clocks of the same type. Most of these clocks require support in the
form of a serial port or special bus peripheral, but some can work
directly from the audio codec found in some workstations. The particular
device is normally specified by adding a soft link
<TT>/dev/device<I>u</I></TT> to the particular hardware device involved,
where <I><TT>u</TT></I> correspond to the unit number above.
<p>Radio and modem clocks by convention have addresses in the form
127.127.<i>t.u</i>, where <i>t</i> is the clock type and <i>u</i>
is a unit number in the range 0-3 used to distinguish multiple
instances of clocks of the same type. Most of these clocks require
support in the form of a serial port or special bus peripheral, but
some can work directly from the audio codec found in some
workstations. The particular device is normally specified by adding
a soft link <tt>/dev/device<i>u</i></tt> to the particular hardware
device involved, where <i><tt>u</tt></i> correspond to the unit
number above.</p>
<p>Most clock drivers communicate with the reference clock using a
serial port, usually at 9600 bps. There are several application program
interfaces (API) used in the various Unix and NT systems, most of which
can be detected at configuration time. Thus, it is important that the
NTP daemon and utilities be compiled on the target system or clone. In
some cases special features are available, such as timestamping in the
kernel or pulse-per-second (PPS) interface. In most cases these features
can be detected at configuration time as well; however, the kernel may
have to be recompiled in order for them to work.
serial port, usually at 9600 bps. There are several application
program interfaces (API) used in the various Unix and NT systems,
most of which can be detected at configuration time. Thus, it is
important that the NTP daemon and utilities be compiled on the
target system or clone. In some cases special features are
available, such as timestamping in the kernel or pulse-per-second
(PPS) interface. In most cases these features can be detected at
configuration time as well; however, the kernel may have to be
recompiled in order for them to work.</p>
<p>The audio drivers are a special case. These include support for the
NIST time/frequency stations WWV and WWVH, the Canadian time/frequency
station CHU and generic IRIG signals. Currently, support for the Solaris
and SunOS audio API is included in the distribution. It is left to the
volunteer corps to extend this support to other systems. Further
information on hookup, debugging and monitoring is given in the <a
href=audio.htm>Audio Drivers</a> page.
<p>The audio drivers are a special case. These include support for
the NIST time/frequency stations WWV and WWVH, the Canadian
time/frequency station CHU and generic IRIG signals. Currently,
support for the Solaris and SunOS audio API is included in the
distribution. It is left to the volunteer corps to extend this
support to other systems. Further information on hookup, debugging
and monitoring is given in the <a href="audio.htm">Audio
Drivers</a> page.</p>
<p>Some drivers depending on longwave and shortwave radio services need
to know the radio propagation time from the transmitter to the receiver,
which can amount to some tens of milliseconds. This must be calculated
for each specific receiver location and requires the geographic
coordinates of both the transmitter and receiver. The transmitter
coordinates for various radio services are given in the <a
href=qth.htm>Stations, Frequencies and Geographic Coordinates</a> page.
Receiver coordinates can be obtained or estimated from various sources.
The actual calculations are beyond the scope of this document.
<p>The local clock driver is also a special case. A server
configured with this driver can operate as a primary server to
synchronize other clients when no other external synchronization
sources are available. If the server is connected directly or
indirectly to the public Internet, there is some danger that it can
adversely affect the operation of unrelated clients. Carefully read
the <a href="driver1.htm">Undisciplined Local Clock</a> page and
respect the stratum limit.</p>
<P>Following is a list showing the type and title of each driver
currently implemented. The compile-time identifier for each is shown in
parentheses. Click on a selected type for specific description and
configuration documentation, including the clock address, reference ID,
driver ID, device name and serial line speed, and features (line
disciplines, etc.). For those drivers without specific documentation,
please contact the author listed in the <A HREF=copyright.htm>Copyright
Notice</A> page.
<p>The local clock driver also supports an external synchronization
source such as a high resolution counter disciplined by a GPS
receiver, for example. Further information is on the <a href=
"extern.htm">External Clock Discipline and the Local Clock
Driver</a> page.</p>
<P><A HREF=driver1.htm>Type 1</A> Undisciplined Local Clock
(<TT>LOCAL</TT>)
<BR><A HREF=driver2.htm>Type 2</A> Trak 8820 GPS Receiver
(<TT>GPS_TRAK</TT>)
<BR><A HREF=driver3.htm>Type 3</A> PSTI/Traconex 1020 WWV/WWVH
Receiver
(<TT>WWV_PST</TT>)
<BR><A HREF=driver4.htm>Type 4</A> Spectracom WWVB and GPS Receivers
(<TT>WWVB_SPEC</TT>)
<BR><A HREF=driver5.htm>Type 5</A> TrueTime GPS/GOES/OMEGA Receivers
(<TT>TRUETIME</TT>)
<BR><A HREF=driver6.htm>Type 6</A> IRIG Audio Decoder
(<TT>IRIG_AUDIO</TT>)
<BR><A HREF=driver7.htm>Type 7</A> Radio CHU Audio Demodulator/Decoder
(<TT>CHU</TT>)
<BR><A HREF=driver8.htm>Type 8</A> Generic Reference Driver
(<TT>PARSE</TT>)
<BR><A HREF=driver9.htm>Type 9</A> Magnavox MX4200 GPS Receiver
(<TT>GPS_MX4200</TT>)
<BR><A HREF=driver10.htm>Type 10</A> Austron 2200A/2201A GPS Receivers
(<TT>GPS_AS2201</TT>)
<BR><A HREF=driver11.htm>Type 11</A> Arbiter 1088A/B GPS Receiver
(<TT>GPS_ARBITER</TT>)
<BR><A HREF=driver12.htm>Type 12</A> KSI/Odetics TPRO/S IRIG Interface
(<TT>IRIG_TPRO</TT>)
<BR>Type 13 Leitch CSD 5300 Master Clock Controller
(<TT>ATOM_LEITCH</TT>)
<BR>Type 14 EES M201 MSF Receiver (<TT>MSF_EES</TT>)
<BR><A HREF=driver5.htm>Type 15</A> * TrueTime generic receivers
<BR>Type 16 Bancomm GPS/IRIG Receiver (<TT>GPS_BANCOMM</TT>)
<BR>Type 17 Datum Precision Time System (<TT>GPS_DATUM</TT>)
<BR><A HREF=driver18.htm>Type 18</A> NIST Modem Time Service
(<TT>ACTS_NIST</TT>)
<BR><A HREF=driver19.htm>Type 19</A> Heath WWV/WWVH Receiver
(<TT>WWV_HEATH</TT>)
<BR><A HREF=driver20.htm>Type 20</A> Generic NMEA GPS Receiver
(<TT>NMEA</TT>)
<BR>Type 21 TrueTime GPS-VME Interface (<TT>GPS_VME</TT>)
<BR><A HREF=driver22.htm>Type 22</A> PPS Clock Discipline
(<TT>PPS</TT>)
<BR><A HREF=driver23.htm>Type 23</A> PTB Modem Time Service
(<TT>ACTS_PTB</TT>)
<BR><A HREF=driver24.htm>Type 24</A> USNO Modem Time Service
(<TT>ACTS_USNO</TT>)
<BR><A HREF=driver5.htm>Type 25</A> * TrueTime generic receivers
<BR><A HREF=driver26.htm>Type 26</A> Hewlett Packard 58503A GPS
Receiver (<TT>GPS_HP</TT>)
<BR><A HREF=driver27.htm>Type 27</A> Arcron MSF Receiver
(<TT>MSF_ARCRON</TT>)
<BR><A HREF=driver28.htm>Type 28</A> Shared Memory Driver
(<TT>SHM</TT>)
<BR><A HREF=driver29.htm>Type 29</A> Trimble Navigation Palisade GPS
(<TT>GPS_PALISADE</TT>)
<BR><A HREF=driver30.htm>Type 30</A> Motorola UT Oncore GPS
(<TT>GPS_ONCORE</TT>)
<BR>Type 31 Rockwell Jupiter GPS (<TT>GPS_JUPITER</TT>)
<BR><A HREF=driver34.htm>Type 34</A> Ultralink WWVB Receivers
<BR><A HREF=driver35.htm>Type 35</A> Conrad Parallel Port Radio Clock
(<TT>PCF</TT>)
<BR><A HREF=driver36.htm>Type 36</A> Radio WWV/H Audio
Demodulator/Decoder(<TT>WWV</TT>)
<BR><A HREF=driver37.htm>Type 37</A> Forum Graphic GPS Dating station
(<TT>FG</TT>)
<h4>Driver Calibration</h4>
<P>* All TrueTime receivers are now supported by one driver, type 5.
Types 15 and 25 will be retained only for a limited time and may be
reassigned in future.
<P>Additional Information
<P><A HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT>
Keyword</A>
<BR><A HREF=rdebug.htm>Debugging Hints for Reference Clock Drivers</A>
<BR><A HREF=ldisc.htm>Line Disciplines and Streams Drivers</A>
<BR><A HREF=audio.htm>Reference Clock Audio Drivers</A>
<BR><A HREF=pps.htm>Pulse-per-second (PPS) Signal Interfacing</A>
<BR><A HREF=howto.htm>How To Write a Reference Clock Driver</A>
<BR><A HREF=index.htm>The Network Time Protocol (NTP)
Distribution&nbsp;</A>&nbsp;
<p>Some drivers depending on longwave and shortwave radio services
need to know the radio propagation time from the transmitter to the
receiver, which can amount to some tens of milliseconds. This must
be calculated for each specific receiver location and requires the
geographic coordinates of both the transmitter and receiver. The
transmitter coordinates for various radio services are given in the
<a href="qth.htm">Stations, Frequencies and Geographic
Coordinates</a> page. Receiver coordinates can be obtained or
estimated from various sources. The actual calculations are beyond
the scope of this document.</p>
<p>When more than one clock driver is supported, it is often the
case that each shows small systematic offset differences relative
to the rest. To reduce the effects of jitter when switching from
one driver to the another, it is useful to calibrate the drivers to
a common ensemble offset. The <tt>enable calibrate</tt>
configuration command in the <a href="miscopt.htm">Miscellaneous
Options</a> page is useful for this purpose. The calibration
function can also be enabled and disabled using the <tt>ntpdc</tt>
program utility.</p>
<p>Most clock drivers use the <tt>time1</tt> value specified in the
<tt>fudge</tt> configuration command to provide the calibration
correction when this cannot be provided by the clock or interface.
When the calibration function is enabled, the <tt>time1</tt> value
is automatically adjusted to match the offset of the remote server
or local clock driver selected for synchronization. Ordinarily, the
NTP selection algorithm chooses the best from among all sources,
usually the best radio clock determined on the basis of stratum,
synchronization distance and jitter. The calibration function
adjusts the <tt>time1</tt> values for all clock drivers except this
source so that their indicated offsets tend to zero. If the
selected source is the kernel PPS discipline, the <tt>fudge
time1</tt> values for all clock drivers are adjusted.</p>
<p>The adjustment function is an exponential average designed to
improve accuracy, so the function takes some time to converge. The
recommended procedure is to enable the function, let it run for an
hour or so, then edit the configuration file using the <tt>
time1</tt> values displayed by the <tt>ntpq</tt> utility and <tt>
clockvar</tt> command. Finally, disable the calibration function to
avoid possible future disruptions due to misbehaving clocks or
drivers.</p>
<h4>Performance Enhancements</h4>
<p>In general, performance can be improved, especially when more
than one clock driver is supported, to use the prefer peer function
described in the <a href="prefer.htm">Mitigation Rules and the <tt>
prefer</tt> Keyword</a> page. The prefer peer is ordinarily
designated the remote peer or local clock driver which provides the
best quality time. All other things equal, only the prefer peer
source is used to discipline the system clock and jitter-producing
"clockhopping" between sources is avoided. This is valuable when
more than one clock driver is present and especially valuable when
the PPS clock driver (type 22) is used. Support for PPS signals is
summarized in the <a href="pps.htm">Pulse-per-second (PPS) Signal
Interfacing</a> page.</p>
<p>Where the highest performance is required, generally better than
one millisecond, additional hardware and/or software functions may
be required. Kernel modifications for precision time are described
in the <a href="kern.htm">A Kernel Model for Precision
Timekeeping</a> page. Special line discipline and streams modules
for use in capturing precision timestamps are described in the <a
href="ldisc.htm">Line Disciplines and Streams Drivers</a> page.</p>
<h4>Comprehensive List of Clock Drivers</h4>
<p>Following is a list showing the type and title of each driver
currently implemented. The compile-time identifier for each is
shown in parentheses. Click on a selected type for specific
description and configuration documentation, including the clock
address, reference ID, driver ID, device name and serial line
speed, and features (line disciplines, etc.). For those drivers
without specific documentation, please contact the author listed in
the <a href="copyright.htm">Copyright Notice</a> page.</p>
<p><a href="driver1.htm">Type 1</a> Undisciplined Local Clock
(<tt>LOCAL</tt>)<br>
<a href="driver2.htm">Type 2</a> Trak 8820 GPS Receiver
(<tt>GPS_TRAK</tt>)<br>
<a href="driver3.htm">Type 3</a> PSTI/Traconex 1020 WWV/WWVH
Receiver (<tt>WWV_PST</tt>)<br>
<a href="driver4.htm">Type 4</a> Spectracom WWVB and GPS Receivers
(<tt>WWVB_SPEC</tt>)<br>
<a href="driver5.htm">Type 5</a> TrueTime GPS/GOES/OMEGA Receivers
(<tt>TRUETIME</tt>)<br>
<a href="driver6.htm">Type 6</a> IRIG Audio Decoder
(<tt>IRIG_AUDIO</tt>)<br>
<a href="driver7.htm">Type 7</a> Radio CHU Audio
Demodulator/Decoder (<tt>CHU</tt>)<br>
<a href="driver8.htm">Type 8</a> Generic Reference Driver
(<tt>PARSE</tt>)<br>
<a href="driver9.htm">Type 9</a> Magnavox MX4200 GPS Receiver
(<tt>GPS_MX4200</tt>)<br>
<a href="driver10.htm">Type 10</a> Austron 2200A/2201A GPS
Receivers (<tt>GPS_AS2201</tt>)<br>
<a href="driver11.htm">Type 11</a> Arbiter 1088A/B GPS Receiver
(<tt>GPS_ARBITER</tt>)<br>
<a href="driver12.htm">Type 12</a> KSI/Odetics TPRO/S IRIG
Interface (<tt>IRIG_TPRO</tt>)<br>
Type 13 Leitch CSD 5300 Master Clock Controller
(<tt>ATOM_LEITCH</tt>)<br>
Type 14 EES M201 MSF Receiver (<tt>MSF_EES</tt>)<br>
<a href="driver5.htm">Type 15</a> * TrueTime generic receivers<br>
<a href="driver16">Type 16</a> Bancomm GPS/IRIG Receiver
(<tt>GPS_BANCOMM</tt>)<br>
Type 17 Datum Precision Time System (<tt>GPS_DATUM</tt>)<br>
<a href="driver18.htm">Type 18</a> NIST Modem Time Service
(<tt>ACTS_NIST</tt>)<br>
<a href="driver19.htm">Type 19</a> Heath WWV/WWVH Receiver
(<tt>WWV_HEATH</tt>)<br>
<a href="driver20.htm">Type 20</a> Generic NMEA GPS Receiver
(<tt>NMEA</tt>)<br>
Type 21 TrueTime GPS-VME Interface (<tt>GPS_VME</tt>)<br>
<a href="driver22.htm">Type 22</a> PPS Clock Discipline
(<tt>PPS</tt>)<br>
<a href="driver23.htm">Type 23</a> PTB Modem Time Service
(<tt>ACTS_PTB</tt>)<br>
<a href="driver24.htm">Type 24</a> USNO Modem Time Service
(<tt>ACTS_USNO</tt>)<br>
<a href="driver5.htm">Type 25</a> * TrueTime generic receivers<br>
<a href="driver26.htm">Type 26</a> Hewlett Packard 58503A GPS
Receiver (<tt>GPS_HP</tt>)<br>
<a href="driver27.htm">Type 27</a> Arcron MSF Receiver
(<tt>MSF_ARCRON</tt>)<br>
<a href="driver28.htm">Type 28</a> Shared Memory Driver
(<tt>SHM</tt>)<br>
<a href="driver29.htm">Type 29</a> Trimble Navigation Palisade GPS
(<tt>GPS_PALISADE</tt>)<br>
<a href="driver30.htm">Type 30</a> Motorola UT Oncore GPS
(<tt>GPS_ONCORE</tt>)<br>
Type 31 Rockwell Jupiter GPS (<tt>GPS_JUPITER</tt>)<br>
<a href="driver32.htm">Type 32</a> Chrono-log K-series WWVB
receiver <a href="driver33.htm">Type 33</a> Dumb Clock <a href=
"driver34.htm">Type 34</a> Ultralink WWVB Receivers<br>
<a href="driver35.htm">Type 35</a> Conrad Parallel Port Radio Clock
(<tt>PCF</tt>)<br>
<a href="driver36.htm">Type 36</a> Radio WWV/H Audio
Demodulator/Decoder(<tt>WWV</tt>)<br>
<a href="driver37.htm">Type 37</a> Forum Graphic GPS Dating station
(<tt>FG</tt>)<br>
<a href="driver38.htm">Type 38</a> hopf GPS/DCF77 6021/komp for
Serial Line (<tt>HOPF_S</tt>)<br>
<a href="driver39.htm">Type 39</a> hopf GPS/DCF77 6039 for PCI-Bus
(<tt>HOPF_P</tt>)</p>
<p>* All TrueTime receivers are now supported by one driver, type
5. Types 15 and 25 will be retained only for a limited time and may
be reassigned in future.</p>
<p>Additional Information</p>
<p><a href="prefer.htm">Mitigation Rules and the <tt>prefer</tt>
Keyword</a><br>
<a href="rdebug.htm">Debugging Hints for Reference Clock
Drivers</a><br>
<a href="kern.htm">A Kernel Model for Precision Timekeeping</a><br>
<a href="ldisc.htm">Line Disciplines and Streams Drivers</a><br>
<a href="audio.htm">Reference Clock Audio Drivers</a><br>
<a href="pps.htm">Pulse-per-second (PPS) Signal Interfacing</a><br>
<a href="howto.htm">How To Write a Reference Clock Driver</a></p>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

421
contrib/ntp/html/release.htm
View File

@ -1,199 +1,290 @@
<HTML><HEAD><TITLE>
NTP Version 4 Release Notes
</TITLE></HEAD><BODY><H3>
NTP Version 4 Release Notes
</H3>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>NTP Version 4 Release Notes</title>
</head>
<body>
<h3>NTP Version 4 Release Notes</h3>
<IMG align=left SRC=pic/hornraba.gif> <i>Alice's Adventures in
Wonderland</i>, by Lewis Carroll, illustrations by Sir John Tenniel
<BR clear=left><HR>
<img align="left" src="pic/hornraba.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
Adventures in Wonderland</i>, Lewis Carroll</a>
<H4>NTP Version 4 Release Notes</H4>
<p>The rabbit toots to make sure you read this.<br clear="left">
</p>
This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates
new features and refinements to the NTP Version 3 (NTPv3) algorithms.
However, it continues the tradition of retaining backwards compatibility
with older versions. The NTPv4 version has been under development for
quite a while and isn't finished yet. In fact, quite a number of NTPv4
features have already been implemented in the current NTPv3. The primary
purpose of this release is to verify the remaining new code compiles and
runs in the various architectures, operating systems and hardware
complement that can't be verified here. Of particular interest are
Windows NT, VMS and various reference clock drivers. As always,
corrections and bugfixes are warmly received, especially in the form of
context diffs.
<hr>
<p>This document was last updated 4 May 2001</p>
<P>This note summarizes the differences between this software release of
NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called
xntp3-5.x.x
<h4>NTP Version 4 Release Notes</h4>
<OL>
<p>This release of the NTP Version 4 (NTPv4) daemon for Unix, VMS
and Windows (NT4 and 2000) incorporates new features and
refinements to the NTP Version 3 (NTPv3) algorithms. However, it
continues the tradition of retaining backwards compatibility with
older versions, except for symmetric mode in NTPv1. Client/server
mode continues to be supported in NTPv1. The NTPv4 version has been
under development for quite a while and isn't finished yet. In
fact, quite a number of NTPv4 features have already been
retrofitted in the current NTPv3, although this version is not
actively maintained by the NTPv4 developer's group.</p>
<P><LI>Most of the extensive calculations are now done using 64-bit
floating-point format, rather than 64-bit fixed-point format. The
motivation for this is to reduce size, improve speed and avoid messy
bounds checking. Workstations of today are much faster than when the
original NTP version was designed in the early 1980s, and it is rare to
find a processor architecture that does not support it. The fixed-point
format is still used with raw timestamps, in order to retain the full
precision of about 212 picoseconds. However, the algorithms which
process raw timestamps all produce fixed-point differences before
converting to double. The differences are ordinarily quite small
so can be expressed without loss of accuracy in double format.</LI>
<p>The primary purpose of this release is to verify the remaining
new code compiles and runs in the various architectures, operating
systems and hardware complement that can't be verified here. Of
particular interest are Windows 2000, VMS and various reference
clock drivers. As always, corrections and bugfixes are warmly
received, especially in the form of context diffs.</p>
<P><LI>The clock discipline algorithm has been redesigned to improve
accuracy, reduce the impact of network jitter and allow an increase in
poll intervals to well over one day with only moderate sacrifice in
accuracy. The NTPv4 design allows servers to increase the poll intervals
even when synchronized directly to the peer. In NTPv3 the poll interval
in such cases was clamped to the minimum, usually 64 s. For those
servers with hundreds of clients, the new design can dramatically reduce
the network load.</LI>
<p>This note summarizes the differences between this software
release of NTPv4, called ntp-4.x.x, and the previous NTPv3 version,
called xntp3-5.x.x. Additional information on protocol
compatibility details is in the <a href="biblio.htm">Protocol
Conformance Statement</a> page.</p>
<P><LI>A <A HREF=assoc.htm>burst-mode</A> feature is available which
results in good accuracy with intermittent connections typical of PPP
and ISDN services. When enabled, at each poll interval the server sends
eight messages over the next 30-s interval and processes them in a
batch. Outlyers due to initial dial-up delays, etc., are avoided and the
server synchronizes with its peer generally within 30 s.</LI>
<ol>
<li>
<p>Most calculations are now done using 64-bit floating double
format, rather than 64-bit fixed point format. The motivation for
this is to reduce size, improve speed and avoid messy bounds
checking. Workstations of today are much faster than when the
original NTP version was designed in the early 1980s, and it is
rare to find a processor architecture that does not support
floating double. The fixed point format is still used with raw
timestamps, in order to retain the full precision of about 212
picoseconds. However, the algorithms which process raw timestamps
all produce fixed point differences before converting to floating
double. The differences are ordinarily quite small so can be
expressed without loss of accuracy in this format.</p>
</li>
<P><LI>In addition to the NTPv3 authentication scheme, which uses
private-key cryptography, a new NTPv4 <A HREF=authopt.htm>autokey
</A>authentication scheme is available. Autokey uses public-key
technology and avoids the need to distribute keys by separate means. The
design is such that full accuracy is available without degradation due
to processing demands of the public-key routines. It can be used in any
of the NTP association modes, but is most useful in broadcast/multicast
modes.</LI>
<li>
<p>The clock discipline algorithm has been redesigned to improve
accuracy, reduce the impact of network jitter and allow an increase
in poll intervals to well over one day with only moderate sacrifice
in accuracy. The NTPv4 design allows servers to increase the poll
intervals even when synchronized directly to the peer. In NTPv3 the
poll interval in such cases was clamped to the minimum, usually 64
s. For those servers with hundreds of clients, the new design can
dramatically reduce the network load.</p>
</li>
<P><LI>NTPv4 includes two new association modes which in most
applications can avoid per-host configuration altogether. Both of these
are based on multicast technology. They provide for automatic discovery
and configuration of servers and clients. In <A HREF=assoc.htm>multicast
</A>mode, a server sends a message at fixed intervals using specified
multicast addresses, while clients listen on these addresses. Upon
receiving the message, a client exchanges several messages with the
server in order to calibrate the multicast propagation delay between the
client and server. In <A HREF=assoc.htm>manycast </A>mode, a client
sends a message and expects one or more servers to reply. Using
engineered algorithms, the client selects an appropriate subset of
servers from the messages received and continues in ordinary
client/server operation with them. The manycast scheme can provide
<li>
<p>This release includes support for the <a href=
"http://www.eecis.udel.edu/~mills/resource.htm"><i>
nanokernel</i></a> precision time kernel support, which is now in
stock Linux and FreeBSD kernels. If a precision time source such as
a GPS timing receiver or cesium clock is available, kernel
timekeeping can be improved to the order less than one microsecond.
The older precision time kernel for the Alpha continues to be
supported.</p>
</li>
<li>
<p>This release includes support for Autokey public-key
cryptography, which is the preferred scheme for authenticating
servers to clients. It uses NTP header extensions fields documented
in: Mills, D.L. Public-Key cryptography for the Network Time
Protocol. Internet Draft draft-ietf-stime-ntpauth-00.txt,
University of Delaware, June 2000, 36 pp. <a href=
"http://www.eecis.udel.edu/~mills/database/memos/draft-ietf-stime-ntpauth-00.txt">
ASCII</a> and implemented in this release. The design provides for
orderly key refreshment and does not require public keys and
related media to be copied from one machine to another. Specific
information about Autokey cryptography is contained in the <a href=
"authopt.htm">Authentication Options</a> page and links from
there.</p>
</li>
<li>
<p>NTPv4 includes two new association modes which in most
applications can avoid per-host configuration altogether. Both of
these are based on IP multicast technology and Autokey
cryptography. They provide for automatic discovery and
configuration of servers and clients without identifying servers or
clients in advance. In multicast mode a server sends a message at
fixed intervals using specified multicast group addresses, while
clients listen on these addresses. Upon receiving the message, a
client exchanges several messages with the server in order to
calibrate the multicast propagation delay between the client and
server. In manycast mode a client sends a message to a specified
multicast group address and expects one or more servers to reply.
Using engineered algorithms, the client selects an appropriate
subset of servers from the messages received and continues in
ordinary client/server operation. The manycast scheme can provide
somewhat better accuracy than the multicast scheme at the price of
additional network overhead.</LI>
additional network overhead. See the <a href="assoc.htm">
Association Management</a> page for further information.</p>
</li>
<P><LI>The reference clock driver interface is smaller, more rational
and moreaccurate. Support for pulse-per-second (PPS) signals has been
extended to all drivers as an intrinsic function. Most of the drivers in
NTPv3 have been converted to this interface, but some, including the
PARSE subinterface, have yet to be overhauled. New drivers have been
added for several GPS receivers now on the market. Drivers for the
Canadian standard time and frequency station CHU and for audio IRIG
signals have been updated and capabilites added to allow direct
connection of these signals to the Sun audio port
<TT>/dev/audio</TT>.</LI>
<li>
<p>There are two burst mode features available where special
conditions apply. One of these is enabled by the <tt>iburst</tt>
keyword in the <tt>server</tt> configuration command. It is
intended for cases where it is important to set the clock quickly
when an association is first mobilized. The other is enabled by the
<tt>burst</tt> keyword in the <tt>server</tt> configuration
command. It is intended for cases where the network attachment
requires an initial calling or training procedure. See the <a href=
"assoc.htm">Association Management</a> page for further
information.</p>
</li>
<P><LI>In all except a very few cases, all timing intervals are
randomized, so that the tendency for NTPv3 to bunch messages, especially
with a large number of configured associations, is minimized.</LI>
<li>
<p>The reference clock driver interface is smaller, more rational
and more accurate. Support for pulse-per-second (PPS) signals has
been extended to all drivers as an intrinsic function. Most of the
drivers in NTPv3 have been converted to this interface, but some,
including the PARSE subinterface, have yet to be overhauled. New
drivers have been added for several GPS receivers now on the market
for a total of 39 drivers. Drivers for the Canadian standard time
and frequency station CHU, the US standard time and frequency
stations WWV/H and for IRIG signals have been updated and
capabilities added to allow direct connection of these signals to
the Sun audio port <tt>/dev/audio</tt>.</p>
</li>
<P><LI>In NTPv3 a large number of weeds and useless code had grown over
the years since the original NTPv1 code was implemented almost ten years
ago. Using a powerful weedwacker, much of the shrubbery has been
removed, with effect a substantial reduction in size of almost 40
percent.</LI>
<li>
<p>In all except a very few cases, all timing intervals are
randomized, so that the tendency for NTPv3 to self-synchronize and
bunch messages, especially with a large number of configured
associations, is minimized.</p>
</li>
<P><LI>The entire distribution has been converted to <TT>gnu
automake</TT>, which should greatly ease the task of porting to new and
different programming environments, as well as reduce the incidence of
bugs due to improper handling of idiosyncratic kernel functions.</LI>
</OL>
<li>
<p>In NTPv3 a large number of weeds and useless code had grown over
the years since the original NTPv1 code was implemented almost
twenty years ago. Using a powerful weedwacker, much of the
shrubbery has been removed, with effect a substantial reduction in
size of almost 40 percent.</p>
</li>
<H4>Nasty Surprises</H4>
<li>
<p>The entire distribution has been converted to gnu <tt>
automake</tt>, which should greatly ease the task of porting to new
and different programming environments, as well as reduce the
incidence of bugs due to improper handling of idiosyncratic kernel
functions.</p>
</li>
</ol>
There are a few things different about this release that have changed
since the latest NTP Version 3 release. Following are a few things to
worry about:
<h4>Nasty Surprises</h4>
<OL>
<p>There are a few things different about this release that have
changed since the latest NTP Version 3 release. Following are a few
things to worry about:</p>
<P><LI>As required by Defense Trade Regulations (DTR), the cryptographic
routines supporting the Data Encryption Standard (DES) has been removed
from the export version of the distribtution. These routines are readily
available in most countries from RSA Laboratories. Directions for their
use are in the <A HREF=build.htm>Building and Installing the
Distribution</A> page.</LI>
<ol>
<li>
<p>As required by Defense Trade Regulations (DTR), the
cryptographic routines supporting the Data Encryption Standard
(DES) have been removed from the base distribution. These routines
are readily available in most countries from RSA Laboratories.
Directions for their use are in the <a href="build.htm">Building
and Installing the Distribution</a> page.</p>
</li>
<P><LI>As the result of the above, the <TT>./authstuff</TT> directory,
<li>
<p>As the result of the above, the <tt>./authstuff</tt> directory,
intended as a development and testing aid for porting cryptographic
routines to exotic architectures, has been removed. Developers should
note the NTP authentication routines use the interface defined in the
<TT>rsaref2.0</TT> package available from RSA laboratories.</LI>
routines to exotic architectures, has been removed. Developers
should note the NTP authentication routines use the interface
defined in the <tt>rsaref2.0</tt> package available from RSA
laboratories.</p>
</li>
<P><LI>The enable and disable commands have a few changes in their
arguments see the <TT>ntpd</TT> <A HREF=confopt.htm>Configuration
Options</A> page for details.</LI>
<li>
<p>The enable and disable commands have a few changes in their
arguments see the <tt>ntpd</tt> <a href="confopt.htm">Configuration
Options</a> page for details. Note that the <tt>authenticate</tt>
command has been removed.</p>
</li>
<P><LI>The scheme for enabling the <TT>ppsclock</TT> line
discipline/streams module has changed. Formerly, it was enabled by
setting f<TT>udge flag3</TT> for the serial port connected to the PPS
signal. Now, there is an explicit command <TT>pps</TT> used to designate
the device name. See the <A HREF=clockopt.htm>Reference Clock
Options</A> page for details.</LI>
<li>
<p>The <tt>ppsclock</tt> line discipline/streams module is no
longer supported. This function is now handled by the <a href=
"driver22.htm">PPS Clock Discipline</a> driver, which uses the new
PPSAPI application program interface proposed by the IETF. Note
that the <tt>pps</tt> configuration file command has been obsoleted
by the driver. See the <a href="pps.htm">Pulse-per-second (PPS)
Signal Interfacing</a> page for further information.</p>
</li>
<P><LI>While in fact not a new problem, some obscure option combinations
require the <TT>server</TT> and <TT>peer</TT> commands to follow the
others; in particular, the <TT>enable</TT> and <TT>pps</TT> commands
should preceed these commands.</LI>
<li>
<p>Several new options have been added for the <tt>ntpd</tt>
command line. For the inveterate knob twiddlers several of the more
important performance variables can be changed to fit actual or
perceived special conditions. It is possible to operate the daemon
in a one-time mode similar to <tt>ntpdate</tt>, which program is
headed for retirement. See the <a href="ntpd.htm"><tt>ntpd</tt> -
Network Time Protocol (NTP) daemon</a> page for the new
features.</p>
</li>
</OL>
<li>
<p>To help reduce the level of spurious network traffic due to
obsolete configuration files, a special control message called the
kiss-of-death packet has been implemented. If enabled and a packet
is denied service or exceeds the client limie, a compliant server
will send this message to the client. A compliant client will cease
further transmission and send a message to the system log. See the
<a href="accopt.htm">Authentication Options</a> page for further
information.</p>
</li>
<H4>Caveats</H4>
<li>
<p>An experimental filter algorithm called huff-n'-puff has been
implemented to reduce errors under conditions of severe assymetric
delays characteristic of <tt>ppp</tt> connections with telephone
modems and downloading or uploading considerable traffic. See the
<a href="ntpd.htm">ntpd - Network Time Protocol (NTP) daemon</a>
page for further information.</p>
</li>
</ol>
This release has been compiled and tested on several systems, including
SunOS 4.1.3, Solaris 2.5.1 and 2.6, Alpha 4.0, Ultrix 4.4, Linux,
FreeBSD and HP-UX 10.02. It has not been compiled for Windows NT or VMS.
We are relying on the NTP volunteer brigade to do that. Known problems
are summarized below:
<h4>Caveats</h4>
<OL>
<p>This release has been compiled and tested on several systems,
including SunOS 4.1.3, Solaris 2.5.1-2.8, Alpha 4.0, Ultrix 4.4,
Linux, FreeBSD and HP-UX 10.02. It has been compiled and tested on
Windows NT, but not yet on any other Windows version or for VMS. We
are relying on the NTP volunteer corps to do that. Known problems
are summarized below:</p>
<P><LI>To work properly in all cases, the <TT>enable</TT> and
<TT>pps</TT> commands, if used, should appear before the <TT>server</TT>
and <TT>fudge</TT> commands in the configuration file.</LI>
<ol>
<li>
<p>The latest NTPv4 <tt>ntpdc</tt> does not work with previous
versions of <tt>ntpd</tt> and previous versions of <tt>ntpdc</tt>
do not work with latest <tt>ntpd</tt>. This situation is
regrettable and may be fixed in future; however, it is necessary in
order for the autokey function to retrieve canonical names and
certificates from directory services such as Secure DNS.</p>
</li>
<P><LI>The precision time kernel modifications now in stock Solaris 2.6
have bugs. The kernel discipline has been disabled by default. For
testing, the kernel can be enabled using the <TT>enable kernel</TT>
command either in the configuration file or via <TT>ntpdc</TT>.</LI>
<li>
<p>The precision time support in stock Solaris 2.6 has bugs that
were fixed in 2.7. A patch is available that fixes the 2.6 bugs.
The 2.6 kernel discipline has been disabled by default. For
testing, the kernel can be enabled using the <tt>enable kernel</tt>
command either in the configuration file or via <tt>ntpdc</tt>.</p>
</li>
<P><LI>On Alpha 4.0 with reference clocks configured, debugging with the
<TT>-d</TT> options doesn't work.</LI>
<li>
<p>The HTML documentation has been partially updated. However, most
of the NTPv3 documentation continues to apply to NTPv4. Until the
update happens, what you see is what you get. We are always happy
to accept comments, corrections and bug reports. However, we are
most thrilled upon receipt of patches to fix the dang bugs.</p>
</li>
</ol>
<P><LI>The autokey function requires an NTP header extensions field,
which is documented in an internet draft and implemented in this
release. This field holds the public-key signature and certificate;
however, the detailed format for these data have not yet been
determined. It is expected this will happen in the near future and that
implementation of the required algorithms will quickly follow using
available cryptographic algorithms.</LI>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<P><LI>The manycast function still needs some work. Ideally, the
existing I/O routines would be enhanced to include the capability to
determine the source address on every multicast packet sent, so that the
autokey function could reliably construct the correct cryptosum.
Meanwhile, the utility of manycast in conjunction with autokey is
limited to clients with only a single network
interface.</LI>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
<P><LI>The HTML documentation has been partially updated. However, most
of the NTPv3 documentation continues to apply to NTPv4. Until the update
happens, what you see is what you get. We are always happy to accept
comments, corrections and bug reports. However, we are most thrilled
upon receipt of patches to fix the dang bugs.</LI>
</OL>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

166
contrib/ntp/html/tickadj.htm
View File

@ -1,107 +1,105 @@
<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>tickadj - set time-related kernel variables
</TITLE>
</HEAD>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>tickadj - set time-related kernel variables</title>
</head>
<body>
<h3><tt>tickadj</tt> - set time-related kernel variables</h3>
<H3>
<TT>tickadj</TT> - set time-related kernel variables</H3>
<hr>
<h4>Synopsis</h4>
<HR>
<H4>
Synopsis</H4>
<TT>tickadj [ -Aqs ] [ -a <I>tickadj</I> ] [ -t <I>tick</I> ]</TT>
<H4>
Description</H4>
The <TT>tickadj</TT> program reads, and optionally modifies, several timekeeping-related
variables in the running kernel, via <TT>/dev/kmem</TT>. The particular
variables it is concerned with are <TT>tick</TT>, which is the number of
microseconds added to the system time during a clock interrupt, <TT>tickadj</TT>,
which sets the slew rate and resolution used by the <TT>adjtime</TT> system
call, and <TT>dosynctodr</TT>, which indicates to the kernels on some machines
whether they should internally adjust the system clock to keep it in line
with time-of-day clock or not.
<tt>tickadj [ -Aqs ] [ -a <i>tickadj</i> ] [ -t <i>tick</i> ]</tt>
<P>We have a report that says starting with Solaris 2.6 we should
leave <I>dosynctodr</I> alone.
<A HREF="solaris-dosynctodr.html">Here is the report</A>.
<h4>Description</h4>
<P>By default, with no arguments, <TT>tickadj</TT> reads the variables
of interest in the kernel and displays them. At the same time, it determines
an "optimal" value for the value of the <TT>tickadj</TT> variable if the
intent is to run the <TT>ntpd</TT> Network Time Protocol (NTP) daemon,
and prints this as well. Since the operation of <TT>tickadj</TT> when reading
the kernel mimics the operation of similar parts of the <TT>ntpd</TT> program
fairly closely, this can be useful when debugging problems with <TT>ntpd</TT>.
The <tt>tickadj</tt> program reads, and optionally modifies,
several timekeeping-related variables in the running kernel in some
machines, via <tt>/dev/kmem</tt>. The particular variables it is
concerned with are <tt>tick</tt>, which is the number of
microseconds added to the system time during a clock interrupt,
<tt>tickadj</tt>, which sets the slew rate and resolution used by
the <tt>adjtime</tt> system call, and <tt>dosynctodr</tt>, which
indicates to the kernels on some machines whether they should
internally adjust the system clock to keep it in line with
time-of-day clock or not.
<P>Note that <TT>tickadj</TT> should be run with some caution when being
used for the first time on different types of machines. The operations
which <TT>tickadj</TT> tries to perform are not guaranteed to work on all
Unix machines and may in rare cases cause the kernel to crash.
<H4>
Command Line Options</H4>
<p>Note that this program does NOT work in some kernels, in
particular Solaris 2.6 or later. See the <a href=
"solaris-dosynctodr.html">report</a>.</p>
<DL>
<DT>
<TT>-a <I>tickadj</I></TT></DT>
<p>By default, with no arguments, <tt>tickadj</tt> reads the
variables of interest in the kernel and displays them. At the same
time, it determines an "optimal" value for the value of the <tt>
tickadj</tt> variable if the intent is to run the <tt>ntpd</tt>
Network Time Protocol (NTP) daemon, and prints this as well. Since
the operation of <tt>tickadj</tt> when reading the kernel mimics
the operation of similar parts of the <tt>ntpd</tt> program fairly
closely, this can be useful when debugging problems with <tt>
ntpd</tt>.</p>
<DD>
Set the kernel variable <TT>tickadj</TT> to the value <I><TT>tickadj</TT></I>
specified.</DD>
<p>Note that <tt>tickadj</tt> should be run with some caution when
being used for the first time on different types of machines. The
operations which <tt>tickadj</tt> tries to perform are not
guaranteed to work on all Unix machines and may in rare cases cause
the kernel to crash.</p>
<DT>
<TT>-A</TT></DT>
<h4>Command Line Options</h4>
<DD>
Set the kernel variable <TT>tickadj</TT> to an internally computed "optimal"
value.</DD>
<dl>
<dt><tt>-a <i>tickadj</i></tt></dt>
<DT>
<TT>-t <I>tick</I></TT></DT>
<dd>Set the kernel variable <tt>tickadj</tt> to the value <i><tt>
tickadj</tt></i>specified.</dd>
<DD>
Set the kernel variable <TT>tick</TT> to the value <I><TT>tick</TT></I>
specified.</DD>
<dt><tt>-A</tt></dt>
<DT>
<TT>-s</TT></DT>
<dd>Set the kernel variable <tt>tickadj</tt> to an internally
computed "optimal" value.</dd>
<DD>
Set the kernel variable <TT>dosynctodr</TT> to zero, which disables the
hardware time-of-year clock, a prerequisite for running the <TT>ntpd</TT>
daemon under SunOS4.</DD>
<dt><tt>-t <i>tick</i></tt></dt>
<DT>
<TT>-q</TT></DT>
<dd>Set the kernel variable <tt>tick</tt> to the value <i><tt>
tick</tt></i> specified.</dd>
<DD>
Normally, <TT>tickadj</TT> is quite verbose about what it is doing. The
<TT>-q</TT> flag tells it to shut up about everything except errors.</DD>
</DL>
<dt><tt>-s</tt></dt>
<H4>
Files</H4>
<dd>Set the kernel variable <tt>dosynctodr</tt> to zero, which
disables the hardware time-of-year clock, a prerequisite for
running the <tt>ntpd</tt> daemon under SunOS4.</dd>
<PRE>
<dt><tt>-q</tt></dt>
<dd>Normally, <tt>tickadj</tt> is quite verbose about what it is
doing. The <tt>-q</tt> flag tells it to shut up about everything
except errors.</dd>
</dl>
<h4>Files</h4>
<pre>
/vmunix
/unix
/dev/kmem</PRE>
/dev/kmem
</pre>
<H4>
Bugs</H4>
Fiddling with kernel variables at run time as a part of ordinary operations
is a hideous practice which is only necessary to make up for deficiencies
in the implementation of <TT>adjtime</TT> in many kernels and/or brokenness
of the system clock in some vendors' kernels. It would be much better if
the kernels were fixed and the <TT>tickadj</TT> program went away.&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<h4>Bugs</h4>
Fiddling with kernel variables at run time as a part of ordinary
operations is a hideous practice which is only necessary to make up
for deficiencies in the implementation of <tt>adjtime</tt> in many
kernels and/or brokenness of the system clock in some vendors'
kernels. It would be much better if the kernels were fixed and the
<tt>tickadj</tt> program went away.&nbsp;
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>
</BODY>
</HTML>

7
contrib/ntp/include/Makefile.am
View File

@ -5,11 +5,13 @@ ETAGS_ARGS = $(srcdir)/Makefile.am
noinst_HEADERS = \
adjtime.h \
audio.h \
ascii.h \
audio.h \
binio.h \
global.h \
gps.h \
hopf6039.h \
icom.h \
ieee754io.h \
iosignal.h \
@ -20,7 +22,10 @@ noinst_HEADERS = \
ntif.h \
ntp.h \
ntp_calendar.h \
ntp_cmdargs.h \
ntp_config.h \
ntp_control.h \
ntp_crypto.h \
ntp_datum.h \
ntp_filegen.h \
ntp_fp.h \
@ -36,6 +41,7 @@ noinst_HEADERS = \
ntp_string.h \
ntp_syscall.h \
ntp_syslog.h \
ntp_tty.h \
ntp_types.h \
ntp_unixtime.h \
ntpd.h \
@ -44,3 +50,4 @@ noinst_HEADERS = \
recvbuff.h \
trimble.h

169
contrib/ntp/include/Makefile.in
View File

@ -1,6 +1,7 @@
# Makefile.in generated automatically by automake 1.4a from Makefile.am
# Makefile.in generated automatically by automake 1.4e from Makefile.am.
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
# Free Software Foundation, Inc.
# This Makefile.in 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.
@ -31,8 +32,6 @@ mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
@ -48,7 +47,7 @@ INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_FLAG =
INSTALL_HEADER = $(INSTALL_DATA)
transform = @program_transform_name@
NORMAL_INSTALL = :
@ -57,24 +56,30 @@ POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_alias = @build_alias@
build_triplet = @build@
host_alias = @host_alias@
host_triplet = @host@
target_alias = @target_alias@
target_triplet = @target@
@SET_MAKE@
AMDEP = @AMDEP@
AMTAR = @AMTAR@
AUTOKEY = @AUTOKEY@
AWK = @AWK@
CC = @CC@
CFLAGS = @CFLAGS@
CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CPP = @CPP@
CXX = @CXX@
CXXCPP = @CXXCPP@
DCFD = @DCFD@
DEPDIR = @DEPDIR@
EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
INSTALL_STRIP_PROGRAM_ENV = @INSTALL_STRIP_PROGRAM_ENV@
LDFLAGS = @LDFLAGS@
LIBPARSE = @LIBPARSE@
LIBRSAREF = @LIBRSAREF@
@ -86,16 +91,27 @@ MAKE_LIBPARSE = @MAKE_LIBPARSE@
MAKE_LIBPARSE_KERNEL = @MAKE_LIBPARSE_KERNEL@
MAKE_LIBRSAREF = @MAKE_LIBRSAREF@
MAKE_NTPTIME = @MAKE_NTPTIME@
MAKE_NTP_GENKEYS = @MAKE_NTP_GENKEYS@
MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
OPENSSL_LIB = @OPENSSL_LIB@
PACKAGE = @PACKAGE@
PATH_PERL = @PATH_PERL@
PATH_SH = @PATH_SH@
PROPDELAY = @PROPDELAY@
RANLIB = @RANLIB@
RSADIR = @RSADIR@
RSAOBJS = @RSAOBJS@
RSAREF = @RSAREF@
RSASRCS = @RSASRCS@
STRIP = @STRIP@
TESTDCF = @TESTDCF@
U = @U@
VERSION = @VERSION@
_am_include = @_am_include@
install_sh = @install_sh@
#AUTOMAKE_OPTIONS = ../util/ansi2knr no-dependencies
@ -107,11 +123,13 @@ ETAGS_ARGS = $(srcdir)/Makefile.am
noinst_HEADERS = \
adjtime.h \
audio.h \
ascii.h \
audio.h \
binio.h \
global.h \
gps.h \
hopf6039.h \
icom.h \
ieee754io.h \
iosignal.h \
@ -122,7 +140,10 @@ noinst_HEADERS = \
ntif.h \
ntp.h \
ntp_calendar.h \
ntp_cmdargs.h \
ntp_config.h \
ntp_control.h \
ntp_crypto.h \
ntp_datum.h \
ntp_filegen.h \
ntp_fp.h \
@ -138,6 +159,7 @@ noinst_HEADERS = \
ntp_string.h \
ntp_syscall.h \
ntp_syslog.h \
ntp_tty.h \
ntp_types.h \
ntp_unixtime.h \
ntpd.h \
@ -146,28 +168,29 @@ noinst_HEADERS = \
recvbuff.h \
trimble.h
EXEEXT =
OBJEXT = o
subdir = include
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_HEADER = ../config.h
CONFIG_CLEAN_FILES =
DIST_SOURCES =
HEADERS = $(noinst_HEADERS)
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
DIST_SOURCES =
HEADERS = $(noinst_HEADERS)
DIST_COMMON = README $(noinst_HEADERS) Makefile.am Makefile.in
DIST_COMMON = README $(noinst_HEADERS) Makefile.am Makefile.in
all: all-am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --gnu include/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status $(BUILT_SOURCES)
cd $(top_builddir) \
&& CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && \
$(AUTOMAKE) --gnu include/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) && \
CONFIG_HEADERS= CONFIG_LINKS= \
CONFIG_FILES=$(subdir)/$@ $(SHELL) ./config.status
tags: TAGS
@ -178,9 +201,9 @@ ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
mkid -f$$here/ID $$unique $(LISP)
mkid -fID $$unique $(LISP)
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
here=`pwd`; \
@ -193,53 +216,50 @@ TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
|| etags $(ETAGS_ARGS) $$tags $$unique $(LISP)
mostlyclean-tags:
clean-tags:
GTAGS:
here=`CDPATH=: && cd $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $$here
distclean-tags:
-rm -f TAGS ID
maintainer-clean-tags:
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
top_distdir = ..
distdir = $(top_distdir)/$(PACKAGE)-$(VERSION)
distdir: $(DISTFILES)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pR $$d/$$file $(distdir); \
cp -pR $$d/$$file $(distdir) \
|| exit 1; \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
|| cp -p $$d/$$file $(distdir)/$$file \
|| exit 1; \
fi; \
done
info-am:
info: info-am
dvi-am:
dvi: dvi-am
check-am: all-am
check: check-am
installcheck-am:
installcheck: installcheck-am
install-exec-am:
install-exec: install-exec-am
all-am: Makefile $(HEADERS)
install-data-am:
installdirs:
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-am
uninstall-am:
uninstall: uninstall-am
all-am: Makefile $(HEADERS)
all-redirect: all-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_STRIP_FLAG=-s install
installdirs:
installcheck: installcheck-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
INSTALL_PROGRAM_ENV='$(INSTALL_STRIP_PROGRAM_ENV)' install
mostlyclean-generic:
@ -250,33 +270,50 @@ distclean-generic:
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-rm -f Makefile.in
mostlyclean-am: mostlyclean-tags mostlyclean-generic
mostlyclean: mostlyclean-am
clean-am: clean-tags clean-generic mostlyclean-am
clean: clean-am
distclean-am: distclean-tags distclean-generic clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
maintainer-clean-am: maintainer-clean-tags maintainer-clean-generic \
distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
distclean-am: clean-am distclean-generic distclean-tags
dvi:
dvi-am:
info:
info-am:
install-data-am:
install-exec-am:
install-info:
install-man:
installcheck-am:
maintainer-clean: maintainer-clean-am
.PHONY: tags mostlyclean-tags distclean-tags clean-tags \
maintainer-clean-tags distdir info-am info dvi-am dvi check check-am \
installcheck-am installcheck install-exec-am install-exec \
install-data-am install-data install-am install uninstall-am uninstall \
all-redirect all-am all install-strip installdirs mostlyclean-generic \
distclean-generic clean-generic maintainer-clean-generic clean \
mostlyclean distclean maintainer-clean
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
.PHONY: all all-am check check-am clean clean-generic distclean \
distclean-generic distclean-tags distdir dvi dvi-am info \
info-am install install-am install-data install-data-am \
install-exec install-exec-am install-info install-man \
install-strip installcheck installcheck-am installdirs \
maintainer-clean maintainer-clean-generic mostlyclean \
mostlyclean-generic tags uninstall uninstall-am
# Tell versions [3.59,3.63) of GNU make to not export all variables.

2
contrib/ntp/include/audio.h
View File

@ -8,6 +8,6 @@
/*
* Function prototypes
*/
int audio_init P((void));
int audio_init P((char *));
int audio_gain P((int, int));
void audio_show P((void));

3
contrib/ntp/include/global.h
View File

@ -30,6 +30,9 @@ typedef unsigned short int UINT2;
/* UINT4 defines a four byte word */
typedef u_int32 UINT4; /* local modification */
/* BYTE defines a unsigned character */
typedef unsigned char BYTE; /* local modification for RSAEuro */
#ifndef NULL_PTR
#define NULL_PTR ((POINTER)0)
#endif

144
contrib/ntp/include/hopf6039.h Normal file
View File

@ -0,0 +1,144 @@
/****************************************************************************/
/* hopf6039.h */
/* hopf Elektronik 6039 PCI radio clock header */
/* (c) 1999, 2000 Bernd Altmeier <altmeier@ATLSoft.de> */
/* Rev. 1.00 Date 25.03.2000 */
/* History: */
/****************************************************************************/
#ifndef _hopf6039_H_
#define _hopf6039_H_
#define HOPF_MAXVERSION 8
#define HOPF_CNTR_MEM_LEN 0x7f
#define HOPF_DATA_MEM_LEN 0x3ff /* this is our memory size */
/* macros and definition for 32 to 16 to 8 bit conversion */
typedef unsigned long DWORD;
typedef unsigned char BYTE;
typedef unsigned short WORD;
#define LOWORD(l) ((WORD)(l))
#define HIWORD(l) ((WORD)(((DWORD)(l) >> 16) & 0xFFFF))
#define LOBYTE(w) ((BYTE)(w))
#define HIBYTE(w) ((BYTE)(((WORD)(w) >> 8) & 0xFF))
/* iocntl codes for driver access */
#define HOPF_CLOCK_CMD_MASK 0xff000
#define HOPF_CLOCK_GET_LOCAL 0x10000
#define HOPF_CLOCK_GET_UTC 0x20000
#define HOPF_CLOCK_GET_ANTENNA 0x30000
#define HOPF_CLOCK_GET_DIFFERENCE 0x40000
#define HOPF_CLOCK_GET_VERSION 0x50000
#define HOPF_CLOCK_GET_POSITION 0x60000
#define HOPF_CLOCK_GET_SATDATA 0x70000
#define HOPF_CLOCK_GET_SYSTEMBYTE 0x80000
#define HOPF_CLOCK_GET_IRIG 0x90000
#define HOPF_CLOCK_SET_DIFFERENCE 0x01000
#define HOPF_CLOCK_SET_ANTENNA 0x02000
#define HOPF_CLOCK_SET_TIME 0x03000
#define HOPF_CLOCK_SET_POSITION 0x04000
#define HOPF_CLOCK_SET_SATMODE 0x05000
#define HOPF_CLOCK_SET_SYSTEMBYTE 0x06000
#define HOPF_CLOCK_SET_RESET 0x07000
#define HOPF_CLOCK_SET_IRIG 0x08000
/* clock command codes */
#define HOPF_CLOCK_HARDRESET 0x00008000
#define HOPF_CLOCK_SOFTRESET 0x00004000
/* sat-information */
typedef struct SatStat{
BYTE wVisible;
BYTE wMode;
BYTE wSat0;
BYTE wRat0;
BYTE wSat1;
BYTE wRat1;
BYTE wSat2;
BYTE wRat2;
BYTE wSat3;
BYTE wRat3;
BYTE wSat4;
BYTE wRat4;
BYTE wSat5;
BYTE wRat5;
BYTE wSat6;
BYTE wRat6;
BYTE wSat7;
BYTE wRat7;
} SatStat;
/* GPS position */
typedef struct GPSPos { /* Position */
long wAltitude;
long wLongitude;
long wLatitude;
} GPSPos;
/* clock hardware version */
typedef struct ClockVersion {
char cVersion[255]; /* Hardware Version like " DCF-RECEIVER, VERSION 01.01, DAT: 23.NOV.1999" */
char dVersion[255]; /* Driver Version */
} ClockVersion;
/* hopftime what you think */
typedef struct HOPFTIME {
unsigned int wYear;
unsigned int wMonth;
unsigned int wDayOfWeek;
unsigned int wDay;
unsigned int wHour;
unsigned int wMinute;
unsigned int wSecond;
unsigned int wMilliseconds;
unsigned int wStatus;
} HOPFTIME;
/* DCF77 antenna alignment */
typedef struct DcfAntenne {
BYTE bStatus;
BYTE bStatus1;
WORD wAntValue;
} DcfAntenne;
/* hopf PCI clock */
typedef struct hopfCard {
char name[32];
unsigned irq;
unsigned long membase; /* without mmap */
unsigned int port;
int versionlen;
char versionbuf[1024];
char *version[HOPF_MAXVERSION];
char cardname[32];
int interrupt;
void *mbase; /* this will be our memory base address */
} hopfCard;
typedef struct cardparams {
unsigned int port;
unsigned irq;
int cardtype;
int cardnr;
unsigned int membase;
} cardparams;
#define WRITE_REGISTER 0x00
#define READ_REGISTER 0x01
#endif /* _hopf6039_H_ */

9
contrib/ntp/include/l_stdlib.h
View File

@ -57,6 +57,10 @@ extern int cfsetospeed P((struct termios *, speed_t));
extern char * getpass P((const char *));
#ifdef DECL_HSTRERROR_0
extern const char * hstrerror P((int));
#endif
#ifdef DECL_INET_NTOA_0
struct in_addr;
extern char * inet_ntoa P((struct in_addr));
@ -136,6 +140,11 @@ struct sigvec;
extern int sigvec P((int, struct sigvec *, struct sigvec *));
#endif
#ifndef HAVE_SNPRINTF
/* PRINTFLIKE3 */
extern int snprintf P((char *, size_t, const char *, ...));
#endif
#ifdef DECL_SRAND48_0
extern void srand48 P((long));
#endif

609
contrib/ntp/include/ntp.h
View File

@ -8,58 +8,64 @@
#include "ntp_types.h"
#include <math.h>
/* common definitions for Y2K repairs [ Y2KFixes */
/*
* Calendar arithmetic - contributed by G. Healton
*/
#define YEAR_BREAK 500 /* years < this are tm_year values:
* Break < AnyFourDigitYear && Break >
* Anytm_yearYear */
/* (this might better be put in ntp_calendar.h) */
#define YEAR_BREAK 500 /* assume years < this are tm_year values: */
/* Break < AnyFourDigitYear
&& Break > Anytm_yearYear */
#define YEAR_PIVOT 98 /* 97/98: assume years < this are year 2000+ */
/* FYI: official UNIX pivot year is 68/69 */
#define YEAR_PIVOT 98 /* 97/98: years < this are year 2000+
* FYI: official UNIX pivot year is
* 68/69 */
/* Number of Days since (mythical) 1.BC Gregorian to 1 January of given year*/
#define julian0(year) \
( \
( (year) * 365 ) + ( (year) > 0 \
? ( ((year)+3) / 4 - ((year-1) / 100) + ((year-1) / 400) ) \
: 0 ) \
)
/*
* Number of Days since 1 BC Gregorian to 1 January of given year
*/
#define julian0(year) (((year) * 365 ) + ((year) > 0 ? (((year) + 3) \
/ 4 - ((year - 1) / 100) + ((year - 1) / \
400)) : 0))
/* Number of days since start of NTP time to 1 January of given year */
#define ntp0(year) ( julian0(year) - julian0(1900) )
/*
* Number of days since start of NTP time to 1 January of given year
*/
#define ntp0(year) (julian0(year) - julian0(1900))
/* Number of days since start of UNIX time to 1 January of given year */
#define unix0(year) ( julian0(year) - julian0(1970) )
/*
* Number of days since start of UNIX time to 1 January of given year
*/
#define unix0(year) (julian0(year) - julian0(1970))
/* LEAP YEAR test for full 4-digit years (e.g, 1999, 2010) */
#define isleap_4(y) /* a TRUE and PROPER leap year test */ \
((y)%4 == 0 && !((y)%100 == 0 && !(y%400 == 0)))
/* NOTE: year 2000 TRULY IS A LEAP YEAR!!! */
/*
* LEAP YEAR test for full 4-digit years (e.g, 1999, 2010)
*/
#define isleap_4(y) ((y) % 4 == 0 && !((y) % 100 == 0 && !(y % \
400 == 0)))
/* LEAP YEAR test for tm_year (struct tm) years (e.g, 99, 110) */
#define isleap_tm(y) /* a TRUE and PROPER leap year test */ \
((y)%4 == 0 && !((y)%100 == 0 && !(((y)+1900)%400 == 0)))
/*
* LEAP YEAR test for tm_year (struct tm) years (e.g, 99, 110)
*/
#define isleap_tm(y) ((y) % 4 == 0 && !((y) % 100 == 0 && !(((y) \
+ 1900) % 400 == 0)))
/* to convert simple two-digit years to tm_year style years:
if ( year < YEAR_PIVOT ) year += 100;
* to convert either two-digit OR tm_year years to four-digit years:
if ( year < YEAR_PIVOT ) year += 100;
if ( year < YEAR_BREAK ) year += 1900;
CALL TO STANDARD:
* As the Internet is an INTERNATIONAL network, it makes SENSE to use
the international standard ISO 8601 to format dates and times.
Basically this is yyyy-mm-dd for years and hh:mm:ss for times
(joining the two togeather in computer readable media calls for
yyyy-mm-ddThh:mm:ss, though yyyy-mm-dd hh:mm:ss is often used
for human readable forms even though it is not not strictly
valid ISO 8601). Standard time-zone offsets ([+-]hh:mm) are allowed.
ghealton ] Y2KFixes */
/*
* to convert simple two-digit years to tm_year style years:
*
* if (year < YEAR_PIVOT)
* year += 100;
*
* to convert either two-digit OR tm_year years to four-digit years:
*
* if (year < YEAR_PIVOT)
* year += 100;
*
* if (year < YEAR_BREAK)
* year += 1900;
*/
/*
* How to get signed characters. On machines where signed char works,
* use it. On machines where signed char doesn't work, char had better
* use it. On machines where signed char doesn't work, char had better
* be signed.
*/
#ifdef NEED_S_CHAR_TYPEDEF
@ -87,37 +93,34 @@ typedef char s_char;
#define NTP_VERSION ((u_char)4) /* current version number */
#define NTP_OLDVERSION ((u_char)1) /* oldest credible version */
#define NTP_PORT 123 /* included for sake of non-unix machines */
#define NTP_MAXSTRATUM ((u_char)15) /* max stratum, infinity a la Bellman-Ford */
#define NTP_MAXAGE 86400 /* one day in seconds */
#define NTP_UNREACH 16 /* poll interval backoff count */
#define NTP_MINDPOLL 6 /* log2 default min poll interval (64 s) */
#define NTP_MAXDPOLL 10 /* log2 default max poll interval (~17 m) */
#define NTP_MINPOLL 4 /* log2 min poll interval (16 s) */
#define NTP_MAXPOLL 17 /* log2 max poll interval (~4.5 h) */
#define NTP_MINCLOCK 3 /* minimum survivors */
#define NTP_CANCLOCK 6 /* minimum candidates */
#define NTP_MAXCLOCK 10 /* maximum candidates */
#define NTP_WINDOW 8 /* reachability register size */
#define NTP_SHIFT 8 /* 8 suitable for crystal time base */
#define NTP_MAXKEY 65535 /* maximum authentication key number */
#define NTP_MAXSESSION 100 /* maximum entries on session key list */
#define NTP_AUTOMAX 12 /* log2 default max session key lifetime */
#define NTP_MAXSESSION 100 /* maximum session key list entries */
#define NTP_AUTOMAX 13 /* log2 default max session key lifetime */
#define KEY_REVOKE 16 /* log2 default key revoke timeout */
#define NTP_FWEIGHT .5 /* clock filter weight */
#define NTP_SWEIGHT .75 /* select weight */
#define CLOCK_SGATE 10. /* popcorn spike gate */
#define CLOCK_SGATE 4. /* popcorn spike gate */
#define BURST_INTERVAL1 4 /* first interburst interval (log2) */
#define BURST_INTERVAL2 1 /* succeeding interburst intervals (log2) */
#define HUFFPUFF 900 /* huff-n'-puff sample interval (s) */
/*
* Operations for jitter (variance) calculations (these use doubles).
* Note that we carefully separate the jitter component from the dispersion
* component (frequency error plus precision). The frequency error
* component is computed as CLOCK_PHI times the difference between the epoch
* of the time measurement and the reference time. The precision componen
* is computed as the square root of the mean of the squares of a zero-
* mean, uniform distribution of unit maximum amplitude. Whether this
* makes statistical sense may be arguable.
* Operations for jitter calculations (these use doubles).
*
* Note that we carefully separate the jitter component from the
* dispersion component (frequency error plus precision). The frequency
* error component is computed as CLOCK_PHI times the difference between
* the epoch of the time measurement and the reference time. The
* precision componen is computed as the square root of the mean of the
* squares of a zero-mean, uniform distribution of unit maximum
* amplitude. Whether this makes statistical sense may be arguable.
*/
#define SQUARE(x) ((x) * (x))
#define SQRT(x) (sqrt(x))
@ -130,16 +133,49 @@ typedef char s_char;
#define MINDISPERSE .01 /* min dispersion */
#define MAXDISTANCE 1. /* max root distance */
/*
* Loop filter parameters. See section 5.1 of the specification.
*
* Note that these are appropriate for a crystal time base. If your
* system clock is line frequency controlled you should read the
* specification for appropriate modifications.
*/
#define CLOCK_PHI 15e-6 /* max frequency wander */
#define EVENT_TIMEOUT 0 /* one second, that is */
#define EVENT_TIMEOUT 0 /* one second, that is */
#ifdef AUTOKEY
/*
* The following structures are used in the autokey protocol.
*
* The autokey structure holds the values used to authenticate key IDs.
*/
struct autokey { /* network byte order */
tstamp_t tstamp; /* timestamp */
keyid_t key; /* key ID */
int32 seq; /* key number */
u_int32 siglen; /* signature length */
u_int32 pkt[1]; /* start of signature field */
u_char *sig; /* signature */
};
/*
* The cookie structure holds the current private value used to
* construct session keys.
*/
struct cookie { /* network byte order */
tstamp_t tstamp; /* timestamp */
keyid_t key; /* key ID */
u_int32 siglen; /* signature length */
u_int32 pkt[1]; /* start of signature field */
u_char *sig; /* signature */
};
/*
* The value structure holds variable length data such as public
* key, agreement parameters, public valule and leapsecond table.
*/
struct value { /* network byte order */
tstamp_t tstamp; /* timestamp */
tstamp_t fstamp; /* filestamp */
u_int32 vallen; /* value length */
u_int32 pkt[1]; /* start of value field */
u_char *ptr; /* data pointer */
u_int32 siglen; /* signature length */
u_char *sig; /* signature */
};
#endif /* AUTOKEY */
/*
* The interface structure is used to hold the addresses and socket
@ -149,8 +185,8 @@ struct interface {
int fd; /* socket this is opened on */
int bfd; /* socket for receiving broadcasts */
struct sockaddr_in sin; /* interface address */
struct sockaddr_in bcast; /* broadcast address */
struct sockaddr_in mask; /* interface mask */
struct sockaddr_in bcast; /* broadcast address */
struct sockaddr_in mask; /* interface mask */
char name[8]; /* name of interface */
int flags; /* interface flags */
int last_ttl; /* last TTL specified */
@ -168,7 +204,7 @@ struct interface {
#define INT_MULTICAST 8 /* multicasting enabled */
/*
* Define flasher bits (tests 1 through 8 in packet procedure)
* Define flasher bits (tests 1 through 11 in packet procedure)
* These reveal the state at the last grumble from the peer and are
* most handy for diagnosing problems, even if not strictly a state
* variable in the spec. These are recorded in the peer structure.
@ -176,102 +212,141 @@ struct interface {
#define TEST1 0x0001 /* duplicate packet received */
#define TEST2 0x0002 /* bogus packet received */
#define TEST3 0x0004 /* protocol unsynchronized */
#define TEST4 0x0008 /* peer delay/dispersion bounds check */
#define TEST5 0x0010 /* peer authentication failed */
#define TEST4 0x0008 /* access denied */
#define TEST5 0x0010 /* authentication failed */
#define TEST6 0x0020 /* peer clock unsynchronized */
#define TEST7 0x0040 /* peer stratum out of bounds */
#define TEST8 0x0080 /* root delay/dispersion bounds check */
#define TEST9 0x0100 /* peer not authenticated */
#define TEST10 0x0200 /* access denied */
#define TEST8 0x0080 /* root delay/dispersion bounds check */
#define TEST9 0x0100 /* peer delay/dispersion bounds check */
#define TEST10 0x0200 /* autokey failed */
#define TEST11 0x0400 /* proventic not confirmed */
/*
* The peer structure. Holds state information relating to the guys
* we are peering with. Most of this stuff is from section 3.2 of the
* The peer structure. Holds state information relating to the guys
* we are peering with. Most of this stuff is from section 3.2 of the
* spec.
*/
struct peer {
struct peer *next;
struct peer *ass_next; /* link pointer in associd hash */
struct sockaddr_in srcadr; /* address of remote host */
struct interface *dstadr; /* pointer to address on local host */
struct refclockproc *procptr; /* pointer to reference clock stuff */
u_char leap; /* leap indicator */
u_char hmode; /* association mode with this peer */
u_char pmode; /* peer's association mode */
u_char stratum; /* stratum of remote peer */
s_char precision; /* peer's clock precision */
u_char ppoll; /* peer poll interval */
u_char hpoll; /* local host poll interval */
u_char minpoll; /* min local host poll interval */
u_char maxpoll; /* max local host poll interval */
u_char burst; /* packets remaining in burst */
u_char version; /* version number */
u_int flags; /* peer flags */
u_char cast_flags; /* flags MDF_?CAST */
u_int flash; /* protocol error tally bits */
u_char refclktype; /* reference clock type */
u_char refclkunit; /* reference clock unit number */
u_char sstclktype; /* clock type for system status word */
u_int32 refid; /* peer reference ID */
l_fp reftime; /* update epoch */
u_long keyid; /* current key ID */
u_long pkeyid; /* previous key ID (autokey) */
u_long *keylist; /* session key identifier list */
int keynumber; /* session key identifier number */
u_short associd; /* association ID, a unique integer */
u_char ttl; /* time to live (multicast) */
struct peer *next; /* pointer to next association */
struct peer *ass_next; /* link pointer in associd hash */
struct sockaddr_in srcadr; /* address of remote host */
struct interface *dstadr; /* pointer to address on local host */
associd_t associd; /* association ID */
u_char version; /* version number */
u_char hmode; /* local association mode */
u_char hpoll; /* local poll interval */
u_char kpoll; /* last poll interval */
u_char minpoll; /* min poll interval */
u_char maxpoll; /* max poll interval */
u_char burst; /* packets remaining in burst */
u_int flags; /* association flags */
u_char cast_flags; /* additional flags */
u_int flash; /* protocol error test tally bits */
u_char last_event; /* last peer error code */
u_char num_events; /* number of error events */
u_char ttlmax; /* max ttl/refclock mode */
/* **Start of clear-to-zero area.*** */
/* Everything that is cleared to zero goes below here */
u_char valid; /* valid counter */
#define clear_to_zero valid
double estbdelay; /* broadcast offset */
u_char status; /* peer status */
u_char pollsw; /* what it says */
u_char reach; /* reachability, NTP_WINDOW bits */
u_char unreach; /* unreachable count */
u_short filter_nextpt; /* index into filter shift register */
double filter_delay[NTP_SHIFT]; /* delay part of shift register */
double filter_offset[NTP_SHIFT]; /* offset part of shift register */
double filter_disp[NTP_SHIFT]; /* dispersion part of shift register */
u_long filter_epoch[NTP_SHIFT]; /* epoch part of shift register */
u_char filter_order[NTP_SHIFT]; /* we keep the filter sorted here */
l_fp org; /* originate time stamp */
l_fp rec; /* receive time stamp */
l_fp xmt; /* transmit time stamp */
double offset; /* peer clock offset */
double delay; /* peer roundtrip delay */
double variance; /* peer variance (jitter) */
double disp; /* peer dispersion */
double rootdelay; /* roundtrip delay to primary clock */
double rootdispersion; /* dispersion to primary clock */
u_long epoch; /* reference epoch */
/* ***End of clear-to-zero area.*** */
/* Everything that is cleared to zero goes above here */
u_long update; /* receive epoch */
#define end_clear_to_zero update
u_long outdate; /* send time last packet */
u_long nextdate; /* send time next packet */
u_long nextaction; /* peer local activity timeout (refclocks mainly) */
void (*action) P((struct peer *));/* action timeout function */
/*
* statistic counters
* Variables used by reference clock support
*/
u_long timereset; /* time stat counters were reset */
u_long sent; /* number of updates sent */
u_long received; /* number of frames received */
u_long timereceived; /* last time a frame received */
u_long timereachable; /* last reachable/unreachable event */
u_long processed; /* processed by the protocol */
u_long badauth; /* bad credentials detected */
u_long bogusorg; /* rejected due to bogus origin */
u_long oldpkt; /* rejected as duplicate packet */
u_long seldisptoolarge; /* too much dispersion for selection */
u_long selbroken; /* broken NTP detected in selection */
u_long seltooold; /* too long since sync in selection */
u_char last_event; /* set to code for last peer error */
u_char num_events; /* num. of events which have occurred */
struct refclockproc *procptr; /* refclock structure pointer */
u_char refclktype; /* reference clock type */
u_char refclkunit; /* reference clock unit number */
u_char sstclktype; /* clock type for system status word */
/*
* Variables set by received packet
*/
u_char leap; /* local leap indicator */
u_char pmode; /* remote association mode */
u_char stratum; /* remote stratum */
s_char precision; /* remote clock precision */
u_char ppoll; /* remote poll interval */
u_int32 refid; /* remote reference ID */
l_fp reftime; /* update epoch */
/*
* Variables used by authenticated client
*/
keyid_t keyid; /* current key ID */
#ifdef AUTOKEY
#define clear_to_zero assoc
associd_t assoc; /* peer association ID */
u_int32 crypto; /* peer status word */
#ifdef PUBKEY
struct value pubkey; /* public key */
struct value certif; /* certificate */
u_char *keystr; /* host name */
#endif /* PUBKEY */
keyid_t pkeyid; /* previous key ID */
keyid_t hcookie; /* host cookie */
struct cookie pcookie; /* peer cookie */
struct autokey recauto; /* autokey */
u_int32 cmmd; /* peer command */
/*
* Variables used by authenticated server
*/
keyid_t *keylist; /* session key ID list */
int keynumber; /* current key number */
struct autokey sndauto; /* autokey */
#else /* AUTOKEY */
#define clear_to_zero status
#endif /* AUTOKEY */
/*
* Ephemeral state variables
*/
u_char status; /* peer status */
u_char pollsw; /* what it says */
u_char ttl; /* ttl for manycast mode */
u_char reach; /* reachability register */
u_char unreach; /* unreachable count */
u_long epoch; /* reference epoch */
u_short filter_nextpt; /* index into filter shift register */
double filter_delay[NTP_SHIFT]; /* delay shift register */
double filter_offset[NTP_SHIFT]; /* offset shift register */
double filter_disp[NTP_SHIFT]; /* dispersion shift register */
u_long filter_epoch[NTP_SHIFT]; /* epoch shift register */
u_char filter_order[NTP_SHIFT]; /* filter sort index */
l_fp org; /* originate time stamp */
l_fp rec; /* receive time stamp */
l_fp xmt; /* transmit time stamp */
double offset; /* peer clock offset */
double delay; /* peer roundtrip delay */
double jitter; /* peer jitter (squares) */
double disp; /* peer dispersion */
double estbdelay; /* clock offset to broadcast server */
/*
* Variables set by received packet
*/
double rootdelay; /* roundtrip delay to primary clock */
double rootdispersion; /* dispersion to primary clock */
/*
* End of clear-to-zero area
*/
u_long update; /* receive epoch */
#define end_clear_to_zero update
u_long outdate; /* send time last packet */
u_long nextdate; /* send time next packet */
u_long nextaction; /* peer local activity timeout (refclocks mainly) */
void (*action) P((struct peer *)); /* action timeout function */
/*
* Statistic counters
*/
u_long timereset; /* time stat counters were reset */
u_long timereceived; /* last packet received time */
u_long timereachable; /* last reachable/unreachable time */
u_long sent; /* packets sent */
u_long received; /* packets received */
u_long processed; /* packets processed by the protocol */
u_long badauth; /* packets cryptosum failed */
u_long bogusorg; /* packets bogus origin */
u_long oldpkt; /* packets duplicate packet */
u_long seldisptoolarge; /* packets dispersion to large*/
u_long selbroken; /* not used */
};
/*
@ -293,34 +368,33 @@ struct peer {
#define MODE_BROADCAST 5 /* broadcast mode */
#define MODE_CONTROL 6 /* control mode packet */
#define MODE_PRIVATE 7 /* implementation defined function */
#define MODE_BCLIENT 8 /* a pseudo mode, used internally */
#define MODE_MCLIENT 9 /* multicast mode, used internally */
#define MODE_BCLIENT 8 /* broadcast client mode */
/*
* Values for peer.stratum, sys_stratum
*/
#define STRATUM_REFCLOCK ((u_char)0) /* stratum claimed by primary clock */
#define STRATUM_PRIMARY ((u_char)1) /* host has a primary clock */
#define STRATUM_INFIN ((u_char)NTP_MAXSTRATUM) /* infinity a la Bellman-Ford */
/* A stratum of 0 in the packet is mapped to 16 internally */
#define STRATUM_PKT_UNSPEC ((u_char)0) /* unspecified in packet */
#define STRATUM_UNSPEC ((u_char)(NTP_MAXSTRATUM+(u_char)1)) /* unspecified */
#define STRATUM_UNSPEC ((u_char)16) /* unspecified */
/*
* Values for peer.flags
*/
#define FLAG_CONFIG 0x1 /* association was configured */
#define FLAG_AUTHENABLE 0x2 /* this guy needs authentication */
#define FLAG_MCAST1 0x4 /* multicast client/server mode */
#define FLAG_MCAST2 0x8 /* multicast client mode */
#define FLAG_AUTHENTIC 0x10 /* last message was authentic */
#define FLAG_REFCLOCK 0x20 /* this is actually a reference clock */
#define FLAG_SYSPEER 0x40 /* this is one of the selected peers */
#define FLAG_PREFER 0x80 /* this is the preferred peer */
#define FLAG_BURST 0x100 /* burst mode */
#define FLAG_SKEY 0x200 /* autokey authentication */
#define FLAG_NOSELECT 0x400 /* this is a "noselect" peer */
#define FLAG_CONFIG 0x0001 /* association was configured */
#define FLAG_AUTHENABLE 0x0002 /* authentication required */
#define FLAG_AUTHENTIC 0x0004 /* last message was authentic */
#define FLAG_SKEY 0x0008 /* autokey authentication */
#define FLAG_MCAST 0x0010 /* multicast client mode */
#define FLAG_REFCLOCK 0x0020 /* this is actually a reference clock */
#define FLAG_SYSPEER 0x0040 /* this is one of the selected peers */
#define FLAG_PREFER 0x0080 /* this is the preferred peer */
#define FLAG_BURST 0x0100 /* burst mode */
#define FLAG_IBURST 0x0200 /* initial burst mode */
#define FLAG_NOSELECT 0x0400 /* this is a "noselect" peer */
#define FLAG_AUTOKEY 0x0800 /* autokey confirmed */
#define FLAG_ASSOC 0x1000 /* autokey reqeust */
#define FLAG_PROVEN 0x2000 /* proventic confirmed */
/*
* Definitions for the clear() routine. We use memset() to clear
@ -331,6 +405,11 @@ struct peer {
#define END_CLEAR_TO_ZERO(p) ((char *)&((p)->end_clear_to_zero))
#define LEN_CLEAR_TO_ZERO (END_CLEAR_TO_ZERO((struct peer *)0) \
- CLEAR_TO_ZERO((struct peer *)0))
#define CRYPTO_TO_ZERO(p) ((char *)&((p)->clear_to_zero))
#define END_CRYPTO_TO_ZERO(p) ((char *)&((p)->end_clear_to_zero))
#define LEN_CRYPTO_TO_ZERO (END_CRYPTO_TO_ZERO((struct peer *)0) \
- CRYPTO_TO_ZERO((struct peer *)0))
/*
* Reference clock identifiers (for pps signal)
*/
@ -376,7 +455,9 @@ struct peer {
#define REFCLK_PCF 35 /* Conrad parallel port radio clock */
#define REFCLK_WWV_AUDIO 36 /* WWV/H audio demodulator/decoder */
#define REFCLK_FG 37 /* Forum Graphic GPS */
#define REFCLK_MAX 37 /* Grow as needed... */
#define REFCLK_HOPF_SERIAL 38 /* hopf DCF77/GPS serial line receiver */
#define REFCLK_HOPF_PCI 39 /* hopf DCF77/GPS PCI receiver */
#define REFCLK_MAX 39 /* Grow as needed... */
/*
* We tell reference clocks from real peers by giving the reference
@ -420,44 +501,45 @@ struct peer {
* and must be converted (except the mac, which isn't, really).
*/
struct pkt {
u_char li_vn_mode; /* contains leap indicator, version and mode */
u_char stratum; /* peer's stratum */
u_char ppoll; /* the peer polling interval */
s_char precision; /* peer clock precision */
u_fp rootdelay; /* distance to primary clock */
u_fp rootdispersion; /* clock dispersion */
u_int32 refid; /* reference clock ID */
l_fp reftime; /* time peer clock was last updated */
l_fp org; /* originate time stamp */
l_fp rec; /* receive time stamp */
l_fp xmt; /* transmit time stamp */
u_char li_vn_mode; /* leap indicator, version and mode */
u_char stratum; /* peer stratum */
u_char ppoll; /* peer poll interval */
s_char precision; /* peer clock precision */
u_fp rootdelay; /* distance to primary clock */
u_fp rootdispersion; /* clock dispersion */
u_int32 refid; /* reference clock ID */
l_fp reftime; /* time peer clock was last updated */
l_fp org; /* originate time stamp */
l_fp rec; /* receive time stamp */
l_fp xmt; /* transmit time stamp */
#define MIN_MAC_LEN (sizeof(u_int32) + 8) /* DES */
#define MAX_MAC_LEN (sizeof(u_int32) + 16) /* MD5 */
#define LEN_PKT_NOMAC 12 * sizeof(u_int32) /* min header length */
#define LEN_PKT_MAC LEN_PKT_NOMAC + sizeof(u_int32)
#define MIN_MAC_LEN 3 * sizeof(u_int32) /* DES */
#define MAX_MAC_LEN 5 * sizeof(u_int32) /* MD5 */
/*
* The length of the packet less MAC must be a multiple of 64
* bits. For normal private-key cryptography, the cryptosum
* covers only the raw NTP header. For autokey cryptography,
* the heade is incresed by 64 bits to contain the field length
* and private value.
* with an RSA modulus and Diffie-Hellman prime of 64 octets
* and maximum host name of 128 octets, the maximum autokey
* command is 152 octets and maximum autokey response is 460
* octets. A packet can contain no more than one command and one
* response, so the maximum total extension field length is 672
* octets. But, to handle humungus certificates, the bank must
* be broke.
*/
u_int32 keyid1; /* key identifier 1 */
u_int32 keyid2; /* key identifier 2 */
u_int32 keyid3; /* key identifier 3 */
u_char mac[MAX_MAC_LEN]; /* mac */
#ifdef AUTOKEY
#ifdef PUBKEY
u_int32 exten[5000 / 4]; /* max extension field */
#else
u_int32 exten[672 / 4]; /* max extension field */
#endif /* PUBKEY */
#else /* AUTOKEY */
u_int32 exten[1]; /* misused */
#endif /* AUTOKEY */
u_char mac[MAX_MAC_LEN]; /* mac */
};
/*
* Packets can come in two flavours, one with a mac and one without.
*/
#define LEN_PKT_NOMAC (sizeof(struct pkt) - MAX_MAC_LEN - 3 * sizeof(u_int32))
/*
* Minimum size of packet with a MAC: has to include at least a key number.
*/
#define LEN_PKT_MAC (LEN_PKT_NOMAC + sizeof(u_int32))
/*
* Stuff for extracting things from li_vn_mode
*/
@ -482,37 +564,42 @@ struct pkt {
#define STRATUM_TO_PKT(s) ((u_char)(((s) == (STRATUM_UNSPEC)) ?\
(STRATUM_PKT_UNSPEC) : (s)))
/*
* Event codes. Used for reporting errors/events to the control module
*/
#define PEER_EVENT 0x80 /* this is a peer event */
/*
* Event codes. Used for reporting errors/events to the control module
* System event codes
*/
#define PEER_EVENT 0x80 /* this is a peer event */
#define EVNT_UNSPEC 0 /* unspecified */
#define EVNT_SYSRESTART 1 /* system restart */
#define EVNT_SYSFAULT 2 /* wsystem or hardware fault */
#define EVNT_SYNCCHG 3 /* new leap or synch change */
#define EVNT_PEERSTCHG 4 /* new source or stratum */
#define EVNT_CLOCKRESET 5 /* clock reset */
#define EVNT_BADDATETIM 6 /* invalid time or date */
#define EVNT_CLOCKEXCPT 7 /* reference clock exception */
#define EVNT_UNSPEC 0
#define EVNT_SYSRESTART 1
#define EVNT_SYSFAULT 2
#define EVNT_SYNCCHG 3
#define EVNT_PEERSTCHG 4
#define EVNT_CLOCKRESET 5
#define EVNT_BADDATETIM 6
#define EVNT_CLOCKEXCPT 7
#define EVNT_PEERIPERR (1|PEER_EVENT)
#define EVNT_PEERAUTH (2|PEER_EVENT)
#define EVNT_UNREACH (3|PEER_EVENT)
#define EVNT_REACH (4|PEER_EVENT)
#define EVNT_PEERCLOCK (5|PEER_EVENT)
/*
* Peer event codes
*/
#define EVNT_PEERIPERR (1 | PEER_EVENT) /* IP error */
#define EVNT_PEERAUTH (2 | PEER_EVENT) /* authentication failure */
#define EVNT_UNREACH (3 | PEER_EVENT) /* change to unreachable */
#define EVNT_REACH (4 | PEER_EVENT) /* change to reachable */
#define EVNT_PEERCLOCK (5 | PEER_EVENT) /* clock exception */
/*
* Clock event codes
*/
#define CEVNT_NOMINAL 0
#define CEVNT_TIMEOUT 1
#define CEVNT_BADREPLY 2
#define CEVNT_FAULT 3
#define CEVNT_PROP 4
#define CEVNT_BADDATE 5
#define CEVNT_BADTIME 6
#define CEVNT_NOMINAL 0 /* unspecified */
#define CEVNT_TIMEOUT 1 /* poll timeout */
#define CEVNT_BADREPLY 2 /* bad reply format */
#define CEVNT_FAULT 3 /* hardware or software fault */
#define CEVNT_PROP 4 /* propagation failure */
#define CEVNT_BADDATE 5 /* bad date format or value */
#define CEVNT_BADTIME 6 /* bad time format or value */
#define CEVNT_MAX CEVNT_BADTIME
/*
@ -522,8 +609,8 @@ struct pkt {
/*
* To speed lookups, peers are hashed by the low order bits of the remote
* IP address. These definitions relate to that.
* To speed lookups, peers are hashed by the low order bits of the
* remote IP address. These definitions relate to that.
*/
#define HASH_SIZE 32
#define HASH_MASK (HASH_SIZE-1)
@ -538,14 +625,11 @@ struct pkt {
* is shifted by EVENT_TIMEOUT and added to the base value.
*/
#if defined(HAVE_MRAND48)
#define RANDOM (mrand48())
#define SRANDOM(x) (srand48(x))
#elif defined(HAVE_RANDOM)
#define RANDOM (random())
#define SRANDOM(x) (srandom(x))
# define RANDOM (mrand48())
# define SRANDOM(x) (srand48(x))
#else
#define RANDOM (0)
#define SRANDOM(x) (0)
# define RANDOM (random())
# define SRANDOM(x) (srandom(x))
#endif
#define RANDPOLL(x) ((1 << (x)) - 1 + (RANDOM & 0x3))
@ -575,14 +659,21 @@ struct pkt {
#define PROTO_KERNEL 9
#define PROTO_MONITOR 10
#define PROTO_FILEGEN 11
#define PROTO_PPS 12
#define PROTO_CAL 13
/*
* Configuration items for the loop filter
*/
#define LOOP_DRIFTINIT 1 /* set initial frequency offset */
#define LOOP_DRIFTCOMP 2 /* set frequency offset */
#define LOOP_PPSDELAY 3 /* set pps delay */
#define LOOP_PPSBAUD 4 /* set pps baud rate */
#define LOOP_MAX 3 /* set step offset */
#define LOOP_PANIC 4 /* set panic offseet */
#define LOOP_PHI 5 /* set dispersion rate */
#define LOOP_MINSTEP 6 /* set step timeout */
#define LOOP_MINPOLL 7 /* set min poll interval (log2 s) */
#define LOOP_ALLAN 8 /* set minimum Allan intercept */
#define LOOP_HUFFPUFF 9 /* set huff-n'-puff filter length */
/*
* Configuration items for the stats printer
@ -598,6 +689,7 @@ struct pkt {
*/
#define DEFBROADDELAY 4e-3 /* default broadcast offset */
#define INADDR_NTP 0xe0000101 /* NTP multicast address 224.0.1.1 */
/*
* Structure used optionally for monitoring when this is turned on.
*/
@ -619,11 +711,15 @@ struct mon_data {
u_char cast_flags; /* flags MDF_?CAST */
};
#define MDF_UCAST 0x1 /* unicast packet */
#define MDF_MCAST 0x2 /* multicast packet */
#define MDF_BCAST 0x4 /* broadcast packet */
#define MDF_LCAST 0x8 /* local packet */
#define MDF_ACAST 0x10 /* manycast packet */
/*
* Values for cast_flags
*/
#define MDF_UCAST 0x01 /* unicast */
#define MDF_MCAST 0x02 /* multicast */
#define MDF_BCAST 0x04 /* broadcast */
#define MDF_LCAST 0x08 /* localcast */
#define MDF_ACAST 0x10 /* manycast */
#define MDF_BCLNT 0x20 /* broadcast client */
/*
* Values used with mon_enabled to indicate reason for enabling monitoring
@ -646,19 +742,22 @@ struct restrictlist {
/*
* Access flags
*/
#define RES_IGNORE 0x1 /* ignore if matched */
#define RES_DONTSERVE 0x2 /* don't give him any time */
#define RES_DONTTRUST 0x4 /* don't trust if matched */
#define RES_NOQUERY 0x8 /* don't allow queries if matched */
#define RES_NOMODIFY 0x10 /* don't allow him to modify server */
#define RES_NOPEER 0x20 /* don't allocate memory resources */
#define RES_NOTRAP 0x40 /* don't allow him to set traps */
#define RES_LPTRAP 0x80 /* traps set by him are low priority */
#define RES_IGNORE 0x001 /* ignore if matched */
#define RES_DONTSERVE 0x002 /* don't give him any time */
#define RES_DONTTRUST 0x004 /* don't trust if matched */
#define RES_NOQUERY 0x008 /* don't allow queries if matched */
#define RES_NOMODIFY 0x010 /* don't allow him to modify server */
#define RES_NOPEER 0x020 /* don't allocate memory resources */
#define RES_NOTRAP 0x040 /* don't allow him to set traps */
#define RES_LPTRAP 0x080 /* traps set by him are low priority */
#define RES_LIMITED 0x100 /* limit per net number of clients */
#define RES_VERSION 0x200 /* serve only current version */
#define RES_DEMOBILIZE 0x400 /* demobilize association */
#define RES_ALLFLAGS \
(RES_IGNORE|RES_DONTSERVE|RES_DONTTRUST|RES_NOQUERY\
|RES_NOMODIFY|RES_NOPEER|RES_NOTRAP|RES_LPTRAP|RES_LIMITED)
(RES_IGNORE | RES_DONTSERVE | RES_DONTTRUST | RES_NOQUERY | \
RES_NOMODIFY | RES_NOPEER | RES_NOTRAP | RES_LPTRAP | \
RES_LIMITED | RES_VERSION | RES_DEMOBILIZE)
/*
* Match flags

4
contrib/ntp/include/ntp_cmdargs.h Normal file
View File

@ -0,0 +1,4 @@
#include "ntp_types.h"
extern void getstartup P((int, char **));
extern void getCmdOpts P((int, char **));

151
contrib/ntp/include/ntp_config.h Normal file
View File

@ -0,0 +1,151 @@
/*
* Configuration file name
*/
#ifndef CONFIG_FILE
# ifndef SYS_WINNT
# define CONFIG_FILE "/etc/ntp.conf"
# else /* SYS_WINNT */
# define CONFIG_FILE "%windir%\\system32\\drivers\\etc\\ntp.conf"
# define ALT_CONFIG_FILE "%windir%\\ntp.conf"
# endif /* SYS_WINNT */
#endif /* not CONFIG_FILE */
/*
* Types of entries we understand.
*/
#define CONFIG_UNKNOWN 0
/*
* Command keywords
*/
#define CONFIG_PEER 1
#define CONFIG_SERVER 2
#define CONFIG_AUTOMAX 3
#define CONFIG_DRIFTFILE 4
#define CONFIG_BROADCAST 5
#define CONFIG_BROADCASTCLIENT 6
#define CONFIG_AUTHENTICATE 7
#define CONFIG_KEYS 8
#define CONFIG_REVOKE 9
#define CONFIG_PPS 10
#define CONFIG_RESTRICT 11
#define CONFIG_BDELAY 12
#define CONFIG_TRUSTEDKEY 13
#define CONFIG_REQUESTKEY 14
#define CONFIG_CONTROLKEY 15
#define CONFIG_TRAP 16
#define CONFIG_FUDGE 17
#define CONFIG_TINKER 18
#define CONFIG_STATSDIR 19
#define CONFIG_FILEGEN 20
#define CONFIG_STATISTICS 21
#define CONFIG_PIDFILE 22
#define CONFIG_SETVAR 23
#define CONFIG_CLIENTLIMIT 24
#define CONFIG_CLIENTPERIOD 25
#define CONFIG_MULTICASTCLIENT 26
#define CONFIG_ENABLE 27
#define CONFIG_DISABLE 28
#define CONFIG_PHONE 29
#define CONFIG_LOGFILE 30
#define CONFIG_LOGCONFIG 31
#define CONFIG_MANYCASTCLIENT 32
#define CONFIG_MANYCASTSERVER 33
#ifdef PUBKEY
#define CONFIG_CRYPTO 34
#define CONFIG_KEYSDIR 35
#endif /* PUBKEY */
#define CONFIG_INCLUDEFILE 36
/*
* "peer", "server", "broadcast" modifier keywords
*/
#define CONF_MOD_VERSION 1
#define CONF_MOD_KEY 2
#define CONF_MOD_MINPOLL 3
#define CONF_MOD_MAXPOLL 4
#define CONF_MOD_PREFER 5
#define CONF_MOD_BURST 6
#define CONF_MOD_IBURST 7
#define CONF_MOD_SKEY 8
#define CONF_MOD_TTL 9
#define CONF_MOD_MODE 10
#define CONF_MOD_NOSELECT 11
#ifdef PUBKEY
#define CONF_MOD_PUBLICKEY 12
#endif /* PUBKEY */
/*
* "restrict" modifier keywords
*/
#define CONF_RES_MASK 1
#define CONF_RES_IGNORE 2
#define CONF_RES_NOSERVE 3
#define CONF_RES_NOTRUST 4
#define CONF_RES_NOQUERY 5
#define CONF_RES_NOMODIFY 6
#define CONF_RES_NOPEER 7
#define CONF_RES_NOTRAP 8
#define CONF_RES_LPTRAP 9
#define CONF_RES_NTPPORT 10
#define CONF_RES_LIMITED 11
#define CONF_RES_VERSION 12
#define CONF_RES_DEMOBILIZE 13
/*
* "trap" modifier keywords
*/
#define CONF_TRAP_PORT 1
#define CONF_TRAP_INTERFACE 2
/*
* "fudge" modifier keywords
*/
#define CONF_FDG_TIME1 1
#define CONF_FDG_TIME2 2
#define CONF_FDG_STRATUM 3
#define CONF_FDG_REFID 4
#define CONF_FDG_FLAG1 5
#define CONF_FDG_FLAG2 6
#define CONF_FDG_FLAG3 7
#define CONF_FDG_FLAG4 8
/*
* "filegen" modifier keywords
*/
#define CONF_FGEN_FILE 1
#define CONF_FGEN_TYPE 2
#define CONF_FGEN_FLAG_LINK 3
#define CONF_FGEN_FLAG_NOLINK 4
#define CONF_FGEN_FLAG_ENABLE 5
#define CONF_FGEN_FLAG_DISABLE 6
/*
* "pps" modifier keywords
*/
#define CONF_PPS_ASSERT 1
#define CONF_PPS_CLEAR 2
#define CONF_PPS_HARDPPS 3
/*
* "tinker" modifier keywords
*/
#define CONF_CLOCK_MAX 1
#define CONF_CLOCK_PANIC 2
#define CONF_CLOCK_PHI 3
#define CONF_CLOCK_MINSTEP 4
#define CONF_CLOCK_MINPOLL 5
#define CONF_CLOCK_ALLAN 6
#define CONF_CLOCK_HUFFPUFF 7
#ifdef PUBKEY
/*
* "crypto" modifier keywords
*/
#define CONF_CRYPTO_DH 1
#define CONF_CRYPTO_PRIVATEKEY 2
#define CONF_CRYPTO_PUBLICKEY 3
#define CONF_CRYPTO_LEAP 4
#define CONF_CRYPTO_FLAGS 5
#define CONF_CRYPTO_CERT 6
#endif /* PUBKEY */

41
contrib/ntp/include/ntp_control.h
View File

@ -9,7 +9,7 @@ struct ntp_control {
u_char r_m_e_op; /* response, more, error, opcode */
u_short sequence; /* sequence number of request */
u_short status; /* status word for association */
u_short associd; /* association ID */
associd_t associd; /* association ID */
u_short offset; /* offset of this batch of data */
u_short count; /* count of data in this packet */
u_char data[(480 + MAX_MAC_LEN)]; /* data + auth */
@ -157,14 +157,26 @@ struct ntp_control {
#define CS_STATE 10
#define CS_OFFSET 11
#define CS_DRIFT 12
#define CS_COMPLIANCE 13
#define CS_JITTER 13
#define CS_CLOCK 14
#define CS_PROCESSOR 15
#define CS_SYSTEM 16
#define CS_STABIL 17
#define CS_VARLIST 18
#define CS_VERSION 17
#define CS_STABIL 18
#define CS_VARLIST 19
#ifdef PUBKEY
#define CS_FLAGS 20
#define CS_HOST 21
#define CS_PUBLIC 22
#define CS_CERTIF 23
#define CS_DHPARAMS 24
#define CS_REVTIME 25
#define CS_LEAPTAB 26
#define CS_TAI 27
#define CS_MAXCODE CS_TAI
#else
#define CS_MAXCODE CS_VARLIST
#endif /* PUBKEY */
/*
* Peer variables we understand
@ -204,10 +216,23 @@ struct ntp_control {
#define CP_SENT 33
#define CP_FILTERROR 34
#define CP_FLASH 35
#define CP_DISP 36
#define CP_VARLIST 37
#define CP_TTL 36
#define CP_TTLMAX 37
#define CP_VARLIST 38
#ifdef PUBKEY
#define CP_FLAGS 39
#define CP_HOST 40
#define CP_PUBLIC 41
#define CP_CERTIF 42
#define CP_SESKEY 43
#define CP_SASKEY 44
#define CP_INITSEQ 45
#define CP_INITKEY 46
#define CP_INITTSP 47
#define CP_MAXCODE CP_INITTSP
#else
#define CP_MAXCODE CP_VARLIST
#endif /* PUBKEY */
/*
* Clock variables we understand

93
contrib/ntp/include/ntp_crypto.h Normal file
View File

@ -0,0 +1,93 @@
/*
* ntp_crypto.h - definitions for cryptographic operations
*/
#ifdef AUTOKEY
#include "global.h"
#include "md5.h"
#ifdef RSAREF
#include "rsaref.h"
#include "rsa.h"
#define EVP_SignInit(a, b) R_SignInit(a, b)
#define EVP_SignUpdate(a, b, c) R_SignUpdate(a, b, c);
#define EVP_SignFinal(a, b, c, d) R_SignFinal(a, b, c, d);
#define EVP_VerifyInit(a, b) R_VerifyInit(a, b)
#define EVP_VerifyUpdate(a, b, c) R_VerifyUpdate(a, b, c);
#define EVP_VerifyFinal(a, b, c, d) R_VerifyFinal(a, b, c, d);
#endif /* RSAREF */
/*
* Cryptostatus word
*/
#define CRYPTO_FLAG_ENAB 0x01 /* crypto enable */
#define CRYPTO_FLAG_RSA 0x02 /* public/private keys */
#define CRYPTO_FLAG_CERT 0x04 /* certificate */
#define CRYPTO_FLAG_DH 0x08 /* agreement parameters */
#define CRYPTO_FLAG_TAI 0x10 /* leapseconds table */
/*
* Extension field definitions
*/
#define CRYPTO_VN 1 /* current protocol version number */
#define CRYPTO_NULL ((CRYPTO_VN << 8) | 0) /* no operation */
#define CRYPTO_STAT ((CRYPTO_VN << 8) | 1) /* status */
#define CRYPTO_ASSOC ((CRYPTO_VN << 8) | 2) /* association ID */
#define CRYPTO_AUTO ((CRYPTO_VN << 8) | 3) /* autokey values */
#define CRYPTO_PRIV ((CRYPTO_VN << 8) | 4) /* cookie value */
#define CRYPTO_DHPAR ((CRYPTO_VN << 8) | 5) /* agreement params */
#define CRYPTO_DH ((CRYPTO_VN << 8) | 6) /* public value */
#define CRYPTO_NAME ((CRYPTO_VN << 8) | 7) /* host name/pub key */
#define CRYPTO_CERT ((CRYPTO_VN << 8) | 8) /* PKI certificate */
#define CRYPTO_TAI ((CRYPTO_VN << 8) | 9) /* leapseconds table */
#define CRYPTO_RESP 0x8000 /* response */
#define CRYPTO_ERROR 0x4000 /* error */
#ifdef PUBKEY
/*
* Configuration codes
*/
#define CRYPTO_CONF_NONE 0 /* nothing doing */
#define CRYPTO_CONF_FLAGS 1 /* initialize flags */
#define CRYPTO_CONF_PRIV 2 /* load private key from file */
#define CRYPTO_CONF_PUBL 3 /* load public key from file */
#define CRYPTO_CONF_DH 4 /* load Diffie_Hellman pars from file */
#define CRYPTO_CONF_LEAP 5 /* load leapsecond table */
#define CRYPTO_CONF_KEYS 6 /* set keys directory path */
#define CRYPTO_CONF_CERT 7 /* load PKI certificate from file */
#endif /* PUBKEY */
/*
* Function prototypes
*/
extern void crypto_recv P((struct peer *, struct recvbuf *));
extern int crypto_xmit P((u_int32 *, int, u_int, keyid_t,
u_int));
extern keyid_t session_key P((struct sockaddr_in *, struct
sockaddr_in *, keyid_t, keyid_t,
u_long));
extern void make_keylist P((struct peer *, struct interface *));
extern void key_expire P((struct peer *));
extern void crypto_agree P((void));
#ifdef PUBKEY
extern void crypto_config P((int, char *));
extern void crypto_setup P((void));
extern int crypto_public P((struct peer *, u_char *, u_int));
#endif /* PUBKEY */
/*
* Cryptographic values
*/
extern u_int crypto_flags; /* status word */
#ifdef PUBKEY
extern R_DH_PARAMS dh_params;
extern struct value host; /* host name/public key */
extern struct value certif; /* certificate */
extern struct value dhparam; /* agreement parameters */
extern struct value dhpub; /* public value */
extern struct value tai_leap; /* leapseconds table */
extern u_int crypto_flags; /* status word */
extern u_int sys_tai; /* current UTC offset from TAI */
#endif /* PUBKEY */
#endif /* AUTOKEY */

6
contrib/ntp/include/ntp_if.h
View File

@ -8,12 +8,6 @@
# include "/sys/sync/sema.h"
#endif
/* was: defined(SYS_AIX) */
#if defined(TIME_WITH_SYS_TIME)
# include <sys/time.h>
# include <time.h>
#endif
/* was: (defined(SYS_SOLARIS) && !defined(bsd)) || defined(SYS_SUNOS4) */
/* was: defined(SYS_UNIXWARE1) */
#ifdef HAVE_SYS_SOCKIO_H

19
contrib/ntp/include/ntp_machine.h
View File

@ -6,11 +6,18 @@
#define __ntp_machine
#ifdef HAVE_CONFIG_H
#include <config.h>
# include <config.h>
#endif
#ifdef HAVE_SYS_TIME_H
#include <sys/time.h>
#ifdef TIME_WITH_SYS_TIME
# include <sys/time.h>
# include <time.h>
#else
# ifdef HAVE_SYS_TIME_H
# include <sys/time.h>
# else
# include <time.h>
# endif
#endif
#include "ntp_proto.h"
@ -235,18 +242,18 @@ typedef unsigned long u_long;
error "NT requires config.h to be included"
# endif /* HAVE_CONFIG_H) */
#if defined SYS_WINNT
# define ifreq _INTERFACE_INFO
# define ifr_flags iiFlags
# define ifr_addr iiAddress.AddressIn
# define ifr_broadaddr iiBroadcastAddress.AddressIn
# define ifr_mask iiNetmask.AddressIn
#endif /* SYS_WINNT */
# define isascii __isascii
# define isatty _isatty
# define mktemp _mktemp
# define getpid GetCurrentProcessId
# if 0
# define getpid GetCurrentProcessId
# endif
# include <windows.h>
# include <ws2tcpip.h>
# undef interface

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