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

Update ntp vendor code to 4.2.4p8.

Browse Source 
This is mainly to fix CVE-2009-3563, a remote DOS.

MFC after:	3 days
Security:	CVE-2009-3563
This commit is contained in:
Ollivier Robert 2009-12-12 22:29:30 +00:00
parent 8c0610b960
commit 7e3cc4cfce
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/vendor/ntp/dist/; revision=200451
svn path=/vendor/ntp/4.2.4p8/; revision=200452; tag=vendor/ntp/4.2.4p8
195 changed files with 29379 additions and 90623 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
COPYRIGHT
View File

@ -13,7 +13,7 @@ This file is automatically generated from html/copyright.html
applies as if the text was explicitly included in the file.
***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2008 *
* Copyright (c) David L. Mills 1992-2009 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *

83
ChangeLog
View File

@ -1,6 +1,85 @@
(4.2.4p5) 2008/08/17 Released by Harlan Stenn <stenn@ntp.org>
---
(4.2.4p5) 2008/08/17 Released by Harlan Stenn <stenn@ntp.org>
(4.2.4p8) 2009/12/08 Released by Harlan Stenn <stenn@ntp.org>
* [Sec 1331] DoS with mode 7 packets - CVE-2009-3563.
---
(4.2.4p7) 2009/05/18 Released by Harlan Stenn <stenn@ntp.org>
* [Sec 1151] Remote exploit if autokey is enabled - CVE-2009-1252.
* [Bug 1187] Update the copyright date.
* [Bug 1191] ntpd fails on Win2000 - "Address already in use" after fix
for [Sec 1149].
---
(4.2.4p7-RC7) 2009/05/12 Released by Harlan Stenn <stenn@ntp.org>
* ntp.isc.org -> ntp.org cleanup.
* [Bug 1178] Use prior FORCE_DNSRETRY behavior as needed at runtime,
add configure --enable-ignore-dns-errors to be even more stubborn
---
(4.2.4p7-RC6) 2009/05/08 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 784] Make --enable-linuxcaps the default when available
* [Bug 1179] error messages for -u/--user and -i lacking droproot
* Updated JJY reference clock driver from Takao Abe
* [Bug 1071] Log a message and exit before trying to use FD_SET with a
descriptor larger than FD_SETSIZE, which will corrupt memory
* On corruption of the iface list head in add_interface, log and exit
---
(4.2.4p7-RC5) 2009/05/02 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1172] 4.2.4p7-RC{3,4} fail to build on linux.
* flock-build script unportable 'set -m' use removed
---
(4.2.4p7-RC4) 2009/04/29 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1167] use gcc -Winit-self only if it is understood
---
(4.2.4p7-RC3) 2009/04/22 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 787] Bug fixes for 64-bit time_t on Windows
* [Bug 813] Conditional naming of Event
* [Bug 1147] System errors should be logged to msyslog()
* [Bug 1155] Fix compile problem on Windows with VS2005
* [Bug 1156] lock_thread_to_processor() should be declared in header
* [Bug 1157] quiet OpenSSL warnings, clean up configure.ac
* [Bug 1158] support for aix6.1
* [Bug 1160] MacOS X is like BSD regarding F_SETOWN
---
(4.2.4p7-RC2) 2009/04/09 Released by Harlan Stenn <stenn@ntp.org>
* [Sec 1144] limited buffer overflow in ntpq. CVE-2009-0159
* [Sec 1149] use SO_EXCLUSIVEADDRUSE on Windows
---
(4.2.4p7-RC1) 2009/03/30 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1131] UDP sockets should not use SIGPOLL on Solaris.
* build system email address cleanup
* [Bug 774] parsesolaris.c does not compile under the new Solaris
* [Bug 873] Windows serial refclock proper TTY line discipline emulation
* [Bug 1014] Enable building with VC9 (in Visual Studio 2008,
Visual C++ 2008, or SDK)
* [Bug 1117] Deferred interface binding under Windows works only correctly
if FORCE_DNSRETRY is defined
* [BUG 1124] Lock QueryPerformanceCounter() client threads to same CPU
* DPRINTF macro made safer, always evaluates to a statement and will not
misassociate an else which follows the macro.
---
(4.2.4p6) 2009/01/08 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1113] Fixed build errors with recent versions of openSSL.
* [Sec 1111] Fix incorrect check of EVP_VerifyFinal()'s return value.
* Update the copyright year.
---
(4.2.4p5) 2008/08/17 Released by Harlan Stenn <stenn@ntp.org>
* [BUG 1051] Month off by one in leap second message written to clockstats

5972
CommitLog
View File

File diff suppressed because it is too large Load Diff

329
Makefile.in
View File

@ -1,8 +1,9 @@
# Makefile.in generated by automake 1.9.6 from Makefile.am.
# Makefile.in generated by automake 1.11 from Makefile.am.
# @configure_input@
# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
# 2003, 2004, 2005 Free Software Foundation, Inc.
# 2003, 2004, 2005, 2006, 2007, 2008, 2009 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.
@ -13,15 +14,12 @@
# PARTICULAR PURPOSE.
@SET_MAKE@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
top_builddir = .
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
INSTALL = @INSTALL@
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
@ -36,11 +34,11 @@ POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@NEED_LIBOPTS_TRUE@am__append_1 = libopts
subdir = .
DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
$(srcdir)/Makefile.in $(srcdir)/config.h.in \
$(top_srcdir)/configure ChangeLog INSTALL NEWS TODO compile \
config.guess config.sub depcomp install-sh ltmain.sh missing
subdir = .
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/libopts/m4/libopts.m4 \
$(top_srcdir)/m4/define_dir.m4 \
@ -50,34 +48,64 @@ am__aclocal_m4_deps = $(top_srcdir)/libopts/m4/libopts.m4 \
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
configure.lineno configure.status.lineno
configure.lineno config.status.lineno
mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
SOURCES =
DIST_SOURCES =
RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
html-recursive info-recursive install-data-recursive \
install-exec-recursive install-info-recursive \
install-recursive installcheck-recursive installdirs-recursive \
pdf-recursive ps-recursive uninstall-info-recursive \
uninstall-recursive
install-dvi-recursive install-exec-recursive \
install-html-recursive install-info-recursive \
install-pdf-recursive install-ps-recursive install-recursive \
installcheck-recursive installdirs-recursive pdf-recursive \
ps-recursive uninstall-recursive
RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive \
distclean-recursive maintainer-clean-recursive
AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
distdir dist dist-all distcheck
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)
am__remove_distdir = \
{ test ! -d $(distdir) \
|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
&& rm -fr $(distdir); }; }
{ test ! -d "$(distdir)" \
|| { find "$(distdir)" -type d ! -perm -200 -exec chmod u+w {} ';' \
&& rm -fr "$(distdir)"; }; }
am__relativize = \
dir0=`pwd`; \
sed_first='s,^\([^/]*\)/.*$$,\1,'; \
sed_rest='s,^[^/]*/*,,'; \
sed_last='s,^.*/\([^/]*\)$$,\1,'; \
sed_butlast='s,/*[^/]*$$,,'; \
while test -n "$$dir1"; do \
first=`echo "$$dir1" | sed -e "$$sed_first"`; \
if test "$$first" != "."; then \
if test "$$first" = ".."; then \
dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
else \
first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
if test "$$first2" = "$$first"; then \
dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
else \
dir2="../$$dir2"; \
fi; \
dir0="$$dir0"/"$$first"; \
fi; \
fi; \
dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
done; \
reldir="$$dir2"
DIST_ARCHIVES = $(distdir).tar.gz
GZIP_ENV = --best
distuninstallcheck_listfiles = find . -type f -print
distcleancheck_listfiles = find . -type f -print
ACLOCAL = @ACLOCAL@
AMDEP_FALSE = @AMDEP_FALSE@
AMDEP_TRUE = @AMDEP_TRUE@
AMTAR = @AMTAR@
AR = @AR@
ARLIB_DIR = @ARLIB_DIR@
@ -93,10 +121,6 @@ CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CXX = @CXX@
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
CXXFLAGS = @CXXFLAGS@
CYGPATH_W = @CYGPATH_W@
DCFD = @DCFD@
DEFS = @DEFS@
@ -109,11 +133,10 @@ EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
F77 = @F77@
FFLAGS = @FFLAGS@
GREP = @GREP@
HAVE_INLINE = @HAVE_INLINE@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_LIBOPTS_FALSE = @INSTALL_LIBOPTS_FALSE@
INSTALL_LIBOPTS_TRUE = @INSTALL_LIBOPTS_TRUE@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
@ -127,6 +150,7 @@ LIBPARSE = @LIBPARSE@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LN_S = @LN_S@
LSCF = @LSCF@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAKE_ADJTIMED = @MAKE_ADJTIMED@
@ -140,8 +164,7 @@ MAKE_NTPTIME = @MAKE_NTPTIME@
MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
NEED_LIBOPTS_FALSE = @NEED_LIBOPTS_FALSE@
NEED_LIBOPTS_TRUE = @NEED_LIBOPTS_TRUE@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
@ -151,6 +174,7 @@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_PERL = @PATH_PERL@
PATH_SEPARATOR = @PATH_SEPARATOR@
@ -164,16 +188,11 @@ STRIP = @STRIP@
TESTDCF = @TESTDCF@
U = @U@
VERSION = @VERSION@
ac_ct_AR = @ac_ct_AR@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
ac_ct_CXX = @ac_ct_CXX@
ac_ct_F77 = @ac_ct_F77@
ac_ct_RANLIB = @ac_ct_RANLIB@
ac_ct_STRIP = @ac_ct_STRIP@
am__fastdepCC_FALSE = @am__fastdepCC_FALSE@
am__fastdepCC_TRUE = @am__fastdepCC_TRUE@
am__fastdepCXX_FALSE = @am__fastdepCXX_FALSE@
am__fastdepCXX_TRUE = @am__fastdepCXX_TRUE@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
@ -185,29 +204,41 @@ build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
subdirs = @subdirs@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
#AUTOMAKE_OPTIONS = util/ansi2knr foreign dist-tarZ no-dependencies
AUTOMAKE_OPTIONS = util/ansi2knr foreign 1.8
@ -299,15 +330,15 @@ $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
echo ' cd $(srcdir) && $(AUTOMAKE) --foreign '; \
cd $(srcdir) && $(AUTOMAKE) --foreign \
echo ' cd $(srcdir) && $(AUTOMAKE) --foreign'; \
$(am__cd) $(srcdir) && $(AUTOMAKE) --foreign \
&& exit 0; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile'; \
cd $(top_srcdir) && \
$(AUTOMAKE) --foreign Makefile
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign Makefile
.PRECIOUS: Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
@ -323,21 +354,22 @@ $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENC
$(SHELL) ./config.status --recheck
$(top_srcdir)/configure: $(am__configure_deps)
cd $(srcdir) && $(AUTOCONF)
$(am__cd) $(srcdir) && $(AUTOCONF)
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
$(am__cd) $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
$(am__aclocal_m4_deps):
config.h: stamp-h1
@if test ! -f $@; then \
rm -f stamp-h1; \
$(MAKE) stamp-h1; \
$(MAKE) $(AM_MAKEFLAGS) stamp-h1; \
else :; fi
stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
@rm -f stamp-h1
cd $(top_builddir) && $(SHELL) ./config.status config.h
$(srcdir)/config.h.in: $(am__configure_deps)
cd $(top_srcdir) && $(AUTOHEADER)
($(am__cd) $(top_srcdir) && $(AUTOHEADER))
rm -f stamp-h1
touch $@
@ -351,8 +383,7 @@ clean-libtool:
-rm -rf .libs _libs
distclean-libtool:
-rm -f libtool
uninstall-info-am:
-rm -f libtool config.lt
# This directory's subdirectories are mostly independent; you can cd
# into them and run `make' without going through this Makefile.
@ -378,15 +409,14 @@ $(RECURSIVE_TARGETS):
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| eval $$failcom; \
done; \
if test "$$dot_seen" = "no"; then \
$(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
mostlyclean-recursive clean-recursive distclean-recursive \
maintainer-clean-recursive:
$(RECURSIVE_CLEAN_TARGETS):
@failcom='exit 1'; \
for f in x $$MAKEFLAGS; do \
case $$f in \
@ -413,16 +443,16 @@ maintainer-clean-recursive:
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| eval $$failcom; \
done && test -z "$$fail"
tags-recursive:
list='$(SUBDIRS)'; for subdir in $$list; do \
test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
done
ctags-recursive:
list='$(SUBDIRS)'; for subdir in $$list; do \
test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
done
ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
@ -430,14 +460,14 @@ ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
mkid -fID $$unique
tags: TAGS
TAGS: tags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
set x; \
here=`pwd`; \
if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
include_option=--etags-include; \
@ -449,84 +479,103 @@ TAGS: tags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) \
list='$(SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
test ! -f $$subdir/TAGS || \
tags="$$tags $$include_option=$$here/$$subdir/TAGS"; \
set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
fi; \
done; \
list='$(SOURCES) $(HEADERS) config.h.in $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
if test -z "$(ETAGS_ARGS)$$tags$$unique"; then :; else \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
shift; \
if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
test -n "$$unique" || unique=$$empty_fix; \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$tags $$unique; \
if test $$# -gt 0; then \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
"$$@" $$unique; \
else \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$unique; \
fi; \
fi
ctags: CTAGS
CTAGS: ctags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
here=`pwd`; \
list='$(SOURCES) $(HEADERS) config.h.in $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$(CTAGS_ARGS)$$tags$$unique" \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
test -z "$(CTAGS_ARGS)$$unique" \
|| $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
$$tags $$unique
$$unique
GTAGS:
here=`$(am__cd) $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) $$here
&& $(am__cd) $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) "$$here"
distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
distdir: $(DISTFILES)
$(am__remove_distdir)
mkdir $(distdir)
$(mkdir_p) $(distdir)/libopts/m4 $(distdir)/m4 $(distdir)/ntpdc $(distdir)/scripts
@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's|.|.|g'`; \
list='$(DISTFILES)'; for file in $$list; do \
case $$file in \
$(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \
$(top_srcdir)/*) file=`echo "$$file" | sed "s|^$$topsrcdirstrip/|$(top_builddir)/|"`;; \
esac; \
test -d "$(distdir)" || mkdir "$(distdir)"
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
if test "$$dir" != "$$file" && test "$$dir" != "."; then \
dir="/$$dir"; \
$(mkdir_p) "$(distdir)$$dir"; \
else \
dir=''; \
fi; \
if test -d $$d/$$file; then \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f $(distdir)/$$file \
|| cp -p $$d/$$file $(distdir)/$$file \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
test -d "$(distdir)/$$subdir" \
|| $(mkdir_p) "$(distdir)/$$subdir" \
|| $(MKDIR_P) "$(distdir)/$$subdir" \
|| exit 1; \
distdir=`$(am__cd) $(distdir) && pwd`; \
top_distdir=`$(am__cd) $(top_distdir) && pwd`; \
(cd $$subdir && \
fi; \
done
@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
$(am__relativize); \
new_distdir=$$reldir; \
dir1=$$subdir; dir2="$(top_distdir)"; \
$(am__relativize); \
new_top_distdir=$$reldir; \
echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
echo " am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
($(am__cd) $$subdir && \
$(MAKE) $(AM_MAKEFLAGS) \
top_distdir="$$top_distdir" \
distdir="$$distdir/$$subdir" \
top_distdir="$$new_top_distdir" \
distdir="$$new_distdir" \
am__remove_distdir=: \
am__skip_length_check=: \
am__skip_mode_fix=: \
distdir) \
|| exit 1; \
fi; \
@ -534,11 +583,12 @@ distdir: $(DISTFILES)
$(MAKE) $(AM_MAKEFLAGS) \
top_distdir="$(top_distdir)" distdir="$(distdir)" \
dist-hook
-find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
-test -n "$(am__skip_mode_fix)" \
|| 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)
! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r "$(distdir)"
dist-gzip: distdir
tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz
$(am__remove_distdir)
@ -547,6 +597,14 @@ dist-bzip2: distdir
tardir=$(distdir) && $(am__tar) | bzip2 -9 -c >$(distdir).tar.bz2
$(am__remove_distdir)
dist-lzma: distdir
tardir=$(distdir) && $(am__tar) | lzma -9 -c >$(distdir).tar.lzma
$(am__remove_distdir)
dist-xz: distdir
tardir=$(distdir) && $(am__tar) | xz -c >$(distdir).tar.xz
$(am__remove_distdir)
dist-tarZ: distdir
tardir=$(distdir) && $(am__tar) | compress -c >$(distdir).tar.Z
$(am__remove_distdir)
@ -573,6 +631,10 @@ distcheck: dist
GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz | $(am__untar) ;;\
*.tar.bz2*) \
bunzip2 -c $(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.lzma*) \
unlzma -c $(distdir).tar.lzma | $(am__untar) ;;\
*.tar.xz*) \
xz -dc $(distdir).tar.xz | $(am__untar) ;;\
*.tar.Z*) \
uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
*.shar.gz*) \
@ -584,9 +646,11 @@ distcheck: dist
mkdir $(distdir)/_build
mkdir $(distdir)/_inst
chmod a-w $(distdir)
test -d $(distdir)/_build || exit 0; \
dc_install_base=`$(am__cd) $(distdir)/_inst && pwd | sed -e 's,^[^:\\/]:[\\/],/,'` \
&& dc_destdir="$${TMPDIR-/tmp}/am-dc-$$$$/" \
&& cd $(distdir)/_build \
&& am__cwd=`pwd` \
&& $(am__cd) $(distdir)/_build \
&& ../configure --srcdir=.. --prefix="$$dc_install_base" \
$(DISTCHECK_CONFIGURE_FLAGS) \
&& $(MAKE) $(AM_MAKEFLAGS) \
@ -608,13 +672,15 @@ distcheck: dist
&& rm -rf "$$dc_destdir" \
&& $(MAKE) $(AM_MAKEFLAGS) dist \
&& rm -rf $(DIST_ARCHIVES) \
&& $(MAKE) $(AM_MAKEFLAGS) distcleancheck
&& $(MAKE) $(AM_MAKEFLAGS) distcleancheck \
&& cd "$$am__cwd" \
|| exit 1
$(am__remove_distdir)
@(echo "$(distdir) archives ready for distribution: "; \
list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
sed -e '1{h;s/./=/g;p;x;}' -e '$${p;x;}'
sed -e 1h -e 1s/./=/g -e 1p -e 1x -e '$$p' -e '$$x'
distuninstallcheck:
@cd $(distuninstallcheck_dir) \
@$(am__cd) '$(distuninstallcheck_dir)' \
&& test `$(distuninstallcheck_listfiles) | wc -l` -le 1 \
|| { echo "ERROR: files left after uninstall:" ; \
if test -n "$(DESTDIR)"; then \
@ -658,6 +724,7 @@ clean-generic:
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
-test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
maintainer-clean-generic:
@ -680,18 +747,38 @@ dvi-am:
html: html-recursive
html-am:
info: info-recursive
info-am:
install-data-am:
install-dvi: install-dvi-recursive
install-dvi-am:
install-exec-am:
install-html: install-html-recursive
install-html-am:
install-info: install-info-recursive
install-info-am:
install-man:
install-pdf: install-pdf-recursive
install-pdf-am:
install-ps: install-ps-recursive
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-recursive
@ -712,24 +799,27 @@ ps: ps-recursive
ps-am:
uninstall-am: uninstall-info-am
uninstall-am:
uninstall-info: uninstall-info-recursive
.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) all check \
ctags-recursive install install-am install-strip \
tags-recursive
.PHONY: $(RECURSIVE_TARGETS) CTAGS GTAGS all all-am am--refresh check \
check-am clean clean-generic clean-libtool clean-recursive \
ctags ctags-recursive dist dist-all dist-bzip2 dist-gzip \
dist-hook dist-shar dist-tarZ dist-zip distcheck distclean \
distclean-generic distclean-hdr distclean-libtool \
distclean-recursive distclean-tags distcleancheck distdir \
.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
all all-am am--refresh check check-am clean clean-generic \
clean-libtool ctags ctags-recursive dist dist-all dist-bzip2 \
dist-gzip dist-hook dist-lzma dist-shar dist-tarZ dist-xz \
dist-zip distcheck distclean distclean-generic distclean-hdr \
distclean-libtool distclean-tags distcleancheck distdir \
distuninstallcheck dvi dvi-am html html-am info info-am \
install install-am install-data install-data-am install-exec \
install-exec-am install-info install-info-am install-man \
install install-am install-data install-data-am install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-strip installcheck installcheck-am installdirs \
installdirs-am maintainer-clean maintainer-clean-generic \
maintainer-clean-recursive mostlyclean mostlyclean-generic \
mostlyclean-libtool mostlyclean-recursive pdf pdf-am ps ps-am \
tags tags-recursive uninstall uninstall-am uninstall-info-am
mostlyclean mostlyclean-generic mostlyclean-libtool pdf pdf-am \
ps ps-am tags tags-recursive uninstall uninstall-am
$(srcdir)/COPYRIGHT: $(srcdir)/html/copyright.html
@ -803,6 +893,7 @@ FRC.CommitLog FRC.distwarn FRC.checkcvo FRC.checkhost FRC.version:
# HMS: what was I trying to do with this?
#dot.emacs: FRC.distwarn
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

88
NEWS
View File

@ -1,3 +1,91 @@
NTP 4.2.4p8 (Harlan Stenn <stenn@ntp.org>, 2009/12/08)
Focus: Security Fixes
Severity: HIGH
This release fixes the following high-severity vulnerability:
* [Sec 1331] DoS with mode 7 packets - CVE-2009-3563.
See http://support.ntp.org/security for more information.
NTP mode 7 (MODE_PRIVATE) is used by the ntpdc query and control utility.
In contrast, ntpq uses NTP mode 6 (MODE_CONTROL), while routine NTP time
transfers use modes 1 through 5. Upon receipt of an incorrect mode 7
request or a mode 7 error response from an address which is not listed
in a "restrict ... noquery" or "restrict ... ignore" statement, ntpd will
reply with a mode 7 error response (and log a message). In this case:
* If an attacker spoofs the source address of ntpd host A in a
mode 7 response packet sent to ntpd host B, both A and B will
continuously send each other error responses, for as long as
those packets get through.
* If an attacker spoofs an address of ntpd host A in a mode 7
response packet sent to ntpd host A, A will respond to itself
endlessly, consuming CPU and logging excessively.
Credit for finding this vulnerability goes to Robin Park and Dmitri
Vinokurov of Alcatel-Lucent.
THIS IS A STRONGLY RECOMMENDED UPGRADE.
---
NTP 4.2.4p7 (Harlan Stenn <stenn@ntp.org>, 2009/05/04)
Focus: Security and Bug Fixes
Severity: HIGH
This release fixes the following high-severity vulnerability:
* [Sec 1151] Remote exploit if autokey is enabled. CVE-2009-1252
See http://support.ntp.org/security for more information.
If autokey is enabled (if ntp.conf contains a "crypto pw whatever"
line) then a carefully crafted packet sent to the machine will cause
a buffer overflow and possible execution of injected code, running
with the privileges of the ntpd process (often root).
Credit for finding this vulnerability goes to Chris Ries of CMU.
This release fixes the following low-severity vulnerabilities:
* [Sec 1144] limited (two byte) buffer overflow in ntpq. CVE-2009-0159
Credit for finding this vulnerability goes to Geoff Keating of Apple.
* [Sec 1149] use SO_EXCLUSIVEADDRUSE on Windows
Credit for finding this issue goes to Dave Hart.
This release fixes a number of bugs and adds some improvements:
* Improved logging
* Fix many compiler warnings
* Many fixes and improvements for Windows
* Adds support for AIX 6.1
* Resolves some issues under MacOS X and Solaris
THIS IS A STRONGLY RECOMMENDED UPGRADE.
---
NTP 4.2.4p6 (Harlan Stenn <stenn@ntp.org>, 2009/01/07)
Focus: Security Fix
Severity: Low
This release fixes oCERT.org's CVE-2009-0021, a vulnerability affecting
the OpenSSL library relating to the incorrect checking of the return
value of EVP_VerifyFinal function.
Credit for finding this issue goes to the Google Security Team for
finding the original issue with OpenSSL, and to ocert.org for finding
the problem in NTP and telling us about it.
This is a recommended upgrade.
---
NTP 4.2.4p5 (Harlan Stenn <stenn@ntp.org>, 2008/08/17)
Focus: Minor Bugfixes

2
README
View File

@ -1,7 +1,7 @@
Submit patches, bug reports, and enhancement requests via
http://bugs.ntp.isc.org
http://bugs.ntp.org
The ntp Distribution Base Directory

2
README.bk
View File

@ -1,6 +1,6 @@
In order to use the BitKeeper repository version of NTP you should visit
http://ntp.isc.org/Main/SoftwareDevelopment
http://support.ntp.org/Main/SoftwareDevelopment
for important information.

56
README.cvs
View File

@ -1,56 +0,0 @@
NOTE: The CVS repository for NTP is inactive. NTP is now maintained
using BitKeeper; see README.bk for more info.
To get the NTP distribution via anonymous CVS:
% cvs -d :pserver:anoncvs@www.ntp.org:/cvs/ntp login
the password is: anoncvs
% 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.
PLEASE NOTE:
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 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.

16
README.des
View File

@ -1,16 +0,0 @@
If you want DES support in ntp:
- Use MD5 instead:
- - convert your DES keys to MD5 by changing the 'A', 'N' or 'S' to 'M'
If you *need* DES support:
- first see if you can simply "want" DES support instead
- Follow the instructions in README.rsa
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".
Dave would prefer that new/alternative encryption schemes follow the
RSA API.

2
README.patches
View File

@ -2,7 +2,7 @@ See README.hackers for notes on coding styles.
The master copy of this information can be found at:
http://ntp.isc.org/bin/view/Dev/MaintainerIssues#How_to_work_on_a_bug_using_BitKe
http://support.ntp.org/Dev/MaintainerIssues#How_to_work_on_a_bug_using_BitKe
If you are going to patch both ntp-stable and ntp-dev
please do it this way:

103
README.rsa
View File

@ -1,103 +0,0 @@
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 is one might
wish for. In particular, DES under NTP will only work between machines
of the same "endianness".
Note that the next release of NTP uses OpenSSL instead of RSAREF.
--- 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
WHERE-TO-START
View File

@ -15,7 +15,7 @@ bugfixes and drivers for new and exotic radios, telephones and sundials.
This distribution is normally available by anonymous ftp as the
compressed tar archive ntp-<version>.tar.gz in the pub/ntp directory on
huey.udel.edu and <version> is the version number. The current stable
and development version numbers can be found at <http://ntp.isc.org>.
and development version numbers can be found at <http://ntp.org>.
A considerable amount of documentation, including build instructions,
configuration advice, program usage and miscellaneous information is

1
acconfig.h
View File

@ -1 +0,0 @@
#undef ULONG_CONST

481
aclocal.m4 vendored
View File

@ -1,7 +1,7 @@
# generated automatically by aclocal 1.9.6 -*- Autoconf -*-
# generated automatically by aclocal 1.11 -*- Autoconf -*-
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
# 2005 Free Software Foundation, Inc.
# 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
@ -11,6 +11,14 @@
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
m4_ifndef([AC_AUTOCONF_VERSION],
[m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.65],,
[m4_warning([this file was generated for autoconf 2.65.
You have another version of autoconf. It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.])])
# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
# serial 47 AC_PROG_LIBTOOL
@ -6175,7 +6183,7 @@ SED=$lt_cv_path_SED
AC_MSG_RESULT([$SED])
])
# Copyright (C) 2002, 2003, 2005 Free Software Foundation, Inc.
# Copyright (C) 2002, 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
@ -6185,14 +6193,31 @@ AC_MSG_RESULT([$SED])
# ----------------------------
# Automake X.Y traces this macro to ensure aclocal.m4 has been
# generated from the m4 files accompanying Automake X.Y.
AC_DEFUN([AM_AUTOMAKE_VERSION], [am__api_version="1.9"])
# (This private macro should not be called outside this file.)
AC_DEFUN([AM_AUTOMAKE_VERSION],
[am__api_version='1.11'
dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
dnl require some minimum version. Point them to the right macro.
m4_if([$1], [1.11], [],
[AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
])
# _AM_AUTOCONF_VERSION(VERSION)
# -----------------------------
# aclocal traces this macro to find the Autoconf version.
# This is a private macro too. Using m4_define simplifies
# the logic in aclocal, which can simply ignore this definition.
m4_define([_AM_AUTOCONF_VERSION], [])
# AM_SET_CURRENT_AUTOMAKE_VERSION
# -------------------------------
# Call AM_AUTOMAKE_VERSION so it can be traced.
# This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
# Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
# This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
[AM_AUTOMAKE_VERSION([1.9.6])])
[AM_AUTOMAKE_VERSION([1.11])dnl
m4_ifndef([AC_AUTOCONF_VERSION],
[m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
_AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
# AM_AUX_DIR_EXPAND -*- Autoconf -*-
@ -6249,14 +6274,14 @@ am_aux_dir=`cd $ac_aux_dir && pwd`
# AM_CONDITIONAL -*- Autoconf -*-
# Copyright (C) 1997, 2000, 2001, 2003, 2004, 2005
# Copyright (C) 1997, 2000, 2001, 2003, 2004, 2005, 2006, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 7
# serial 9
# AM_CONDITIONAL(NAME, SHELL-CONDITION)
# -------------------------------------
@ -6265,8 +6290,11 @@ AC_DEFUN([AM_CONDITIONAL],
[AC_PREREQ(2.52)dnl
ifelse([$1], [TRUE], [AC_FATAL([$0: invalid condition: $1])],
[$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
AC_SUBST([$1_TRUE])
AC_SUBST([$1_FALSE])
AC_SUBST([$1_TRUE])dnl
AC_SUBST([$1_FALSE])dnl
_AM_SUBST_NOTMAKE([$1_TRUE])dnl
_AM_SUBST_NOTMAKE([$1_FALSE])dnl
m4_define([_AM_COND_VALUE_$1], [$2])dnl
if $2; then
$1_TRUE=
$1_FALSE='#'
@ -6280,15 +6308,14 @@ AC_CONFIG_COMMANDS_PRE(
Usually this means the macro was only invoked conditionally.]])
fi])])
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2009
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 8
# serial 10
# 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,
@ -6316,6 +6343,7 @@ AC_REQUIRE([AM_DEP_TRACK])dnl
ifelse([$1], CC, [depcc="$CC" am_compiler_list=],
[$1], CXX, [depcc="$CXX" am_compiler_list=],
[$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc'],
[$1], UPC, [depcc="$UPC" am_compiler_list=],
[$1], GCJ, [depcc="$GCJ" am_compiler_list='gcc3 gcc'],
[depcc="$$1" am_compiler_list=])
@ -6344,6 +6372,16 @@ AC_CACHE_CHECK([dependency style of $depcc],
if test "$am_compiler_list" = ""; then
am_compiler_list=`sed -n ['s/^#*\([a-zA-Z0-9]*\))$/\1/p'] < ./depcomp`
fi
am__universal=false
m4_case([$1], [CC],
[case " $depcc " in #(
*\ -arch\ *\ -arch\ *) am__universal=true ;;
esac],
[CXX],
[case " $depcc " in #(
*\ -arch\ *\ -arch\ *) am__universal=true ;;
esac])
for depmode in $am_compiler_list; do
# Setup a source with many dependencies, because some compilers
# like to wrap large dependency lists on column 80 (with \), and
@ -6361,7 +6399,17 @@ AC_CACHE_CHECK([dependency style of $depcc],
done
echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf
# 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. Also, some Intel
# versions had trouble with output in subdirs
am__obj=sub/conftest.${OBJEXT-o}
am__minus_obj="-o $am__obj"
case $depmode in
gcc)
# This depmode causes a compiler race in universal mode.
test "$am__universal" = false || continue
;;
nosideeffect)
# after this tag, mechanisms are not by side-effect, so they'll
# only be used when explicitly requested
@ -6371,18 +6419,23 @@ AC_CACHE_CHECK([dependency style of $depcc],
break
fi
;;
msvisualcpp | msvcmsys)
# This compiler won't grok `-c -o', but also, the minuso test has
# not run yet. These depmodes are late enough in the game, and
# so weak that their functioning should not be impacted.
am__obj=conftest.${OBJEXT-o}
am__minus_obj=
;;
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=sub/conftest.c object=sub/conftest.${OBJEXT-o} \
source=sub/conftest.c object=$am__obj \
depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
$SHELL ./depcomp $depcc -c -o sub/conftest.${OBJEXT-o} sub/conftest.c \
$SHELL ./depcomp $depcc -c $am__minus_obj sub/conftest.c \
>/dev/null 2>conftest.err &&
grep sub/conftst1.h sub/conftest.Po > /dev/null 2>&1 &&
grep sub/conftst6.h sub/conftest.Po > /dev/null 2>&1 &&
grep sub/conftest.${OBJEXT-o} sub/conftest.Po > /dev/null 2>&1 &&
grep $am__obj sub/conftest.Po > /dev/null 2>&1 &&
${MAKE-make} -s -f confmf > /dev/null 2>&1; then
# icc doesn't choke on unknown options, it will just issue warnings
# or remarks (even with -Werror). So we grep stderr for any message
@ -6433,61 +6486,74 @@ if test "x$enable_dependency_tracking" != xno; then
AMDEPBACKSLASH='\'
fi
AM_CONDITIONAL([AMDEP], [test "x$enable_dependency_tracking" != xno])
AC_SUBST([AMDEPBACKSLASH])
AC_SUBST([AMDEPBACKSLASH])dnl
_AM_SUBST_NOTMAKE([AMDEPBACKSLASH])dnl
])
# Generate code to set up dependency tracking. -*- Autoconf -*-
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
#serial 3
#serial 5
# _AM_OUTPUT_DEPENDENCY_COMMANDS
# ------------------------------
AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
[for mf in $CONFIG_FILES; do
# Strip MF so we end up with the name of the file.
mf=`echo "$mf" | sed -e 's/:.*$//'`
# Check whether this is an Automake generated Makefile or not.
# We used to match only the files named `Makefile.in', but
# some people rename them; so instead we look at the file content.
# Grep'ing the first line is not enough: some people post-process
# each Makefile.in and add a new line on top of each file to say so.
# So let's grep whole file.
if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
dirpart=`AS_DIRNAME("$mf")`
else
continue
fi
# Extract the definition of DEPDIR, am__include, and am__quote
# from the Makefile without running `make'.
DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
test -z "$DEPDIR" && continue
am__include=`sed -n 's/^am__include = //p' < "$mf"`
test -z "am__include" && continue
am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
# When using ansi2knr, U may be empty or an underscore; expand it
U=`sed -n 's/^U = //p' < "$mf"`
# Find all dependency output files, they are included files with
# $(DEPDIR) in their names. We invoke sed twice because it is the
# simplest approach to changing $(DEPDIR) to its actual value in the
# expansion.
for file in `sed -n "
s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
# Make sure the directory exists.
test -f "$dirpart/$file" && continue
fdir=`AS_DIRNAME(["$file"])`
AS_MKDIR_P([$dirpart/$fdir])
# echo "creating $dirpart/$file"
echo '# dummy' > "$dirpart/$file"
[{
# Autoconf 2.62 quotes --file arguments for eval, but not when files
# are listed without --file. Let's play safe and only enable the eval
# if we detect the quoting.
case $CONFIG_FILES in
*\'*) eval set x "$CONFIG_FILES" ;;
*) set x $CONFIG_FILES ;;
esac
shift
for mf
do
# Strip MF so we end up with the name of the file.
mf=`echo "$mf" | sed -e 's/:.*$//'`
# Check whether this is an Automake generated Makefile or not.
# We used to match only the files named `Makefile.in', but
# some people rename them; so instead we look at the file content.
# Grep'ing the first line is not enough: some people post-process
# each Makefile.in and add a new line on top of each file to say so.
# Grep'ing the whole file is not good either: AIX grep has a line
# limit of 2048, but all sed's we know have understand at least 4000.
if sed -n 's,^#.*generated by automake.*,X,p' "$mf" | grep X >/dev/null 2>&1; then
dirpart=`AS_DIRNAME("$mf")`
else
continue
fi
# Extract the definition of DEPDIR, am__include, and am__quote
# from the Makefile without running `make'.
DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
test -z "$DEPDIR" && continue
am__include=`sed -n 's/^am__include = //p' < "$mf"`
test -z "am__include" && continue
am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
# When using ansi2knr, U may be empty or an underscore; expand it
U=`sed -n 's/^U = //p' < "$mf"`
# Find all dependency output files, they are included files with
# $(DEPDIR) in their names. We invoke sed twice because it is the
# simplest approach to changing $(DEPDIR) to its actual value in the
# expansion.
for file in `sed -n "
s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
# Make sure the directory exists.
test -f "$dirpart/$file" && continue
fdir=`AS_DIRNAME(["$file"])`
AS_MKDIR_P([$dirpart/$fdir])
# echo "creating $dirpart/$file"
echo '# dummy' > "$dirpart/$file"
done
done
done
}
])# _AM_OUTPUT_DEPENDENCY_COMMANDS
@ -6518,14 +6584,14 @@ AU_DEFUN([AM_CONFIG_HEADER], [AC_CONFIG_HEADERS($@)])
# Do all the work for Automake. -*- Autoconf -*-
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
# Free Software Foundation, Inc.
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
# 2005, 2006, 2008, 2009 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 12
# serial 16
# 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.
@ -6542,16 +6608,20 @@ AU_DEFUN([AM_CONFIG_HEADER], [AC_CONFIG_HEADERS($@)])
# arguments mandatory, and then we can depend on a new Autoconf
# release and drop the old call support.
AC_DEFUN([AM_INIT_AUTOMAKE],
[AC_PREREQ([2.58])dnl
[AC_PREREQ([2.62])dnl
dnl Autoconf wants to disallow AM_ names. We explicitly allow
dnl the ones we care about.
m4_pattern_allow([^AM_[A-Z]+FLAGS$])dnl
AC_REQUIRE([AM_SET_CURRENT_AUTOMAKE_VERSION])dnl
AC_REQUIRE([AC_PROG_INSTALL])dnl
# test to see if srcdir already configured
if test "`cd $srcdir && pwd`" != "`pwd`" &&
test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
if test "`cd $srcdir && pwd`" != "`pwd`"; then
# Use -I$(srcdir) only when $(srcdir) != ., so that make's output
# is not polluted with repeated "-I."
AC_SUBST([am__isrc], [' -I$(srcdir)'])_AM_SUBST_NOTMAKE([am__isrc])dnl
# test to see if srcdir already configured
if test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
fi
fi
# test whether we have cygpath
@ -6571,6 +6641,9 @@ m4_ifval([$2],
AC_SUBST([PACKAGE], [$1])dnl
AC_SUBST([VERSION], [$2])],
[_AM_SET_OPTIONS([$1])dnl
dnl Diagnose old-style AC_INIT with new-style AM_AUTOMAKE_INIT.
m4_if(m4_ifdef([AC_PACKAGE_NAME], 1)m4_ifdef([AC_PACKAGE_VERSION], 1), 11,,
[m4_fatal([AC_INIT should be called with package and version arguments])])dnl
AC_SUBST([PACKAGE], ['AC_PACKAGE_TARNAME'])dnl
AC_SUBST([VERSION], ['AC_PACKAGE_VERSION'])])dnl
@ -6586,8 +6659,8 @@ AM_MISSING_PROG(AUTOCONF, autoconf)
AM_MISSING_PROG(AUTOMAKE, automake-${am__api_version})
AM_MISSING_PROG(AUTOHEADER, autoheader)
AM_MISSING_PROG(MAKEINFO, makeinfo)
AM_PROG_INSTALL_SH
AM_PROG_INSTALL_STRIP
AC_REQUIRE([AM_PROG_INSTALL_SH])dnl
AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl
AC_REQUIRE([AM_PROG_MKDIR_P])dnl
# We need awk for the "check" target. The system "awk" is bad on
# some platforms.
@ -6595,20 +6668,37 @@ AC_REQUIRE([AC_PROG_AWK])dnl
AC_REQUIRE([AC_PROG_MAKE_SET])dnl
AC_REQUIRE([AM_SET_LEADING_DOT])dnl
_AM_IF_OPTION([tar-ustar], [_AM_PROG_TAR([ustar])],
[_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])],
[_AM_PROG_TAR([v7])])])
[_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])],
[_AM_PROG_TAR([v7])])])
_AM_IF_OPTION([no-dependencies],,
[AC_PROVIDE_IFELSE([AC_PROG_CC],
[_AM_DEPENDENCIES(CC)],
[define([AC_PROG_CC],
defn([AC_PROG_CC])[_AM_DEPENDENCIES(CC)])])dnl
[_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
[_AM_DEPENDENCIES(CXX)],
[define([AC_PROG_CXX],
defn([AC_PROG_CXX])[_AM_DEPENDENCIES(CXX)])])dnl
AC_PROVIDE_IFELSE([AC_PROG_OBJC],
[_AM_DEPENDENCIES(OBJC)],
[define([AC_PROG_OBJC],
defn([AC_PROG_OBJC])[_AM_DEPENDENCIES(OBJC)])])dnl
])
_AM_IF_OPTION([silent-rules], [AC_REQUIRE([AM_SILENT_RULES])])dnl
dnl The `parallel-tests' driver may need to know about EXEEXT, so add the
dnl `am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen. This macro
dnl is hooked onto _AC_COMPILER_EXEEXT early, see below.
AC_CONFIG_COMMANDS_PRE(dnl
[m4_provide_if([_AM_COMPILER_EXEEXT],
[AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
])
dnl Hook into `_AC_COMPILER_EXEEXT' early to learn its expansion. Do not
dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further
dnl mangled by Autoconf and run in a shell conditional statement.
m4_define([_AC_COMPILER_EXEEXT],
m4_defn([_AC_COMPILER_EXEEXT])[m4_provide([_AM_COMPILER_EXEEXT])])
# When config.status generates a header, we must update the stamp-h file.
# This file resides in the same directory as the config header
@ -6619,18 +6709,19 @@ AC_PROVIDE_IFELSE([AC_PROG_CXX],
# our stamp files there.
AC_DEFUN([_AC_AM_CONFIG_HEADER_HOOK],
[# Compute $1's index in $config_headers.
_am_arg=$1
_am_stamp_count=1
for _am_header in $config_headers :; do
case $_am_header in
$1 | $1:* )
$_am_arg | $_am_arg:* )
break ;;
* )
_am_stamp_count=`expr $_am_stamp_count + 1` ;;
esac
done
echo "timestamp for $1" >`AS_DIRNAME([$1])`/stamp-h[]$_am_stamp_count])
echo "timestamp for $_am_arg" >`AS_DIRNAME(["$_am_arg"])`/stamp-h[]$_am_stamp_count])
# Copyright (C) 2001, 2003, 2005 Free Software Foundation, Inc.
# Copyright (C) 2001, 2003, 2005, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
@ -6641,7 +6732,14 @@ echo "timestamp for $1" >`AS_DIRNAME([$1])`/stamp-h[]$_am_stamp_count])
# Define $install_sh.
AC_DEFUN([AM_PROG_INSTALL_SH],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
install_sh=${install_sh-"$am_aux_dir/install-sh"}
if test x"${install_sh}" != xset; then
case $am_aux_dir in
*\ * | *\ *)
install_sh="\${SHELL} '$am_aux_dir/install-sh'" ;;
*)
install_sh="\${SHELL} $am_aux_dir/install-sh"
esac
fi
AC_SUBST(install_sh)])
# Copyright (C) 2003, 2005 Free Software Foundation, Inc.
@ -6667,13 +6765,13 @@ AC_SUBST([am__leading_dot])])
# Check to see how 'make' treats includes. -*- Autoconf -*-
# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
# Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 3
# serial 4
# AM_MAKE_INCLUDE()
# -----------------
@ -6682,7 +6780,7 @@ AC_DEFUN([AM_MAKE_INCLUDE],
[am_make=${MAKE-make}
cat > confinc << 'END'
am__doit:
@echo done
@echo this is the am__doit target
.PHONY: am__doit
END
# If we don't find an include directive, just comment out the code.
@ -6692,24 +6790,24 @@ am__quote=
_am_result=none
# First try GNU make style include.
echo "include confinc" > confmf
# We grep out `Entering directory' and `Leaving directory'
# messages which can occur if `w' ends up in MAKEFLAGS.
# In particular we don't look at `^make:' because GNU make might
# be invoked under some other name (usually "gmake"), in which
# case it prints its new name instead of `make'.
if test "`$am_make -s -f confmf 2> /dev/null | grep -v 'ing directory'`" = "done"; then
am__include=include
am__quote=
_am_result=GNU
fi
# Ignore all kinds of additional output from `make'.
case `$am_make -s -f confmf 2> /dev/null` in #(
*the\ am__doit\ target*)
am__include=include
am__quote=
_am_result=GNU
;;
esac
# Now try BSD make style include.
if test "$am__include" = "#"; then
echo '.include "confinc"' > confmf
if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then
am__include=.include
am__quote="\""
_am_result=BSD
fi
case `$am_make -s -f confmf 2> /dev/null` in #(
*the\ am__doit\ target*)
am__include=.include
am__quote="\""
_am_result=BSD
;;
esac
fi
AC_SUBST([am__include])
AC_SUBST([am__quote])
@ -6717,16 +6815,51 @@ AC_MSG_RESULT([$_am_result])
rm -f confinc confmf
])
# Fake the existence of programs that GNU maintainers use. -*- Autoconf -*-
# Copyright (C) 1997, 1999, 2000, 2001, 2003, 2005
# Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 4
# serial 6
# AM_PROG_CC_C_O
# --------------
# Like AC_PROG_CC_C_O, but changed for automake.
AC_DEFUN([AM_PROG_CC_C_O],
[AC_REQUIRE([AC_PROG_CC_C_O])dnl
AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
AC_REQUIRE_AUX_FILE([compile])dnl
# FIXME: we rely on the cache variable name because
# there is no other way.
set dummy $CC
am_cc=`echo $[2] | sed ['s/[^a-zA-Z0-9_]/_/g;s/^[0-9]/_/']`
eval am_t=\$ac_cv_prog_cc_${am_cc}_c_o
if test "$am_t" != yes; then
# Losing compiler, so override with the script.
# FIXME: It is wrong to rewrite CC.
# But if we don't then we get into trouble of one sort or another.
# A longer-term fix would be to have automake use am__CC in this case,
# and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
CC="$am_aux_dir/compile $CC"
fi
dnl Make sure AC_PROG_CC is never called again, or it will override our
dnl setting of CC.
m4_define([AC_PROG_CC],
[m4_fatal([AC_PROG_CC cannot be called after AM_PROG_CC_C_O])])
])
# Fake the existence of programs that GNU maintainers use. -*- Autoconf -*-
# Copyright (C) 1997, 1999, 2000, 2001, 2003, 2004, 2005, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 6
# AM_MISSING_PROG(NAME, PROGRAM)
# ------------------------------
@ -6742,7 +6875,15 @@ AC_SUBST($1)])
# If it does, set am_missing_run to use it, otherwise, to nothing.
AC_DEFUN([AM_MISSING_HAS_RUN],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
test x"${MISSING+set}" = xset || MISSING="\${SHELL} $am_aux_dir/missing"
AC_REQUIRE_AUX_FILE([missing])dnl
if test x"${MISSING+set}" != xset; then
case $am_aux_dir in
*\ * | *\ *)
MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
*)
MISSING="\${SHELL} $am_aux_dir/missing" ;;
esac
fi
# Use eval to expand $SHELL
if eval "$MISSING --run true"; then
am_missing_run="$MISSING --run "
@ -6752,7 +6893,7 @@ else
fi
])
# Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
# Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
@ -6760,70 +6901,33 @@ fi
# AM_PROG_MKDIR_P
# ---------------
# Check whether `mkdir -p' is supported, fallback to mkinstalldirs otherwise.
#
# Automake 1.8 used `mkdir -m 0755 -p --' to ensure that directories
# created by `make install' are always world readable, even if the
# installer happens to have an overly restrictive umask (e.g. 077).
# This was a mistake. There are at least two reasons why we must not
# use `-m 0755':
# - it causes special bits like SGID to be ignored,
# - it may be too restrictive (some setups expect 775 directories).
#
# Do not use -m 0755 and let people choose whatever they expect by
# setting umask.
#
# We cannot accept any implementation of `mkdir' that recognizes `-p'.
# Some implementations (such as Solaris 8's) are not thread-safe: if a
# parallel make tries to run `mkdir -p a/b' and `mkdir -p a/c'
# concurrently, both version can detect that a/ is missing, but only
# one can create it and the other will error out. Consequently we
# restrict ourselves to GNU make (using the --version option ensures
# this.)
# Check for `mkdir -p'.
AC_DEFUN([AM_PROG_MKDIR_P],
[if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
# We used to keeping the `.' as first argument, in order to
# allow $(mkdir_p) to be used without argument. As in
# $(mkdir_p) $(somedir)
# where $(somedir) is conditionally defined. However this is wrong
# for two reasons:
# 1. if the package is installed by a user who cannot write `.'
# make install will fail,
# 2. the above comment should most certainly read
# $(mkdir_p) $(DESTDIR)$(somedir)
# so it does not work when $(somedir) is undefined and
# $(DESTDIR) is not.
# To support the latter case, we have to write
# test -z "$(somedir)" || $(mkdir_p) $(DESTDIR)$(somedir),
# so the `.' trick is pointless.
mkdir_p='mkdir -p --'
else
# On NextStep and OpenStep, the `mkdir' command does not
# recognize any option. It will interpret all options as
# directories to create, and then abort because `.' already
# exists.
for d in ./-p ./--version;
do
test -d $d && rmdir $d
done
# $(mkinstalldirs) is defined by Automake if mkinstalldirs exists.
if test -f "$ac_aux_dir/mkinstalldirs"; then
mkdir_p='$(mkinstalldirs)'
else
mkdir_p='$(install_sh) -d'
fi
fi
AC_SUBST([mkdir_p])])
[AC_PREREQ([2.60])dnl
AC_REQUIRE([AC_PROG_MKDIR_P])dnl
dnl Automake 1.8 to 1.9.6 used to define mkdir_p. We now use MKDIR_P,
dnl while keeping a definition of mkdir_p for backward compatibility.
dnl @MKDIR_P@ is magic: AC_OUTPUT adjusts its value for each Makefile.
dnl However we cannot define mkdir_p as $(MKDIR_P) for the sake of
dnl Makefile.ins that do not define MKDIR_P, so we do our own
dnl adjustment using top_builddir (which is defined more often than
dnl MKDIR_P).
AC_SUBST([mkdir_p], ["$MKDIR_P"])dnl
case $mkdir_p in
[[\\/$]]* | ?:[[\\/]]*) ;;
*/*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
esac
])
# Helper functions for option handling. -*- Autoconf -*-
# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
# Copyright (C) 2001, 2002, 2003, 2005, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 3
# serial 4
# _AM_MANGLE_OPTION(NAME)
# -----------------------
@ -6840,7 +6944,7 @@ AC_DEFUN([_AM_SET_OPTION],
# ----------------------------------
# OPTIONS is a space-separated list of Automake options.
AC_DEFUN([_AM_SET_OPTIONS],
[AC_FOREACH([_AM_Option], [$1], [_AM_SET_OPTION(_AM_Option)])])
[m4_foreach_w([_AM_Option], [$1], [_AM_SET_OPTION(_AM_Option)])])
# _AM_IF_OPTION(OPTION, IF-SET, [IF-NOT-SET])
# -------------------------------------------
@ -6848,14 +6952,14 @@ AC_DEFUN([_AM_SET_OPTIONS],
AC_DEFUN([_AM_IF_OPTION],
[m4_ifset(_AM_MANGLE_OPTION([$1]), [$2], [$3])])
# Copyright (C) 1996, 1997, 1998, 2000, 2001, 2002, 2003, 2005
# Copyright (C) 1996, 1997, 1998, 2000, 2001, 2002, 2003, 2005, 2006
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 4
# serial 5
AC_DEFUN([AM_C_PROTOTYPES],
[AC_REQUIRE([AC_C_PROTOTYPES])
@ -6866,23 +6970,24 @@ else
fi
# Ensure some checks needed by ansi2knr itself.
AC_REQUIRE([AC_HEADER_STDC])
AC_CHECK_HEADERS(string.h)
AC_SUBST(U)dnl
AC_SUBST(ANSI2KNR)dnl
AC_CHECK_HEADERS([string.h])
AC_SUBST([U])dnl
AC_SUBST([ANSI2KNR])dnl
_AM_SUBST_NOTMAKE([ANSI2KNR])dnl
])
AU_DEFUN([fp_C_PROTOTYPES], [AM_C_PROTOTYPES])
# Check to make sure that the build environment is sane. -*- Autoconf -*-
# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005
# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 4
# serial 5
# AM_SANITY_CHECK
# ---------------
@ -6891,16 +6996,29 @@ AC_DEFUN([AM_SANITY_CHECK],
# Just in case
sleep 1
echo timestamp > conftest.file
# Reject unsafe characters in $srcdir or the absolute working directory
# name. Accept space and tab only in the latter.
am_lf='
'
case `pwd` in
*[[\\\"\#\$\&\'\`$am_lf]]*)
AC_MSG_ERROR([unsafe absolute working directory name]);;
esac
case $srcdir in
*[[\\\"\#\$\&\'\`$am_lf\ \ ]]*)
AC_MSG_ERROR([unsafe srcdir value: `$srcdir']);;
esac
# 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 conftest.file 2> /dev/null`
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 conftest.file`
set X `ls -t "$srcdir/configure" conftest.file`
fi
rm -f conftest.file
if test "$[*]" != "X $srcdir/configure conftest.file" \
@ -6950,9 +7068,28 @@ dnl Don't test for $cross_compiling = yes, because it might be `maybe'.
if test "$cross_compiling" != no; then
AC_CHECK_TOOL([STRIP], [strip], :)
fi
INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s"
INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s"
AC_SUBST([INSTALL_STRIP_PROGRAM])])
# Copyright (C) 2006, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 2
# _AM_SUBST_NOTMAKE(VARIABLE)
# ---------------------------
# Prevent Automake from outputting VARIABLE = @VARIABLE@ in Makefile.in.
# This macro is traced by Automake.
AC_DEFUN([_AM_SUBST_NOTMAKE])
# AM_SUBST_NOTMAKE(VARIABLE)
# ---------------------------
# Public sister of _AM_SUBST_NOTMAKE.
AC_DEFUN([AM_SUBST_NOTMAKE], [_AM_SUBST_NOTMAKE($@)])
# Check how to create a tarball. -*- Autoconf -*-
# Copyright (C) 2004, 2005 Free Software Foundation, Inc.

278
adjtimed/Makefile.in
View File

@ -1,8 +1,9 @@
# Makefile.in generated by automake 1.9.6 from Makefile.am.
# Makefile.in generated by automake 1.11 from Makefile.am.
# @configure_input@
# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
# 2003, 2004, 2005 Free Software Foundation, Inc.
# 2003, 2004, 2005, 2006, 2007, 2008, 2009 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.
@ -18,15 +19,12 @@
# in sbindir. Now that we offer a choice, look in the "other" installation
# subdir to warn folks if there is another version there.
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
top_builddir = ..
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
INSTALL = @INSTALL@
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
@ -41,7 +39,6 @@ POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
ANSI2KNR = ../util/ansi2knr
bin_PROGRAMS = @MAKE_ADJTIMED@
EXTRA_PROGRAMS = adjtimed$(EXEEXT)
DIST_COMMON = README $(srcdir)/../bincheck.mf $(srcdir)/Makefile.am \
$(srcdir)/Makefile.in
@ -57,32 +54,32 @@ am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
am__installdirs = "$(DESTDIR)$(bindir)"
binPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
PROGRAMS = $(bin_PROGRAMS)
adjtimed_SOURCES = adjtimed.c
adjtimed_OBJECTS = adjtimed$U.$(OBJEXT)
adjtimed_LDADD = $(LDADD)
adjtimed_DEPENDENCIES = ../libntp/libntp.a
DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)
DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
depcomp = $(SHELL) $(top_srcdir)/depcomp
am__depfiles_maybe = depfiles
am__mv = mv -f
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
LINK = $(LIBTOOL) --tag=CC --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
$(AM_LDFLAGS) $(LDFLAGS) -o $@
LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@
SOURCES = adjtimed.c
DIST_SOURCES = adjtimed.c
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
AMDEP_FALSE = @AMDEP_FALSE@
AMDEP_TRUE = @AMDEP_TRUE@
AMTAR = @AMTAR@
AR = @AR@
ARLIB_DIR = @ARLIB_DIR@
@ -98,10 +95,6 @@ CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CXX = @CXX@
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
CXXFLAGS = @CXXFLAGS@
CYGPATH_W = @CYGPATH_W@
DCFD = @DCFD@
DEFS = @DEFS@
@ -114,11 +107,10 @@ EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
F77 = @F77@
FFLAGS = @FFLAGS@
GREP = @GREP@
HAVE_INLINE = @HAVE_INLINE@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_LIBOPTS_FALSE = @INSTALL_LIBOPTS_FALSE@
INSTALL_LIBOPTS_TRUE = @INSTALL_LIBOPTS_TRUE@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
@ -132,6 +124,7 @@ LIBPARSE = @LIBPARSE@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LN_S = @LN_S@
LSCF = @LSCF@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAKE_ADJTIMED = @MAKE_ADJTIMED@
@ -145,8 +138,7 @@ MAKE_NTPTIME = @MAKE_NTPTIME@
MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
NEED_LIBOPTS_FALSE = @NEED_LIBOPTS_FALSE@
NEED_LIBOPTS_TRUE = @NEED_LIBOPTS_TRUE@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
@ -156,6 +148,7 @@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_PERL = @PATH_PERL@
PATH_SEPARATOR = @PATH_SEPARATOR@
@ -169,16 +162,11 @@ STRIP = @STRIP@
TESTDCF = @TESTDCF@
U = @U@
VERSION = @VERSION@
ac_ct_AR = @ac_ct_AR@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
ac_ct_CXX = @ac_ct_CXX@
ac_ct_F77 = @ac_ct_F77@
ac_ct_RANLIB = @ac_ct_RANLIB@
ac_ct_STRIP = @ac_ct_STRIP@
am__fastdepCC_FALSE = @am__fastdepCC_FALSE@
am__fastdepCC_TRUE = @am__fastdepCC_TRUE@
am__fastdepCXX_FALSE = @am__fastdepCXX_FALSE@
am__fastdepCXX_TRUE = @am__fastdepCXX_TRUE@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
@ -190,30 +178,43 @@ build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
subdirs = @subdirs@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
AUTOMAKE_OPTIONS = ../util/ansi2knr
bin_PROGRAMS = @MAKE_ADJTIMED@
AM_CPPFLAGS = -I$(top_srcdir)/include
LDADD = ../libntp/libntp.a
ETAGS_ARGS = Makefile.am
@ -225,14 +226,14 @@ $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(srcdir)/../bincheck.mf $(am__con
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \
&& exit 0; \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign adjtimed/Makefile'; \
cd $(top_srcdir) && \
$(AUTOMAKE) --foreign adjtimed/Makefile
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign adjtimed/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign adjtimed/Makefile
.PRECIOUS: Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
@ -250,37 +251,53 @@ $(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-binPROGRAMS: $(bin_PROGRAMS)
@$(NORMAL_INSTALL)
test -z "$(bindir)" || $(mkdir_p) "$(DESTDIR)$(bindir)"
@list='$(bin_PROGRAMS)'; for p in $$list; do \
p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
if test -f $$p \
|| test -f $$p1 \
; then \
f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(binPROGRAMS_INSTALL) '$$p' '$(DESTDIR)$(bindir)/$$f'"; \
$(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(binPROGRAMS_INSTALL) "$$p" "$(DESTDIR)$(bindir)/$$f" || exit 1; \
else :; fi; \
done
test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
for p in $$list; do echo "$$p $$p"; done | \
sed 's/$(EXEEXT)$$//' | \
while read p p1; do if test -f $$p || test -f $$p1; \
then echo "$$p"; echo "$$p"; else :; fi; \
done | \
sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
-e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
sed 'N;N;N;s,\n, ,g' | \
$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
{ d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
if ($$2 == $$4) files[d] = files[d] " " $$1; \
else { print "f", $$3 "/" $$4, $$1; } } \
END { for (d in files) print "f", d, files[d] }' | \
while read type dir files; do \
if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
test -z "$$files" || { \
echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
$(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
} \
; done
uninstall-binPROGRAMS:
@$(NORMAL_UNINSTALL)
@list='$(bin_PROGRAMS)'; for p in $$list; do \
f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
echo " rm -f '$(DESTDIR)$(bindir)/$$f'"; \
rm -f "$(DESTDIR)$(bindir)/$$f"; \
done
@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
files=`for p in $$list; do echo "$$p"; done | \
sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
-e 's/$$/$(EXEEXT)/' `; \
test -n "$$list" || exit 0; \
echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
cd "$(DESTDIR)$(bindir)" && rm -f $$files
clean-binPROGRAMS:
@list='$(bin_PROGRAMS)'; for p in $$list; do \
f=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
echo " rm -f $$p $$f"; \
rm -f $$p $$f ; \
done
@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
echo " rm -f" $$list; \
rm -f $$list || exit $$?; \
test -n "$(EXEEXT)" || exit 0; \
list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
echo " rm -f" $$list; \
rm -f $$list
adjtimed$(EXEEXT): $(adjtimed_OBJECTS) $(adjtimed_DEPENDENCIES)
@rm -f adjtimed$(EXEEXT)
$(LINK) $(adjtimed_LDFLAGS) $(adjtimed_OBJECTS) $(adjtimed_LDADD) $(LIBS)
$(LINK) $(adjtimed_OBJECTS) $(adjtimed_LDADD) $(LIBS)
mostlyclean-compile:
-rm -f *.$(OBJEXT)
@ -288,7 +305,7 @@ mostlyclean-compile:
distclean-compile:
-rm -f *.tab.c
../util/ansi2knr:
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr
$(am__cd) ../util && $(MAKE) $(AM_MAKEFLAGS) ./ansi2knr
mostlyclean-kr:
-test "$U" = "" || rm -f *_.c
@ -296,22 +313,22 @@ mostlyclean-kr:
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/adjtimed$U.Po@am__quote@
.c.o:
@am__fastdepCC_TRUE@ if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c $<
.c.obj:
@am__fastdepCC_TRUE@ if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ `$(CYGPATH_W) '$<'`; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c `$(CYGPATH_W) '$<'`
.c.lo:
@am__fastdepCC_TRUE@ if $(LTCOMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Plo"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(LTCOMPILE) -c -o $@ $<
@ -325,83 +342,85 @@ mostlyclean-libtool:
clean-libtool:
-rm -rf .libs _libs
distclean-libtool:
-rm -f libtool
uninstall-info-am:
ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
mkid -fID $$unique
tags: TAGS
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
set x; \
here=`pwd`; \
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
if test -z "$(ETAGS_ARGS)$$tags$$unique"; then :; else \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
shift; \
if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
test -n "$$unique" || unique=$$empty_fix; \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$tags $$unique; \
if test $$# -gt 0; then \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
"$$@" $$unique; \
else \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$unique; \
fi; \
fi
ctags: CTAGS
CTAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
here=`pwd`; \
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$(CTAGS_ARGS)$$tags$$unique" \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
test -z "$(CTAGS_ARGS)$$unique" \
|| $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
$$tags $$unique
$$unique
GTAGS:
here=`$(am__cd) $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) $$here
&& $(am__cd) $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) "$$here"
distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
distdir: $(DISTFILES)
$(mkdir_p) $(distdir)/..
@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's|.|.|g'`; \
list='$(DISTFILES)'; for file in $$list; do \
case $$file in \
$(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \
$(top_srcdir)/*) file=`echo "$$file" | sed "s|^$$topsrcdirstrip/|$(top_builddir)/|"`;; \
esac; \
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
if test "$$dir" != "$$file" && test "$$dir" != "."; then \
dir="/$$dir"; \
$(mkdir_p) "$(distdir)$$dir"; \
else \
dir=''; \
fi; \
if test -d $$d/$$file; then \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f $(distdir)/$$file \
|| cp -p $$d/$$file $(distdir)/$$file \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
@ -410,7 +429,7 @@ check: check-am
all-am: Makefile $(PROGRAMS)
installdirs:
for dir in "$(DESTDIR)$(bindir)"; do \
test -z "$$dir" || $(mkdir_p) "$$dir"; \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
@ -432,6 +451,7 @@ clean-generic:
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@ -444,7 +464,7 @@ distclean: distclean-am
-rm -rf ./$(DEPDIR)
-rm -f Makefile
distclean-am: clean-am distclean-compile distclean-generic \
distclean-libtool distclean-tags
distclean-tags
dvi: dvi-am
@ -452,20 +472,39 @@ dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am:
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am: install-binPROGRAMS
@$(NORMAL_INSTALL)
$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
@ -486,19 +525,23 @@ ps: ps-am
ps-am:
uninstall-am: uninstall-binPROGRAMS uninstall-info-am
uninstall-am: uninstall-binPROGRAMS
.MAKE: ../util/ansi2knr install-am install-exec-am install-strip
.PHONY: CTAGS GTAGS all all-am check check-am clean clean-binPROGRAMS \
clean-generic clean-libtool ctags distclean distclean-compile \
distclean-generic distclean-libtool distclean-tags distdir dvi \
dvi-am html html-am info info-am install install-am \
install-binPROGRAMS install-data install-data-am install-exec \
install-exec-am install-exec-hook install-info install-info-am \
install-man install-strip installcheck installcheck-am \
install-binPROGRAMS install-data install-data-am install-dvi \
install-dvi-am install-exec install-exec-am install-exec-hook \
install-html install-html-am install-info install-info-am \
install-man install-pdf install-pdf-am install-ps \
install-ps-am install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-compile mostlyclean-generic \
mostlyclean-kr mostlyclean-libtool pdf pdf-am ps ps-am tags \
uninstall uninstall-am uninstall-binPROGRAMS uninstall-info-am
uninstall uninstall-am uninstall-binPROGRAMS
install-exec-hook:
@ -512,6 +555,7 @@ install-exec-hook:
done
#
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

234
arlib/Makefile.in
View File

@ -1,8 +1,9 @@
# Makefile.in generated by automake 1.9.6 from Makefile.am.
# Makefile.in generated by automake 1.11 from Makefile.am.
# @configure_input@
# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
# 2003, 2004, 2005 Free Software Foundation, Inc.
# 2003, 2004, 2005, 2006, 2007, 2008, 2009 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.
@ -16,15 +17,12 @@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
top_builddir = .
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
INSTALL = @INSTALL@
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
@ -47,9 +45,10 @@ am__aclocal_m4_deps = $(top_srcdir)/configure.in
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
configure.lineno configure.status.lineno
configure.lineno config.status.lineno
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
LIBRARIES = $(noinst_LIBRARIES)
AR = ar
ARFLAGS = cru
@ -61,9 +60,10 @@ PROGRAMS = $(noinst_PROGRAMS)
am_example_OBJECTS = sample.$(OBJEXT)
example_OBJECTS = $(am_example_OBJECTS)
example_DEPENDENCIES = libares.a
DEFAULT_INCLUDES = -I. -I$(srcdir)
DEFAULT_INCLUDES = -I.@am__isrc@
depcomp = $(SHELL) $(top_srcdir)/depcomp
am__depfiles_maybe = depfiles
am__mv = mv -f
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
@ -77,16 +77,14 @@ DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)
am__remove_distdir = \
{ test ! -d $(distdir) \
|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
&& rm -fr $(distdir); }; }
{ test ! -d "$(distdir)" \
|| { find "$(distdir)" -type d ! -perm -200 -exec chmod u+w {} ';' \
&& rm -fr "$(distdir)"; }; }
DIST_ARCHIVES = $(distdir).tar.gz
GZIP_ENV = --best
distuninstallcheck_listfiles = find . -type f -print
distcleancheck_listfiles = find . -type f -print
ACLOCAL = @ACLOCAL@
AMDEP_FALSE = @AMDEP_FALSE@
AMDEP_TRUE = @AMDEP_TRUE@
AMTAR = @AMTAR@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
@ -103,6 +101,7 @@ ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
EXEEXT = @EXEEXT@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
@ -112,12 +111,14 @@ LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
RANLIB = @RANLIB@
@ -125,11 +126,11 @@ SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRIP = @STRIP@
VERSION = @VERSION@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
ac_ct_RANLIB = @ac_ct_RANLIB@
ac_ct_STRIP = @ac_ct_STRIP@
am__fastdepCC_FALSE = @am__fastdepCC_FALSE@
am__fastdepCC_TRUE = @am__fastdepCC_TRUE@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
@ -137,24 +138,36 @@ am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build_alias = @build_alias@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host_alias = @host_alias@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
AUTOMAKE_OPTIONS = foreign # ansi2knr
#lib_LIBRARIES = libares.a
@ -178,15 +191,15 @@ $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
echo ' cd $(srcdir) && $(AUTOMAKE) --foreign '; \
cd $(srcdir) && $(AUTOMAKE) --foreign \
echo ' cd $(srcdir) && $(AUTOMAKE) --foreign'; \
$(am__cd) $(srcdir) && $(AUTOMAKE) --foreign \
&& exit 0; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile'; \
cd $(top_srcdir) && \
$(AUTOMAKE) --foreign Makefile
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign Makefile
.PRECIOUS: Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
@ -202,9 +215,10 @@ $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENC
$(SHELL) ./config.status --recheck
$(top_srcdir)/configure: $(am__configure_deps)
cd $(srcdir) && $(AUTOCONF)
$(am__cd) $(srcdir) && $(AUTOCONF)
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
$(am__cd) $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
$(am__aclocal_m4_deps):
clean-noinstLIBRARIES:
-test -z "$(noinst_LIBRARIES)" || rm -f $(noinst_LIBRARIES)
@ -217,7 +231,7 @@ clean-noinstPROGRAMS:
-test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)
example$(EXEEXT): $(example_OBJECTS) $(example_DEPENDENCIES)
@rm -f example$(EXEEXT)
$(LINK) $(example_LDFLAGS) $(example_OBJECTS) $(example_LDADD) $(LIBS)
$(LINK) $(example_OBJECTS) $(example_LDADD) $(LIBS)
mostlyclean-compile:
-rm -f *.$(OBJEXT)
@ -229,102 +243,109 @@ distclean-compile:
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sample.Po@am__quote@
.c.o:
@am__fastdepCC_TRUE@ if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c $<
.c.obj:
@am__fastdepCC_TRUE@ if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ `$(CYGPATH_W) '$<'`; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c `$(CYGPATH_W) '$<'`
uninstall-info-am:
ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
mkid -fID $$unique
tags: TAGS
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
set x; \
here=`pwd`; \
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
if test -z "$(ETAGS_ARGS)$$tags$$unique"; then :; else \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
shift; \
if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
test -n "$$unique" || unique=$$empty_fix; \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$tags $$unique; \
if test $$# -gt 0; then \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
"$$@" $$unique; \
else \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$unique; \
fi; \
fi
ctags: CTAGS
CTAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
here=`pwd`; \
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$(CTAGS_ARGS)$$tags$$unique" \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
test -z "$(CTAGS_ARGS)$$unique" \
|| $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
$$tags $$unique
$$unique
GTAGS:
here=`$(am__cd) $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) $$here
&& $(am__cd) $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) "$$here"
distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
distdir: $(DISTFILES)
$(am__remove_distdir)
mkdir $(distdir)
@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's|.|.|g'`; \
list='$(DISTFILES)'; for file in $$list; do \
case $$file in \
$(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \
$(top_srcdir)/*) file=`echo "$$file" | sed "s|^$$topsrcdirstrip/|$(top_builddir)/|"`;; \
esac; \
test -d "$(distdir)" || mkdir "$(distdir)"
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
if test "$$dir" != "$$file" && test "$$dir" != "."; then \
dir="/$$dir"; \
$(mkdir_p) "$(distdir)$$dir"; \
else \
dir=''; \
fi; \
if test -d $$d/$$file; then \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f $(distdir)/$$file \
|| cp -p $$d/$$file $(distdir)/$$file \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
-find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
-test -n "$(am__skip_mode_fix)" \
|| 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)
! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r "$(distdir)"
dist-gzip: distdir
tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz
$(am__remove_distdir)
@ -333,6 +354,14 @@ dist-bzip2: distdir
tardir=$(distdir) && $(am__tar) | bzip2 -9 -c >$(distdir).tar.bz2
$(am__remove_distdir)
dist-lzma: distdir
tardir=$(distdir) && $(am__tar) | lzma -9 -c >$(distdir).tar.lzma
$(am__remove_distdir)
dist-xz: distdir
tardir=$(distdir) && $(am__tar) | xz -c >$(distdir).tar.xz
$(am__remove_distdir)
dist-tarZ: distdir
tardir=$(distdir) && $(am__tar) | compress -c >$(distdir).tar.Z
$(am__remove_distdir)
@ -359,6 +388,10 @@ distcheck: dist
GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz | $(am__untar) ;;\
*.tar.bz2*) \
bunzip2 -c $(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.lzma*) \
unlzma -c $(distdir).tar.lzma | $(am__untar) ;;\
*.tar.xz*) \
xz -dc $(distdir).tar.xz | $(am__untar) ;;\
*.tar.Z*) \
uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
*.shar.gz*) \
@ -370,9 +403,11 @@ distcheck: dist
mkdir $(distdir)/_build
mkdir $(distdir)/_inst
chmod a-w $(distdir)
test -d $(distdir)/_build || exit 0; \
dc_install_base=`$(am__cd) $(distdir)/_inst && pwd | sed -e 's,^[^:\\/]:[\\/],/,'` \
&& dc_destdir="$${TMPDIR-/tmp}/am-dc-$$$$/" \
&& cd $(distdir)/_build \
&& am__cwd=`pwd` \
&& $(am__cd) $(distdir)/_build \
&& ../configure --srcdir=.. --prefix="$$dc_install_base" \
$(DISTCHECK_CONFIGURE_FLAGS) \
&& $(MAKE) $(AM_MAKEFLAGS) \
@ -394,13 +429,15 @@ distcheck: dist
&& rm -rf "$$dc_destdir" \
&& $(MAKE) $(AM_MAKEFLAGS) dist \
&& rm -rf $(DIST_ARCHIVES) \
&& $(MAKE) $(AM_MAKEFLAGS) distcleancheck
&& $(MAKE) $(AM_MAKEFLAGS) distcleancheck \
&& cd "$$am__cwd" \
|| exit 1
$(am__remove_distdir)
@(echo "$(distdir) archives ready for distribution: "; \
list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
sed -e '1{h;s/./=/g;p;x;}' -e '$${p;x;}'
sed -e 1h -e 1s/./=/g -e 1p -e 1x -e '$$p' -e '$$x'
distuninstallcheck:
@cd $(distuninstallcheck_dir) \
@$(am__cd) '$(distuninstallcheck_dir)' \
&& test `$(distuninstallcheck_listfiles) | wc -l` -le 1 \
|| { echo "ERROR: files left after uninstall:" ; \
if test -n "$(DESTDIR)"; then \
@ -441,6 +478,7 @@ clean-generic:
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@ -463,18 +501,38 @@ dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am:
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
@ -496,20 +554,26 @@ ps: ps-am
ps-am:
uninstall-am: uninstall-info-am
uninstall-am:
.MAKE: install-am install-strip
.PHONY: CTAGS GTAGS all all-am am--refresh check check-am clean \
clean-generic clean-noinstLIBRARIES clean-noinstPROGRAMS ctags \
dist dist-all dist-bzip2 dist-gzip dist-shar dist-tarZ \
dist-zip distcheck distclean distclean-compile \
distclean-generic distclean-tags distcleancheck distdir \
distuninstallcheck dvi dvi-am html html-am info info-am \
install install-am install-data install-data-am install-exec \
install-exec-am install-info install-info-am install-man \
install-strip installcheck installcheck-am installdirs \
maintainer-clean maintainer-clean-generic mostlyclean \
mostlyclean-compile mostlyclean-generic pdf pdf-am ps ps-am \
tags uninstall uninstall-am uninstall-info-am
dist dist-all dist-bzip2 dist-gzip dist-lzma dist-shar \
dist-tarZ dist-xz dist-zip distcheck distclean \
distclean-compile distclean-generic distclean-tags \
distcleancheck distdir distuninstallcheck dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dvi install-dvi-am install-exec \
install-exec-am install-html install-html-am install-info \
install-info-am install-man install-pdf install-pdf-am \
install-ps install-ps-am install-strip installcheck \
installcheck-am installdirs maintainer-clean \
maintainer-clean-generic mostlyclean mostlyclean-compile \
mostlyclean-generic pdf pdf-am ps ps-am tags uninstall \
uninstall-am
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.

431
arlib/aclocal.m4 vendored
View File

@ -1,7 +1,7 @@
# generated automatically by aclocal 1.9.6 -*- Autoconf -*-
# generated automatically by aclocal 1.11 -*- Autoconf -*-
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
# 2005 Free Software Foundation, Inc.
# 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
@ -11,7 +11,15 @@
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
# Copyright (C) 2002, 2003, 2005 Free Software Foundation, Inc.
m4_ifndef([AC_AUTOCONF_VERSION],
[m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.65],,
[m4_warning([this file was generated for autoconf 2.65.
You have another version of autoconf. It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.])])
# Copyright (C) 2002, 2003, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
@ -21,14 +29,31 @@
# ----------------------------
# Automake X.Y traces this macro to ensure aclocal.m4 has been
# generated from the m4 files accompanying Automake X.Y.
AC_DEFUN([AM_AUTOMAKE_VERSION], [am__api_version="1.9"])
# (This private macro should not be called outside this file.)
AC_DEFUN([AM_AUTOMAKE_VERSION],
[am__api_version='1.11'
dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
dnl require some minimum version. Point them to the right macro.
m4_if([$1], [1.11], [],
[AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
])
# _AM_AUTOCONF_VERSION(VERSION)
# -----------------------------
# aclocal traces this macro to find the Autoconf version.
# This is a private macro too. Using m4_define simplifies
# the logic in aclocal, which can simply ignore this definition.
m4_define([_AM_AUTOCONF_VERSION], [])
# AM_SET_CURRENT_AUTOMAKE_VERSION
# -------------------------------
# Call AM_AUTOMAKE_VERSION so it can be traced.
# This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
# Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
# This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
[AM_AUTOMAKE_VERSION([1.9.6])])
[AM_AUTOMAKE_VERSION([1.11])dnl
m4_ifndef([AC_AUTOCONF_VERSION],
[m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
_AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
# AM_AUX_DIR_EXPAND -*- Autoconf -*-
@ -85,14 +110,14 @@ am_aux_dir=`cd $ac_aux_dir && pwd`
# AM_CONDITIONAL -*- Autoconf -*-
# Copyright (C) 1997, 2000, 2001, 2003, 2004, 2005
# Copyright (C) 1997, 2000, 2001, 2003, 2004, 2005, 2006, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 7
# serial 9
# AM_CONDITIONAL(NAME, SHELL-CONDITION)
# -------------------------------------
@ -101,8 +126,11 @@ AC_DEFUN([AM_CONDITIONAL],
[AC_PREREQ(2.52)dnl
ifelse([$1], [TRUE], [AC_FATAL([$0: invalid condition: $1])],
[$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
AC_SUBST([$1_TRUE])
AC_SUBST([$1_FALSE])
AC_SUBST([$1_TRUE])dnl
AC_SUBST([$1_FALSE])dnl
_AM_SUBST_NOTMAKE([$1_TRUE])dnl
_AM_SUBST_NOTMAKE([$1_FALSE])dnl
m4_define([_AM_COND_VALUE_$1], [$2])dnl
if $2; then
$1_TRUE=
$1_FALSE='#'
@ -116,15 +144,14 @@ AC_CONFIG_COMMANDS_PRE(
Usually this means the macro was only invoked conditionally.]])
fi])])
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2009
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 8
# serial 10
# 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,
@ -152,6 +179,7 @@ AC_REQUIRE([AM_DEP_TRACK])dnl
ifelse([$1], CC, [depcc="$CC" am_compiler_list=],
[$1], CXX, [depcc="$CXX" am_compiler_list=],
[$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc'],
[$1], UPC, [depcc="$UPC" am_compiler_list=],
[$1], GCJ, [depcc="$GCJ" am_compiler_list='gcc3 gcc'],
[depcc="$$1" am_compiler_list=])
@ -180,6 +208,16 @@ AC_CACHE_CHECK([dependency style of $depcc],
if test "$am_compiler_list" = ""; then
am_compiler_list=`sed -n ['s/^#*\([a-zA-Z0-9]*\))$/\1/p'] < ./depcomp`
fi
am__universal=false
m4_case([$1], [CC],
[case " $depcc " in #(
*\ -arch\ *\ -arch\ *) am__universal=true ;;
esac],
[CXX],
[case " $depcc " in #(
*\ -arch\ *\ -arch\ *) am__universal=true ;;
esac])
for depmode in $am_compiler_list; do
# Setup a source with many dependencies, because some compilers
# like to wrap large dependency lists on column 80 (with \), and
@ -197,7 +235,17 @@ AC_CACHE_CHECK([dependency style of $depcc],
done
echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf
# 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. Also, some Intel
# versions had trouble with output in subdirs
am__obj=sub/conftest.${OBJEXT-o}
am__minus_obj="-o $am__obj"
case $depmode in
gcc)
# This depmode causes a compiler race in universal mode.
test "$am__universal" = false || continue
;;
nosideeffect)
# after this tag, mechanisms are not by side-effect, so they'll
# only be used when explicitly requested
@ -207,18 +255,23 @@ AC_CACHE_CHECK([dependency style of $depcc],
break
fi
;;
msvisualcpp | msvcmsys)
# This compiler won't grok `-c -o', but also, the minuso test has
# not run yet. These depmodes are late enough in the game, and
# so weak that their functioning should not be impacted.
am__obj=conftest.${OBJEXT-o}
am__minus_obj=
;;
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=sub/conftest.c object=sub/conftest.${OBJEXT-o} \
source=sub/conftest.c object=$am__obj \
depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
$SHELL ./depcomp $depcc -c -o sub/conftest.${OBJEXT-o} sub/conftest.c \
$SHELL ./depcomp $depcc -c $am__minus_obj sub/conftest.c \
>/dev/null 2>conftest.err &&
grep sub/conftst1.h sub/conftest.Po > /dev/null 2>&1 &&
grep sub/conftst6.h sub/conftest.Po > /dev/null 2>&1 &&
grep sub/conftest.${OBJEXT-o} sub/conftest.Po > /dev/null 2>&1 &&
grep $am__obj sub/conftest.Po > /dev/null 2>&1 &&
${MAKE-make} -s -f confmf > /dev/null 2>&1; then
# icc doesn't choke on unknown options, it will just issue warnings
# or remarks (even with -Werror). So we grep stderr for any message
@ -269,61 +322,74 @@ if test "x$enable_dependency_tracking" != xno; then
AMDEPBACKSLASH='\'
fi
AM_CONDITIONAL([AMDEP], [test "x$enable_dependency_tracking" != xno])
AC_SUBST([AMDEPBACKSLASH])
AC_SUBST([AMDEPBACKSLASH])dnl
_AM_SUBST_NOTMAKE([AMDEPBACKSLASH])dnl
])
# Generate code to set up dependency tracking. -*- Autoconf -*-
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
#serial 3
#serial 5
# _AM_OUTPUT_DEPENDENCY_COMMANDS
# ------------------------------
AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
[for mf in $CONFIG_FILES; do
# Strip MF so we end up with the name of the file.
mf=`echo "$mf" | sed -e 's/:.*$//'`
# Check whether this is an Automake generated Makefile or not.
# We used to match only the files named `Makefile.in', but
# some people rename them; so instead we look at the file content.
# Grep'ing the first line is not enough: some people post-process
# each Makefile.in and add a new line on top of each file to say so.
# So let's grep whole file.
if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
dirpart=`AS_DIRNAME("$mf")`
else
continue
fi
# Extract the definition of DEPDIR, am__include, and am__quote
# from the Makefile without running `make'.
DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
test -z "$DEPDIR" && continue
am__include=`sed -n 's/^am__include = //p' < "$mf"`
test -z "am__include" && continue
am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
# When using ansi2knr, U may be empty or an underscore; expand it
U=`sed -n 's/^U = //p' < "$mf"`
# Find all dependency output files, they are included files with
# $(DEPDIR) in their names. We invoke sed twice because it is the
# simplest approach to changing $(DEPDIR) to its actual value in the
# expansion.
for file in `sed -n "
s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
# Make sure the directory exists.
test -f "$dirpart/$file" && continue
fdir=`AS_DIRNAME(["$file"])`
AS_MKDIR_P([$dirpart/$fdir])
# echo "creating $dirpart/$file"
echo '# dummy' > "$dirpart/$file"
[{
# Autoconf 2.62 quotes --file arguments for eval, but not when files
# are listed without --file. Let's play safe and only enable the eval
# if we detect the quoting.
case $CONFIG_FILES in
*\'*) eval set x "$CONFIG_FILES" ;;
*) set x $CONFIG_FILES ;;
esac
shift
for mf
do
# Strip MF so we end up with the name of the file.
mf=`echo "$mf" | sed -e 's/:.*$//'`
# Check whether this is an Automake generated Makefile or not.
# We used to match only the files named `Makefile.in', but
# some people rename them; so instead we look at the file content.
# Grep'ing the first line is not enough: some people post-process
# each Makefile.in and add a new line on top of each file to say so.
# Grep'ing the whole file is not good either: AIX grep has a line
# limit of 2048, but all sed's we know have understand at least 4000.
if sed -n 's,^#.*generated by automake.*,X,p' "$mf" | grep X >/dev/null 2>&1; then
dirpart=`AS_DIRNAME("$mf")`
else
continue
fi
# Extract the definition of DEPDIR, am__include, and am__quote
# from the Makefile without running `make'.
DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
test -z "$DEPDIR" && continue
am__include=`sed -n 's/^am__include = //p' < "$mf"`
test -z "am__include" && continue
am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
# When using ansi2knr, U may be empty or an underscore; expand it
U=`sed -n 's/^U = //p' < "$mf"`
# Find all dependency output files, they are included files with
# $(DEPDIR) in their names. We invoke sed twice because it is the
# simplest approach to changing $(DEPDIR) to its actual value in the
# expansion.
for file in `sed -n "
s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
# Make sure the directory exists.
test -f "$dirpart/$file" && continue
fdir=`AS_DIRNAME(["$file"])`
AS_MKDIR_P([$dirpart/$fdir])
# echo "creating $dirpart/$file"
echo '# dummy' > "$dirpart/$file"
done
done
done
}
])# _AM_OUTPUT_DEPENDENCY_COMMANDS
@ -342,14 +408,14 @@ AC_DEFUN([AM_OUTPUT_DEPENDENCY_COMMANDS],
# Do all the work for Automake. -*- Autoconf -*-
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
# Free Software Foundation, Inc.
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
# 2005, 2006, 2008, 2009 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 12
# serial 16
# 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.
@ -366,16 +432,20 @@ AC_DEFUN([AM_OUTPUT_DEPENDENCY_COMMANDS],
# arguments mandatory, and then we can depend on a new Autoconf
# release and drop the old call support.
AC_DEFUN([AM_INIT_AUTOMAKE],
[AC_PREREQ([2.58])dnl
[AC_PREREQ([2.62])dnl
dnl Autoconf wants to disallow AM_ names. We explicitly allow
dnl the ones we care about.
m4_pattern_allow([^AM_[A-Z]+FLAGS$])dnl
AC_REQUIRE([AM_SET_CURRENT_AUTOMAKE_VERSION])dnl
AC_REQUIRE([AC_PROG_INSTALL])dnl
# test to see if srcdir already configured
if test "`cd $srcdir && pwd`" != "`pwd`" &&
test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
if test "`cd $srcdir && pwd`" != "`pwd`"; then
# Use -I$(srcdir) only when $(srcdir) != ., so that make's output
# is not polluted with repeated "-I."
AC_SUBST([am__isrc], [' -I$(srcdir)'])_AM_SUBST_NOTMAKE([am__isrc])dnl
# test to see if srcdir already configured
if test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
fi
fi
# test whether we have cygpath
@ -395,6 +465,9 @@ m4_ifval([$2],
AC_SUBST([PACKAGE], [$1])dnl
AC_SUBST([VERSION], [$2])],
[_AM_SET_OPTIONS([$1])dnl
dnl Diagnose old-style AC_INIT with new-style AM_AUTOMAKE_INIT.
m4_if(m4_ifdef([AC_PACKAGE_NAME], 1)m4_ifdef([AC_PACKAGE_VERSION], 1), 11,,
[m4_fatal([AC_INIT should be called with package and version arguments])])dnl
AC_SUBST([PACKAGE], ['AC_PACKAGE_TARNAME'])dnl
AC_SUBST([VERSION], ['AC_PACKAGE_VERSION'])])dnl
@ -410,8 +483,8 @@ AM_MISSING_PROG(AUTOCONF, autoconf)
AM_MISSING_PROG(AUTOMAKE, automake-${am__api_version})
AM_MISSING_PROG(AUTOHEADER, autoheader)
AM_MISSING_PROG(MAKEINFO, makeinfo)
AM_PROG_INSTALL_SH
AM_PROG_INSTALL_STRIP
AC_REQUIRE([AM_PROG_INSTALL_SH])dnl
AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl
AC_REQUIRE([AM_PROG_MKDIR_P])dnl
# We need awk for the "check" target. The system "awk" is bad on
# some platforms.
@ -419,20 +492,37 @@ AC_REQUIRE([AC_PROG_AWK])dnl
AC_REQUIRE([AC_PROG_MAKE_SET])dnl
AC_REQUIRE([AM_SET_LEADING_DOT])dnl
_AM_IF_OPTION([tar-ustar], [_AM_PROG_TAR([ustar])],
[_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])],
[_AM_PROG_TAR([v7])])])
[_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])],
[_AM_PROG_TAR([v7])])])
_AM_IF_OPTION([no-dependencies],,
[AC_PROVIDE_IFELSE([AC_PROG_CC],
[_AM_DEPENDENCIES(CC)],
[define([AC_PROG_CC],
defn([AC_PROG_CC])[_AM_DEPENDENCIES(CC)])])dnl
[_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
[_AM_DEPENDENCIES(CXX)],
[define([AC_PROG_CXX],
defn([AC_PROG_CXX])[_AM_DEPENDENCIES(CXX)])])dnl
AC_PROVIDE_IFELSE([AC_PROG_OBJC],
[_AM_DEPENDENCIES(OBJC)],
[define([AC_PROG_OBJC],
defn([AC_PROG_OBJC])[_AM_DEPENDENCIES(OBJC)])])dnl
])
_AM_IF_OPTION([silent-rules], [AC_REQUIRE([AM_SILENT_RULES])])dnl
dnl The `parallel-tests' driver may need to know about EXEEXT, so add the
dnl `am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen. This macro
dnl is hooked onto _AC_COMPILER_EXEEXT early, see below.
AC_CONFIG_COMMANDS_PRE(dnl
[m4_provide_if([_AM_COMPILER_EXEEXT],
[AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
])
dnl Hook into `_AC_COMPILER_EXEEXT' early to learn its expansion. Do not
dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further
dnl mangled by Autoconf and run in a shell conditional statement.
m4_define([_AC_COMPILER_EXEEXT],
m4_defn([_AC_COMPILER_EXEEXT])[m4_provide([_AM_COMPILER_EXEEXT])])
# When config.status generates a header, we must update the stamp-h file.
# This file resides in the same directory as the config header
@ -443,18 +533,19 @@ AC_PROVIDE_IFELSE([AC_PROG_CXX],
# our stamp files there.
AC_DEFUN([_AC_AM_CONFIG_HEADER_HOOK],
[# Compute $1's index in $config_headers.
_am_arg=$1
_am_stamp_count=1
for _am_header in $config_headers :; do
case $_am_header in
$1 | $1:* )
$_am_arg | $_am_arg:* )
break ;;
* )
_am_stamp_count=`expr $_am_stamp_count + 1` ;;
esac
done
echo "timestamp for $1" >`AS_DIRNAME([$1])`/stamp-h[]$_am_stamp_count])
echo "timestamp for $_am_arg" >`AS_DIRNAME(["$_am_arg"])`/stamp-h[]$_am_stamp_count])
# Copyright (C) 2001, 2003, 2005 Free Software Foundation, Inc.
# Copyright (C) 2001, 2003, 2005, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
@ -465,7 +556,14 @@ echo "timestamp for $1" >`AS_DIRNAME([$1])`/stamp-h[]$_am_stamp_count])
# Define $install_sh.
AC_DEFUN([AM_PROG_INSTALL_SH],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
install_sh=${install_sh-"$am_aux_dir/install-sh"}
if test x"${install_sh}" != xset; then
case $am_aux_dir in
*\ * | *\ *)
install_sh="\${SHELL} '$am_aux_dir/install-sh'" ;;
*)
install_sh="\${SHELL} $am_aux_dir/install-sh"
esac
fi
AC_SUBST(install_sh)])
# Copyright (C) 2003, 2005 Free Software Foundation, Inc.
@ -491,13 +589,13 @@ AC_SUBST([am__leading_dot])])
# Check to see how 'make' treats includes. -*- Autoconf -*-
# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
# Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 3
# serial 4
# AM_MAKE_INCLUDE()
# -----------------
@ -506,7 +604,7 @@ AC_DEFUN([AM_MAKE_INCLUDE],
[am_make=${MAKE-make}
cat > confinc << 'END'
am__doit:
@echo done
@echo this is the am__doit target
.PHONY: am__doit
END
# If we don't find an include directive, just comment out the code.
@ -516,24 +614,24 @@ am__quote=
_am_result=none
# First try GNU make style include.
echo "include confinc" > confmf
# We grep out `Entering directory' and `Leaving directory'
# messages which can occur if `w' ends up in MAKEFLAGS.
# In particular we don't look at `^make:' because GNU make might
# be invoked under some other name (usually "gmake"), in which
# case it prints its new name instead of `make'.
if test "`$am_make -s -f confmf 2> /dev/null | grep -v 'ing directory'`" = "done"; then
am__include=include
am__quote=
_am_result=GNU
fi
# Ignore all kinds of additional output from `make'.
case `$am_make -s -f confmf 2> /dev/null` in #(
*the\ am__doit\ target*)
am__include=include
am__quote=
_am_result=GNU
;;
esac
# Now try BSD make style include.
if test "$am__include" = "#"; then
echo '.include "confinc"' > confmf
if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then
am__include=.include
am__quote="\""
_am_result=BSD
fi
case `$am_make -s -f confmf 2> /dev/null` in #(
*the\ am__doit\ target*)
am__include=.include
am__quote="\""
_am_result=BSD
;;
esac
fi
AC_SUBST([am__include])
AC_SUBST([am__quote])
@ -543,14 +641,14 @@ rm -f confinc confmf
# Fake the existence of programs that GNU maintainers use. -*- Autoconf -*-
# Copyright (C) 1997, 1999, 2000, 2001, 2003, 2005
# Copyright (C) 1997, 1999, 2000, 2001, 2003, 2004, 2005, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 4
# serial 6
# AM_MISSING_PROG(NAME, PROGRAM)
# ------------------------------
@ -566,7 +664,15 @@ AC_SUBST($1)])
# If it does, set am_missing_run to use it, otherwise, to nothing.
AC_DEFUN([AM_MISSING_HAS_RUN],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
test x"${MISSING+set}" = xset || MISSING="\${SHELL} $am_aux_dir/missing"
AC_REQUIRE_AUX_FILE([missing])dnl
if test x"${MISSING+set}" != xset; then
case $am_aux_dir in
*\ * | *\ *)
MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
*)
MISSING="\${SHELL} $am_aux_dir/missing" ;;
esac
fi
# Use eval to expand $SHELL
if eval "$MISSING --run true"; then
am_missing_run="$MISSING --run "
@ -576,7 +682,7 @@ else
fi
])
# Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
# Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
@ -584,70 +690,33 @@ fi
# AM_PROG_MKDIR_P
# ---------------
# Check whether `mkdir -p' is supported, fallback to mkinstalldirs otherwise.
#
# Automake 1.8 used `mkdir -m 0755 -p --' to ensure that directories
# created by `make install' are always world readable, even if the
# installer happens to have an overly restrictive umask (e.g. 077).
# This was a mistake. There are at least two reasons why we must not
# use `-m 0755':
# - it causes special bits like SGID to be ignored,
# - it may be too restrictive (some setups expect 775 directories).
#
# Do not use -m 0755 and let people choose whatever they expect by
# setting umask.
#
# We cannot accept any implementation of `mkdir' that recognizes `-p'.
# Some implementations (such as Solaris 8's) are not thread-safe: if a
# parallel make tries to run `mkdir -p a/b' and `mkdir -p a/c'
# concurrently, both version can detect that a/ is missing, but only
# one can create it and the other will error out. Consequently we
# restrict ourselves to GNU make (using the --version option ensures
# this.)
# Check for `mkdir -p'.
AC_DEFUN([AM_PROG_MKDIR_P],
[if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
# We used to keeping the `.' as first argument, in order to
# allow $(mkdir_p) to be used without argument. As in
# $(mkdir_p) $(somedir)
# where $(somedir) is conditionally defined. However this is wrong
# for two reasons:
# 1. if the package is installed by a user who cannot write `.'
# make install will fail,
# 2. the above comment should most certainly read
# $(mkdir_p) $(DESTDIR)$(somedir)
# so it does not work when $(somedir) is undefined and
# $(DESTDIR) is not.
# To support the latter case, we have to write
# test -z "$(somedir)" || $(mkdir_p) $(DESTDIR)$(somedir),
# so the `.' trick is pointless.
mkdir_p='mkdir -p --'
else
# On NextStep and OpenStep, the `mkdir' command does not
# recognize any option. It will interpret all options as
# directories to create, and then abort because `.' already
# exists.
for d in ./-p ./--version;
do
test -d $d && rmdir $d
done
# $(mkinstalldirs) is defined by Automake if mkinstalldirs exists.
if test -f "$ac_aux_dir/mkinstalldirs"; then
mkdir_p='$(mkinstalldirs)'
else
mkdir_p='$(install_sh) -d'
fi
fi
AC_SUBST([mkdir_p])])
[AC_PREREQ([2.60])dnl
AC_REQUIRE([AC_PROG_MKDIR_P])dnl
dnl Automake 1.8 to 1.9.6 used to define mkdir_p. We now use MKDIR_P,
dnl while keeping a definition of mkdir_p for backward compatibility.
dnl @MKDIR_P@ is magic: AC_OUTPUT adjusts its value for each Makefile.
dnl However we cannot define mkdir_p as $(MKDIR_P) for the sake of
dnl Makefile.ins that do not define MKDIR_P, so we do our own
dnl adjustment using top_builddir (which is defined more often than
dnl MKDIR_P).
AC_SUBST([mkdir_p], ["$MKDIR_P"])dnl
case $mkdir_p in
[[\\/$]]* | ?:[[\\/]]*) ;;
*/*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
esac
])
# Helper functions for option handling. -*- Autoconf -*-
# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
# Copyright (C) 2001, 2002, 2003, 2005, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 3
# serial 4
# _AM_MANGLE_OPTION(NAME)
# -----------------------
@ -664,7 +733,7 @@ AC_DEFUN([_AM_SET_OPTION],
# ----------------------------------
# OPTIONS is a space-separated list of Automake options.
AC_DEFUN([_AM_SET_OPTIONS],
[AC_FOREACH([_AM_Option], [$1], [_AM_SET_OPTION(_AM_Option)])])
[m4_foreach_w([_AM_Option], [$1], [_AM_SET_OPTION(_AM_Option)])])
# _AM_IF_OPTION(OPTION, IF-SET, [IF-NOT-SET])
# -------------------------------------------
@ -674,14 +743,14 @@ AC_DEFUN([_AM_IF_OPTION],
# Check to make sure that the build environment is sane. -*- Autoconf -*-
# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005
# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 4
# serial 5
# AM_SANITY_CHECK
# ---------------
@ -690,16 +759,29 @@ AC_DEFUN([AM_SANITY_CHECK],
# Just in case
sleep 1
echo timestamp > conftest.file
# Reject unsafe characters in $srcdir or the absolute working directory
# name. Accept space and tab only in the latter.
am_lf='
'
case `pwd` in
*[[\\\"\#\$\&\'\`$am_lf]]*)
AC_MSG_ERROR([unsafe absolute working directory name]);;
esac
case $srcdir in
*[[\\\"\#\$\&\'\`$am_lf\ \ ]]*)
AC_MSG_ERROR([unsafe srcdir value: `$srcdir']);;
esac
# 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 conftest.file 2> /dev/null`
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 conftest.file`
set X `ls -t "$srcdir/configure" conftest.file`
fi
rm -f conftest.file
if test "$[*]" != "X $srcdir/configure conftest.file" \
@ -749,9 +831,28 @@ dnl Don't test for $cross_compiling = yes, because it might be `maybe'.
if test "$cross_compiling" != no; then
AC_CHECK_TOOL([STRIP], [strip], :)
fi
INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s"
INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s"
AC_SUBST([INSTALL_STRIP_PROGRAM])])
# Copyright (C) 2006, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 2
# _AM_SUBST_NOTMAKE(VARIABLE)
# ---------------------------
# Prevent Automake from outputting VARIABLE = @VARIABLE@ in Makefile.in.
# This macro is traced by Automake.
AC_DEFUN([_AM_SUBST_NOTMAKE])
# AM_SUBST_NOTMAKE(VARIABLE)
# ---------------------------
# Public sister of _AM_SUBST_NOTMAKE.
AC_DEFUN([AM_SUBST_NOTMAKE], [_AM_SUBST_NOTMAKE($@)])
# Check how to create a tarball. -*- Autoconf -*-
# Copyright (C) 2004, 2005 Free Software Foundation, Inc.

5700
arlib/configure vendored
View File

File diff suppressed because it is too large Load Diff

32
build
View File

@ -2,13 +2,15 @@
LOGF=make.log
IAM=`hostname || uname -n`
MYNAME=`IFS=. ; set $IAM ; echo $1`
SIG=
case "$1" in
0.*)
SIG=$1
shift
CONFIG_ARGS="$@"
KEY=`sed -e q < .buildkey`
KEY=`sed -e q < .buildkey-$MYNAME`
case "$SIG" in
$KEY) ;;
*)
@ -36,8 +38,6 @@ case "$CVO" in
;;
esac
MYNAME=`IFS=. ; set $IAM ; echo $1`
case "$IAM" in
*.udel.edu)
BDIR=A.$MYNAME
@ -90,17 +90,33 @@ BDIR="$BDIR$KEYSUF$CCSUF"
[ -f "$BDIR/.buildcvo" ] || echo $CVO > $BDIR/.buildcvo
[ -f "$BDIR/.buildhost" ] || echo $IAM > $BDIR/.buildhost
cd $BDIR
(
[ -f config.status ] || ../configure $CONFIG_ARGS
#
# make sure we have a nice that works,
#
nice true && NICEB=nice
nice true || NICEB=./.nicebuild-$MYNAME-$SIG && (
cat > .nicebuild-$MYNAME-$SIG <<UNLYKUHLY
#! /bin/sh
shift
\$*
UNLYKUHLY
chmod +x .nicebuild-$MYNAME-$SIG
)
./config.status
(
[ -f config.status ] || $NICEB -7 ../configure --config-cache \
$CONFIG_ARGS
$NICEB -5 ./config.status
case "$MAKE" in
'') make && make check
'') $NICEB -14 make && $NICEB -10 make check
;;
*) $MAKE && $MAKE check
*) $NICEB -14 $MAKE && $NICEB -10 $MAKE check
;;
esac
) > $LOGF 2>&1

228
clockstuff/Makefile.in
View File

@ -1,8 +1,9 @@
# Makefile.in generated by automake 1.9.6 from Makefile.am.
# Makefile.in generated by automake 1.11 from Makefile.am.
# @configure_input@
# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
# 2003, 2004, 2005 Free Software Foundation, Inc.
# 2003, 2004, 2005, 2006, 2007, 2008, 2009 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.
@ -14,15 +15,12 @@
@SET_MAKE@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
top_builddir = ..
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
INSTALL = @INSTALL@
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
@ -37,7 +35,6 @@ POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
ANSI2KNR = ../util/ansi2knr
noinst_PROGRAMS = @PROPDELAY@ @CHUTEST@ @CLKTEST@
EXTRA_PROGRAMS = propdelay$(EXEEXT) chutest$(EXEEXT) clktest$(EXEEXT)
subdir = clockstuff
DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in
@ -52,6 +49,7 @@ am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
PROGRAMS = $(noinst_PROGRAMS)
chutest_SOURCES = chutest.c
chutest_OBJECTS = chutest$U.$(OBJEXT)
@ -62,25 +60,25 @@ clktest_DEPENDENCIES = ../libntp/libntp.a
propdelay_SOURCES = propdelay.c
propdelay_OBJECTS = propdelay$U.$(OBJEXT)
propdelay_DEPENDENCIES = ../libntp/libntp.a
DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)
DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
depcomp = $(SHELL) $(top_srcdir)/depcomp
am__depfiles_maybe = depfiles
am__mv = mv -f
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(DEFS) \
$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
$(AM_CFLAGS) $(CFLAGS)
LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
LINK = $(LIBTOOL) --tag=CC --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
$(AM_LDFLAGS) $(LDFLAGS) -o $@
LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@
SOURCES = chutest.c clktest.c propdelay.c
DIST_SOURCES = chutest.c clktest.c propdelay.c
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
AMDEP_FALSE = @AMDEP_FALSE@
AMDEP_TRUE = @AMDEP_TRUE@
AMTAR = @AMTAR@
AR = @AR@
ARLIB_DIR = @ARLIB_DIR@
@ -96,10 +94,6 @@ CHUTEST = @CHUTEST@
CLKTEST = @CLKTEST@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CXX = @CXX@
CXXCPP = @CXXCPP@
CXXDEPMODE = @CXXDEPMODE@
CXXFLAGS = @CXXFLAGS@
CYGPATH_W = @CYGPATH_W@
DCFD = @DCFD@
DEFS = @DEFS@
@ -112,11 +106,10 @@ EF_LIBS = @EF_LIBS@
EF_PROGS = @EF_PROGS@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
F77 = @F77@
FFLAGS = @FFLAGS@
GREP = @GREP@
HAVE_INLINE = @HAVE_INLINE@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_LIBOPTS_FALSE = @INSTALL_LIBOPTS_FALSE@
INSTALL_LIBOPTS_TRUE = @INSTALL_LIBOPTS_TRUE@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
@ -130,6 +123,7 @@ LIBPARSE = @LIBPARSE@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LN_S = @LN_S@
LSCF = @LSCF@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAKE_ADJTIMED = @MAKE_ADJTIMED@
@ -143,8 +137,7 @@ MAKE_NTPTIME = @MAKE_NTPTIME@
MAKE_PARSEKMODULE = @MAKE_PARSEKMODULE@
MAKE_TICKADJ = @MAKE_TICKADJ@
MAKE_TIMETRIM = @MAKE_TIMETRIM@
NEED_LIBOPTS_FALSE = @NEED_LIBOPTS_FALSE@
NEED_LIBOPTS_TRUE = @NEED_LIBOPTS_TRUE@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
OPENSSL = @OPENSSL@
OPENSSL_INC = @OPENSSL_INC@
@ -154,6 +147,7 @@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_PERL = @PATH_PERL@
PATH_SEPARATOR = @PATH_SEPARATOR@
@ -167,16 +161,11 @@ STRIP = @STRIP@
TESTDCF = @TESTDCF@
U = @U@
VERSION = @VERSION@
ac_ct_AR = @ac_ct_AR@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
ac_ct_CXX = @ac_ct_CXX@
ac_ct_F77 = @ac_ct_F77@
ac_ct_RANLIB = @ac_ct_RANLIB@
ac_ct_STRIP = @ac_ct_STRIP@
am__fastdepCC_FALSE = @am__fastdepCC_FALSE@
am__fastdepCC_TRUE = @am__fastdepCC_TRUE@
am__fastdepCXX_FALSE = @am__fastdepCXX_FALSE@
am__fastdepCXX_TRUE = @am__fastdepCXX_TRUE@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
@ -188,32 +177,45 @@ build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
subdirs = @subdirs@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
#AUTOMAKE_OPTIONS = ../ansi2knr no-dependencies
AUTOMAKE_OPTIONS = ../util/ansi2knr
noinst_PROGRAMS = @PROPDELAY@ @CHUTEST@ @CLKTEST@
INCLUDES = -I$(top_srcdir)/include
# We need -lm (and perhaps $(COMPAT) for propdelay, -lntp for {chu,clk}test
propdelay_LDADD = -lm ../libntp/libntp.a
@ -228,14 +230,14 @@ $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \
&& exit 0; \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign clockstuff/Makefile'; \
cd $(top_srcdir) && \
$(AUTOMAKE) --foreign clockstuff/Makefile
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign clockstuff/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign clockstuff/Makefile
.PRECIOUS: Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
@ -253,16 +255,19 @@ $(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
clean-noinstPROGRAMS:
@list='$(noinst_PROGRAMS)'; for p in $$list; do \
f=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
echo " rm -f $$p $$f"; \
rm -f $$p $$f ; \
done
@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
echo " rm -f" $$list; \
rm -f $$list || exit $$?; \
test -n "$(EXEEXT)" || exit 0; \
list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
echo " rm -f" $$list; \
rm -f $$list
propdelay$(EXEEXT): $(propdelay_OBJECTS) $(propdelay_DEPENDENCIES)
@rm -f propdelay$(EXEEXT)
$(LINK) $(propdelay_LDFLAGS) $(propdelay_OBJECTS) $(propdelay_LDADD) $(LIBS)
$(LINK) $(propdelay_OBJECTS) $(propdelay_LDADD) $(LIBS)
mostlyclean-compile:
-rm -f *.$(OBJEXT)
@ -270,7 +275,7 @@ mostlyclean-compile:
distclean-compile:
-rm -f *.tab.c
../util/ansi2knr:
cd ../util && $(MAKE) $(AM_MAKEFLAGS) ansi2knr
$(am__cd) ../util && $(MAKE) $(AM_MAKEFLAGS) ./ansi2knr
mostlyclean-kr:
-test "$U" = "" || rm -f *_.c
@ -280,22 +285,22 @@ mostlyclean-kr:
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/propdelay$U.Po@am__quote@
.c.o:
@am__fastdepCC_TRUE@ if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c $<
.c.obj:
@am__fastdepCC_TRUE@ if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ `$(CYGPATH_W) '$<'`; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(COMPILE) -c `$(CYGPATH_W) '$<'`
.c.lo:
@am__fastdepCC_TRUE@ if $(LTCOMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \
@am__fastdepCC_TRUE@ then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Plo"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi
@am__fastdepCC_TRUE@ $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
@am__fastdepCC_TRUE@ $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@ $(LTCOMPILE) -c -o $@ $<
@ -314,82 +319,85 @@ mostlyclean-libtool:
clean-libtool:
-rm -rf .libs _libs
distclean-libtool:
-rm -f libtool
uninstall-info-am:
ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
mkid -fID $$unique
tags: TAGS
TAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
set x; \
here=`pwd`; \
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
if test -z "$(ETAGS_ARGS)$$tags$$unique"; then :; else \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
shift; \
if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
test -n "$$unique" || unique=$$empty_fix; \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$tags $$unique; \
if test $$# -gt 0; then \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
"$$@" $$unique; \
else \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$unique; \
fi; \
fi
ctags: CTAGS
CTAGS: $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
$(TAGS_FILES) $(LISP)
tags=; \
here=`pwd`; \
list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | \
$(AWK) ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$(CTAGS_ARGS)$$tags$$unique" \
$(AWK) '{ files[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in files) print i; }; }'`; \
test -z "$(CTAGS_ARGS)$$unique" \
|| $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
$$tags $$unique
$$unique
GTAGS:
here=`$(am__cd) $(top_builddir) && pwd` \
&& cd $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) $$here
&& $(am__cd) $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) "$$here"
distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
distdir: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's|.|.|g'`; \
list='$(DISTFILES)'; for file in $$list; do \
case $$file in \
$(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \
$(top_srcdir)/*) file=`echo "$$file" | sed "s|^$$topsrcdirstrip/|$(top_builddir)/|"`;; \
esac; \
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
if test "$$dir" != "$$file" && test "$$dir" != "."; then \
dir="/$$dir"; \
$(mkdir_p) "$(distdir)$$dir"; \
else \
dir=''; \
fi; \
if test -d $$d/$$file; then \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f $(distdir)/$$file \
|| cp -p $$d/$$file $(distdir)/$$file \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
@ -417,6 +425,7 @@ clean-generic:
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@ -430,7 +439,7 @@ distclean: distclean-am
-rm -rf ./$(DEPDIR)
-rm -f Makefile
distclean-am: clean-am distclean-compile distclean-generic \
distclean-libtool distclean-tags
distclean-tags
dvi: dvi-am
@ -438,18 +447,38 @@ dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am:
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
@ -470,19 +499,23 @@ ps: ps-am
ps-am:
uninstall-am: uninstall-info-am
uninstall-am:
.MAKE: ../util/ansi2knr install-am install-strip
.PHONY: CTAGS GTAGS all all-am check check-am clean clean-generic \
clean-libtool clean-noinstPROGRAMS ctags distclean \
distclean-compile distclean-generic distclean-libtool \
distclean-tags distdir dvi dvi-am html html-am info info-am \
install install-am install-data install-data-am install-exec \
install-exec-am install-info install-info-am install-man \
install install-am install-data install-data-am install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-strip installcheck installcheck-am installdirs \
maintainer-clean maintainer-clean-generic mostlyclean \
mostlyclean-compile mostlyclean-generic mostlyclean-kr \
mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
uninstall-am uninstall-info-am
uninstall-am
#EXTRA_DIST = TAGS
@ -491,6 +524,7 @@ uninstall-am: uninstall-info-am
chutest$(EXEEXT): ../libntp/libntp.a
clktest$(EXEEXT): ../libntp/libntp.a
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

42
conf/dewey.conf
View File

@ -1,42 +0,0 @@
#
# NTP configuration file (ntp.conf)
#
# Generic configuration file for UDel NTP stratum-2 time servers. Don't
# forget each server should have a /etc/ntp.drift and /etc/ntp.keys file.
#
# Stratum-1 peers. Each server should chime two different stratum-1
# servers from the following list. Each stratum-1 server should be used
# only once.
#
#peer 128.8.10.1 # umd1.umd.edu
#peer 18.72.0.3 version 2 # bitsy.mit.edu
peer 132.249.16.1 # fuzz.sdsc.edu
peer 128.118.46.3 version 2 # otc1.psu.edu
#peer 128.9.2.129 # wwvb.isi.edu
#peer 130.43.2.2 version 2 # apple.com
#peer 16.1.0.22 # clepsydra.dec.com
#peer 130.105.1.156 version 2 # clock.osf.orga
#peer 128.96.60.5 version 2 # pi.bellcore.com
#peer 128.4.1.1 # rackety.udel.edu
#peer 129.116.3.5 # shorty.chpc.utexas.edu
#
# Stratum-2 peers. Each server should chime all of the others in this
# list except itself.
#
peer 128.175.1.1 # huey.udel.edu (VAX)
#peer 128.175.1.2 # dewey.udel.edu (VAX)
peer 128.175.1.3 # louie.udel.edu (SPARC)
peer 128.175.2.15 # snow-white.ee.udel.edu (SPARC)
peer 128.175.7.4 # sol.cis.udel.edu (SPARC)
#
# Miscellaneous stuff
#
driftfile /etc/ntp.drift # path for drift file
#
# Authentication stuff. Note the different authentication delay on
# VAX and SPARC.
#
keys /usr/local/etc/ntp.keys # path for key file
trustedkey 1 2 15 # define trusted keys
requestkey 15 # key (7) for accessing server variables
controlkey 15 # key (6) for accessing server variables

133
config.h.in
View File

@ -1,5 +1,8 @@
/* config.h.in. Generated from configure.ac by autoheader. */
/* Define if building universal (internal helper macro) */
#undef AC_APPLE_UNIVERSAL_BUILD
/* Is adjtime() accurate? */
#undef ADJTIME_IS_ACCURATE
@ -325,7 +328,7 @@
/* Define to 1 if you don't have `vprintf' but do have `_doprnt.' */
#undef HAVE_DOPRNT
/* Can we drop root privileges? */
/* [Can we drop root privileges?] */
#undef HAVE_DROPROOT
/* Define to 1 if you have the <errno.h> header file. */
@ -370,9 +373,12 @@
/* Define to 1 if you have the <ieeefp.h> header file. */
#undef HAVE_IEEEFP_H
/* ISC: Use iflist_sysctl? */
/* have iflist_sysctl? */
#undef HAVE_IFLIST_SYSCTL
/* inline keyword or macro available */
#undef HAVE_INLINE
/* Define to 1 if the system has the type `int16_t'. */
#undef HAVE_INT16_T
@ -388,6 +394,9 @@
/* Define to 1 if you have the <inttypes.h> header file. */
#undef HAVE_INTTYPES_H
/* Do we have IPTOS support? */
#undef HAVE_IPTOS_SUPPORT
/* Define to 1 if you have the `isfinite' function. */
#undef HAVE_ISFINITE
@ -421,18 +430,9 @@
/* Define to 1 if you have the `ld' library (-lld). */
#undef HAVE_LIBLD
/* Define to 1 if you have the `md' library (-lmd). */
#undef HAVE_LIBMD
/* Define to 1 if you have the `md5' library (-lmd5). */
#undef HAVE_LIBMD5
/* Define to 1 if you have the `mld' library (-lmld). */
#undef HAVE_LIBMLD
/* Define to 1 if you have the `nsl' library (-lnsl). */
#undef HAVE_LIBNSL
/* Define to 1 if you have the `posix4' library (-lposix4). */
#undef HAVE_LIBPOSIX4
@ -442,19 +442,13 @@
/* Define to 1 if you have the `rt' library (-lrt). */
#undef HAVE_LIBRT
/* Define to 1 if you have the `socket' library (-lsocket). */
#undef HAVE_LIBSOCKET
/* Define to 1 if you have the `syslog' library (-lsyslog). */
#undef HAVE_LIBSYSLOG
/* Define to 1 if you have the `xnet' library (-lxnet). */
#undef HAVE_LIBXNET
/* Define to 1 if you have the <libscf.h> header file. */
#undef HAVE_LIBSCF_H
/* Define to 1 if you have the <limits.h> header file. */
#undef HAVE_LIMITS_H
/* Do we have Linux capabilities? */
/* [Do we have Linux capabilities?] */
#undef HAVE_LINUX_CAPABILITIES
/* Define to 1 if you have the <machine/inline.h> header file. */
@ -544,6 +538,9 @@
/* Define to 1 if you have the `ntp_gettime' function. */
#undef HAVE_NTP_GETTIME
/* Do we want support for Samba's signing daemon? */
#undef HAVE_NTP_SIGND
/* Define this if pathfind(3) works */
#undef HAVE_PATHFIND
@ -646,6 +643,9 @@
/* Define to 1 if you have the `snprintf' function. */
#undef HAVE_SNPRINTF
/* [Are Solaris privileges available?] */
#undef HAVE_SOLARIS_PRIVS
/* Does struct sockaddr_storage have ss_family? */
#undef HAVE_SS_FAMILY_IN_SS
@ -691,7 +691,7 @@
/* Do we have struct ntptimeval? */
#undef HAVE_STRUCT_NTPTIMEVAL
/* Define to 1 if `time.tv_nsec' is member of `struct ntptimeval'. */
/* Define to 1 if `time.tv_nsec' is a member of `struct ntptimeval'. */
#undef HAVE_STRUCT_NTPTIMEVAL_TIME_TV_NSEC
/* Does a system header define struct ppsclockev? */
@ -700,9 +700,6 @@
/* Do we have struct snd_size? */
#undef HAVE_STRUCT_SND_SIZE
/* Define to 1 if `sin6_scope_id' is member of `struct sockaddr_in6'. */
#undef HAVE_STRUCT_SOCKADDR_IN6_SIN6_SCOPE_ID
/* Does a system header define struct sockaddr_storage? */
#undef HAVE_STRUCT_SOCKADDR_STORAGE
@ -978,6 +975,9 @@
/* Does struct sockaddr_storage have __ss_len? */
#undef HAVE___SS_LEN_IN_SS
/* [Retry queries on _any_ DNS error?] */
#undef IGNORE_DNS_ERRORS
/* Should we use the IRIG sawtooth filter? */
#undef IRIG_SUCKS
@ -987,30 +987,33 @@
/* ISC: do we have if_nametoindex()? */
#undef ISC_PLATFORM_HAVEIFNAMETOINDEX
/* ISC: have struct if_laddrconf? */
/* have struct if_laddrconf? */
#undef ISC_PLATFORM_HAVEIF_LADDRCONF
/* ISC: have struct if_laddrreq? */
/* have struct if_laddrreq? */
#undef ISC_PLATFORM_HAVEIF_LADDRREQ
/* ISC: Have struct in6_pktinfo? */
/* have struct in6_pktinfo? */
#undef ISC_PLATFORM_HAVEIN6PKTINFO
/* ISC: Have IPv6? */
/* have IPv6? */
#undef ISC_PLATFORM_HAVEIPV6
/* ISC: struct sockaddr as sa_len? */
#undef ISC_PLATFORM_HAVESALEN
/* ISC: Have sin6_scope_id? */
/* have sin6_scope_id? */
#undef ISC_PLATFORM_HAVESCOPEID
/* ISC: provide inet_aton() */
#undef ISC_PLATFORM_NEEDATON
/* ISC: Need in6addr_any? */
/* missing in6addr_any? */
#undef ISC_PLATFORM_NEEDIN6ADDRANY
/* Do we need netinet6/in6.h? */
#undef ISC_PLATFORM_NEEDNETINET6IN6H
/* ISC: provide inet_ntop() */
#undef ISC_PLATFORM_NEEDNTOP
@ -1089,6 +1092,9 @@
/* Default location of crypto key info */
#undef NTP_KEYSDIR
/* Path to sign daemon rendezvous socket */
#undef NTP_SIGND_PATH
/* Do we have ntp_{adj,get}time in libc? */
#undef NTP_SYSCALLS_LIBC
@ -1129,6 +1135,9 @@
/* Define to the one symbol short name of this package. */
#undef PACKAGE_TARNAME
/* Define to the home page for this package. */
#undef PACKAGE_URL
/* Define to the version of this package. */
#undef PACKAGE_VERSION
@ -1171,22 +1180,22 @@
/* Do we want the SCO clock hacks? */
#undef SCO5_CLOCK
/* The size of a `char*', as computed by sizeof. */
/* The size of `char*', as computed by sizeof. */
#undef SIZEOF_CHARP
/* The size of a `int', as computed by sizeof. */
/* The size of `int', as computed by sizeof. */
#undef SIZEOF_INT
/* The size of a `long', as computed by sizeof. */
/* The size of `long', as computed by sizeof. */
#undef SIZEOF_LONG
/* The size of a `short', as computed by sizeof. */
/* The size of `short', as computed by sizeof. */
#undef SIZEOF_SHORT
/* The size of a `signed char', as computed by sizeof. */
/* The size of `signed char', as computed by sizeof. */
#undef SIZEOF_SIGNED_CHAR
/* The size of a `time_t', as computed by sizeof. */
/* The size of `time_t', as computed by sizeof. */
#undef SIZEOF_TIME_T
/* Does SIOCGIFCONF return size in the buffer? */
@ -1249,6 +1258,28 @@ typedef unsigned int uintptr_t;
/* Must we have a CTTY for fsetown? */
#undef USE_FSETOWNCTTY
/* Enable extensions on AIX 3, Interix. */
#ifndef _ALL_SOURCE
# undef _ALL_SOURCE
#endif
/* Enable GNU extensions on systems that have them. */
#ifndef _GNU_SOURCE
# undef _GNU_SOURCE
#endif
/* Enable threading extensions on Solaris. */
#ifndef _POSIX_PTHREAD_SEMANTICS
# undef _POSIX_PTHREAD_SEMANTICS
#endif
/* Enable extensions on HP NonStop. */
#ifndef _TANDEM_SOURCE
# undef _TANDEM_SOURCE
#endif
/* Enable general extensions on Solaris. */
#ifndef __EXTENSIONS__
# undef __EXTENSIONS__
#endif
/* Can we use SIGPOLL for tty IO? */
#undef USE_TTY_SIGPOLL
@ -1258,15 +1289,26 @@ typedef unsigned int uintptr_t;
/* Version number of package */
#undef VERSION
/* ISC: Want IPv6? */
/* configure --enable-ipv6 */
#undef WANT_IPV6
/* Do we want the windows symmetric client hack? */
#undef WINTIME
/* Define this if a working libregex can be found */
#undef WITH_LIBREGEX
/* Define to 1 if your processor stores words with the most significant byte
first (like Motorola and SPARC, unlike Intel and VAX). */
#undef WORDS_BIGENDIAN
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
# define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
# undef WORDS_BIGENDIAN
# endif
#endif
/* Handle ss_family */
#if !defined(HAVE_SS_FAMILY_IN_SS) && defined(HAVE___SS_FAMILY_IN_SS)
@ -1278,13 +1320,6 @@ typedef unsigned int uintptr_t;
# define ss_len __ss_len
#endif /* !defined(HAVE_SS_LEN_IN_SS) && defined(HAVE_SA_LEN_IN_SS) */
/* Define to 1 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 to 1 if on MINIX. */
#undef _MINIX
@ -1315,10 +1350,10 @@ typedef unsigned int uintptr_t;
#undef inline
#endif
/* Define to `long' if <sys/types.h> does not define. */
/* Define to `long int' if <sys/types.h> does not define. */
#undef off_t
/* Define to `unsigned' if <sys/types.h> does not define. */
/* Define to `unsigned int' if <sys/types.h> does not define. */
#undef size_t
/* Define to `long' if <sys/types.h> does not define. */

47580
configure vendored
View File

File diff suppressed because it is too large Load Diff

1897
configure.ac
View File

File diff suppressed because it is too large Load Diff

94
flock-build
View File

@ -5,14 +5,26 @@ PARSE="--enable-parse-clocks"
#PARSE=
STD="--enable-simulator"
case "$SIMUL" in
'') PARALLEL_BUILDS=1
;;
*) PARALLEL_BUILDS=$SIMUL
esac
case "$PARALLEL_BUILDS" in
1) ;;
*) echo Launching $PARALLEL_BUILDS parallel builds on each machine
esac
# Backroom:
# beauregard freebsd-6
# o churchy alpha-dec-osf5.1
# barnstable freebsd-6.1
# beauregard freebsd-6.0
# X churchy alpha-dec-osf5.1
# deacon sparc-sun-solaris2.10
# grundoon freebsd-6.1
# grundoon freebsd-6.2
# howland freebsd-6.1
# o macabre sparc-sun-solaris2.8
# o mort sparc-sun-solaris2.8
# o macabre freebsd-6.1-STABLE
# o mort freebsd-6.1
# whimsy sparc-sun-solaris2.10
# Campus:
@ -23,10 +35,11 @@ STD="--enable-simulator"
# * pogo sparc-sun-solaris2.10
# * rackety freebsd-6.1
# HMS: we need $PWD because solaris produces /deacon/backroom when
# we are in /backroom and in general there is no /deacon/backroom.
c_d=${PWD:-`pwd`}
SIG=`perl -e 'print rand'`
echo $SIG > .buildkey
case "$LIST" in
'') LIST="baldwin bridgeport cowbird malarky pogo rackety" ;;
@ -34,19 +47,60 @@ esac
for i in $LIST
do
echo $i
case "1" in
0)
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD --without-crypto $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $STD --disable-all-clocks $BUILD_ARGS" &
;;
1) ssh $i "cd $c_d ; \
./build $SIG $PARSE $STD $BUILD_ARGS ; \
./build $SIG $PARSE $STD --disable-debugging $BUILD_ARGS ; \
./build $SIG $PARSE $STD --without-crypto $BUILD_ARGS ; \
./build $SIG $STD --disable-all-clocks $BUILD_ARGS" \
&
;;
SKIPTHIS=0
[ -f .buildkey-$i ] && SKIPTHIS=1
case "$SKIPTHIS" in
1)
echo flock-build running on $i? check LIST, skipping
;;
0)
echo $i
echo $SIG > .buildkey-$i
case "1" in
0)
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $PARSE $STD --without-crypto $BUILD_ARGS" &
ssh $i "cd $c_d ; ./build $SIG $STD --disable-all-clocks $BUILD_ARGS" &
;;
1)
cat > .flockbuild-$i-$SIG <<ENDQUOT
#!/bin/sh
# depends on job control and expects to be invoked under ssh -tt
cd $c_d
COUNT=0
./build $SIG $PARSE $STD $BUILD_ARGS &
COUNT=\`expr \$COUNT + 1\`
echo $i started build \$COUNT of 4
[ 0 -lt \`expr \$COUNT % $PARALLEL_BUILDS\` ] || wait
./build $SIG $PARSE $STD --disable-debugging $BUILD_ARGS &
COUNT=\`expr \$COUNT + 1\`
echo $i started build \$COUNT of 4
[ 0 -lt \`expr \$COUNT % $PARALLEL_BUILDS\` ] || wait
./build $SIG $PARSE $STD --without-crypto $BUILD_ARGS &
COUNT=\`expr \$COUNT + 1\`
echo $i started build \$COUNT of 4
[ 0 -lt \`expr \$COUNT % $PARALLEL_BUILDS\` ] || wait
./build $SIG $STD --disable-all-clocks $BUILD_ARGS &
COUNT=\`expr \$COUNT + 1\`
echo $i started build \$COUNT of 4
wait
echo \`date -u '+%H:%M:%S'\` $i flock-build $c_d done.
rm .buildkey-$i
ENDQUOT
chmod +x .flockbuild-$i-$SIG
ssh -tt $i "$c_d/.flockbuild-$i-$SIG ; \
rm $c_d/.flockbuild-$i-$SIG" 2>/dev/null &
esac
esac
done
echo `date -u '+%H:%M:%S'` flock-build launched

257
html/Oncore-SHMEM.htm
View File

@ -1,257 +0,0 @@
<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>

210
html/accopt.htm
View File

@ -1,210 +0,0 @@
<!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>
<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>
<p>The skunk watches for intruders and sprays.<br clear="left">
</p>
<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 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>
<h4>The Kiss-of-Death Packet</h4>
<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>
<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>
<h4>Access Control Commands</h4>
<dl>
<dt><tt>restrict <i>numeric_address</i> [mask <i>numeric_mask</i>]
[<i>flag</i>][...]</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>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>
<dl>
<dt><tt>kod</tt></dt>
<dd>If access is denied, send a kiss-of-death packet.</dd>
<dt><tt>ignore</tt></dt>
<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>noquery</tt></dt>
<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>
<dt><tt>nomodify</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>
<dt><tt>notrap</tt></dt>
<dd>Decline to provide mode 6 control message trap service to
matching hosts. The trap service is a subsystem of the mode 6
control message protocol which is intended for use by remote event
logging programs.</dd>
<dt><tt>lowpriotrap</tt></dt>
<dd>Declare traps set by matching hosts to be low priority. The
number of traps a server can maintain is limited (the current limit
is 3). Traps are usually assigned on a first come, first served
basis, with later trap requestors being denied service. This flag
modifies the assignment algorithm by allowing low priority traps to
be overridden by later requests for normal priority traps.</dd>
<dt><tt>noserve</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>
<dt><tt>nopeer</tt></dt>
<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>
<dd>Treat these hosts normally in other respects, but never use
them as synchronization sources.</dd>
<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>
<dt><tt>ntpport</tt></dt>
<dd>This is actually a match algorithm modifier, rather than a
restriction flag. Its presence causes the restriction entry to be
matched only if the source port in the packet is the standard NTP
UDP port (123). Both <tt>ntpport</tt> and <tt>non-ntpport</tt> may
be specified. The <tt>ntpport</tt> is considered more specific and
is sorted later in the list.</dd>
<dt><tt>version</tt></dt>
<dd>Ignore these hosts if not the current NTP version.</dd>
</dl>
</dd>
<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>
<dt><tt>clientlimit <i>limit</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>
<dt><tt>clientperiod <i>period</i></tt></dt>
<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>
<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>

89
html/assoc.htm
View File

@ -1,89 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><title>
Association Management
</title></head><body><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>
<p>Make sure who your friends are.
<br clear=left><hr>
<h4>Association Modes</h4>
<p>NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the <a href=confopt.htm>Configuration Options</a> and <a href=authopt.htm>Authentication Options</a> pages and in the papers, reports, memoranda and briefings at <a href=http://www.ntp.org>www.ntp.org</a>.
<p>There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message.
<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.
<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.
<h4>Client/Server Mode</h4>
<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.
<h4>Symmetric Active/Passive Mode</h4>
<p>Symmetric active/passive mode is intended for configurations were a clique of low-stratum peers operate as mutual backups for each other. Each peer operates with one or more primary reference sources, such as a radio clock, or a 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.
<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.
<h4>Broadcast Mode</h4>
<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.
<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.
<h4>IP Multicast Support</h4>
<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.
<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>

187
html/audio.htm
View File

@ -1,187 +0,0 @@
<!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
time/frequency radio stations WWV and WWVH. The radio drivers are
designed to work with ordinary inexpensive shortwave radios and may
be one of the least expensive ways to build a good primary time
server.</p>
<p>All three drivers make ample use of sophisticated digital signal
processing algorithms designed to efficiently extract timing
signals from noise and interference. The radio station drivers in
particular implement optimum linear demodulation and decoding
techniques, including maximum likelihood and soft-decision methods.
The documentation page for each driver contains an in-depth
discussion on the algorithms and performance expectations. In some
cases the algorithms are further analyzed, 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.</p>
<p>The audio drivers include a number of common features designed
to groom input signals, suppress spikes and normalize signal
levels. An automatic gain control (AGC) feature provides protection
against overdriven or underdriven input signals. It is designed to
maintain adequate demodulator signal amplitude while avoiding
occasional noise spikes. In order to assure reliable operation, the
signal level must be in the range where the audio gain control is
effective. In general, this means the input signal level must be
such as to cause the AGC to set the gain somewhere in the middle of
the range from 0 to 255, as indicated in the timecode displayed by
the <tt>ntpq</tt> program.</p>
<p>The drivers operate by disciplining a logical clock based on the
codec sample clock to the audio signal as received. This is done by
stuffing or slipping samples as required to maintain exact
frequency to the order of 0.1 PPM. In order for the driver to
reliably lock on the audio signal, the sample clock frequency
tolerance must be less than 250 PPM (.025 percent) for the IRIG
driver and half that for the radio drivers. The largest error
observed so far is about 60 PPM, but it is possible some sound
cards or codecs may exceed that value.</p>
<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.</p>
<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>
<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.</p>
<p>The WWV/H and CHU transmitters operate on several frequencies
simultaneously, so that in most parts of North America at least one
frequency supports propagation to the receiver location at any
given hour. While both drivers support the ICOM CI-V radio
interface and can tune the radio automatically, computer-tunable
radios are expensive and probably not cost effective compared to a
GPS receiver. So, the radio frequency must usually be fixed and
chosen by compromise.</p>
<p>Shortwave (3-30 MHz) radio propagation phenomena are well known
to shortwave enthusiasts. The phenomena generally obey the
following rules:</p>
<ul>
<li>The optimum frequency is higher in daytime than nighttime,
stays high longer on summer days and low longer on winter
nights.</li>
<li>Transitions between daytime and nightime conditions generally
occur somewhat after sunrise and sunset at the midpoint of the path
from transmitter to receiver.</li>
<li>Ambient noise (static) on the lower frequencies follows the
thunderstorm season, so is higher on summer afternoons and
evenings.</li>
<li>The lower frequency bands are best for shorter distances, while
the higher bands are best for longer distances.</li>
<li>The optimum frequencies are higher at the peak of the 11-year
sunspot cycle and lower at the trough. The current sunspot cycle
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.
<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>
<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>
<h4>Additional Information</h4>
<a href="refclock.htm">Reference Clock Drivers</a> <br>
<a href="driver7.htm">Radio CHU Audio Demodulator/Decoder</a> <br>
<a href="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</a>
<br>
<a href="driver6.htm">IRIG Audio Decoder</a>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

415
html/authopt.htm
View File

@ -1,415 +0,0 @@
<!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>
<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>
<p>Our resident cryptographer; now you see him, now you don't.<br
clear="left">
</p>
<hr>
<h4>Authentication Support</h4>
<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>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>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 <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>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>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>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>
<h4>Symmetric-Key Scheme</h4>
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.
<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>
<h4>Public-Key Scheme</h4>
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.
<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>
<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>
<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>
<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>
<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>
<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>
<h4>Leapseconds Table</h4>
<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>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>
<h4>Key Management</h4>
<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 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>
<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>
<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>
<h4>Authentication Commands</h4>
<dl>
<dt><tt>autokey [<i>logsec</i>]</tt></dt>
<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>controlkey <i>key</i></tt></dt>
<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>
<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>
<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>
<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>

106
html/biblio.htm
View File

@ -1,106 +0,0 @@
<html><head><title>
Protocol Conformance Statement
</title></head><body><h3>
Protocol Conformance Statement
</h3>
<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. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks.
<p>Information on the NTP architecture, protocol and algorithms can be found in the following articles and reports, which are available online. General issues of the concepts and facilities assumed by NTP are discussed in the <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page, while issues related to the NTP timescale and pending century are discussed in the <a href=y2k.htm> Network Time Protocol Year 2000 Conformance Statement</a> page, both of which are included in this software distribution. Network timekeeping technology continues to advance and may obsolete some of the following documents. For a current list of all papers, reports, briefings and other documents relevant to the NTP community, see the <a href=http://www.eecis.udel.edu/~mills>David L. Mills</a> web page. A historical perspective is available in
<ul>
<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>
<p>The NTP architecture, protocol and algorithm models are described 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.
</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>
<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>.
</ul>
<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:
<ol>
<p><li>Support for precision-time kernel modifications, as described in
<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>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, 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><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. 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. 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>Simple Network Monitoring Protocol (SNMP) monitoring tools, 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><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>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. 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>
<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>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><li>Support for International Atomic Time (TAI), as described in</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>Performance surveys for NTP Version 4 can be found in</li>
<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>
<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>

239
html/build.htm
View File

@ -1,239 +0,0 @@
<!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" 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">
</p>
<hr>
<h4>Building and Installing the Distribution</h4>
<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>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>
<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>
<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.
<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>
<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.</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>
<h4>Compilation</h4>
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,
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.</p>
<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 in the destination directory. This
includes the following programs:
<ul>
<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>
</ul>
<p>If the precision time kernel modifications are present, the
following program is installed:</p>
<ul>
<li><a href="ntptime.htm"><tt>ntptime</tt> - read kernel time
variables</a></li>
</ul>
<p>If the public key authentication functions are present, the
following program is installed:</p>
<ul>
<li><a href="genkeys.htm"><tt>ntp-genkeys</tt> - generate public
and private keys</a></li>
</ul>
<p>In some systems that include the capability to edit kernel
variables, the following program is installed:</p>
<ul>
<li><a href="tickadj.htm"><tt>tickadj</tt> - set time-related
kernel variables</a></li>
</ul>
<h4>Configuration</h4>
<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>
<h4>If You Have Problems</h4>
<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>
<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>

74
html/build/hints/solaris.xtra.4095849 Normal file
View File

@ -0,0 +1,74 @@
Bug Id: 4095849
Category: kernel
Subcategory: syscall
State: evaluated
Synopsis: time_constant value >6 with PLL in use leads to integer divide
zero trap panic
Description:
If the time_constant parameter is 7 or higher, and the phase-lock looping model
is in use, the system will take a "integer divide zero trap" panic in
the clock routine as soon as the time_offset becomes non-zero.
time_constant defaults to 0. The only place it is set is in the ntp_adjtime
system call, from the 'constant' element of the timex structure argument.
Work around:
Never set the constant element of the timex structure passed to ntp_adjtime to
a value larger than 6.
satish.mynam@Eng 1998-04-30
1. Use Sun's version of NTP software instead of PD version. This problem
is not seen with Sun's NTP version (which is mostly eqivalent to PD NTP 3.4
plus some Sun's local functionality futures).
2. Workaround for the public domain NTP version ONLY:
=====================================================
The workaround for public domain NTP version is to disable the
KERNEL_PLL from the NTP code. This way ntp_Adjtime() system call is
totally bypassed without sacrificing any of the functionality of the
NTP. The only hit you might see is the way kernel precision timminig
is done without the PLL algorithm in the kernel.
The easiest way to disable ntp_adjtime option is(without changing
any makefiles or other config files) to disable the KERNEL_PLL
value in the ./config.h file.
After doing a ./configure for probing for all the necessary tools(compilers,
os version, libraries), please comment out KERNEL_PLL macro in
the ./config.h file. This will disable the KERNEL_PLL part of the source
code and the newly obtained xntpd is just similar to the old one but it
does not use ntp_adjtime() system call. This prevents it from panic'ng
the kernel.
/*#define KERNEL_PLL 1*/
I complied a new xntpd binary this way and it does nothave any ntp_adjtime()
related stuff.
Default:
=======
/net/divya/export/home/mynam/public_domain/ntp/xntp3-5.92/xntpd>strings
xntpd |
grep ntp_adjtime
354:adj_frequency: ntp_adjtime failed: %m
357:loop_config: ntp_adjtime() failed: %m
435:get_kernel_info: ntp_adjtime() failed: %m
With KERNEL_PLL disabled in config.h file
-=======================
/net/divya/export/home/mynam/public_domain/ntp/xntp3-5.92/xntpd>strings
xntpd.nopll | grep ntp_adjtime
Integrated in releases:
Duplicate of:
Patch id:
See also: 4133517
Summary:
If the time_constant parameter is 7 or higher, and the phase-lock looping model
is in use, the system will take a "integer divide zero trap" panic in
the clock routine as soon as the time_offset becomes non-zero.
time_constant defaults to 0. The only place it is set is in the ntp_adjtime
system call, from the 'constant' element of the timex structure argument.
----------------------------------------------------------------------------

76
html/clockopt.htm
View File

@ -1,76 +0,0 @@
<html><head><title>
Reference Clock Options
</title></head><body><h3>
Reference Clock Options
</h3>
<img align=left src=pic/boom4.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
<p>See the radios, all in a row.
<br clear=left><hr>
<h4>Reference Clock Support</h4>
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 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 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>fudge</tt> command is used to provide additional information for individual clock drivers and normally follows immediately after the <tt>server</tt> command. The <i><tt>address</tt></i> argument specifies the clock address. The <tt>refid</tt> and <tt>stratum</tt> options control can be used to override the defaults for the device. There are two optional device-dependent time offsets and four flags that can be included in the <tt>fudge</tt> command as well.
<p>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.
<h4>Reference Clock Commands</h4>
<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>
<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>mode <i>int</i></tt></dt>
<dd>Specifies a mode number which is interpreted in a device-specific fashion. For instance, it selects a dialing protocol in the ACTS driver and a device subtype in the <tt>parse</tt> drivers.</dd>
<dt><tt>minpoll <i>int</i></tt></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>
</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>
<dl>
<dt><tt>time1 <i>sec</i></tt></dt>
<dd>Specifies a constant to be added to the time offset produced by the driver, a fixed-point decimal number in seconds. This is used as a calibration constant to adjust the nominal time offset of a particular clock to agree with an external standard, such as a precision PPS signal. It also provides a way to correct a systematic error or bias due to serial port or operating system latencies, different cable lengths or receiver internal delay. The specified offset is in addition to the propagation delay provided by other means, such as internal DIPswitches. Where a calibration for an individual system and driver is available, an approximate correction is noted in the driver documentation pages.</dd>
<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>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>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>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>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>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>
</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>

188
html/config.htm
View File

@ -1,188 +0,0 @@
<html><head><title>
Configuration Options
</title></head><body><h3>
Configuration Options
</h3>
<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>
The following options are for compiling and installing a working version
of the NTP distribution. In most cases, the build process is completely
automatic. In some cases where memory space is at a premium, or the
binaries are to be installed in a different place, it is possible to
tailor the configuration to remove such features as reference clock
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, as of the 4.0.99m version:
<P>Usage: <TT>configure [options] [host]</TT>
<BR>Options: <TT>[defaults in brackets after descriptions]</TT>
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
</PRE>
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]
--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]
--sysconfdir=DIR read-only single-machine data in DIR
[PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data in DIR
[PREFIX/com]
--localstatedir=DIR modifiable single-machine data in DIR
[PREFIX/var]
--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
--program-suffix=SUFFIX append SUFFIX to installed program
names
--program-transform-name=PROGRAM run sed PROGRAM on installed program
names
</PRE>
Host type:
<PRE>
--build=BUILD configure for building on BUILD [BUILD=HOST]
--host=HOST configure for HOST [guessed]
--target=TARGET configure for TARGET [TARGET=HOST]
</PRE>
Optional packages:
<PRE>
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
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]
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>
</address></a></body></html>

257
html/confopt.htm
View File

@ -1,257 +0,0 @@
<!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 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>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>
<h4>Auxilliary Commands</h4>
<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>

142
html/copyright.htm
View File

@ -1,142 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><head><title>
Copyright Notice
</title></head><body><h3>
Copyright Notice
</h3>
<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.
<br>
<pre>
***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2001 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission *
* notice appear in supporting documentation, and that the name *
* University of Delaware not be used in advertising or publicity *
* pertaining to distribution of the software without specific, *
* written prior permission. The University of Delaware makes no *
* representations about the suitability this software for any *
* purpose. It is provided "as is" without express or implied *
* warranty. *
* *
***********************************************************************
</pre>
The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.
<ol>
<li><A HREF="mailto: marka@syd.dms.csiro.au">Mark Andrews &lt;marka@syd.dms.csiro.au&gt;</a> Leitch atomic clock controller</li>
<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>
<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: 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: Marc.Brett@westgeo.com">Marc Brett &lt;Marc.Brett@westgeo.com&gt;</a> Magnavox GPS 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: reg@dwf.com">Reg Clemens &lt;reg@dwf.com&gt;</a> Oncore driver (Current maintainer)</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: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: 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: 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: duwe@immd4.informatik.uni-erlangen.de">Torsten Duwe &lt;duwe@immd4.informatik.uni-erlangen.de&gt;</a> Linux 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: glenn@herald.usask.ca">Glenn Hollinger &lt;glenn@herald.usask.ca&gt;</a> GOES clock driver</li>
<li><A HREF="mailto: iglesias@uci.edu">Mike Iglesias &lt;iglesias@uci.edu&gt;</a> DEC Alpha port</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: jbj@chatham.usdesign.com">Jeff Johnson &lt;jbj@chatham.usdesign.com&gt;</a> massive prototyping overhaul</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: phk@FreeBSD.ORG">Poul-Henning Kamp &lt;phk@FreeBSD.ORG&gt;</a> Oncore driver (Original author)</li>
<li><A HREF="http://www4.informatik.uni-erlangen.de/~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: 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: dkatz@cisco.com">Dave Katz &lt;dkatz@cisco.com&gt;</a> RS/6000 AIX port</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: lindholm@ucs.ubc.ca">George Lindholm &lt;lindholm@ucs.ubc.ca&gt;</a> SunOS 5.1 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: 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: 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: moeller@gwdgv1.dnet.gwdg.de">Wolfgang Moeller &lt;moeller@gwdgv1.dnet.gwdg.de&gt;</a> VMS port</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: tmoore@fievel.daytonoh.ncr.com">Tom Moore &lt;tmoore@fievel.daytonoh.ncr.com&gt;</a> i386 svr4 port</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: 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: 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: dirce@zk3.dec.com">Dirce Richards &lt;dirce@zk3.dec.com&gt;</a> Digital UNIX V4.0 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: mrapple@quack.kfu.com">Nick Sayer &lt;mrapple@quack.kfu.com&gt;</a> SunOS streams modules</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: schnitz@unipress.com">Ray Schnitzler &lt;schnitz@unipress.com&gt;</a> Unixware1 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: pebbles.jpl.nasa.gov">Jeff Steinman &lt;jss@pebbles.jpl.nasa.gov&gt;</a> Datum PTS 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: ken@sdd.hp.com">Kenneth Stone &lt;ken@sdd.hp.com&gt;</a> HP-UX 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: 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>

2
html/copyright.html
View File

@ -19,7 +19,7 @@
<pre>
***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2008 *
* Copyright (c) David L. Mills 1992-2009 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *

477
html/debug.htm
View File

@ -1,477 +0,0 @@
<!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" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<p>We make house calls and bring our own bugs.<br clear="left">
</p>
<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>
<h4>Initial Startup</h4>
<p>The best way to verify correct operation is using the <tt><a
href="ntpq.htm">ntpq</a></tt> and <tt><a href="ntpdc.htm">
ntpdc</a></tt> utility programs, either on the server itself or
from another machine elsewhere in the network. The <tt>ntpq</tt>
program implements the management functions specified in 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>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 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>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>
<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>
<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>
<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 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>
<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>
<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&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>
<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>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>
<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>
<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>The state of the local clock itself can be determined using the
<tt>rv</tt> command (without the argument), such as</p>
<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>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>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>
<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>
<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>
<h4>Special Problems</h4>
<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>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>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>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>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>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>
<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>

157
html/driver1.htm
View File

@ -1,157 +0,0 @@
<!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>
<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>
<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>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>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>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>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>
<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>
<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>
<h4>Monitor Data</h4>
No <tt>filegen clockstats</tt> monitor data are produced by this
driver.
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the time offset calibration factor, in seconds and
fraction, with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Specifies the frequency offset calibration factor, in parts per
million, with default 0.0.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 3.</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>LCL</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
</dl>
<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>

114
html/driver10.htm
View File

@ -1,114 +0,0 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>Austron 2200A/2201A GPS Receivers
</TITLE>
</HEAD>
<BODY>
<H3>
Austron 2200A/2201A GPS Receivers</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.10.<I>u</I>
<BR>Reference ID: <TT>GPS</TT>
<BR>Driver ID: <TT>GPS_AS2201</TT>
<BR>Serial Port: <TT>/dev/gps<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock
and Timing Receiver connected via a serial port. It supports several special
features of the clock, including the Input Buffer Module, Output Buffer
Module, IRIG-B Interface Module and LORAN Assist Module. It requires the
RS232 Buffered Serial Interface module for communication with the driver.
For operation with multiple computers, it requires the <TT>ppsclock</TT>
streams module described in the <A HREF="ldisc.htm">Line Disciplines and
Streams Modules</A> page. The streams module requires a gadget box and
1-PPS level converter, such as described in the <A HREF="pps.htm">Pulse-per-second
(PPS) Signal Interfacing</A> page.
<P>For use with a single computer, the receiver can be connected directly
to the receiver. For use with multiple computers, one of them is connected
directly to the receiver and generates the polling messages. The other
computers just listen to the receiver output directly or through a buffer
amplifier. For computers that just listen, <TT>fudge flag2</TT> must be
set and the <TT>ppsclock </TT>streams module configured on each of them.
<P>This receiver is capable of a comprehensive and large volume of statistics
and operational data. The specific data collection commands and attributes
are embedded in the driver source code; however, the collection process
can be enabled or disabled using the flag4 flag. If set, collection is
enabled; if not, which is the default, it is disabled. A comprehensive
suite of data reduction and summary scripts is in the ./scripts/stats directory
of the ntp3 distribution.
<H4>
Monitor Data</H4>
When enabled by the <TT>flag4</TT> fudge flag, every received timecode
is written as-is to the <TT>clockstats</TT> file.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>GPS</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Set for computers that listen-only.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Enable verbose <TT>clockstats</TT> recording if set.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

150
html/driver11.htm
View File

@ -1,150 +0,0 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>Arbiter 1088A/B GPS Receiver
</TITLE>
</HEAD>
<BODY>
<H3>
Arbiter 1088A/B GPS Receiver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.11.<I>u</I>
<BR>Reference ID: <TT>GPS</TT>
<BR>Driver ID: <TT>GPS_ARBITER</TT>
<BR>Serial Port: <TT>/dev/gps<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The
claimed accuracy of this clock is 100 ns relative to the PPS output when
receiving four or more satellites.
<P>The receiver should be configured before starting the NTP daemon, in
order to establish reliable position and operating conditions. It does
not initiate surveying or hold mode. For use with NTP, the daylight savings
time feature should be disables (<TT>D0</TT> command) and the broadcast
mode set to operate in UTC (<TT>BU</TT> command).
<P>The timecode format supported by this driver is selected by the poll
sequence <TT>B5</TT>, which initiates a line in the following format to
be repeated once per second until turned off by the <TT>B0</TT> command.
<P>Format <TT>B5</TT> (24 ASCII printing characters):
<PRE>&lt;cr>&lt;lf>i yy ddd hh:mm:ss.000bbb
on-time = &lt;cr>
i = synchronization flag (' ' = locked, '?' = unlocked)
yy = year of century
ddd = day of year
hh:mm:ss = hours, minutes, seconds
.000 = fraction of second (not used)
bbb = tailing spaces for fill</PRE>
The alarm condition is indicated by a '?' at i, which indicates the receiver
is not synchronized. In normal operation, a line consisting of the timecode
followed by the time quality character (TQ) followed by the receiver status
string (SR) is written to the clockstats file.
<P>The time quality character is encoded in IEEE P1344 standard:
<P>Format <TT>TQ</TT> (IEEE P1344 estimated worst-case time quality)
<PRE>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock locked, maximum accuracy
F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock failure, time not reliable
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 1 us
5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 10 us
6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 100 us
7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 1 ms
8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 10 ms
9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 100 ms
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 1 s
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clock unlocked, accuracy &lt; 10 s</PRE>
The status string is encoded as follows:
<P>Format <TT>SR</TT> (25 ASCII printing characters)
<PRE>V=vv S=ss T=t P=pdop E=ee
vv = satellites visible
ss = relative signal strength
t = satellites tracked
pdop = position dilution of precision (meters)
ee = hardware errors</PRE>
A three-stage median filter is used to reduce jitter and provide a dispersion
measure. The driver makes no attempt to correct for the intrinsic jitter
of the radio itself.
<H4>
Monitor Data</H4>
When enabled by the <TT>flag4</TT> fudge flag, an additional line containing
the latitude, longitude, elevation and optional deviation data is written
to the <TT>clockstats</TT> file. The deviation data operates with an external
pulse-per-second (PPS) input, such as a cesium oscillator or another radio
clock. The PPS input should be connected to the B event channel and the
radio initialized for deviation data on that channel. The deviation data
consists of the mean offset and standard deviation of the external PPS
signal relative the GPS signal, both in microseconds over the last 16 seconds.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>GPS</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Enable verbose <TT>clockstats</TT> recording if set.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

98
html/driver12.htm
View File

@ -1,98 +0,0 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>KSI/Odetics TPRO/S IRIG Interface
</TITLE>
</HEAD>
<BODY>
<H3>
KSI/Odetics TPRO/S IRIG Interface</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.12.<I>u</I>
<BR>Reference ID: <TT>IRIG</TT>
<BR>Driver ID: <TT>IRIG_TPRO</TT>
<BR>TPRO Device: <TT>/dev/tpro<I>u</I></TT>
<BR>Requires: KSI/Odetics device driver, <TT>/usr/include/sys/tpro.h</TT> header file
<H4>
Description</H4>
This driver supports the KSI/Odetics TPRO and TPRO-SAT IRIG-B Decoder,
which is a module connected directly to the SBus of a Sun workstation.
The module works with the IRIG-B signal generated by several radio clocks,
including those made by Arbiter, Austron, Odetics, Spectracom and TrueTime,
among others, although it is generally an add- on option. In the case of
the TPRO-SAT, the module is an integral part of a GPS receiver, which serves
as the primary timing source.
<P>Using the TPRO interface as a NTP reference clock provides precision
time only to ntpd and its clients. With suitable kernel modifications,
it is possible to use the TPRO as the CPU system clock, avoiding errors
introduced by the CPU clock oscillator wander. See the <A HREF="kern.htm">A
Kernel Model for Precision Timekeeping </A>page for further details.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>IRIG</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

43
html/driver16.htm
View File

@ -1,43 +0,0 @@
<!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.6 [en] (Win95; U) [Netscape]">
<meta name="Author" content="Ganesh Ramasivan">
<title>Bancomm bc635VME Time and Frequency Processor</title>
</head>
<body>
<h3>
bc635VME/bc350VXI Time and Frequency Processor</h3>
<hr>
<h4>
Synopsis</h4>
Address: <font size=-1>127.127.16</font>.<i>u</i>
<br>Reference ID: <font size=-1>BTFP</font>
<br>Driver ID: <font size=-1>GPS_BANCOMM</font>
<br>Bancomm Device<font size=-1>:&nbsp; /dev/btfp0</font>
<br>Requires<font size=-1>: Bancomm bc635 TFP device module driver for
SunOS 4.x/SunOS 5.x</font>
<h4>
Description</h4>
This is the clock driver for the Bancomm bc635VME Time and Frequency Processor.
It requires the BANCOMM bc635VME /
<br>bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS
5.x UNIX Systems.
<p>Most of this code is originally from refclock_bancomm.c with thanks.
It has been modified and tested on an UltraSparc IIi-cEngine
<br>running Solaris 2.6. A port for HPUX is not available henceforth.
<br>&nbsp;
<h4>
Additional Information</h4>
<p><br><a href="http://www.eecis.udel.edu/~ntp/ntp_spool/html/refclock.htm">Reference
Clock Drivers</a>
<hr>
<address>
David L. Mills (mills@udel.edu)</address>
</body>
</html>

235
html/driver18.htm
View File

@ -1,235 +0,0 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>NIST Modem Time Service
</TITLE>
</HEAD>
<BODY>
<H3>
NIST Modem Time Service</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.18.<I>u</I>
<BR>Reference ID: <TT>NIST</TT>
<BR>Driver ID: <TT>ACTS_NIST</TT>
<BR>Serial Port: <TT>/dev/acts<I>u</I></TT>; 1200 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<BR>Requires: <TT>/usr/include/sys/termios.h</TT> header file with modem
control
<H4>
Description</H4>
This driver supports the NIST Automated Computer Time Service (ACTS). It
periodically dials a prespecified telephone number, receives the NIST 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>The ACTS is located at NIST Boulder, CO, telephone 303 494 4774. A toll
call from Newark, DE, costs between three and four cents, although it is
not clear what carrier and time of day discounts apply. The modem dial
string will differ depending on local telephone configuration, etc., and
is specified by the phone command in the configuration file. The argument
to this command is an AT command for a Hayes compatible modem.
<P>The driver can operate in either of two modes, as determined by the
mode parameter in the server configuration command. In mode 0 the driver
operates continuously at intervals determined by the fudge time1 parameter,
as described above. In mode 1 the driver is enabled only when no other
sources of synchronization are available and when we have gone more than
MAXOUTAGE (3600 s) since last synchronized by other sources of synchronization.
<P>The accuracy produced by this driver should be in the range of a millisecond
or two, but may need correction due to the delay characteristics of the
individual modem involved. For undetermined reasons, some modems work with
the ACTS echo-delay measurement scheme and some don't. This driver tries
to do the best it can with what it gets. Initial experiments with a Practical
Peripherals 9600SA modem here in Delaware suggest an accuracy of a millisecond
or two can be achieved without the scheme by using a fudge time1 value
of 65.0 ms. In either case, the dispersion for a single call involving
ten samples is about 1.3 ms.
<P>For reliable call management, this driver requires a 1200-bps modem
with a Hayes-compatible command set and control over the modem data terminal
ready (DTR) control line. Present restrictions require the use of a POSIX-compatible
programming interface, although other interfaces may work as well. The
ACTS telephone number and modem setup string are hard-coded in the driver
and may require changes for nonstandard modems or special circumstances.
<P>The fudge time1 parameter represents a propagation-delay correction
factor which is added to the value computed by ACTS when the echo-delay
scheme is used. This scheme does not work with all modems; for those that
don't, fudge flag2 should be set to disable the feature. In this case the
fudge time1 parameter represents the total propagation delay due to all
causes and must be determined by external calibration.
<P>The ACTS call interval is determined by a counter initially set to the
fudge time2 parameter. At each poll interval, minpoll (usually 64 s) is
subtracted from the counter. When the counter is equal to or less than
zero, the fudge flag1 is set, which causes up to three call attempts to
be made to ACTS. The fudge flag1 is reset after a valid clock update has
been determined or by a device fault, timeout or manually using <TT>ntpdc</TT>.
After a valid clock update, the counter is reset for the next interval.
Setting the <TT>fudge time2</TT> parameter to zero disables automatic call
attempts. Manual call attempts can be made at any time by setting <TT>fudge
flag1</TT> using ntpdc.
<P>The NIST timecode message is transmitted at 1200 bps in the following
format:
<PRE>
jjjjj yy-mm-dd hh:mm:ss tt l uuu mmmmm UTC(NIST) *
jjjjj = modified Julian day
yy-mm-dd = year, month, day
hh:mm:ss = hours, minutes, seconds
tt = DST indicator (see driver listing)
l = leap-second warning (see driver listing)
uuu = DUT1 correction (see driver listing)
mmmmm = modem calibration (see driver listing)
on-time = '*'</PRE>
The timecode message is transmitted continuously after a signon banner,
which this driver ignores. The driver also ignores all but the yy-mm-dd,
hh:mm:ss and on-time character '*' fields, although it checks the format
of all fields of the message. A timestamp is captured at the '*' character,
as required by the ACTS specification, and used as the reference time of
the timecode. If a message with an on-time character of '#' is received,
the driver updates the propagation delay. The driver disconnects when (a)
ten valid messages have been received, (b) no message has been received
for 15 s, (c) an on-time character of '#' is received. These messages are
processed by a trimmed-mean filter to reduce timing noise and then by the
usual NTP algorithms to develop the clock correction.
<P>Since the accumulated error grows with the interval between calls, it
is important that the intrinsic frequency error be minimized. This can
be done by observing difference in offsets between two calls placed some
hours apart and calculating the uncorrected frequency error. This error,
as a fixed-point value in parts-per-million, should be installed in the
ntp.drift file before the daemon is started. Some experimentation may be
necessary in order to reduce the intrinsic frequency error to the order
of 1 ppm.
<P>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 prefer keyword of the server configuration command,
in which case only this driver will be selected for synchronization and
all other discipline sources will be ignored.
<P>Unlike other drivers, each ACTS call generates one clock correction
and that correction is processed immediately. There is no wait to allow
the clock filter to accumulate samples. In addition, the watchdog timeout
of the local clock algorithm is disabled, so that a correction received
from this driver that exceeds CLOCK_MAX (128 ms) causes an immediate step/slew.
<P>Since the interval between updates can be much longer than used with
ordinary NTP peers, the local clock procedure has been modified to operate
in either of two modes, depending on whether the interval between updates
is less than or greater than CLOCK_MAXSEC (1200 s). If less than this value,
the local clock procedure operates using the standard NTP phase-lock loop
as with other NTP peers. If greater than this value, the procedure operates
using a modified frequency-lock loop suggested by Judah Levine in his lockclock
algorithm designed specifically for ACTS.
<H4>
Call Management</H4>
Since ACTS will be a toll call in most areas of the country, it is necessary
to carefully manage the call frequency. This can be done in two ways, by
specifying the interval between calls, or by setting a flag bit manually
or via a cron job. The call interval is determined by a counter initially
set to the fudge time2 parameter. At each poll interval, minpoll (usually
64 s) is subtracted from the counter. When the counter is equal to or less
than zero, the fudge flag1 is set, which causes up to three call attempts
to be made. The fudge flag1 is reset after ten offset samples have been
determined in a single call or by a device fault, timeout or manually using
ntpdc. Upon successful completion of a call, the eight samples have been
shifted into the clock filter, the local clock updated and the counter
reset for the next interval. Setting the fudge time2 parameter to zero
disables automatic call attempts.
<P>Manual call attempts can be made at any time by setting fudge flag1
using ntpdc. For example, the ntpdc command
<PRE>
fudge 127.127.18.1 flags 1</PRE>
will ask for a key identifier and password and, if authenticated by the
server, will set flag1. There may be a short delay until the expiration
of the current poll timeout.
<P>The flag1 can be set from a cron job in the following way. Construct
a file with contents
<PRE>keyid 11
passwd dialup
fudge 127.127.18.1 flags 1
quit</PRE>
Then, run the following program at specified times as required.
<PRE>/usr/local/bin/ntpdc &lt;file</PRE>
<H4>
Monitor Data</H4>
When enabled by the <TT>flag4</TT> fudge flag, every received timecode
is written as-is to the <TT>clockstats</TT> file.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>NIST</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

124
html/driver19.htm
View File

@ -1,124 +0,0 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>Heath WWV/WWVH Receiver
</TITLE>
</HEAD>
<BODY>
<H3>
Heath WWV/WWVH Receiver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.19.<I>u</I>
<BR>Reference ID: <TT>WWV</TT>
<BR>Driver ID: <TT>WWV_HEATH</TT>
<BR>Serial Port: <TT>/dev/heath<I>u</I></TT>; 1200 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<BR>Requires: <TT>/usr/include/sys/termios.h</TT> header file with modem
control
<H4>
Description</H4>
This driver supports the Heath GC-1000 Most Accurate Clock, with RS232C
Output Accessory. This is a WWV/WWVH receiver somewhat less robust than
other supported receivers. Its claimed accuracy is 100 ms when actually
synchronized to the broadcast signal, but this doesn't happen even most
of the time, due to propagation conditions, ambient noise sources, etc.
When not synchronized, the accuracy is at the whim of the internal clock
oscillator, which can wander into the sunset without warning. Since the
indicated precision is 100 ms, expect a host synchronized only to this
thing to wander to and fro, occasionally being rudely stepped when the
offset exceeds the default CLOCK_MAX of 128 ms.
<P>The internal DIPswitches should be set to operate at 1200 baud in MANUAL
mode and the current year. The external DIPswitches should be set to GMT
and 24-hour format. It is very important that the year be set correctly
in the DIPswitches; otherwise, the day of year will be incorrect after
28 April of a normal or leap year.
<P>In MANUAL mode the clock responds to a rising edge of the request to
send (RTS) modem control line by sending the timecode. Therefore, it is
necessary that the operating system implement the <TT>TIOCMBIC</TT> and
<TT>TIOCMBIS</TT> ioctl system calls and <TT>TIOCM_RTS</TT> control bit.
Present restrictions require the use of a POSIX-compatible programming
interface, although other interfaces may work as well.
<P>The clock message consists of 23 ASCII printing characters in the following
format:
<PRE>hh:mm:ss.f&nbsp;&nbsp;&nbsp;&nbsp; dd/mm/yr&lt;cr>
hh:mm:ss.f = hours, minutes, seconds
f = deciseconds ('?' when out of spec)
dd/mm/yr = day, month, year</PRE>
The alarm condition is indicated by '?', rather than a digit, at A. Note
that 0?:??:??.? is displayed before synchronization is first established
and hh:mm:ss.? once synchronization is established and then lost again
for about a day.
<P>A fudge time1 value of .07 s appears to center the clock offset residuals.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>WWV</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

137
html/driver2.htm
View File

@ -1,137 +0,0 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>Trak 8820 GPS Receiver
</TITLE>
</HEAD>
<BODY>
<H3>
Trak 8820 GPS Receiver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.2.<I>u</I>
<BR>Reference ID: <TT>GPS</TT>
<BR>Driver ID: <TT>GPS_TRAK</TT>
<BR>Serial Port: <TT>/dev/trak<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver supports the Trak 8820 GPS Station Clock. The claimed accuracy
at the 1-PPS output is 200-300 ns relative to the broadcast signal; however,
in most cases the actual accuracy is limited by the precision of the timecode
and the latencies of the serial interface and operating system.
<P>For best accuracy, this radio requires the <TT>tty_clk</TT> line discipline,
which captures a timestamp at the <TT>*</TT> on-time character of the timecode.
Using this discipline the jitter is in the order of 1 ms and systematic
error about 0.5 ms. If unavailable, the buffer timestamp is used, which
is captured at the <TT>\r</TT> ending the timecode message. This introduces
a systematic error of 23 character times, or about 24 ms at 9600 bps, together
with a jitter well over 8 ms on Sun IPC-class machines.
<P>Using the menus, the radio should be set for 9600 bps, one stop bit
and no parity. It should be set to operate in computer (no echo) mode.
The timecode format includes neither the year nor leap-second warning.
<P>In operation, this driver sends a <TT>RQTS\r</TT> request to the radio
at initialization in order to put it in continuous time output mode. The
radio then sends the following message once each second:
<PRE>*RQTS U,ddd:hh:mm:ss.0,q&lt;cr>&lt;lf>
on-time = '*'
ddd = day of year
hh:mm:ss = hours, minutes, seconds
q = quality indicator (phase error), 0-6:
&nbsp;&nbsp;&nbsp;&nbsp; 0 > 20 us
&nbsp;&nbsp;&nbsp;&nbsp; 6 > 10 us
&nbsp;&nbsp;&nbsp;&nbsp; 5 > 1 us
&nbsp;&nbsp;&nbsp;&nbsp; 4 > 100 ns
&nbsp;&nbsp;&nbsp;&nbsp; 3 > 10 ns
&nbsp;&nbsp;&nbsp;&nbsp; 2 &lt; 10 ns</PRE>
The alarm condition is indicated by <TT>0</TT> at <TT>Q</TT>, which means
the radio has a phase error greater than 20 us relative to the broadcast
time. The absence of year, DST and leap-second warning in this format is
also alarmed.
<P>The continuous time mode is disabled using the <TT>RQTX\r</TT> request,
following which the radio sends a <TT>RQTX DONE&lt;cr>&lt;lf></TT> response.
In the normal mode, other control and status requests are effective, including
the leap-second status request <TT>RQLS&lt;cr></TT>. The radio responds
with <TT>RQLS yy,mm,dd&lt;cr>&lt;lf></TT>, where <TT>yy,mm,dd</TT> are
the year, month and day. Presumably, this gives the epoch of the next leap
second, <TT>RQLS 00,00,00</TT> if none is specified in the GPS message.
Specified in this form, the information is generally useless and is ignored
by the driver.
<H4>
Monitor Data</H4>
When enabled by the <TT>flag4</TT> fudge flag, every received timecode
is written as-is to the <TT>clockstats</TT> file.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>GPS</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<P>Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A></DL>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

161
html/driver20.htm
View File

@ -1,161 +0,0 @@
<!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>
<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
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>
&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)
&nbsp; LON&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Longitude (yyyyy.yy)
&nbsp; LON_REF&nbsp; - Longitude direction (E = East, W = West)
&nbsp; SPD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Speed over ground. (knots) (x.x)
&nbsp; HDG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Heading/track made good (degrees True) (x.x)
&nbsp; DATE&nbsp;&nbsp;&nbsp;&nbsp; - Date (ddmmyy)
&nbsp; MAG_VAR&nbsp; - Magnetic variation (degrees) (x.x)
&nbsp; MAG_REF&nbsp; - Magnetic variation (E = East, W = West)
&nbsp; FIX_MODE - Position Fix Mode ( 0 = Invalid, >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.</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>
Switch off all output with by sending it the following string.
<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>
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>
<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>
<dd>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</dd>
<dt>
<tt>time2 <i>time</i></tt></dt>
<dd>
Not used by this driver.</dd>
<dt>
<tt>stratum <i>number</i></tt></dt>
<dd>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd>
<dt>
<tt>refid <i>string</i></tt></dt>
<dd>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <tt>GPS</tt>.</dd>
<dt>
<tt>flag1 0 | 1</tt></dt>
<dd>
Not used by this driver.</dd>
<dt>
<tt>flag2 0 | 1</tt></dt>
<dd>
Specifies the PPS signal on-time edge: 0 for assert (default), 1 for clear.</dd>
<dt>
<tt>flag3 0 | 1</tt></dt>
<dd>
Controls the kernel PPS discipline: 0 for disable (default), 1 for enable.</dd>
<dt>
<tt>flag4 0 | 1</tt></dt>
<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>
<hr>
<address>
David L. Mills (mills@udel.edu)</address>
</body>
</html>

159
html/driver22.htm
View File

@ -1,159 +0,0 @@
<!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>
<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 or Parallel Port: <tt>/dev/pps<i>u</i></tt> <br>
Requires: PPSAPI interface
<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>
<h4>Description</h4>
<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>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>
<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>
<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>
<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>
<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>
<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&gt;</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 0.</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from
one to four characters, with default <tt>PPS</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Specifies the PPS signal on-time edge: 0 for assert (default),
1 for clear.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Controls the kernel PPS discipline: 0 for disable (default), 1
for enable.</dd>
<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>

178
html/driver23.htm
View File

@ -1,178 +0,0 @@
<HTML>
<HEAD>
<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 and other European Laboratories Time
Services</H3>
<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>
<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>
<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>

85
html/driver24.htm
View File

@ -1,85 +0,0 @@
<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>USNO Modem Time Service
</TITLE>
</HEAD>
<BODY>
<H3>
USNO Modem Time Service</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.24.<I>u</I>
<BR>Reference ID: <TT>USNO</TT>
<BR>Driver ID: <TT>ACTS_USNO</TT>
<BR>Serial Port: <TT>/dev/cua<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 information available.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>USNO</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Enable <TT>clockstats</TT> recording if set.</DD>
</DL>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

109
html/driver26.htm
View File

@ -1,109 +0,0 @@
<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>Hewlett Packard 58503A GPS Receiver
</TITLE>
</HEAD>
<BODY>
<H3>
Hewlett Packard 58503A GPS Receiver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.26.<I>u</I>
<BR>Reference ID: <TT>GPS</TT>
<BR>Driver ID: <TT>GPS_HP</TT>
<BR>Serial Port: <TT>/dev/hpgps<I>u</I></TT>; 9600 baud, 8-bits, no parity
<H4>
Description</H4>
This driver supports the HP 58503A Time and Frequency Reference Receiver.
It uses HP SmartClock (TM) to implement an Enhanced GPS receiver. The receiver
accuracy when locked to GPS in normal operation is better than 1 usec.
The accuracy when operating in holdover is typically better than 10 us
per day. It receiver should be operated with factory default settings.
Initial driver operation: expects the receiver to be already locked to
GPS, configured and able to output timecode format 2 messages.
<P>The driver uses the poll sequence <TT>:PTIME:TCODE?</TT> to get a response
from the receiver. The receiver responds with a timecode string of ASCII
printing characters, followed by a &lt;cr>&lt;lf>, followed by a prompt
string issued by the receiver, in the following format:
<PRE>T#yyyymmddhhmmssMFLRVcc&lt;cr>&lt;lf></PRE>
The driver processes the response at the &lt;cr> and &lt;lf>&lt;cr> and
&lt;lf>, so what the driver sees is the prompt from the previous poll,
followed by this timecode. The prompt from the current poll is (usually)
left unread until the next poll. So (except on the very first poll) the
driver sees this:
<PRE>T#yyyymmddhhmmssMFLRVcc&lt;cr>&lt;lf></PRE>
The T is the on-time character, at 980 msec. before the next 1PPS edge.
The # is the timecode format type. We look for format 2. Without any of
the CLK or PPS stuff, then, the receiver buffer timestamp at the &lt;cr>y
is 24 characters later, which is about 25 msec. at 9600 bps, so the first
approximation for fudge time1 is nominally -0.955 seconds. This number
probably needs adjusting for each machine / OS type, so far: -0.955000
on an HP 9000 Model 712/80 HP-UX 9.05 -0.953175 on an HP 9000 Model 370
HP-UX 9.10
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>GPS</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
</DL>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

634
html/driver27.htm
View File

@ -1,634 +0,0 @@
<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>Arcron MSF Receiver
</TITLE>
</HEAD>
<BODY>
<H3>
Arcron MSF Receiver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.27.<I>u</I>
<BR>Reference ID: <TT>MSFa</TT>
<BR>Driver ID: <TT>MSF_ARCRON</TT>
<BR>Serial Port: <TT>/dev/arc<I>u</I></TT>; 300 baud, 8-bits, 2-stop, no
parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver supports the Arcron MSF receiver, and would probably also support
the DCF77 variant of the same clock. The clock reports its ID as ``<TT>MSFa</TT>''
to indicate MSF as a source and the use of the ARCRON driver.
<P>This documentation describes version V1.1 (1997/06/23) of the source
and has been tested (amongst others) against ntpd3-5.90 on Solaris-1 (SunOS
4.1.3_U1 on an SS1 serving as a router and firewall) and against ntpd3-5.90
on Solaris-2.5 (on a SS1+ and TurboSPARC 170MHz). This code will probably
work, and show increased stability, reduced jitter and more efficiency
(fewer context switches) with the <TT>tty_clk</TT> discipline/STREAMS module
installed, but this has not been tested. For a to-do list see the comments
at the start of the code.
<P>This code has been significantly slimmed down since the V1.0 version,
roughly halving the memory footprint of its code and data.
<P>This driver is designed to allow the unit to run from batteries as designed,
for something approaching the 2.5 years expected in the usual stand-alone
mode, but no battery-life measurements have been taken.
<P>Much of this code is originally from the other refclock driver files
with thanks. The code was originally made to work with the clock by <A HREF="mailto:derek@toybox.demon.co.uk">Derek
Mulcahy</A>, with modifications by <A HREF="mailto:d@hd.org">Damon Hart-Davis</A>.
Thanks also to <A HREF="mailto:lyndond@sentinet.co.uk">Lyndon David</A>
for some of the specifications of the clock.
<P>There is support for a Tcl/Tk monitor written by Derek Mulcahy that
examines the output stats; see the <A HREF="http://www2.exnet.com/NTP/ARC/ARC.htm">ARC
Rugby MSF Receiver</A> page for more details and the code.
<P>Look at the notes at the start of the code for further information;
some of the more important details follow.
<P>The driver interrogates the clock at each poll (ie every 64s by default)
for a timestamp. The clock responds at the start of the next second (with
the start bit of the first byte being on-time). The time is in `local'
format, including the daylight savings adjustment when it is in effect.
The driver code converts the time back to UTC.
<P>The clock claims to be accurate to within about 20ms of the MSF-broadcast
time, and given the low data transmission speed from clock to host, and
the fact that the clock is not in continuous sync with MSF, it seems sensible
to set the `precision' of this clock to -5 or -4, -4 being used in this
code, which builds in a reported dispersion of over 63ms (ie says ``This
clock is not very good.''). You can improve the reported precision to -4
(and thus reduce the base dispersion to about 31ms) by setting the fudge
<TT>flag3</TT> to <TT>1</TT>.
<P>Even a busy and slow IP link can yield lower dispersions than this from
polls of primary time servers on the Internet, which reinforces the idea
that this clock should be used as a backup in case of problems with such
an IP link, or in the unfortunate event of failure of more accurate sources
such as GPS.
<P>By default this clock reports itself to be at stratum 2 rather than
the usual stratum 0 for a refclock, because it is not really suited to
be used as other than a backup source. The stratum reported can be changed
with the <TT>fudge</TT> directive to be whatever you like. After careful
monitoring of your clock, and appropriate choice of the <TT>time1</TT>
fudge factor to remove systematic errors in the clock's reported time,
you might fudge the clock to stratum 1 to allow a stratum-2 secondary server
to sync to it.
<P>The driver code arranges to resync the clock to MSF at intervals of
a little less than an hour (deliberately avoiding the same time each hour
to avoid any systematic problems with the signal or host). Whilst resyncing,
the driver supplements the normal polls for time from the clock with polls
for the reception signal quality reported by the clock. If the signal quality
is too low (0--2 out of a range of 0--5), we chose not to trust the clock
until the next resync (which we bring forward by about half an hour). If
we don't catch the resync, and so don't know the signal quality, we do
trust the clock (because this would generally be when the signal is very
good and a resync happens quickly), but we still bring the next resync
forward and reduce the reported precision (and thus increase reported dispersion).
<P>If we force resyncs to MSF too often we will needlessly exhaust the
batteries the unit runs from. During clock resync this driver tries to
take enough time samples to avoid <TT>ntpd</TT> losing sync in case this
clock is the current peer. By default the clock would only resync to MSF
about once per day, which would almost certainly not be acceptable for
NTP purposes.
<P>The driver does not force an immediate resync of the clock to MSF when
it starts up to avoid excessive battery drain in case <TT>ntpd</TT> is
going to be repeatedly restarted for any reason, and also to allow enough
samples of the clock to be taken for <TT>ntpd</TT> to sync immediately
to this clock (and not remain unsynchronised or to sync briefly to another
configured peer, only to hop back in a few poll times, causing unnecessary
disturbance). This behaviour should not cause problems because the driver
will not accept the timestamps from the clock if the status flag delivered
with the time code indicates that the last resync attempt was unsuccessful,
so the initial timestamps will be close to reality, even if with up to
a day's clock drift in the worst case (the clock by default resyncs to
MSF once per day).
<P>The clock has a peculiar RS232 arrangement where the transmit lines
are powered from the receive lines, presumably to minimise battery drain.
This arrangement has two consequences:
<UL>
<LI>
Your RS232 interface must drive both +ve and -ve</LI>
<LI>
You must (in theory) wait for an echo and a further 10ms between characters</LI>
</UL>
This driver, running on standard Sun hardware, seems to work fine; note
the use of the <TT>send_slow()</TT> routine to queue up command characters
to be sent once every two seconds.
<P>Three commands are sent to the clock by this driver. Each command consists
of a single letter (of which only the bottom four bits are significant),
followed by a CR (ASCII 13). Each character sent to the clock should be
followed by a delay to allow the unit to echo the character, and then by
a further 10ms. Following the echo of the command string, there may be
a response (ie in the cae of the <TT>g</TT> and <TT>o</TT> commands below),
which in the case of the <TT>o</TT> command may be delayed by up to 1 second
so as the start bit of the first byte of the response can arrive on time.
The commands and their responses are:
<DL>
<DT>
<TT>g</TT> CR</DT>
<DD>
Request for signal quality. Answer only valid during (late part of) resync
to MSF signal. The response consists of two characters as follows:</DD>
<OL>
<DL compact>
<DT>
bit 7</DT>
<DD>
parity</DD>
<DT>
bit 6</DT>
<DD>
always 0</DD>
<DT>
bit 5</DT>
<DD>
always 1</DD>
<DT>
bit 4</DT>
<DD>
always 1</DD>
<DT>
bit 3</DT>
<DD>
always 0</DD>
<DT>
bit 2</DT>
<DD>
always 0</DD>
<DT>
bit 1</DT>
<DD>
always 1</DD>
<DT>
bit 0</DT>
<DD>
= 0 if no reception attempt at the moment, = 1 if reception attempt (ie
resync) in progress</DD>
</DL>
<DL compact>
<DT>
bit 7</DT>
<DD>
parity</DD>
<DT>
bit 6</DT>
<DD>
always 0</DD>
<DT>
bit 5</DT>
<DD>
always 1</DD>
<DT>
bit 4</DT>
<DD>
always 1</DD>
<DT>
bit 3</DT>
<DD>
always 0</DD>
<DT>
bit 2--0</DT>
<DD>
reception signal quality in the range 0--5 (very poor to very good); if
in the range 0--2 no successful reception is to be expected. The reported
value drops to zero when not resyncing, ie when first returned byte is
not `3'.</DD>
</DL>
</OL>
<DT>
<TT>h</TT> CR</DT>
<DD>
Request to resync to MSF. Can take up from about 30s to 360s. Drains batteries
so should not be used excessively. After this the clock time and date should
be correct and the phase within 20ms of time as transmitted from Rugby
MSF (remember to allow for propagation time). By default the clock resyncs
once per day shortly after 2am (presumably to catch transitions to/from
daylight saving time quickly). With this driver code we resync at least
once per hour to minimise clock wander.</DD>
<DT>
<TT>o</TT> CR</DT>
<DD>
Request timestamp. Start bit of first byte of response is on-time, so may
be delayed up to 1 second. Note that when the BST mode is in effect the
time is GMT/UTC +0100, ie an hour ahead of UTC to reflect local time in
the UK. The response data is as follows:</DD>
<OL>
<LI>
hours tens (hours range from 00 to 23)</LI>
<LI>
hours units</LI>
<LI>
minutes tens (minutes range from 00 to 59)</LI>
<LI>
minutes units</LI>
<LI>
seconds tens (seconds presumed to range from 00 to 60 to allow for leap
second)</LI>
<LI>
seconds units</LI>
<LI>
day of week 1 (Monday) to 7 (Sunday)</LI>
<LI>
day of month tens (day ranges from 01 to 31)</LI>
<LI>
day of month units</LI>
<LI>
month tens (months range from 01 to 12)</LI>
<LI>
month units</LI>
<LI>
year tens (years range from 00 to 99)</LI>
<LI>
year units</LI>
<LI>
BST/UTC status</LI>
<DL compact>
<DT>
bit 7</DT>
<DD>
parity</DD>
<DT>
bit 6</DT>
<DD>
always 0</DD>
<DT>
bit 5</DT>
<DD>
always 1</DD>
<DT>
bit 4</DT>
<DD>
always 1</DD>
<DT>
bit 3</DT>
<DD>
always 0</DD>
<DT>
bit 2</DT>
<DD>
= 1 if UTC is in effect (reverse of bit 1)</DD>
<DT>
bit 1</DT>
<DD>
= 1 if BST is in effect (reverse of bit 2)</DD>
<DT>
bit 0</DT>
<DD>
= 1 if BST/UTC change pending</DD>
</DL>
<LI>
clock status</LI>
<DL compact>&nbsp;
<DT>
bit 7</DT>
<DD>
parity</DD>
<DT>
bit 6</DT>
<DD>
always 0</DD>
<DT>
bit 5</DT>
<DD>
always 1</DD>
<DT>
bit 4</DT>
<DD>
always 1</DD>
<DT>
bit 3</DT>
<DD>
= 1 if low battery is detected</DD>
<DT>
bit 2</DT>
<DD>
= 1 if last resync failed (though officially undefined for the MSF clock)</DD>
<DT>
bit 1</DT>
<DD>
= 1 if at least one reception attempt since 0230 for the MSF clock was
successful (0300 for the DCF77 clock)</DD>
<DT>
bit 0</DT>
<DD>
= 1 if the clock has valid time---reset to zero when clock is reset (eg
at power-up), and set to 1 after first successful resync attempt.</DD>
</DL>
</OL>
The driver only accepts time from the clock if the bottom three bits of
the status byte are <TT>011</TT>. The leap-year logic for computing day-in-year
is only valid until 2099, and the clock will ignore stamps from the clock
that claim BST is in effect in the first hour of each year. If the UK parliament
decides to move us to +0100/+0200 time as opposed to the current +0000/+0100
time, it is not clear what effect that will have on the time broadcast
by MSF, and therefore on this driver's usefulness.</DL>
A typical <TT>ntp.conf</TT> configuration file for this driver might be:
<PRE># hostname(n) means we expect (n) to be the stratum at which hostname runs.
#------------------------------------------------------------------------------
# SYNCHRONISATION PARTNERS
# ========================
# Our betters...
server 127.127.27.0 # ARCRON MSF radio clock(1).
# Fudge stratum and other features as required.
# ADJUST time1 VALUE FOR YOUR HOST, CLOCK AND LOCATION!
fudge 127.127.27.0 stratum 1 time1 0.016 flag3 1 flag4 1
peer 11.22.33.9 # tick(1--2).
peer 11.22.33.4 # tock(3), boot/NFS server.
# This shouldn't get swept away unless left untouched for a long time.
driftfile /var/tmp/ntp.drift
#------------------------------------------------------------------------------
# RESTRICTIONS
# ============
# By default, don't trust and don't allow modifications.&nbsp; Ignore in fact.
restrict default ignore notrust nomodify
# Allow others in our subnet to check us out...
restrict 11.22.33.0 mask 255.255.255.0 nomodify notrust
# Trust our peers for time.&nbsp; Don't trust others in case they are insane.
restrict 127.127.27.0 nomodify
restrict 11.22.33.4 nomodify
restrict 11.22.33.9 nomodify
# Allow anything from the local host.
restrict 127.0.0.1</PRE>
There are a few <TT>#define</TT>s in the code that you might wish to play
with:
<DL>
<DT>
<TT>ARCRON_KEEN</TT></DT>
<DD>
With this defined, the code is relatively trusting of the clock, and assumes
that you will have the clock as one of a few time sources, so will bend
over backwards to use the time from the clock when available and avoid
<TT>ntpd</TT> dropping sync from the clock where possible. You may wish
to undefine this, especially if you have better sources of time or your
reception is ropey. However, there are many checks built in even with this
flag defined.</DD>
<DT>
<TT>ARCRON_OWN_FILTER</TT></DT>
<DD>
When defined, the code uses its own median-filter code rather than that
available in <TT>ntp_refclock.c</TT> since the latter seems to have a minor
bug, at least in version 3-5.90. If this bug goes away this flag should
be turned off to avoid duplication of code. (The bug, if that's what it
is, causes the last raw offset to be used rather than the median offset.)</DD>
<P>Without this defined (and without <TT>ARCRON_MULTIPLE_SAMPLES</TT> below)
a typical set of offsets reported and used to drive the clock-filter algorithm
is (oldest last):
<PRE>filtoffset=&nbsp; -4.32&nbsp; -34.82&nbsp;&nbsp; -0.78&nbsp;&nbsp;&nbsp; 0.89&nbsp;&nbsp;&nbsp; 2.76&nbsp;&nbsp;&nbsp; 4.58&nbsp;&nbsp; -3.92&nbsp;&nbsp; -2.17</PRE>
Look at that spike!
<P>With this defined a typical set of offsets is:
<PRE>filtoffset=&nbsp; -7.06&nbsp;&nbsp; -7.06&nbsp;&nbsp; -2.91&nbsp;&nbsp; -2.91&nbsp;&nbsp; -2.91&nbsp;&nbsp; -1.27&nbsp;&nbsp; -9.54&nbsp;&nbsp; -6.70</PRE>
with the repeated values being some evidence of outlyers being discarded.
<DT>
<TT>ARCRON_MULTIPLE_SAMPLES</TT></DT>
<DD>
When is defined, we regard each character in the returned timecode as at
a known delay from the start of the second, and use the smallest (most
negative) offset implied by any such character, ie with the smallest kernel-induced
display, and use that. This helps to reduce jitter and spikes.</DD>
<DT>
<TT>ARCRON_LEAPSECOND_KEEN</TT></DT>
<DD>
When is defined, we try to do a resync to MSF as soon as possible in the
first hour of the morning of the first day of the first and seventh months,
ie just after a leap-second insertion or deletion would happen if it is
going to. This should help compensate for the fact that this clock does
not continuously sample MSF, which compounds the fact that MSF itself gives
no warning of an impending leap-second event. This code did not seem functional
at the leap-second insertion of 30th June 1997 so is by default disabled.</DD>
<DT>
<TT>PRECISION</TT></DT>
<DD>
Currently set to <TT>-4</TT>, but you may wish to set it to <TT>-5</TT>
if you are more conservative, or to <TT>-6</TT> if you have particularly
good experience with the clock and you live on the edge. Note that the
<TT>flag3</TT> fudge value will improve the reported dispersion one notch
if clock signal quality is known good. So maybe just leave this alone.
B^)</DD>
<DT>
<TT>NSAMPLES</TT></DT>
<DD>
Should be at least 3 to help smooth out sampling jitters. Can be more,
but if made too long can make <TT>ntpd</TT> overshoot on clock corrections
and can hold onto bad samples longer than you would like. With this set
to 4 and <TT>NKEEP</TT> set to 3 this allows the occasional bad sample
(in my experience less than 1 value in 10) to be dropped. (Note that there
seems to be some sort of `beat' effect in the offset with a periodicity
of about 7 samples as of this writing (1997/05/11) still under investigation;
a filter of approximately this length should be able to almost completely
suppress this effect.) Note that if the fudge-factor <TT>flag3</TT> is
set to 1, a larger <TT>NSAMPLES</TT> is used.</DD>
</DL>
<H4>
Monitor Data</H4>
Each timecode is written to the <TT>clockstats</TT> file with a signal
quality value appended (`0'--`5' as reported by the clock, or `6' for unknown).
<P>Each resync and result (plus gaining or losing MSF sync) is logged to
the system log at level <TT>LOG_NOTICE</TT>; note that each resync drains
the unit's batteries, so the syslog entry seems justified.
<P>Syslog entries are of the form:
<PRE>May 10 10:15:24 oolong ntpd[615]: ARCRON: unit 0: sending resync command
May 10 10:17:32 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock
May 10 11:13:01 oolong ntpd[615]: ARCRON: unit 0: sending resync command
May 10 11:14:06 oolong ntpd[615]: ARCRON: sync finished, signal quality -1: UNKNOWN, will use clock anyway
May 10 11:41:49 oolong ntpd[615]: ARCRON: unit 0: sending resync command
May 10 11:43:57 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock
May 10 12:39:26 oolong ntpd[615]: ARCRON: unit 0: sending resync command
May 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, will use clock</PRE>
<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. On a Sun SparcStation 1 running SunOS 4.1.3_U1, with
the receiver in London, a value of 0.020 (20ms) seems to be appropriate.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not currently 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.
It is suggested that the clock be fudged to stratum 1 so this it is used
a backup time source rather than a primary when more accurate sources are
available.</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>MSFa</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
If set to 1, better precision is reported (and thus lower dispersion) while
clock's received signal quality is known to be good.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
If set to 1, a longer-than-normal (8-stage rather than 4-stage) median
filter is used, to provide some extra smoothing of clock output and reduction
in jitter, at the cost of extra clock overshoot. Probably not advisable
unless the server using this clock has other sources it can use to help
mitigate the overshoot.</DD>
</DL>
<H4>
Additional Information</H4>
<A HREF="refclock.htm">Reference Clock Drivers</A>
<P><A HREF="http://www2.exnet.com/NTP/ARC/ARC.htm">ARC Rugby MSF Receiver</A>
page&nbsp;
<HR>
<ADDRESS>
Damon Hart-Davis (d@hd.org)</ADDRESS>
</BODY>
</HTML>

133
html/driver28.htm
View File

@ -1,133 +0,0 @@
<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>Shared memoy Driver
</TITLE>
</HEAD>
<BODY>
<H3>
Shared Memory Driver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.28.<I>u</I>
<BR>Reference ID: <TT>SHM</TT>
<BR>Driver ID: <TT>SHM</TT>
<H4>
Description</H4>
This driver receives its reference clock info from a shared memory-segment.
The shared memory-segment is created with owner-only access for unit 0
and 1, and world access for unit 2 and 3
<H4>
Structure of shared memory-segment</H4>
<PRE>struct shmTime {
&nbsp; int&nbsp;&nbsp;&nbsp; mode; /* 0 - if valid set
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use values,&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clear valid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * 1 - if valid set&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if count before and after read of&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; values is equal,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use values&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clear valid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; */
&nbsp; int&nbsp;&nbsp;&nbsp; count;
&nbsp; time_t clockTimeStampSec;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* external clock */
&nbsp; int&nbsp;&nbsp;&nbsp; clockTimeStampUSec;&nbsp;&nbsp;&nbsp;&nbsp; /* external clock */
&nbsp; time_t receiveTimeStampSec;&nbsp;&nbsp;&nbsp; /* internal clock, when external value was received */
&nbsp; int&nbsp;&nbsp;&nbsp; receiveTimeStampUSec;&nbsp;&nbsp; /* internal clock, when external value was received */
&nbsp; int&nbsp;&nbsp;&nbsp; leap;
&nbsp; int&nbsp;&nbsp;&nbsp; precision;
&nbsp; int&nbsp;&nbsp;&nbsp; nsamples;
&nbsp; int&nbsp;&nbsp;&nbsp; valid;
&nbsp; int&nbsp;&nbsp;&nbsp; dummy[10];&nbsp;
};</PRE>
<H4>
Operation mode=0</H4>
When the poll-method of the driver is called, the valid-flag of the shared
memory-segment is checked:
<P>If set, the values in the record (clockTimeStampSec, clockTimeStampUSec,
receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are passed
to ntp, and the valid-flag is cleared.
<P>If not set, a timeout is reported to ntp, nothing else happend
<H4>
Operation mode=1</H4>
When the poll-method of the driver is called, the valid-flag of the shared
memory-segment is checked:
<P>If set, the count-field of the record is remembered, and the values
in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec,
receiveTimeStampUSec, leap, precision) are read. Then, the remembered count
is compared to the count now in the record. If both are equal, the values
read from the record are passed to ntp. If they differ, another process
has modified the record while it was read out (was not able to produce
this case), and failure is reported to ntp. The valid flag is cleared.
<P>If not set, a timeout is reported to ntp, nothing else happend
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>SHM</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<P>Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A></DL>
</BODY>
</HTML>

1254
html/driver29.htm
View File

File diff suppressed because it is too large Load Diff

131
html/driver3.htm
View File

@ -1,131 +0,0 @@
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
<TITLE>PSTI/Traconex 1020 WWV/WWVH Receiver
</TITLE>
</HEAD>
<BODY>
<H3>
PSTI/Traconex 1020 WWV/WWVH Receiver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.3.<I>u</I>
<BR>Reference ID: <TT>WWV</TT>
<BR>Driver ID: <TT>WWV_PST</TT>
<BR>Serial Port: <TT>/dev/wwv<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver supports the PSTI 1010 and Traconex 1020 WWV/WWVH Receivers.
No specific claim of accuracy is made for these receiver, but actual experience
suggests that 10 ms would be a conservative assumption.
<P>The DIP-switches should be set for 9600 bps line speed, 24-hour day-of-year
format and UTC time zone. Automatic correction for DST should be disabled.
It is very important that the year be set correctly in the DIP-switches;
otherwise, the day of year will be incorrect after 28 April of a normal
or leap year. The propagation delay DIP-switches should be set according
to the distance from the transmitter for both WWV and WWVH, as described
in the instructions. While the delay can be set only to within 11 ms, the
fudge time1 parameter can be used for vernier corrections.
<P>Using the poll sequence <TT>QTQDQM</TT>, the response timecode is in
three sections totalling 50 ASCII printing characters, as concatenated
by the driver, in the following format:
<PRE>ahh:mm:ss.fffs&lt;cr> yy/dd/mm/ddd&lt;cr>
frdzycchhSSFTttttuuxx&lt;cr>
on-time = first &lt;cr>
hh:mm:ss.fff = hours, minutes, seconds, milliseconds
a = AM/PM indicator (' ' for 24-hour mode)
yy = year (from DIPswitches)
dd/mm/ddd = day of month, month, day of year
s = daylight-saving indicator (' ' for 24-hour mode)
f = frequency enable (O = all frequencies enabled)
r = baud rate (3 = 1200, 6 = 9600)
d = features indicator (@ = month/day display enabled)
z = time zone (0 = UTC)
y = year (5 = 91)
cc = WWV propagation delay (52 = 22 ms)
hh = WWVH propagation delay (81 = 33 ms)
SS = status (80 or 82 = operating correctly)
F = current receive frequency (4 = 15 MHz)
T = transmitter (C = WWV, H = WWVH)
tttt = time since last update (0000 = minutes)
uu = flush character (03 = ^c)
xx = 94 (unknown)</PRE>
The alarm condition is indicated by other than <TT>8</TT> at <TT>a</TT>,
which occurs during initial synchronization and when received signal is
lost for an extended period; unlock condition is indicated by other than
<TT>0000</TT> in the <TT>tttt</TT> subfield.
<H4>
Monitor Data</H4>
When enabled by the <TT>flag4</TT> fudge flag, every received timecode
is written as-is to the <TT>clockstats</TT> file.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>WWV</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

190
html/driver30.htm
View File

@ -1,190 +0,0 @@
<!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.06 [en] (X11; I; FreeBSD
3.0-CURRENT i386) [Netscape]">
<TITLE>Motorola Oncore GPS Receiver
</TITLE>
</HEAD>
<BODY>
<H3>
Motorola Oncore GPS receiver</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.30.<i>u</i><BR>
Reference ID: <TT>GPS</TT><BR>
Driver ID: ONCORE<BR>
Serial Port: <TT>/dev/oncore.serial.</TT><i>u</i>; &nbsp;9600 baud, 8-bits,
no parity.<BR>
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 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,
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>.
<BR>&nbsp;
<CENTER><TABLE NOSAVE >
<TR NOSAVE>
<TD NOSAVE><IMG SRC="pic/oncore_utplusbig.gif" HEIGHT=124
WIDTH=210></TD>
<TD><IMG SRC="pic/oncore_evalbig.gif" HEIGHT=124 WIDTH=182></TD>
<TD><IMG SRC="pic/oncore_remoteant.jpg" HEIGHT=188 WIDTH=178></TD>
</TR>
<TR>
<TD>
<CENTER>UT+ oncore</CENTER>
</TD>
<TD>
<CENTER>Evaluation kit</CENTER>
</TD>
<TD>
<CENTER>Oncore Remote</CENTER>
</TD>
</TR>
</TABLE></CENTER>
<P>The driver requires a standard <TT>PPS</TT> interface for the
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 to determine the antenna position.
<H4>
Monitor Data</H4>
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>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default
0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>GPS</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
</DL>
<B>Additional Information</B>
<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.
The offset shifts the PPS signal to avoid interrupt pileups `on' the second,
and adjust the timestamp accordingly.
See the driver source for information on this file.
The default with no file is: no delay, no offset, and a site survey is done
to get the location of the gps receiver.
<P>The <TT>/etc/ntp.conf</TT> file will need a line of the form<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<TT> pps /dev/oncore.pps.0 [ assert/clear ] hardpps</TT><BR>
if you want the oncore driver to control the kernel PLL.
For more information, see the <A HREF=clockopt.htm>Reference Clock
Options</A> page.
<P><B>Performance</B>
<P>Really good.&nbsp; With the VP/UT+, the generated PPS pulse is referenced
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, 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>.
<HR>
<ADDRESS>
Poul-Henning Kamp (phk@FreeBSD.org),
Reg Clemens (reg@dwf.com)
</ADDRESS>
</BODY>
</HTML>

42
html/driver32.htm
View File

@ -1,42 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<meta http-equiv="Content-Type" content="text/html; charset=iso8859-1">
<title>Chrono-log K-series WWVB receiver</title>
</head>
<body>
<h3>Chrono-log K-series WWVB receiver</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.32.<i>u</i><br>
Reference ID: <TT>CHRONOLOG</TT><br>
Driver ID: <tt>CHRONOLOG</tt><br>
Serial Port: <tt>/dev/chronolog<i>u</i></tt>; 2400 bps, 8-bits,
no parity<br>
<br>Features: <tt>(none)</tt>
<h4>Description</h4>
This driver supports the Chrono-log K-series WWVB receiver. This is a
very old receiver without provisions for leap seconds, quality codes,
etc. It assumes output in the local time zone, and that the C library
mktime()/localtime() routines will correctly convert back and forth
between local and UTC. There is a hack in the driver for permitting
UTC, but it has not been tested.
<P>Most of this code is originally from refclock_wwvb.c with thanks. It
has been so mangled that wwvb is not a recognizable ancestor.
<pre>
Timecode format: Y yy/mm/ddCLZhh:mm:ssCL
Y - year/month/date line indicator
yy/mm/dd -- two-digit year/month/day
C - \r (carriage return)
L - \n (newline)
Z - timestamp indicator
hh:mm:ss - local time
</pre>
<hr>
<address></address>
<!-- hhmts start -->
Last modified: Sun Feb 14 11:57:27 EST 1999
<!-- hhmts end -->
</body> </html>

38
html/driver33.htm
View File

@ -1,38 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<meta http-equiv="Content-Type" content="text/html; charset=iso8859-1">
<title>Dumb Clock</title>
</head>
<body>
<h3>Dumb Clock</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.33.<i>u</i><br>
Reference ID: <TT>DUMBCLOCK</TT><br>
Driver ID: <tt>DUMBCLOCK</tt><br>
Serial Port: <tt>/dev/dumbclock<i>u</i></tt>; 9600 bps, 8-bits,
no parity<br>
<br>Features: <tt>(none)</tt>
<h4>Description</h4>
This driver supports a dumb ASCII clock that only emits localtime at a reliable
interval. This has no provisions for leap seconds, quality codes,
etc. It assumes output in the local time zone, and that the C library
mktime()/localtime() routines will correctly convert back and forth
between local and UTC.
<P>Most of this code is originally from refclock_wwvb.c with thanks. It
has been so mangled that wwvb is not a recognizable ancestor.
<pre>
Timecode format: hh:mm:ssCL
hh:mm:ss - local time
C - \r (carriage return)
L - \n (newline)
</pre>
<hr>
<address></address>
<!-- hhmts start -->
Last modified: Sun Feb 14 12:07:01 EST 1999
<!-- hhmts end -->
</body> </html>

96
html/driver34.htm
View File

@ -1,96 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<meta http-equiv="Content-Type" content="text/html; charset=iso8859-1">
<title>Ultralink Clock</title>
</head>
<body>
<h3>Ultralink Clock</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.34.<i>u</i><br>
Reference ID: <TT>WWVB</TT><br>
Driver ID: <tt>ULINK</tt><br>
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.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 Model 320 timecode format is:
<cr><lf>SQRYYYYDDD+HH:MM:SS.mmLT<cr>
where:
S = 'S' -- sync'd in last hour, '0'-'9' - hours x 10 since last update, else '?'
Q = Number of correlating time-frames, from 0 to 5
R = 'R' -- reception in progress, 'N' -- Noisy reception, ' ' -- standby mode
YYYY = year from 1990 to 2089
DDD = current day from 1 to 366
+ = '+' if current year is a leap year, else ' '
HH = UTC hour 0 to 23
MM = Minutes of current hour from 0 to 59
SS = Seconds of current minute from 0 to 59
mm = 10's milliseconds of the current second from 00 to 99
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 T flag.
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>
<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 -->
</body> </html>

80
html/driver35.htm
View File

@ -1,80 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Conrad parallel port radio clock</title>
</head>
<body>
<h3>Conrad parallel port radio clock</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.35.<i>u</i><br>
Reference ID: <tt>PCF</tt><br>
Driver ID: <tt>PCF</tt><br>
Parallel Port: <tt>/dev/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 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 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>
<h4>Monitor Data</h4>
<p>Each timecode is written to the <tt>clockstats</tt> file in the format
<tt>YYYY MM DD HH MI SS</tt>.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the time offset calibration factor, in seconds and fraction,
with default 0.1725.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <tt>PCF</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>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>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
</dl>
<hr>
<address>Andreas Voegele &lt;voegelas@users.sourceforge.net&gt;</address>
</body>
</html>

930
html/driver36.htm
View File

@ -1,930 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Radio WWV/H Audio Demodulator/Decoder</title>
</head>
<body>
<h3>Radio WWV/H Audio Demodulator/Decoder</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.36.<i>u</i> <br>
Reference ID: <tt>WWV</tt> or <tt>WWVH</tt> <br>
Driver ID: <tt>WWV_AUDIO</tt> <br>
Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no
parity <br>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
This driver synchronizes the computer time using data encoded in
shortwave radio transmissions from NIST time/frequency stations WWV
in Ft. Collins, CO, and WWVH in Kauai, HI. Transmissions are made
continuously on 2.5, 5, 10, 15 and 20 MHz. An ordinary shortwave
receiver can be tuned manually to one of these frequencies or, in
the case of ICOM receivers, the receiver can be tuned automatically
by the driver as propagation conditions change throughout the day
and night. The performance of this driver when tracking one of the
stations is ordinarily better than 1 ms in time with frequency
drift less than 0.5 PPM when not tracking either station.
<p>The demodulation and decoding algorithms used by this driver are
based on a machine language program developed for the TAPR DSP93
DSP unit, which uses the TI 320C25 DSP chip. The analysis, design
and performance of the program running on this unit is described
in: Mills, D.L. A precision radio clock for WWV transmissions.
Electrical Engineering Report 97-8-1, University of Delaware,
August 1997, 25 pp. Available from <a href=
"http://www.eecis.udel.edu/~mills/reports.htm">
www.eecis.udel.edu/~mills/reports.htm</a>. For use in this driver,
the original program was rebuilt in the C language and adapted to
the NTP driver interface. The algorithms have been modified
somewhat to improve performance under weak signal conditions and to
provide an automatic station identification feature.</p>
<p>This driver incorporates several features in common with other
audio drivers such as described in the <a href="driver7.htm">Radio
CHU Audio Demodulator/Decoder</a> and the <a href="driver6.htm">
IRIG Audio Decoder</a> pages. They include automatic gain control
(AGC), selectable audio codec port and signal monitoring
capabilities. For a discussion of these common features, as well as
a guide to hookup, debugging and monitoring, see the <a href=
"audio.htm">Reference Clock Audio Drivers</a> page.</p>
<p>The WWV signal format is described in NIST Special Publication
432 (Revised 1990). It consists of three elements, a 5-ms, 1000-Hz
pulse, which occurs at the beginning of each second, a 800-ms,
1000-Hz pulse, which occurs at the beginning of each minute, and a
pulse-width modulated 100-Hz subcarrier for the data bits, one bit
per second. The WWVH format is identical, except that the 1000-Hz
pulses are sent at 1200 Hz. Each minute encodes nine BCD digits for
the time of century plus seven bits for the daylight savings time
(DST) indicator, leap warning indicator and DUT1 correction.</p>
<h4>Program Architecture</h4>
<p>As in the original program, the clock discipline is modelled as
a Markov process, with probabilistic state transitions
corresponding to a conventional clock and the probabilities of
received decimal digits. The result is a performance level which
results in very high accuracy and reliability, even under
conditions when the minute beep of the signal, normally its most
prominent feature, can barely be detected by ear with a shortwave
receiver.</p>
<p>The analog audio signal from the shortwave radio is sampled at
8000 Hz and converted to digital representation. The 1000/1200-Hz
pulses and 100-Hz subcarrier are first separated using two IIR
filters, a 600-Hz bandpass filter centered on 1100 Hz and a 150-Hz
lowpass filter. The minute sync pulse is extracted using a 800-ms
synchronous matched filter and pulse grooming logic which
discriminates between WWV and WWVH signals and noise. The second
sync pulse is extracted using a 5-ms FIR matched filter and
8000-stage comb filter.</p>
<p>The phase of the 100-Hz subcarrier relative to the second sync
pulse is fixed at the transmitter; however, the audio highpass
filter in most radios affects the phase response at 100 Hz in
unpredictable ways. The driver adjusts for each radio using two
170-ms synchronous matched filters. The I (in-phase) filter is used
to demodulate the subcarrier envelope, while the Q
(quadrature-phase) filter is used in a tracking loop to discipline
the codec sample clock and thus the demodulator phase.</p>
<p>The data bit probabilities are determined from the subcarrier
envelope using a threshold-corrected slicer. The averaged envelope
amplitude 30 ms from the beginning of the second establishes the
minimum (noise floor) value, while the amplitude 200 ms from the
beginning establishes the maximum (signal peak) value. The slice
level is midway between these two values. The negative-going
envelope transition at the slice level establishes the length of
the data pulse, which in turn establish probabilities for binary
zero (P0) or binary one (P1). The values are established by linear
interpolation between the pulse lengths for P0 (300 ms) and P1 (500
ms) so that the sum is equal to one. If the driver has not
synchronized to the minute pulse, or if the data bit amplitude,
signal/noise ratio (SNR) or length are below thresholds, the bit is
considered invalid and all three probabilities are set to zero.</p>
<p>The difference between the P1 and P0 probabilities, or
likelihood, for each data bit is exponentially averaged in a set of
60 accumulators, one for each second, to determine the semi-static
miscellaneous bits, such as DST indicator, leap second warning and
DUT1 correction. In this design, an average value larger than a
positive threshold is interpreted as a hit on one and a value
smaller than a negative threshold as a hit on zero. Values between
the two thresholds, which can occur due to signal fades or loss of
signal, are interpreted as a miss, and result in no change of
indication.</p>
<p>The BCD digit in each digit position of the timecode is
represented as four data bits, all of which must be valid for the
digit itself to be considered valid. If so, the bits are correlated
with the bits corresponding to each of the valid decimal digits in
this position. If the digit is invalid, the correlated value for
all digits in this position is assumed zero. In either case, the
values for all digits are exponentially averaged in a likelihood
vector associated with this position. The digit associated with the
maximum over all of the averaged values then becomes the maximum
likelihood selection for this position and the ratio of the maximum
over the next lower value becomes the likelihood ratio.</p>
<p>The decoding matrix contains nine row vectors, one for each
digit position. Each row vector includes the maximum likelihood
digit, likelihood vector and other related data. The maximum
likelihood digit for each of the nine digit positions becomes the
maximum likelihood time of the century. A built-in transition
function implements a conventional clock with decimal digits that
count the minutes, hours, days and years, as corrected for leap
seconds and leap years. The counting operation also rotates the
likelihood vector corresponding to each digit as it advances. Thus,
once the clock is set, each clock digit should correspond to the
maximum likelihood digit as transmitted.</p>
<p>Each row of the decoding matrix also includes a compare counter
and the difference (modulo the radix) between the current clock
digit and most recently determined maximum likelihood digit. If a
digit likelihood exceeds the decision level and the difference is
constant for a number of successive minutes in any row, the maximum
likelihood digit replaces the clock digit in that row. When this
condition is true for all rows and the second epoch has been
reliably determined, the clock is set (or verified if it has
already been set) and delivers correct time to the integral second.
The fraction within the second is derived from the logical master
clock, which runs at 8000 Hz and drives all system timing
functions.</p>
<p>The logical master clock is derived from the audio codec clock.
Its frequency is disciplined by a frequency-lock loop (FLL) which
operates independently of the data recovery functions. At averaging
intervals determined by the measured jitter, the frequency error is
calculated as the difference between the most recent and the
current second epoch divided by the interval. The sample clock
frequency is then corrected by this amount using an exponential
average. When first started, the frequency averaging interval is
eight seconds, in order to compensate for intrinsic codec clock
frequency offsets up to 125 PPM. Under most conditions, the
averaging interval doubles in stages from the initial value to over
1000 seconds, which results in an ultimate frequency precision of
0.125 PPM, or about 11 ms/day.</p>
<p>It is important that the logical clock frequency is stable and
accurately determined, since in most applications the shortwave
radio will be tuned to a fixed frequency where WWV or WWVH signals
are not available throughout the day. In addition, in some parts of
the US, especially on the west coast, signals from either or both
WWV and WWVH may be available at different times or even at the
same time. Since the propagation times from either station are
almost always different, each station must be reliably identified
before attempting to set the clock.</p>
<p>Station identification uses the 800-ms minute pulse transmitted
by each station. In the acquisition phase the entire minute is
searched using both the WWV and WWVH using matched filters and a
pulse gate discriminator similar to that found in radar acquisition
and tracking receivers. The peak amplitude found determines a range
gate and window where the next pulse is expected to be found. The
minute is scanned again to verify the peak is indeed in the window
and with acceptable amplitude, SNR and jitter. At this point the
receiver begins to track the second sync pulse and operate as above
until the clock is set.</p>
<p>Once the minute is synchronized, the range gate is fixed and
only energy within the window is considered for the minute sync
pulse. A compare counter increments by one if the minute pulse has
acceptable amplitude, SNR and jitter and decrements otherwise. This
is used as a quality indicator and reported in the timecode and
also for the autotune function described below.</p>
<h4>Performance</h4>
<p>It is the intent of the design that the accuracy and stability
of the indicated time be limited only by the characteristics of the
propagation medium. Conventional wisdom is that synchronization via
the HF medium is good only to a millisecond under the best
propagation conditions. The performance of the NTP daemon
disciplined by the driver is clearly better than this, even under
marginal conditions. Ordinarily, with marginal to good signals and
a frequency averaging interval of 1024 s, the frequency is
stabilized within 0.1 PPM and the time within 125 <font face=
"Symbol">m</font>s. The frequency stability characteristic is
highly important, since the clock may have to free-run for several
hours before reacquiring the WWV/H signal.</p>
<p>The expected accuracy over a typical day was determined using
the DSP93 and an oscilloscope and cesium oscillator calibrated with
a GPS receiver. With marginal signals and allowing 15 minutes for
initial synchronization and frequency compensation, the time
accuracy determined from the WWV/H second sync pulse was reliably
within 125 <font face="Symbol">m</font>s. In the particular DSP-93
used for program development, the uncorrected CPU clock frequency
offset was 45.8&plusmn;0.1 PPM. Over the first hour after initial
synchronization, the clock frequency drifted about 1 PPM as the
frequency averaging interval increased to the maximum 1024 s. Once
reaching the maximum, the frequency wandered over the day up to 1
PPM, but it is not clear whether this is due to the stability of
the DSP-93 clock oscillator or the changing height of the
ionosphere. Once the frequency had stabilized and after loss of the
WWV/H signal, the frequency drift was less than 0.5 PPM, which is
equivalent to 1.8 ms/h or 43 ms/d. This resulted in a step phase
correction up to several milliseconds when the signal returned.</p>
<p>The measured propagation delay from the WWV transmitter at
Boulder, CO, to the receiver at Newark, DE, is 23.5&plusmn;0.1 ms.
This is measured to the peak of the pulse after the second sync
comb filter and includes components due to the ionospheric
propagation delay, nominally 8.9 ms, communications receiver delay
and program delay. The propagation delay can be expected to change
about 0.2 ms over the day, as the result of changing ionosphere
height. The DSP93 program delay was measured at 5.5 ms, most of
which is due to the 400-Hz bandpass filter and 5-ms matched filter.
Similar delays can be expected of this driver.</p>
<h4>Program Operation</h4>
The driver begins operation immediately upon startup. It first
searches for one or both of the stations WWV and WWVH and attempts
to acquire minute sync. This may take some fits and starts, as the
driver expects to see three consecutive minutes with good signals
and low jitter. If the autotune function is active, the driver will
rotate over all five frequencies and both WWV and WWVH stations
until three good minutes are found.
<p>The driver then acquires second sync, which can take up to
several minutes, depending on signal quality. At the same time the
driver accumulates likelihood values for each of the nine digits of
the clock, plus the seven miscellaneous bits included in the WWV/H
transmission format. The minute units digit is decoded first and,
when five repetitions have compared correctly, the remaining eight
digits are decoded. When five repetitions of all nine digits have
decoded correctly, which normally takes 15 minutes with good
signals and up to an hour when buried in noise, and the second sync
alarm has not been raised for two minutes, the clock is set (or
verified) and is selectable to discipline the system clock.</p>
<p>As long as the clock is set or verified, the system clock
offsets are provided once each second to the reference clock
interface, where they are saved in a buffer. At the end of each
minute, the buffer samples are groomed by the median filter and
trimmed-mean averaging functions. Using these functions, the system
clock can in principle be disciplined to a much finer resolution
than the 125-<font face="Symbol">m</font>s sample interval would
suggest, although the ultimate accuracy is probably limited by
propagation delay variations as the ionspheric height varies
throughout the day and night.</p>
<p>As long as signals are available, the clock frequency is
disciplined for use during times when the signals are unavailable.
The algorithm refines the frequency offset using increasingly
longer averaging intervals to 1024 s, where the precision is about
0.1 PPM. With good signals, it takes well over two hours to reach
this degree of precision; however, it can take many more hours than
this in case of marginal signals. Once reaching the limit, the
algorithm will follow frequency variations due to temperature
fluctuations and ionospheric height variations.</p>
<p>It may happen as the hours progress around the clock that WWV
and WWVH signals may appear alone, together or not at all. When the
driver is first started, the NTP reference identifier appears as
<tt>NONE</tt>. When the driver has acquired one or both stations
and mitigated which one is best, it sets the station identifier in
the timecode as described below. In addition, the NTP reference
identifier is set to the station callsign. If the propagation
delays has been properly set with the <tt>fudge time1</tt> (WWV)
and <tt>fudge time2</tt> (WWVH) commands in the configuration file,
handover from one station to the other will be seamless.</p>
<p>Once the clock has been set for the first time, it will appear
reachable and selectable to discipline the system clock, even if
the broadcast signal fades to obscurity. A consequence of this
design is that, once the clock is set, the time and frequency are
disciplined only by the second sync pulse and the clock digits
themselves are driven by the clock state machine and ordinarily
never changed. However, as long as the clock is set correctly, it
will continue to read correctly after a period of signal loss, as
long as it does not drift more than 500 ms from the correct time.
Assuming the clock frequency can be disciplined within 1 PPM, the
clock could coast without signals for some 5.8 days without
exceeding that limit. If for some reason this did happen, the clock
would be in the wrong second and would never resynchronize. To
protect against this most unlikely situation, if after four days
with no signals, the clock is considered unset and resumes the
synchronization procedure from the beginning.</p>
<p>To work well, the driver needs a communications receiver with
good audio response at 100 Hz. Most shortwave and communications
receivers roll off the audio response below 250 Hz, so this can be
a problem, especially with receivers using DSP technology, since
DSP filters can have very fast rolloff outside the passband. Some
DSP transceivers, in particular the ICOM 775, have a programmable
low frequency cutoff which can be set as low as 80 Hz. However,
this particular radio has a strong low frequency buzz at about 10
Hz which appears in the audio output and can affect data recovery
under marginal conditions. Although not tested, it would seem very
likely that a cheap shortwave receiver could function just as well
as an expensive communications receiver.</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 serial port using a level
converter such as the CT-17. The serial port speed is presently
compiled in the program, but can be changed in the driver source
file.</p>
<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>If specified, the driver will attempt to open the device <tt>
/dev/icom</tt> and, if successful will activate the autotune
function and tune the radio to each operating frequency in turn
while attempting to acquire minute sync from either WWV or WWVH.
However, the driver is liberal in what it assumes of the
configuration. If the <tt>/dev/icom</tt> link is not present or the
open fails or the CI-V bus or radio is inoperative, the driver
quietly gives up with no harm done.</p>
<p>Once acquiring minute sync, the driver operates as described
above to set the clock. However, during seconds 59, 0 and 1 of each
minute it tunes the radio to one of the five broadcast frequencies
to measure the sync pulse and data pulse amplitudes and SNR and
update the compare counter. Each of the five frequencies are probed
in a five-minute rotation to build a database of current
propagation conditions for all signals that can be heard at the
time. At the end of each rotation, a mitigation procedure scans the
database and retunes the radio to the best frequency and station
found. For this to work well, the radio should be set for a fast
AGC recovery time. This is most important while tracking a strong
signal, which is normally the case, and then probing another
frequency, which may have much weaker signals.</p>
<p>Reception conditions for each frequency and station are
evaluated according to a metric which considers the minute sync
pulse amplitude, SNR and jitter, as well as, the data pulse
amplitude and SNR. The minute pulse is evaluated at second 0, while
the data pulses are evaluated at seconds 59 and 1. The results are
summarized in a scoreboard of three bits</p>
<dl>
<dt><tt>0x0001</tt></dt>
<dd>Jitter exceeded. The difference in epoches between the last
minute sync pulse and the current one exceeds 50 ms (400
samples).</dd>
<dt><tt>0x0002</tt></dt>
<dd>Minute pulse error. For the minute sync pulse in second 0,
either the amplitude or SNR is below threshold (2000 and 20 dB,
respectively).</dd>
<dt><tt>0x0004</tt></dt>
<dd>Minute pulse error. For both of the data pulses in seocnds 59
and 1, either the amplitude or SNR is below threshold (1000 and 10
dB, respectively).</dd>
</dl>
<p>If none of the scoreboard bits are set, the compare counter is
increased by one to a maximum of six. If any bits are set, the
counter is decreased by one to a minimum of zero. At the end of
each minute, the frequency and station with the maximum compare
count is chosen, with ties going to the highest frequency.</p>
<h4>Diagnostics</h4>
<p>The autotune process produces diagnostic information along with
the timecode. This is very useful for evaluating the performance of
the algorithm, as well as radio propagation conditions in general.
The message is produced once each minute for each frequency in turn
after minute sync has been acquired.</p>
<p><tt>wwv5 port agc wwv wwvh</tt></p>
<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and
gain, respectively, for this frequency and <tt>wwv</tt> and <tt>
wwvh</tt> are two sets of fields, one each for WWV and WWVH. Each
of the two fields has the format</p>
<p><tt>ident score comp sync/snr/jitr</tt></p>
<p>where <tt>ident</tt>encodes the station (<tt>C</tt> for WWV,
<tt>H</tt> for WWVH) and frequency (2, 5, 10, 15 and 20), <tt>
score</tt> is the scoreboard described above, <tt>comp</tt> is the
compare counter, <tt>sync</tt> is the minute sync pulse amplitude,
<tt>snr</tt> the SNR of the pulse and <tt>jitr</tt> is the sample
difference between the current epoch and the last epoch. An example
is:</p>
<p><tt>wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0
22/-12.4/8846</tt></p>
<p>Here the radio is tuned to 20 MHz and the line-in port AGC is
currently 111 at that frequency. The message contains a report for
WWV (<tt>C20</tt>) and WWVH (<tt>H20</tt>). The WWV report
scoreboard is 0100 and the compare count is 6, which suggests very
good reception conditions, and the minute sync amplitude and SNR
are well above thresholds (2000 and 20 dB, respectively). Probably
the most sensitive indicator of reception quality is the jitter, -3
samples, which is well below threshold (50 ms or 400 samples).
While the message shows solid reception conditions from WWV, this
is not the case for WWVH. Both the minute sync amplitude and SNR
are below thresholds and the jitter is above threshold.</p>
<p>A sequence of five messages, one for each minute, might appear
as follows:</p>
<pre>
wwv5 2 95 C2 0107 0 164/7.2/8100 H2 0207 0 80/-5.5/7754
wwv5 2 99 C5 0104 0 3995/21.8/395 H5 0207 0 27/-9.3/18826
wwv5 2 239 C10 0105 0 9994/30.0/2663 H10 0207 0 54/-16.1/-529
wwv5 2 155 C15 0103 3 3300/17.8/-1962 H15 0203 0 236/17.0/4873
wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846
</pre>
<p>Clearly, the only frequencies that are available are 15 MHz and
20 MHz and propagation may be failing for 15 MHz. However, minute
sync pulses are being heard on 5 and 10 MHz, even though the data
pulses are not. This is typical of late afternoon when the maximum
usable frequency (MUF) is falling and the ionospheric loss at the
lower frequencies is beginning to decrease.</p>
<h4>Debugging Aids</h4>
<p>The most convenient way to track the driver status is using the
<tt>ntpq</tt> program and the <tt>clockvar</tt> command. This
displays the last determined timecode and related status and error
counters, even when the driver is not discipline the system clock.
If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt>
command line)is enabled, the driver produces detailed status
messages as it operates. If the <tt>fudge flag 4</tt> is set, these
messages are written to the <tt>clockstats</tt> file. All messages
produced by this driver have the prefix <tt>chu</tt> for convenient
filtering with the Unix <tt>grep</tt> command.</p>
<p>In the following descriptions the units of amplitude, phase,
probability and likelihood are normalized to the range 0-6000 for
convenience. In addition, the signal/noise ratio (SNR) and
likelihood ratio are measured in decibels and the words with bit
fields are in hex. Most messages begin with a leader in the
following format:</p>
<p><tt>wwvn ss stat sigl</tt></p>
<p>where <tt>wwvn</tt> is the message code, <tt>ss</tt> the second
of minute, <tt>stat</tt> the driver status word and <tt>sigl</tt>
the second sync pulse amplitude. A full explanation of the status
bits is contained in the driver source listing; however, the
following are the most useful for debugging.</p>
<dl>
<dt><tt>0x0001</tt></dt>
<dd>Minute sync. Set when the decoder has identified a station and
acquired the minute sync pulse.</dd>
<dt><tt>0x0002</tt></dt>
<dd>Second sync. Set when the decoder has acquired the second sync
pulse and within 125 <font face="Symbol">m</font>s of the correct
phase.</dd>
<dt><tt>0x0004</tt></dt>
<dd>Minute unit sync. Set when the decoder has reliably determined
the unit digit of the minute.</dd>
<dt><tt>0x0008</tt></dt>
<dd>Clock set. Set when the decoder has reliably determined all
nine digits of the timecode and is selectable to discipline the
system clock.</dd>
</dl>
<p>With debugging enabled the driver produces messages in the
following formats:</p>
<p>Format <tt>wwv8</tt> messages are produced once per minute by
the WWV and WWVH station processes before minute sync has been
acquired. They show the progress of identifying and tracking the
minute pulse of each station.</p>
<p><tt>wwv8 port agc ident comp ampl snr epoch jitr offs</tt></p>
<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and
gain, respectively. The <tt>ident</tt>encodes the station
(<tt>C</tt> for WWV, <tt>H</tt> for WWVH) and frequency (2, 5, 10,
15 and 20). For the encoded frequency, <tt>comp</tt> is the compare
counter, <tt>ampl</tt> the pulse amplitude, <tt>snr</tt> the SNR,
<tt>epoch</tt> the sample number of the minute pulse in the minute,
<tt>jitr</tt> the change since the last <tt>epoch</tt> and <tt>
offs</tt> the minute pulse offset relative to the second pulse. An
example is:</p>
<p><tt>wwv8 2 127 C15 2 9247 30.0 18843 -1 1</tt><br>
<tt>wwv8 2 127 H15 0 134 -2.9 19016 193 174</tt></p>
<p>Here the radio is tuned to 15 MHz and the line-in port AGC is
currently 127 at that frequency. The driver has not yet acquired
minute sync, WWV has been heard for at least two minutes, and WWVH
is in the noise. The WWV minute pulse amplitude and SNR are well
above the threshold (2000 and 6 dB, respectively) and the minute
epoch has been determined -1 sample relative to the last one and 1
sample relative to the second sync pulse. The compare counter has
incrmented to two; when it gets to three, minute sync has been
acquired.</p>
<p>Format <tt>wwv3</tt> messages are produced after minute sync has
been acquired and until the seconds unit digit is determined. They
show the results of decoding each bit of the transmitted
timecode.</p>
<p><tt>wwv3 ss stat sigl ampl phas snr prob like</tt></p>
<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above,
<tt>ampl</tt> is the subcarrier amplitude, <tt>phas</tt> the
subcarrier phase, <tt>snr</tt> the subcarrier SNR, <tt>prob</tt>
the bit probability and <tt>like</tt> the bit likelihood. An
example is:</p>
<p><tt>wwv3 28 0123 4122 4286 0 24.8 -5545 -1735</tt></p>
<p>Here the driver has acquired minute and second sync, but has not
yet determined the seconds unit digit. However, it has just decoded
bit 28 of the minute. The results show the second sync pulse
amplitude well over the threshold (500), subcarrier amplitude well
above the threshold (1000), good subcarrier tracking phase and SNR
well above the threshold (10 dB). The bit is almost certainly a
zero and the likelihood of a zero in this second is very high.</p>
<p>Format <tt>wwv4</tt> messages are produced for each of the nine
BCD timecode digits until the clock has been set or verified. They
show the results of decoding each digit of the transmitted
timecode.</p>
<p><tt>wwv4 ss stat sigl radx ckdig mldig diff cnt like
snr</tt></p>
<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above,
<tt>radx</tt> is the digit radix (3, 4, 6, 10), <tt>ckdig</tt> the
current clock digit, <tt>mldig</tt> the maximum likelihood digit,
<tt>diff</tt> the difference between these two digits modulo the
radix, <tt>cnt</tt> the compare counter, <tt>like</tt> the digit
likelihood and <tt>snr</tt> the likelihood ratio. An example
is:</p>
<p><tt>wwv4 8 010f 5772 10 9 9 0 6 4615 6.1</tt></p>
<p>Here the driver has previousl set or verified the clock. It has
just decoded the digit preceding second 8 of the minute. The digit
radix is 10, the current clock and maximum likelihood digits are
both 9, the likelihood is well above the threshold (1000) and the
likelihood function well above threshold (3.0 dB). Short of a
hugely unlikely probability conspiracy, the clock digit is most
certainly a 9.</p>
<p>Format <tt>wwv2</tt> messages are produced at each master
oscillator frequency update, which starts at 8 s, but eventually
climbs to 1024 s. They show the progress of the algorithm as it
refines the frequency measurement to a precision of 0.1 PPM.</p>
<p><tt>wwv2 ss stat sigl avint avcnt avinc jitr delt freq</tt></p>
<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above,
<tt>avint</tt> is the averaging interval, <tt>avcnt</tt> the
averaging interval counter, <tt>avinc</tt> the interval increment,
<tt>jitr</tt> the sample change between the beginning and end of
the interval, <tt>delt</tt> the computed frequency change and <tt>
freq</tt> the current frequency (PPM). An example is:</p>
<p><tt>wwv2 22 030f 5795 256 256 4 0 0.0 66.7</tt></p>
<p>Here the driver has acquired minute and second sync and set the
clock. The averaging interval has increased to 256 s on the way to
1024 s, has stayed at that interval for 4 averaging intervals, has
measured no change in frequency and the current frequency is 66.7
PPM.</p>
<p>If the CI-V interface for ICOM radios is active, a debug level
greater than 1 will produce a trace of the CI-V command and
response messages. Interpretation of these messages requires
knowledge of the CI-V protocol, which is beyond the scope of this
document.</p>
<h4>Monitor Data</h4>
When enabled by the <tt>filegen</tt> facility, every received
timecode is written to the <tt>clockstats</tt> file in the
following format:
<pre>
sq yy ddd hh:mm:ss.fff ld du lset agc stn rfrq errs freq cons
s sync indicator
q quality character
yyyy Gregorian year
ddd day of year
hh hour of day
mm minute of hour
fff millisecond of second
l leap second warning
d DST state
dut DUT sign and magnitude
lset minutes since last set
agc audio gain
ident station identifier and frequency
comp minute sync compare counter
errs bit error counter
freq frequency offset
avgt averaging time
</pre>
The fields beginning with <tt>year</tt> and extending through <tt>
dut</tt> are decoded from the received data and are in fixed-length
format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the
following driver-dependent fields, are in variable-length format.
<dl>
<dt><tt>s</tt></dt>
<dd>The sync indicator is initially <tt>?</tt> before the clock is
set, but turns to space when all nine digits of the timecode are
correctly set.</dd>
<dt><tt>q</tt></dt>
<dd>The quality character is a four-bit hexadecimal code showing
which alarms have been raised. Each bit is associated with a
specific alarm condition according to the following:
<dl>
<dt><tt>0x8</tt></dt>
<dd>Sync alarm. The decoder may not be in correct second or minute
phase relative to the transmitter.</dd>
<dt><tt>0x4</tt></dt>
<dd>Error alarm. More than 30 data bit errors occurred in the last
minute.</dd>
<dt><tt>0x2</tt></dt>
<dd>Symbol alarm. The probability of correct decoding for a digit
or miscellaneous bit has fallen below the threshold.</dd>
<dt><tt>0x1</tt></dt>
<dd>Decoding alarm. A maximum likelihood digit fails to agree with
the current associated clock digit.</dd>
</dl>
It is important to note that one or more of the above alarms does
not necessarily indicate a clock error, but only that the decoder
has detected a condition that may in future result in an
error.</dd>
<dt><tt>yyyy ddd hh:mm:ss.fff</tt></dt>
<dd>The timecode format itself is self explanatory. Since the
driver latches the on-time epoch directly from the second sync
pulse, the fraction <tt>fff</tt>is always zero. Although the
transmitted timecode includes only the year of century, the
Gregorian year is augmented 2000 if the indicated year is less than
72 and 1900 otherwise.</dd>
<dt><tt>l</tt></dt>
<dd>The leap second warning is normally space, but changes to <tt>
L</tt> if a leap second is to occur at the end of the month of June
or December.</dd>
<dt><tt>d</tt></dt>
<dd>The DST state is <tt>S</tt> or <tt>D</tt> when standard time or
daylight time is in effect, respectively. The state is <tt>I</tt>
or <tt>O</tt> when daylight time is about to go into effect or out
of effect, respectively.</dd>
<dt><tt>dut</tt></dt>
<dd>The DUT sign and magnitude shows the current UT1 offset
relative to the displayed UTC time, in deciseconds.</dd>
<dt><tt>lset</tt></dt>
<dd>Before the clock is set, the interval since last set is the
number of minutes since the driver was started; after the clock is
set, this is number of minutes since the 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>ident</tt></dt>
<dd>The station identifier shows the station, <tt>C</tt> for WWV or
<tt>H</tt> for WWVH, and frequency being tracked. If neither
station is heard on any frequency, the station identifier shows
<tt>X</tt>.</dd>
<dt><tt>comp</tt></dt>
<dd>The minute sync compare counter is useful to determine the
quality of the minute sync signal and can range from 0 (no signal)
to 5 (best).</dd>
<dt><tt>errs</tt></dt>
<dd>The bit error counter is useful to determine the quality of the
data signal received in the most recent minute. It is normal to
drop a couple of data bits under good signal conditions and
increasing numbers as conditions worsen. While the decoder performs
moderately well even with half the bits are in error in any minute,
usually by that point the sync signals are lost and the decoder
reverts to free-run anyway.</dd>
<dt><tt>freq</tt></dt>
<dd>The frequency offset is the current estimate of the codec
frequency offset to within 0.1 PPM. This may wander a bit over the
day due to local temperature fluctuations and propagation
conditions.</dd>
<dt><tt>avgt</tt></dt>
<dd>The averaging time is the interval between frequency updates in
powers of two to a maximum of 1024 s. Attainment of the maximum
indicates the driver is operating at the best possible resolution
in time and frequency.</dd>
</dl>
<p>An example timecode is:</p>
<p><tt>0 2000 006 22:36:00.000 S +3 1 115 C20 6 5 66.4
1024</tt></p>
<p>Here the clock has been set and no alarms are raised. The year,
day and time are displayed along with no leap warning, standard
time and DUT +0.3 s. The clock was set on the last minute, the AGC
is safely in the middle ot the range 0-255, and the receiver is
tracking WWV on 20 MHz. Excellent reeiving conditions prevail, as
indicated by the compare count 6 and 5 bit errors during the last
minute. The current frequency is 66.4 PPM and the averaging
interval is 1024 s, indicating the maximum precision available.</p>
<h4>Modes</h4>
<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration
command specifies the ICOM ID select code. A missing or zero
argument disables the CI-V interface. Following are the ID select
codes for the known radios.</p>
<table cols="6" width="100%">
<tr>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
</tr>
<tr>
<td>IC725</td>
<td>0x28</td>
<td>40</td>
<td>IC781</td>
<td>0x26</td>
<td>38</td>
</tr>
<tr>
<td>IC726</td>
<td>0x30</td>
<td>48</td>
<td>R7000</td>
<td>0x08</td>
<td>8</td>
</tr>
<tr>
<td>IC735</td>
<td>0x04</td>
<td>4</td>
<td>R71</td>
<td>0x1A</td>
<td>26</td>
</tr>
<tr>
<td>IC751</td>
<td>0x1c</td>
<td>28</td>
<td>R7100</td>
<td>0x34</td>
<td>52</td>
</tr>
<tr>
<td>IC761</td>
<td>0x1e</td>
<td>30</td>
<td>R72</td>
<td>0x32</td>
<td>50</td>
</tr>
<tr>
<td>IC765</td>
<td>0x2c</td>
<td>44</td>
<td>R8500</td>
<td>0x4a</td>
<td>74</td>
</tr>
<tr>
<td>IC775</td>
<td>0x46</td>
<td>68</td>
<td>R9000</td>
<td>0x2a</td>
<td>42</td>
</tr>
</table>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the propagation delay for WWV (40:40:49.0N
105:02:27.0W), in seconds and fraction, with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Specifies the propagation delay for WWVH (21:59:26.0N
159:46:00.0W), in seconds and fraction, with default 0.0.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 0.</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Ordinarily, this field specifies the driver reference
identifier; however, the driver sets the reference identifier
automatically as described above.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Specifies the microphone port if set to zero or the line-in
port if set to one. It does not seem useful to specify the compact
disc player port.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Enables audio monitoring of the input signal. For this purpose,
the speaker volume must be set before the driver is started.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<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>

75
html/driver37.htm
View File

@ -1,75 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<title>Forum Graphic GPS Dating station</title>
</head>
<body>
<h3>Forum Graphic GPS Dating station</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.37.<i>u</i><br>
Reference ID: <tt>GPS</tt><br>
Driver ID: <tt>GPS</tt><br>
Parallel Port: <tt>/dev/fgclock<i>u</i></tt>
</p>
<h4>Description</h4>
<p>This driver supports the Forum Graphic GPS Dating station sold by <a
href="http://www.emr.fr/gpsclock.htm">EMR company</a>.
<p>Unfortunately sometime FG GPS start continues reporting of the same
date. The only way to fix this problem is GPS power cycling and ntpd
restart after GPS power-up.
</P>
After Jan,10 2000 my FG GPS unit start send a wrong answer after 10:00am
till 11:00am. It repeat hour value in result string twice. I wroite a small
code to avoid such problem. Unfortunately I have no second FG GPS unit
to evaluate this problem. Please let me know if your GPS has no problems
after Y2K.
<p>
<h4>Monitor Data</h4>
<p>Each timecode is written to the <tt>clockstats</tt> file in the format
<tt>YYYY YD HH MI SS</tt>.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <tt>FG</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
</dl>
<hr>
<address>Dmitry Smirnov (das@amt.ru)</address>
</body>
</html>

191
html/driver38.htm
View File

@ -1,191 +0,0 @@
<!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
html/driver39.htm
View File

@ -1,162 +0,0 @@
<!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>

126
html/driver4.htm
View File

@ -1,126 +0,0 @@
<HTML><HEAD><TITLE>
Spectracom 8170 and Netclock/2 WWVB Receivers
</TITLE></HEAD><BODY><H3>
Spectracom 8170 and Netclock/2 WWVB Receivers
</H3><HR>
<H4>Synopsis</H4>
Address: 127.127.4.<I>u</I>
<BR>Reference ID: <TT>WWVB</TT>
<BR>Driver ID: <TT>WWVB_SPEC</TT>
<BR>Serial Port: <TT>/dev/wwvb<I>u</I></TT>; 9600 baud, 8-bits, no
parity
<BR>Features: <TT>tty_clk</TT>
<H4>Description</H4>
This driver supports all known Spectracom radio and satellite clocks,
including the Model 8170 and Netclock/2 WWVB Synchronized Clocks and the
Netclock/GPS GPS Master Clock. The claimed accuracy of the WWVB clocks
is 100 usec relative to the broadcast signal. These clocks have proven a
reliable source of time, except in some parts of the country with high
levels of conducted RF interference. WIth the GPS clock the claimed
accuracy is 130 ns. However, in most cases the actual accuracy is
limited by the precision of the timecode and the latencies of the serial
interface and operating system.
<P>The DIPswitches on these clocks should be set to 24-hour display,
AUTO DST off, data format 0 or 2 (see below) and baud rate 9600. If this
clock is used as the source for the IRIG Audio Decoder
(<tt>refclock_irig.c</tt> in this distribution), set the DIPswitches for
AM IRIG output and IRIG format 1 (IRIG B with signature control).
<P>There are two timecode formats used by these clocks. Format 0, which
is available with all clocks, and format 2, which is available with all
clocks except the original (unmodified) Model 8170.
<P>Format 0 (22 ASCII printing characters):
<br>&lt;cr&gt;&lt;lf&gt;i ddd hh:mm:ss TZ=zz&lt;cr&gt;&lt;lf&gt;
<p>on-time = first &lt;cr&gt;
<br>i = synchronization flag (' ' = in synch, '?' = out synch)
<br>hh:mm:ss = hours, minutes, seconds</PRE>
<p>The alarm condition is indicated by other than ' ' at <TT>i</TT>,
which occurs during initial synchronization and when received signal is
lost for about ten hours.
<P>Format 2 (24 ASCII printing characters):
<br>lt;cr&gt;lf&gt;iqyy ddd hh:mm:ss.fff ld
<p>on-time = &lt;cr>
<br>i = synchronization flag (' ' = in synch, '?' = out synch)
<br>q = quality indicator (' ' = locked, 'A'...'D' = unlocked)
<br>yy = year (as broadcast)
<br>ddd = day of year
<br>hh:mm:ss.fff = hours, minutes, seconds, milliseconds</PRE>
<p>The alarm condition is indicated by other than ' ' at <TT>i</TT>,
which occurs during initial synchronization and when received signal is
lost for about ten hours. The unlock condition is indicated by other
than ' ' at <TT>q</TT>.
<P>The <TT>q</TT> is normally ' ' when the time error is less than 1 ms
and a character in the set <TT>A...D</TT> when the time error is less
than 10, 100, 500 and greater than 500 ms respectively. The <TT>l</TT>
is normally ' ', but is set to <TT>L</TT> early in the month of an
upcoming UTC leap second and reset to ' ' on the first day of the
following month. The <TT>d</TT> is set to <TT>S</TT> for standard time
<TT>S</TT>, <TT>I</TT> on the day preceding a switch to daylight time,
<TT>D</TT> for daylight time and <TT>O</TT> on the day preceding a
switch to standard time. The start bit of the first
&lt;cr&gt; is synchronized to the indicated time as returned.
<P>This driver does not need to be told which format is in use - it
figures out which one from the length of the message. A three-stage
median filter is used to reduce jitter and provide a dispersion measure.
The driver makes no attempt to correct for the intrinsic jitter of the
radio itself, which is a known problem with the older radios.
<H4>Monitor Data</H4>
The driver writes each timecode as received to the <TT>clockstats</TT>
file. When enabled by the <TT>flag4</TT> fudge flag, a table of quality
data maintained internally by the Netclock/2 is retrieved and written to
the <TT>clockstats</TT> file when the first timecode message of a new
dayis received.
<H4>Fudge Factors</H4>
<DL>
<DT><TT>time1 <I>time</I></TT></DT>
<DD>Specifies the time offset calibration factor, in seconds and
fraction,
with default 0.0.</DD>
<DT><TT>time2 <I>time</I></TT></DT>
<DD>Not used by this driver.</DD>
<DT><TT>stratum <I>number</I></TT></DT>
<DD>Specifies the driver stratum, in decimal from 0 to 15, with default
0.</DD>
<DT><TT>refid <I>string</I></TT></DT>
<DD>Specifies the driver reference identifier, an ASCII string from one
to four characters, with default <TT>WWVB</TT>.</DD>
<DT><TT>flag1 0 | 1</TT></DT>
<DD>Not used by this driver.</DD>
<DT><TT>flag2 0 | 1</TT></DT>
<DD>Not used by this driver.</DD>
<DT><TT>flag3 0 | 1</TT></DT>
<DD>Not used by this driver.</DD>
<DT><TT>flag4 0 | 1</TT></DT>
<DD>Enable verbose <TT>clockstats</TT> recording if set.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR><ADDRESS>David L. Mills (mills@udel.edu)</ADDRESS></BODY></HTML>

141
html/driver40.htm
View File

@ -1,141 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>JJY Receivers</title>
</head>
<body>
<h3>JJY Receivers</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.40.<i>u</i> <br>
Reference ID: <tt>JJY</tt> <br>
Driver ID: <tt>JJY</tt> <br>
Serial Port: <tt>/dev/jjy<i>u</i></tt>; 9600 baud, 8-bits, no
parity, 1 stop bit
<h4>Description</h4>
<p>This driver supports the following JJY receivers sold in
Japan.</p>
<ul>
<li>
<p>Tristate Ltd. JJY01 <a href=
"http://www.tristate.ne.jp/rf-clock.htm">
http://www.tristate.ne.jp/rf-clock.htm</a> (Japanese only)<br>
Time code format<br>
</p>
<table>
<tr>
<td>Command</td>
<td>Reply</td>
</tr>
<tr>
<td><tt>date&lt;CR&gt;&lt;LF&gt;</tt></td>
<td><tt>YYYY/MM/DD WWW&lt;CR&gt;&lt;LF&gt;</tt></td>
</tr>
<tr>
<td><tt>stim&lt;CR&gt;&lt;LF&gt;</tt></td>
<td><tt>HH:MM:SS&lt;CR&gt;&lt;LF&gt;</tt></td>
</tr>
</table>
</li>
<li>
<p>C-DEX Co.,Ltd. JST2000 <a href="http://www.c-dex.co.jp/">
http://www.c-dex.co.jp/</a> (Japanese only)<br>
Time code format<br>
</p>
<table>
<tr>
<td>Command</td>
<td>Reply</td>
</tr>
<tr>
<td><tt>&lt;ENQ&gt;1J&lt;ETX&gt;</tt></td>
<td><tt>&lt;STX&gt;JYYMMDD HHMMSSS&lt;ETX&gt;</tt></td>
</tr>
</table>
</li>
</ul>
<p>JJY is the radio station which transmites the JST (Japan
Standard Time) in long wave radio. The station JJY is operated by
the Communication Research Laboratory. An operating announcement
and some information are avaiable from <a href=
"http://www.crl.go.jp/">http://www.crl.go.jp/</a> (English and
Japanese)<a href="http://jjy.crl.go.jp/">http://jjy.crl.go.jp/</a>
(Written in Japanese only</p>
<p>The user is expected to provide a symbolic link to an available
serial port device. This is typically performed by a command such
as:</p>
<p><tt>ln -s /dev/ttyS0 /dev/jjy0</tt></p>
<p>Windows NT does not support symbolic links to device files.
COM<i>X</i>: is the unit used by the driver, based on the refclock
unit number, where unit 1 corresponds to COM1: and unit 3
corresponds to COM3:</p>
<h4>Monitor Data</h4>
<p>The driver writes each timecode as received to the <tt>
clockstats</tt> file.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the time offset calibration factor, in seconds and
fraction, with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 0.</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from
one to four characters, with default <tt>WWVB</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<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>

41
html/driver42.htm
View File

@ -1,41 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Solaris (vers 1st May 2002), 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>Zyfer GPStarplus Receiver</title>
</head>
<body>
<h3>Zyfer GPStarplus Receiver</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.42.<i>u</i> <br>
Reference ID: <tt>GPS</tt> <br>
Driver ID: <tt>Zyfer GPStarplus</tt> <br>
Serial Port: <tt>/dev/zyfer<i>u</i></tt>; 9600 baud, 8-bits, no
parity <br>
Features: <tt>(none)</tt>
<h4>Description</h4>
This driver supports the <a href="http://www.zyfer.com/">Zyfer
GPStarplus</a> receiver.
<p>The receiver has a DB15 port on the back which has input TxD and
RxD lines for configuration and control, and a separate TxD line
for the once-per-second timestamp.</p>
<p>Additionally, there are BNC connectors on the back for things
like PPS and IRIG output. Additional Information</p>
<p><a href="refclock.htm">Reference Clock Drivers</a>&nbsp;</p>
<hr>
<address>Harlan Stenn (stenn@whimsy.udel.edu)</address>
</body>
</html>

39
html/driver42.html
View File

@ -1,39 +0,0 @@
<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>Zyfer GPStarplus Receiver</TITLE>
</HEAD>
<BODY>
<H3>Zyfer GPStarplus Receiver</H3>
<HR>
<H4>Synopsis</H4>
Address: 127.127.42.<I>u</I>
<BR>Reference ID: <TT>GPS</TT>
<BR>Driver ID: <TT>Zyfer GPStarplus</TT>
<BR>Serial Port: <TT>/dev/zyfer<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>(none)</TT>
<H4>Description</H4>
This driver supports the <a href="http://www.zyfer.com/">Zyfer GPStarplus</a>
receiver.
<p>The receiver has a DB15 port on the back which has input TxD and RxD
lines for configuration and control, and a separate TxD line for the
once-per-second timestamp.
<p>Additionally, there are BNC connectors on the back for things like PPS
and IRIG output.
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
Harlan Stenn (stenn@whimsy.udel.edu)</ADDRESS>
</BODY>
</HTML>

109
html/driver43.htm
View File

@ -1,109 +0,0 @@
<html>
<head>
<title>RIPE NCC interface for Trimble Palisade</title>
</head>
<body>
<h3>RIPE NCC interface for Trimble Palisade</h3>
<hr>
<img src="pic/driver43_2.jpg" alt="Trimble Acutime 2000" align="right">
<h4>Synopsis</h4>
Address: 127.127.43.<i>u</i> <br>
Reference ID: <tt>RIPENCC</tt> <br>
Driver ID: <tt>RIPENCC</tt>
<h4>Description</h4>
<p> This is a special driver developed to be used in conjuction with the
RIPE NCC clock card in the RIPE NCC Test Traffic Measurements project.
</p>
<h4>Why this driver?</h4>
<p>
The reason why we created a seperated driver for an antenna for which
already a (vendor supplied) driver exist is a design decision.
To be more specific, the standard Trimble interface uses a 12 pin
connector. The cable sold by Trimble to connect to this wire is a very
thick cable. Certainly not something you wish to run for several 100
meters through your building. And if you wanted to run it for 100 meters,
you always would have to really run the cable, and didn't have the option
to use existing wiring.<br>
This is where we wanted more flexibility. We wanted to be able to use
existing wiring in buildings. That leaded us to CAT-5(UTP) which only
gives us 8 wires. Therefor we decided to redesing the use of the Trimble
antenna. The Trimble supports two modes: EVENT driver and PPS mode. The
default is to use the EVENT mode which needs all 12 wires. We only use the
PPS timestamps for which we have enough with 8 wires. For our purposes
this is more than fine.
</p>
More information about the project can be found on the <a href="http://www.ripe.net/test-traffic" TARGET=_new>Test Traffic Measurements</a> website.
<img src="pic/driver43_1.gif" alt="RIPE NCC clock card" align="right">
<h4> RIPE NCC clock card</h4>
<p>The card is very a simple PCI card. The only feature on the bus it uses
is the power supply. It uses this power supply to power the Trimble GPS
antenna.</p>
<p>The card basicly just is a RS422 to RS232 converter. It gets the
Trimble's RS422 signal on a RJ45 connector and transforms that to RS232 on a
DIN9 connector. This connector should be loopbacked on the back of the
machine to the serial port. As said, the card doesn't do any PCI data
transfers.</p>
<p>The schematics of the interface card is available here: <a
href="http://www.ripe.net/ripencc/mem-services/ttm/Documents/gps_interface_schematic.pdf">gps_interface_schematic.pdf</a>.
You are free to create this card yourself as long as you give some credit
or reference to us. Note that we don't sell these cards on a commercial
basis, but for interested parties we do have some spares to share.<p>
<h4>Monitor Data</h4>
In the <tt>filegen clockstats</tt> file the following (example) data is
collected:
<pre>
52445 41931.275 127.127.40.0 U1 20.6.2002 11:38:51 13 11
52445 41931.395 127.127.40.0 C1 20062002 113851 6 364785 110.2 450 6.7 13 5222.374737 N 0453.268013 E 48 7 11 0 1 -14 20 0 -25
52445 41931.465 127.127.40.0 S1 07 1 1 02 59.3 291.5 39.3
52445 41931.485 127.127.40.0 S1 11 2 1 02 59.9 138.0 60.2
52445 41931.525 127.127.40.0 S1 01 4 1 02 48.4 185.7 28.3
52445 41931.555 127.127.40.0 S1 14 5 2 02 32.7 41.0 15.4
52445 41931.585 127.127.40.0 S1 20 6 1 02 59.9 256.6 78.0
52445 41931.615 127.127.40.0 S1 25 8 2 00 0.0 86.6 20.1
</pre>
This is in the form of:
<pre>
All output lines consist of a prefix and a message, the prefix is:
[days since epoch] [sec.ms since start of day] [peer address]
And all individual messages:
*Primary UTC time packet:
U1 [date] [time] [trackstat] [utcflags]
*Comprehensive time packet:
C1 [date] [time] [mode] [bias] [biasunc] [rate] [rateunc] [utcoff] [latitude] [longtitude] [alt] [vis sat](x8)
*Tracking status packet:
S1 [prn] [channel] [aqflag] [ephstat] [snr] [azinuth] [elevation]
</pre>
<h4>Additional Information</h4>
<a href="refclock.htm">Reference Clock Drivers</a>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"Home"></a>
<address><a href="mailto:marks@ripe.net">Mark Santcroos
&lt;marks@ripe.net&gt;</a></address>
</body>
</html>

131
html/driver44.htm
View File

@ -1,131 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>NeoClock4X</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-15">
</head>
<body>
<h1>NeoClock4X - DCF77 / TDF serial line receiver<br>
</h1>
<hr width="100%" size="2">
<h2>Synopsis</h2>
<table cellpadding="0" cellspacing="0" border="0" width="100%">
<tbody>
<tr>
<td valign="top">
<table cellpadding="2" cellspacing="0" border="0" width="100%">
<tbody>
<tr>
<td valign="top">Adress<br>
</td>
<td valign="top">127.127.44.u<br>
</td>
</tr>
<tr>
<td valign="top">Reference ID<br>
</td>
<td valign="top">neol<br>
</td>
</tr>
<tr>
<td valign="top">Driver ID<br>
</td>
<td valign="top">NEOCLK4X<br>
</td>
</tr>
<tr>
<td valign="top">Serial Port<br>
</td>
<td valign="top">/dev/neoclock4x-u<br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
<td valign="top" align="right"><a href="http://www.linum.com"><img
src="pic/neoclock4x.gif" alt="NeoClock4X - DCF77 receiver" width="150"
height="195">
</a><br>
</td>
</tr>
</tbody>
</table>
<hr width="100%" size="2">
<h2>Description</h2>
The refclock_neoclock4x driver supports the NeoClock4X receiver available
from <a href="http://www.linum.com">Linum Software GmbH</a>. The receiver
is available as a <a href="http://www.dcf77.de">DCF77</a> or TDF receiver.
Both receivers have the same output string. For more information about the
NeoClock4X receiver please visit <a
href="http://www.linum.com/redir/jump/id=neoclock4x&amp;action=redir">http://www.linum.com/redir/jump/id=neoclock4x&amp;action=redir</a>.
 
<hr width="100%" size="2">
<h2>Fudge Factors</h2>
<dl>
<dt> <b><a href="clockopt.htm">time1 time</a></b></dt>
<dd> Specifies the time offset calibration factor with the default value
off 0.16958333 seconds. This offset is used  to correct serial line and
operating system delays incurred in capturing time stamps. If you want to
fudge the time1 offset <b>ALWAYS</b> add a value off 0.16958333. This is
neccessary to compensate to delay that is caused by transmit the timestamp
at 2400 Baud. If you want to compensate the delay that the DCF77 or TDF radio
signal takes to travel to your site simply add the needed millisecond delay
to the given value. Note that the time here is given in seconds.</dd>
<dd>Default setting is 0.16958333 seconds.<br>
</dd>
</dl>
<dl>
<dt> <b><a href="file:///E:/ntp-4.1.1a/html/clockopt.htm">time2 time</a></b></dt>
<dd> Not used by this driver.</dd>
</dl>
<dl>
<dt> <a href="clockopt.htm"><b>flag1 0 | 1</b></a></dt>
<dd>When set to 1 the driver will feed ntp with timestampe even if the
radio signal is lost. In this case an internal backup clock generates the
timestamps. This is ok as long as the receiver is synced once since the receiver
is able to keep time for a long period.</dd>
<dd>Default setting is 0 = don't synchronize to CMOS clock.<br>
</dd>
<dd><br>
</dd>
<dt> <a href="clockopt.htm"><b>flag2 0 | 1</b></a></dt>
<dd>You can allow the NeoClock4X driver to use the quartz clock even if
it is never synchronized to a radio clock. This is usally not a good idea
if you want preceise timestamps since the CMOS clock is maybe not adjusted
to a dst status change. So <b>PLEASE</b> switch this only on if you now
what you're doing.</dd>
<dd>Default setting is 0 = don't synchronize to unsynchronized CMOS clock.<br>
</dd>
<dt><br>
</dt>
<dt><a href="clockopt.htm"><b>flag3 0 | 1</b></a></dt>
<dd> Not used by this driver.<tt><tt><tt><tt><tt><tt> </tt></tt></tt></tt></tt></tt></dd>
<dd><br>
</dd>
<dt> <a href="clockopt.htm"><b>flag4 0 | 1</b></a></dt>
<dd>It is recommended to allow extensive logging while you setup the NeoClock4X
receiver. If you activate flag4 every received data is logged. You should
turn off flag4 as soon as the clock works as expected to reduce logfile
cluttering.</dd>
<dd>Default setting is 0 = don't log received data and converted utc time.<br>
</dd>
</dl>
<hr width="100%" size="2">Please send any comments or question to <a
href="mailto:neoclock4@linum.com">neoclock4x@linum.com</a>.<br>
<br>
<br>
</body>
</html>

159
html/driver5.htm
View File

@ -1,159 +0,0 @@
<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>TrueTime GPS/GOES/OMEGA Receivers
</TITLE>
</HEAD>
<BODY>
<H3>
TrueTime GPS/GOES/OMEGA Receivers</H3>
<HR>
<H4>
Synopsis</H4>
Address: 127.127.5.<I>u</I>
<BR>Reference ID: <TT>GPS, OMEGA, GOES</TT>
<BR>Driver ID: <TT>TRUETIME</TT>
<BR>Serial Port: <TT>/dev/true<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver supports several models models of Kinemetrics/TrueTime timing
receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK
III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported
by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232
Talker/Listener module), OM-DC OMEGA Synchronized Clock, and very likely
others in the same model family that use the same timecode formats.
<P>Most of this code is originally from refclock_wwvb.c with thanks. It
has been so mangled that wwvb is not a recognizable ancestor.
<PRE>Timcode format: ADDD:HH:MM:SSQCL
A - control A (this is stripped before we see it)
Q - Quality indication (see below)
C - Carriage return
L - Line feed
Quality codes indicate possible error of
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 468-DC GOES Receiver:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GPS-TM/TMD Receiver:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ? +/- 500 milliseconds&nbsp; # +/- 50 milliseconds
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * +/- 5 milliseconds&nbsp;&nbsp;&nbsp; . +/- 1 millisecond
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; space less than 1 millisecond
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OM-DC OMEGA Receiver:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > +/- 5 seconds
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ? +/- 500 milliseconds&nbsp; # +/- 50 milliseconds
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * +/- 5 milliseconds&nbsp;&nbsp;&nbsp; . +/- 1 millisecond
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A-H less than 1 millisecond. Character indicates which
station
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is being received as follows: A = Norway, B = Liberia,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C = Hawaii, D = North Dakota, E = La Reunion, F =
Argentina,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; G = Australia, H = Japan.</PRE>
The carriage return start bit begins on 0 seconds and extends to 1 bit
time.
<P>Notes on 468-DC and OMEGA receiver:
<P>Send the clock a <TT>R</TT> or <TT>C</TT> and once per second a timestamp
will appear. Send a <TT>R</TT> to get the satellite position once (GOES
only).
<P>Notes on the 468-DC receiver:
<P>Since the old east/west satellite locations are only historical, you
can't set your clock propagation delay settings correctly and still use
automatic mode. The manual says to use a compromise when setting the switches.
This results in significant errors. The solution; use fudge time1 and time2
to incorporate corrections. If your clock is set for 50 and it should be
58 for using the west and 46 for using the east, use the line
<P><TT>fudge 127.127.5.0 time1 +0.008 time2 -0.004</TT>
<P>This corrects the 4 milliseconds advance and 8 milliseconds retard needed.
The software will ask the clock which satellite it sees.
<P>The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch
of TTL input and output pins, all brought out to the back panel. If you
wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime
clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's
INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since
the last PPS upward edge, mediated by reading OUT0 to find out if the counter
has wrapped around (this happens if more than 65535us (65ms) elapses between
the PPS event and our being called.)
<H4>
Monitor Data</H4>
When enabled by the <TT>flag4</TT> fudge flag, every received timecode
is written as-is to the <TT>clockstats</TT> file.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
to be used for the West satellite, with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
. Specifies the time offset calibration factor, in seconds and fraction,
to be used for the East satellite, with default 0.0.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>TRUE</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Silence the clock side of ntpd, just reading the clock without trying to
write to it.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Generate a debug file /tmp/true%d.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

271
html/driver6.htm
View File

@ -1,271 +0,0 @@
<!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>
<hr>
<h4>Synopsis</h4>
Address: 127.127.6.<i>u</i> <br>
Reference ID: <tt>IRIG</tt> <br>
Driver ID: <tt>IRIG_AUDIO</tt> <br>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<p>Note: This driver supersedes an older one of the same name,
address and ID which required replacing the original kernel audio
driver with another which works only on older Sun SPARCstation
systems. The new driver described here uses the stock kernel audio
driver and works in SunOS 4.1.3 and Solaris 2.6 versions and
probably all versions in between. The new driver requires no
modification of the operating system. While it is generic and
likely portable to other systems, it is somewhat slower than the
original, since the extensive signal conditioning, filtering and
decoding is done in user space, not kernel space.</p>
<h4>Description</h4>
This driver supports the Inter-Range Instrumentation Group (IRIG)
standard time distribution signal using the audio codec native to
some workstations. This signal is generated by several radio
clocks, including those made by Arbiter, Austron, Bancomm, Odetics,
Spectracom and TrueTime, among others, although it is often an
add-on option. The signal is connected via an optional attenuator
box and cable to either the microphone or line-in port. The driver
receives, demodulates and decodes the IRIG-B and IRIG-E signal
formats using internal filters designed to reduce the effects of
noise and interference.
<p>This driver incorporates several features in common with other
audio drivers such as described in the <a href="driver7.htm">Radio
CHU Audio Demodulator/Decoder</a> and the <a href="driver36.htm">
Radio WWV/H Audio Demodulator/Decoder</a> pages. They include
automatic gain control (AGC), selectable audio codec port and
signal monitoring capabilities. For a discussion of these common
features, as well as a guide to hookup, debugging and monitoring,
see the <a href="audio.htm">Reference Clock Audio Drivers</a>
page.</p>
<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>
<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.
Secifically, if any of the following errors occur for a time
measurement, the data are rejected.</p>
<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 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>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>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>
Note that additional checks are done elsewhere in the reference
clock interface routines.
<p>Unlike other drivers, which can have multiple instantiations,
this one supports only one. It does not seem likely that more than
one audio codec would be useful in a single machine. More than one
would probably chew up too much CPU time anyway.</p>
<h4>IRIG-B Timecode Format</h4>
The 100 elements of the IRIG timecode are numbered from 0 through
99. Position identifiers occur at elements 0, 9, 19 and every ten
thereafter to 99. The control function (CF) elements begin at
element 50 (CF 1) and extend to element 78 (CF 27). The
straight-binary-seconds (SBS) field, which encodes the seconds of
the UTC day, begins at element 80 (CF 28) and extends to element 97
(CF 44). The encoding of elements 50 (CF 1) through 78 (CF 27) is
device dependent. This driver presently decodes the CF elements,
but does nothing with them.
<p>Where feasible, the IRIG signal source should be operated with
signature control so that, if the signal is lost or mutilated, the
source produces an unmodulated signal, rather than possibly random
digits. The driver will automatically reject the data and declare
itself unsynchronized in this case. Some devices, in particular
Spectracom radio/satellite clocks, provide additional year and
status indication in the format:</p>
<pre>
Element CF Function
-------------------------------------
55 6 time sync status
60-63 10-13 BCD year units
65-68 15-18 BCD year tens
</pre>
Other devices set these elements to zero.
<h4>Performance</h4>
The mu-law companded data format allows considerable latitude in
signal levels; however, an automatic gain control (AGC) function is
implemented to further compensate for varying input signal levels
and to avoid signal distortion. For proper operation, the IRIG
signal source should be configured for analog signal levels, NOT
digital TTL levels.
<p>The accuracy of the system clock synchronized to the IRIG-B
source with this driver and the <tt>ntpd</tt> daemon is 10-20 <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>
The timecode format used for debugging and data recording includes
data helpful in diagnosing problems with the IRIG signal and codec
connections. With debugging enabled (-d on the ntpd command line),
the driver produces one line for each timecode in the following
format:
<p><tt>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5
3094572411.00027</tt></p>
<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>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the time offset calibration factor, in seconds and
fraction, with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 0.</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from
one to four characters, with default <tt>IRIG</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Specifies the microphone port if set to zero or the line-in
port if set to one. It does not seem useful to specify the compact
disc player port.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Enables audio monitoring of the input signal. For this purpose,
the speaker volume must be set before the driver is started.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<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>

657
html/driver7.htm
View File

@ -1,657 +0,0 @@
<!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>; 1200/9600 baud, 8-bits, no
parity <br>
Audio Device: <tt>/dev/chu_audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
<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>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>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>
<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h),
although this can be changed with configuration commands. As long
as the clock is set or verified at least once during this interval,
the NTP algorithms will consider the source reachable and
selectable to discipline the system clock. However, if this does
not happen for eight poll intervals, the algorithms will consider
the source unreachable and some other source will be chosen (if
available) to discipline the system clock.</p>
<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 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.</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>
<h4>Program Operation</h4>
<p>The program consists of four major parts: the DSP modem, maximum
likelihood UART, burst assembler and majority decoder. The DSP
modem demodulates Bell 103 modem answer-frequency signals; that is,
frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz
(space). This is done using a 4th-order IIR filter and
limiter/discriminator with 500-Hz bandpass centered on 2125 Hz and
followed by a FIR raised-cosine lowpass filter optimized for the
300-b/s data rate. Alternately, the driver can be compiled to
delete the modem and input 300 b/s data directly from an external
modem via a serial port.</p>
<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>
<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.</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.</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>
<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>
<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.</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.</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>
<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>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>
<p>Format A bursts are sent at seconds 32 through 39 of the minute
in hex digits</p>
<p><tt>6dddhhmmss6dddhhmmss</tt></p>
<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.</p>
<p>The <tt>x</tt> is coded</p>
<dl>
<dt><tt>1</tt></dt>
<dd>Sign of DUT (0 = +)/dd&gt;</dd>
<dt><tt>2</tt></dt>
<dd>Leap second warning. One second will be added.</dd>
<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></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.</p>
<h4>Debugging Aids</h4>
<p>The most convenient way to track the program status is using the
<tt>ntpq</tt> program and the <tt>clockvar</tt> command. This
displays the last determined timecode and related status and error
counters, even when the program is not discipline the system clock.
If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt>
command line)is enabled, the program produces detailed status
messages as it operates. If the <tt>fudge flag 4</tt> is set, these
messages are written to the <tt>clockstats</tt> file. All messages
produced by this driver have the prefix <tt>chu</tt> for convenient
filtering with the Unix <tt>grep</tt> command.</p>
<p>With debugging enabled the driver produces messages in the
following formats:</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>
<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>
<p><tt>11 40 1091891300ef6e76ecff</tt></p>
<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>A format <tt>chuB</tt> message is produced for each format B
burst received in second 31 of the minute:</p>
<p><tt>chuB n b f s m 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>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.</p>
<h4>Monitor Data</h4>
When enabled by the <tt>filegen</tt> facility, every received
timecode is written to the <tt>clockstats</tt> file in the
following format:
<pre>
sq yy ddd hh:mm:ss.fff ld dut lset agc rfrq bcnt dist tsmp
s sync indicator
q quality character
yyyy Gregorian year
ddd day of year
hh hour of day
mm minute of hour
ss second of minute
fff millisecond of second
l leap second warning
d DST state
dut DUT sign and magnitude in deciseconds
lset minutes since last set
agc audio gain (0-255)
rfrq radio frequency
bcnt burst count
dist decoding distance
tsmp timestamps captured
</pre>
The fields beginning with <tt>year</tt> and extending through <tt>
dut</tt> are decoded from the received data and are in fixed-length
format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the
following driver-dependent fields, are in variable-length format.
<dl>
<dt><tt>s</tt></dt>
<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></dt>
<dd>The quality character is a four-bit hexadecimal code showing
which alarms have been raised during the most recent minute. Each
bit is associated with a specific alarm condition according to the
following:
<dl>
<dt><tt>8</tt></dt>
<dd>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>
<dd>Format alarm. The majority timecode contains invalid bit
combinations.</dd>
<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.</dd>
<dt><tt>yyyy ddd hh:mm:ss.fff</tt></dt>
<dd>The timecode format itself is self explanatory. Note that the
Gregorian year is decoded directly from the transmitted
timecode.</dd>
<dt><tt>l</tt></dt>
<dd>The leap second warning is normally space, but changes to <tt>
L</tt> if a leap second is to occur at the end of the month of June
or December.</dd>
<dt><tt>d</tt></dt>
<dd>The DST code for Canada encodes the state for all
provinces.</dd>
<dt><tt>dut</tt></dt>
<dd>The DUT sign and magnitude shows the current UT1 offset
relative to the displayed UTC time, in deciseconds.</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>
<dd>The minimum decoding distance determined during the most recent
minute bursts were received.</dd>
<dt><tt>tsmp</tt></dt>
<dd>The number of timestamps determined during the most recent
minute bursts were received.</dd>
</dl>
<h4>Modes</h4>
<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration
command specifies the ICOM ID select code. A missing or zero
argument disables the CI-V interface. Following are the ID select
codes for the known radios.</p>
<table cols="6" width="100%">
<tr>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
</tr>
<tr>
<td>IC725</td>
<td>0x28</td>
<td>40</td>
<td>IC781</td>
<td>0x26</td>
<td>38</td>
</tr>
<tr>
<td>IC726</td>
<td>0x30</td>
<td>48</td>
<td>R7000</td>
<td>0x08</td>
<td>8</td>
</tr>
<tr>
<td>IC735</td>
<td>0x04</td>
<td>4</td>
<td>R71</td>
<td>0x1A</td>
<td>26</td>
</tr>
<tr>
<td>IC751</td>
<td>0x1c</td>
<td>28</td>
<td>R7100</td>
<td>0x34</td>
<td>52</td>
</tr>
<tr>
<td>IC761</td>
<td>0x1e</td>
<td>30</td>
<td>R72</td>
<td>0x32</td>
<td>50</td>
</tr>
<tr>
<td>IC765</td>
<td>0x2c</td>
<td>44</td>
<td>R8500</td>
<td>0x4a</td>
<td>74</td>
</tr>
<tr>
<td>IC775</td>
<td>0x46</td>
<td>68</td>
<td>R9000</td>
<td>0x2a</td>
<td>42</td>
</tr>
</table>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the propagation delay for CHU (45:18N 75:45N), in
seconds and fraction, with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with
default 0.</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from
one to four characters, with default <tt>CHU</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>When the audio driver is compiled, this flag selects the audio
input port, where 0 is the mike port (default) and 1 is the line-in
port. It does not seem useful to select the compact disc player
port.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>When the audio driver is compiled, this flag enables audio
monitoring of the input signal. For this purpose, the speaker
volume must be set before the driver is started.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<h4>Additional Information</h4>
<a href="refclock.htm">Reference Clock Drivers</a> <br>
<a href="audio.htm">Reference Clock Audio Drivers</a>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

353
html/driver8.htm
View File

@ -1,353 +0,0 @@
<HTML><HEAD><TITLE>
Generic Reference Driver
</TITLE></HEAD><BODY><H3>
Generic Reference Driver
</H3><HR>
<H4>Synopsis</H4>
Address: 127.127.8.<I>u</I>
<BR>Reference ID: <TT>PARSE</TT>
<BR>Driver ID: <TT>GENERIC</TT>
<BR>Serial Port: <TT>/dev/refclock-<I>u</I></TT>; TTY mode according to
clock type
<H4>Description</H4>
The timecode of these receivers is sampled via a STREAMS module in the
kernel (The STREAMS module has been designed for use with SUN Systems
under SunOS 4.1.x or Solaris 2.3 - 2.6. It can be linked directly into
the kernel or loaded via the loadable driver mechanism). This STREAMS
module can be adapted to be able to convert different time code formats.
If the daemon is compiled without the STREAM definition synchronization
will work without the Sun streams module, though accuracy is
significantly degraded. This feature allows to use PARSE also on non Sun
machines.
<P>The actual receiver status is mapped into various synchronization
states generally used by receivers. The STREAMS module is configured to
interpret the time codes of DCF C51, PZF535, PZF509, GPS166, Trimble SV6
GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see list
below).
<P>The reference clock support in ntp contains the necessary
configuration tables for those receivers. In addition to supporting
several different clock types and 4 devices, the generation a a PPS
signal is also provided as an configuration option. The PPS
configuration option uses the receiver generated time stamps for feeding
the PPS loopfilter control for much finer clock synchronization.
<P>CAUTION: The PPS configuration option is different from the hardware
PPS signal, which is also supported (see below), as it controls the way
ntpd is synchronized to the reference clock, while the hardware PPS
signal controls the way time offsets are determined.
<P>The use of the PPS option requires receivers with an accuracy of
better than 1ms.
<P>Fudge factors
<P>Only two fudge factors are utilized. The time1 fudge factor defines
the phase offset of the synchronization character to the actual time. On
the availability of PPS information the time2 fudge factor defines the
skew between the PPS time stamp and the receiver timestamp of the PPS
signal. This parameter is usually zero, as usually the PPS signal is
believed in time and OS delays should be corrected in the machine
specific section of the kernel driver. time2 needs only be set when the
actual PPS signal is delayed for some reason. The flag1 enables input
filtering. This a median filter with continuous sampling. The flag2
selects averaging of the samples remaining after the filtering. Leap
second-handling is controlled with the flag3. When set a leap second
will be deleted on receipt of a leap second indication from the
receiver. Otherwise the leap second will be added, (which is the
default). flag3 should never be set. PPS handling is enabled by adding
128 to the mode parameter in the server/peer command.
<P>ntpq (8)
<P>timecode variable
<P>The ntpq program can read clock variables command list several
variables.
These hold the following information: refclock_time is the local time
with
the offset to UTC (format HHMM). The currently active receiver flags are
listed in refclock_status. Additional feature flags of the receiver are
optionally listed in parentheses. The actual time code is listed in
timecode.
A qualification of the decoded time code format is following in
refclock_format. The last piece of information is the overall running
time and the accumulated times for the clock event states in
refclock_states. When PPS information is present additional variable are
available. refclock_ppstime lists then the PPS timestamp and
refclock_ppsskew lists the difference between RS232
derived timestamp and the PPS timestamp.
<P>Currently, eighteen clock types (devices /dev/refclock-0 -
/dev/refclock-3) are supported by the PARSE driver.
<BR>A note on the implementations:
<UL><li>These implementations where mainly done <B><I>WITHOUT</I></B>
actual access to the hardware. Thus not all implementations provide full
support. The development was done with the help of many souls who had
the hardware and where so kind to borrow me their time an patience
during the development and debugging cycle. Thus for continued support
and quality direct access to the receivers is a big help. Nevertheless i
am not prepared to buy these reference clocks - donations to <A
HREF="http://www4.informatik.uni-erlangen.de/~kardel">me</A>
(<A HREF="mailto: kardel@acm.org">kardel@acm.org</A>) are welcome as
long as they work within Europe 8-).
<P>Verified implementations are:
<UL>
<LI>
RAWDCF variants
<p>These variants are tested for the decoding with my own homegrown
receivers. Interfacing with specific commercial products may involve
some fiddeling with cables. Especially commericial RAWDCF receivers have
a seemingly unlimited number of ways to draw power from the RS232 port
and to encode the DCF77 datastream. You are mainly on your own here
unless i have a sample of the receiver.
<LI>
<A HREF="http://www.meinberg.de">Meinberg clocks</A>
<p>These implementations are verified by the Meinberg people themselves
and i have access to one of these clocks.</UL>
</UL>
The pictures below refer to the respective clock and where taken from
the vendors web pages. They are linked to the respective vendors.
<UL>
<LI>
<B><TT>server 127.127.8.0-3 mode 0</TT></B>
<p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A>PZF535/<A
HREF="http://www.meinberg.de/english/products/pzf509.htm">PZF509 receiver</A> (FM
demodulation/TCXO / 50us)</TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 1</TT></B>
<p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A> PZF535/<A
HREF="http://www.meinberg.de/english/products/pzf509.htm">PZF509
receiver</A> (FM demodulation/OCXO / 50us)</TT></B>
<BR><A HREF="http://www.meinberg.de/english/products/pzf509.htm"><IMG
SRC="pic/pzf509.jpg" ALT="BILD PZF509" HEIGHT=300 WIDTH=260
ALIGN=TEXTTOP></A>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 2</TT></B>
<p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A> DCF U/A
31/<A HREF="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver</A>
(AM demodulation / 4ms)</TT></B>
<BR><A HREF="http://www.meinberg.de/english/products/c51.htm"><IMG
SRC="pic/c51.jpg" ALT="BILD C51" HEIGHT=180 WIDTH=330 ALIGN=TEXTTOP></A>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 3</TT></B>
<p><B><TT><A HREF="http://www.elv.de">ELV</A> DCF7000 (sloppy AM
demodulation
/ 50ms)</TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 4</TT></B>
<p><B><TT>Walter Schmid DCF receiver Kit (AM demodulation /
1ms)</TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 5</TT></B>
<p><B><TT>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module /
5ms)</TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 6</TT></B>
<p><B><TT>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module
/ 5ms)</TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 7</TT></B>
<p><B><TT><A HREF="http://www.meinberg.de">Meinberg </A> <A
HREF="http://www.meinberg.de/english/products/gps167.htm">GPS166/GPS167
receiver</A> (GPS / &lt;&lt;1us)</TT></B>
<BR><A HREF="http://www.meinberg.de/english/products/gps167.htm"><IMG
SRC="pic/gps167.jpg" ALT="BILD GPS167" HEIGHT=300 WIDTH=280
ALIGN=TEXTTOP></A>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 8</TT></B>
<p><B><TT><A HREF="http://www.igel.de">IGEL</A> <A
HREF="http://www.igel.de/eigelmn.htm">clock</A></TT></B>
<BR><A HREF="http://www.igel.de/eigelmn.htm"><IMG SRC="pic/igclock.gif"
HEIGHT=174 WIDTH=200></A>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 9</TT></B>
<p><B><TT><A HREF="http://www.trimble.com">Trimble</A> <A
HREF="http://www.trimble.com/cgi/omprod.cgi/pd_om011.htm">SVeeSix
GPS receiver</A>TAIP protocol (GPS / &lt;&lt;1us)</TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 10</TT></B>
<p><B><TT><A HREF="http://www.trimble.com">Trimble</A> <A
HREF="http://www.trimble.com/cgi/omprod.cgi/pd_om011.htm">SVeeSix
GPS receiver</A> TSIP protocol (GPS / &lt;&lt;1us) (no kernel support
yet)</TT></B>
<BR><A HREF="http://www.trimble.com/cgi/omprod.cgi/pd_om011.htm"><IMG
SRC="pic/pd_om011.gif" ALT="SVeeSix-CM3" BORDER=0 HEIGHT=100 WIDTH=420
ALIGN=TEXTTOP></A>
<BR><A HREF="http://www.trimble.com/cgi/omprod.cgi/pd_om006.htm"><IMG
SRC="pic/pd_om006.gif" ALT="Lassen-SK8" BORDER=0 HEIGHT=100
WIDTH=420></A>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 11</TT></B>
<p><B><TT>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master
Clock
support </TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 12</TT></B>
<p><B><TT><A HREF="http://www.hopf-time.com">HOPF</A> <A
HREF="http://www.hopf-time.com/kart6021.htm">Funkuhr
6021</A></TT></B>
<BR><A HREF="http://www.hopf-time.com/engl/kart6021.htm"><IMG
SRC="pic/fg6021.gif" ALT="DCF77-Interface Board" HEIGHT=207 WIDTH=238
ALIGN=TEXTTOP></A>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 13</TT></B>
<p><B><TT>Diem's Computime Radio Clock</TT></B>
<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 14</TT></B>
<p><B><TT>RAWDCF receiver (DTR=high/RTS=low)</TT></B>
<LI>
<B><TT>server 127.127.8.0-3 mode 15</TT></B>
<p><B><TT>WHARTON 400A Series Clocks with a 404.2 Serial
Interface</TT></B>
<LI>
<B><TT>server 127.127.8.0-3 mode 16</TT></B>
<p><B><TT>RAWDCF receiver (DTR=low/RTS=high)
</TT></B>
<LI>
<B><TT>server 127.127.8.0-3 mode 17</TT></B>
<p><B><TT>VARITEXT Receiver (MSF)
</TT></B>
</UL>
<p>
Actual data formats and set-up requirements of the various clocks can be
found in <A HREF="parsedata.htm">NTP PARSE clock data formats</A>.
<P>The reference clock support carefully monitors the state transitions
of the receiver. All state changes and exceptional events such as loss
of time code transmission are logged via the syslog facility. Every hour
a summary of the accumulated times for the clock states is listed via
syslog.
<P>PPS support is only available when the receiver is completely
synchronized. The receiver is believed to deliver correct time for an
additional period of time after losing synchronizations, unless a
disruption in time code transmission is detected (possible power loss).
The trust period is dependent on the receiver oscillator and thus a
function of clock type. This is one of the parameters in the clockinfo
field of the reference clock implementation. This parameter cannot be
configured by ntpdc.
<P>In addition to the PPS loopfilter control a true PPS hardware signal
can be applied on Sun Sparc stations via the CPU serial ports on the CD
pin. This signal is automatically detected and will be used for offset
calculation. The input signal must be the time mark for the following
time code. (The edge sensitivity can be selected - look into the
appropriate kernel/parsestreams.c for details). Meinberg receivers can
be connected by feeding the PPS pulse of the receiver via a 1488 level
converter to Pin 8 (CD) of a Sun serial zs-port. To select PPS support
the STREAMS driver for PARSE must be loaded and the mode parameter ist
the mode value of above plus 128. If 128 is not added to the mode value
PPS will be detected to be available but it will not be used. For PPS to
be used you MUST add 128 to the mode parameter.
<P>For the Meinberg GPS166/GPS167 receiver is also a special firmware
release available (Uni-Erlangen). This release should be used for proper
operation.
<P>The raw DCF77 pulses can be fed via a level converter directly into
Pin 3 (Rx) of the Sun. The telegrams will be decoded an used for
synchronization. AM DCF77 receivers are running as low as $25. The
accuracy is dependent on the receiver and is somewhere between 2ms
(expensive) to 10ms (cheap). Upon bad signal reception of DCF77
synchronizations will cease as no backup oscillator is available as
usually found in other reference clock receivers. So it is important to
have a good place for the DCF77 antenna. For transmitter shutdowns you
are out of luck unless you have other NTP servers with alternate time
sources available.
<H4>Monitor Data</H4>
Clock states statistics are written hourly the the syslog service.
Online information can be found by examining the clock variable via the
ntpq cv command.
<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 depending on clock type.</DD>
<DT><TT>time2 <I>time</I></TT></DT>
<DD>Specifies the offset if the PPS signal to the actual time. (PPS fine
tuning).</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 according to current clock type.</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>delete next leap second instead of adding it.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>Delete next leap second instead of adding it - flag will be re-
defined soon - so don't use it. Statistics are provided by more common
means (syslog, clock variable via ntpq)</DD>
</DL>
<H4>Making your own PARSE clocks</H4>
The parse clock mechanismis deviated from the way other ntp reference
clocks work. For a short description how to build parse reference clocks
see <A HREF="parsenew.htm">making PARSE clocks</A>
<P>Additional Information
<P><A HREF="refclock.htm">Reference Clock 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></body></html>

129
html/driver9.htm
View File

@ -1,129 +0,0 @@
<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>Magnavox MX4200 GPS Receiver</TITLE>
</HEAD>
<BODY>
<H3>Magnavox MX4200 GPS Receiver</H3>
<HR>
<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>
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
Disciplines and Streams Modules</A> page. It also requires a <A
HREF="gadget.htm">gadget box</A> and 1-PPS level converter, such as
described in the <A HREF="pps.htm">Pulse-per-second (PPS) Signal
Interfacing</A> page.
<P>This driver supports all compatible receivers such as the 6-channel
MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.
<P>
<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
MX4200 and its successors.</P>
<BR CLEAR=LEFT>
Leica MX9400N Navigator.
<P>
<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. 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>
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>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</DD>
<DT>
<TT>time2 <I>time</I></TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>stratum <I>number</I></TT></DT>
<DD>
Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
<DT>
<TT>refid <I>string</I></TT></DT>
<DD>
Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <TT>GPS</TT>.</DD>
<DT>
<TT>flag1 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag2 0 | 1</TT></DT>
<DD>
Assume GPS receiver is on a mobile platform if set.</DD>
<DT>
<TT>flag3 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
<DD>
Not used by this driver.</DD>
</DL>
Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A>&nbsp;
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

195
html/drivers/driver40.html
View File

@ -5,7 +5,10 @@
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
<meta http-equiv="Content-Script-Type" content="text/javascript">
<title>JJY Receivers</title>
<link rev="made" href="http://www.bea.hi-ho.ne.jp/abetakao/">
<link rel="start" href="http://www.eecis.udel.edu/~mills/ntp/html/refclock.html">
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
@ -13,122 +16,174 @@
<h3>JJY Receivers</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.40.<i>u</i><br>
Reference ID: <tt>JJY</tt><br>
Driver ID: <tt>JJY</tt><br>
Serial Port: <tt>/dev/jjy<i>u</i></tt>; 9600 baud, 8-bits, no parity, 1 stop bit
Address: 127.127.40.<em>u</em><br>
Reference ID: <code>JJY</code><br>
Driver ID: <code>JJY</code><br>
Serial Port: <code>/dev/jjy<em>u</em></code>; 9600|4800(See corresponding receiver) baud, 8-bits, no parity, 1 stop bit
<h4>Description</h4>
<p>This driver supports the following JJY receivers sold in Japan.</p>
<ul>
<li>Tristate Ltd. JJY01 <a href="http://www.tristate.ne.jp/">http://www.tristate.ne.jp/</a> (Japanese only)<br>
<dl>
<dt>Time code format
<dd><br>
<table>
<tr>
<td>Command</td>
<td>&nbsp;</td>
<td>Reply</td>
</tr>
<tr>
<td><tt>date&lt;CR&gt;&lt;LF&gt;</tt></td>
<td>&nbsp;</td>
<td><tt>YYYY/MM/DD WWW&lt;CR&gt;&lt;LF&gt;</tt></td>
</tr>
<tr>
<td><tt>stim&lt;CR&gt;&lt;LF&gt;</tt></td>
<td>&nbsp;</td>
<td><tt>HH:MM:SS&lt;CR&gt;&lt;LF&gt;</tt></td>
</tr>
</table>
<br>
<dt>NTP configuration ( ntp.conf )
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 1</p>
<br>
</dl>
<li>C-DEX Co.,Ltd. JST2000 <a href="http://www.c-dex.co.jp/">http://www.c-dex.co.jp/</a> (Japanese only)<br>
<dl>
<dt>Time code format
<dd><br>
<table>
<tr>
<td>Command</td>
<td>&nbsp;</td>
<td>Reply</td>
</tr>
<tr>
<td><tt>&lt;ENQ&gt;1J&lt;ETX&gt;</tt></td>
<td>&nbsp;</td>
<td><tt>&lt;STX&gt;JYYMMDD HHMMSSS&lt;ETX&gt;</tt></td>
</tr>
</table>
<br>
<dt>NTP configuration ( ntp.conf )
</dd>
<dt>RS-232C</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 2</p>
<p>9600 Baud</p>
<br>
</dl>
<li>
<p>Echo Keisokuki Co.,Ltd. LT-2000 <a href="http://www.clock.co.jp/">http://www.clock.co.jp/</a> (Japanese only)</p>
<dl>
<dt>Time code format
</dd>
<dt>Time code format</dt>
<dd><br>
<table summary="CommandAndReply">
<tr>
<td>Command</td>
<td>&nbsp;</td>
<td>&nbsp;--&gt;&nbsp;</td>
<td>Reply</td>
</tr>
<tr>
<td><code>date&lt;CR&gt;&lt;LF&gt;</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>YYYY/MM/DD WWW&lt;CR&gt;&lt;LF&gt;</code></td>
</tr>
<tr>
<td><code>stim&lt;CR&gt;&lt;LF&gt;</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>HH:MM:SS&lt;CR&gt;&lt;LF&gt;</code></td>
</tr>
</table>
<br>
</dd>
</dl>
<li>C-DEX Co.,Ltd. JST2000 <a href="http://www.c-dex.co.jp/">http://www.c-dex.co.jp/</a> (Japanese only)<br>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 2</p>
<br>
</dd>
<dt>RS-232C</dt>
<dd>
<p>9600 Baud</p>
<br>
</dd>
<dt>Time code format</dt>
<dd><br>
<table summary="CommandAndReply">
<tr>
<td>Command</td>
<td>&nbsp;--&gt;&nbsp;</td>
<td>Reply</td>
</tr>
<tr>
<td><code>&lt;ENQ&gt;1J&lt;ETX&gt;</code></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td><code>&lt;STX&gt;JYYMMDD HHMMSSS&lt;ETX&gt;</code></td>
</tr>
</table>
<br>
</dd>
</dl>
<li>
<p>Echo Keisokuki Co.,Ltd. LT-2000 <a href="http://www.clock.co.jp/">http://www.clock.co.jp/</a> (Japanese only)</p>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 3</p>
<br>
</dd>
<dt>RS-232C</dt>
<dd>
<p>9600 Baud</p>
<br>
</dd>
<dt>Time code format</dt>
<dd><br>
<table summary="CommandAndReply">
<tr>
<td>Command</td>
<td>&nbsp;--&gt;&nbsp;</td>
<td>Reply</td>
</tr>
<tr>
<td><code>C</code></td>
<td></td>
<td>&nbsp;--&gt;&nbsp;</td>
<td>( Mode 2 : Continuous )</td>
</tr>
<tr>
<td></td>
<td>( Every second before 0.5 second )</td>
<td></td>
<td><code>YYMMDDWHHMMSS&lt;ST1&gt;&lt;ST2&gt;&lt;ST3&gt;&lt;ST4&gt;&lt;CR&gt;</code></td>
</tr>
<tr>
<td><code>#</code></td>
<td></td>
<td>( Mode 1 : Request&Send )</td>
<td>&nbsp;--&gt;&nbsp;</td>
<td>( Mode 1 : Request&amp;Send )</td>
</tr>
</table>
<br>
<dt>NTP configuration ( ntp.conf )
</dd>
</dl>
<li>
<p>CITIZEN T.I.C. CO.,LTD. JJY-200 <a href="http://www.tic-citizen.co.jp/">http://www.tic-citizen.co.jp/</a> (Japanese only)</p>
<dl>
<dt>NTP configuration ( ntp.conf )</dt>
<dd>
<p>server &nbsp; 127.127.40.X &nbsp; mode 3</p>
<p>server &nbsp; 127.127.40.X &nbsp; mode 4</p>
<br>
</dd>
<dt>RS-232C</dt>
<dd>
<p>4800 Baud</p>
<br>
</dd>
<dt>Time code format</dt>
<dd><br>
<table summary="CommandAndReply">
<tr>
<td>Command</td>
<td>&nbsp;--&gt;&nbsp;</td>
<td>Reply</td>
</tr>
<tr>
<td>( Every second )</td>
<td></td>
<td><code>'XX YY/MM/DD W HH:MM:SS&lt;CR&gt;</code></td>
</tr>
</table>
<br>
</dd>
</dl>
</ul>
<p>JJY is the radio station which transmites the JST (Japan Standard Time) in long wave radio. The station JJY is operated by the National Institute of Information and Communications Technology. An operating announcement and some information are avaiable from <a href="http://www.nict.go.jp/">http://www.nict.go.jp/</a> (English and Japanese) and <a href="http://jjy.nict.go.jp/">http://jjy.nict.go.jp/</a> (English and Japanese)</p>
<p>The user is expected to provide a symbolic link to an available serial port device. This is typically performed by a command such as:</p>
<p><tt>ln -s /dev/ttyS0 /dev/jjy0</tt></p>
<p>Windows NT does not support symbolic links to device files. COM<i>X</i>: is the unit used by the driver, based on the refclock unit number, where unit 1 corresponds to COM1: and unit 3 corresponds to COM3:</p>
<p><code>ln -s /dev/ttyS0 /dev/jjy0</code></p>
<p>Windows NT does not support symbolic links to device files. COM<em>X</em>: is the unit used by the driver, based on the refclock unit number, where unit 1 corresponds to COM1: and unit 3 corresponds to COM3:</p>
<h4>Monitor Data</h4>
<p>The driver writes each timecode as received to the <tt>clockstats</tt> file.</p>
<p>The driver writes each timecode as received to the <code>clockstats</code> file.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<dt><code>time1 <em>time</em></code>
<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dt><code>time2 <em>time</em></code>
<dd>Not used by this driver.
<dt><tt>stratum <i>number</i></tt>
<dt><code>stratum <em>number</em></code>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
<dt><tt>refid <i>string</i></tt>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>JJY</tt>.
<dt><tt>flag1 0 | 1</tt>
<dt><code>refid <em>string</em></code>
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <code>JJY</code>.
<dt><code>flag1 0 | 1</code>
<dd>Not used by this driver.
<dt><tt>flag2 0 | 1</tt>
<dt><code>flag2 0 | 1</code>
<dd>Not used by this driver.
<dt><tt>flag3 0 | 1</tt>
<dt><code>flag3 0 | 1</code>
<dd>Not used by this driver.
<dt><tt>flag4 0 | 1</tt>
<dt><code>flag4 0 | 1</code>
<dd>Not used by this driver.
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
</html>

393
html/exec.htm
View File

@ -1,393 +0,0 @@
<!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" 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">
</p>
<hr>
<h4>Introduction</h4>
<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>
<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>
<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.</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.</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>
<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.
<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>
<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>
<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>
<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.</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>
<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.</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.</p>
<h4>Further Reading</h4>
<ol>
<li>
<p>Cristian, F. Probabilistic clock synchronization. In Distributed
Computing 3, Springer Verlag, 1989, 146-158.</p>
</li>
<li>
<p>Digital Time Service Functional Specification Version T.1.0.5.
DigitalEquipment Corporation, 1989.</p>
</li>
<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).</p>
</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>
<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>
<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>
<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>
<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.</p>
</li>
<li>
<p>Schneider, F.B. A paradigm for reliable clock synchronization.
Department of Computer Science Technical Report TR 86-735, Cornell
University, February 1986.</p>
</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" alt=
"home"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>

108
html/extern.htm
View File

@ -1,108 +0,0 @@
<!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>
<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 and
synchronization service fall back to other means, such as a local
reference clock or another NTP server. In addition, when the
external clock and driver are in control, some means needs to be
provided for the clock driver to pass on status information and
error statistics to the NTP daemon.</p>
<p>Control and monitoring functions for the external clock and
driver are implemented using the <a href="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>When the external clock is enabled, <tt>ntpd</tt> does not
discipline the system clock, nor does it maintain the error
statistics. In this case, the external clock and driver do this
using mechanisms unknown to <tt>ntpd</tt>; however, in this case
the kernel state variables are retrieved at 64-s intervals by the
Local Clock driver and used by the clock selection and mitigation
algorithms to determine the system variables presented to other NTP
clients and peers. In this way, downstream clients and servers in
the NTP subnet can make an intelligent choice when more than one
server is available.</p>
<p>In order to implement a reliable mitigation between ordinary NTP
sources and the external clock source, a protocol is necessary
between the local clock driver and the external clock driver. This
is implemented using Boolean variables and certain bits in the
kernel clock status word. The Boolean variables include the
following:</p>
<p>ntp__enable. set/reset by enable command. enables ntp clock
discipline</p>
<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>
<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>
<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>
<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>

48
html/gadget.htm
View File

@ -1,48 +0,0 @@
<html><head><title>
Gadget Box PPS Level Converter and CHU Modem
</title></head><body><h3>
Gadget Box PPS Level Converter and CHU Modem
</h3>
<img align=left src=pic/gadget.jpg>A Gadget Box built by Chuck Hanavin
<br clear=left><hr>
<h4>Introduction</h4>
<p>Many radio clocks used as a primary reference source for NTP servers produce a pulse-per-second (PPS) signal that can be used to improve accuracy to a high degree. However, the signals produced are usually incompatible with the modem interface signals on the serial ports used to connect the signal to the host. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional radio modem designed to decode the radio timecode signals transmitted by the Canadian time and frequency station CHU. A complete set of schematics, PCB artwork, drill templates can be obrtained via the web as the distribution <a href= "http://www.eecis.udel.edu/~mills/ntp/ntp">gadget.tar.Z</a>, or by anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
<p>The gadget box is assembled in a 5&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.
<h4>Circuit Description</h4>
<p>Following is a brief functional description of the device. See the schematic diagram gadget.s01 for reference. The audio output of a shortwave radio tuned to CHU at 3330, 7335 or 14670 kHz is connected to J2. A level of at least 30 mV peak-peak is required, such as provided by the recorder output on many receivers. The input level is adjusted by potentiometer R8 so that the timecode modulation broadcast at 31-39 seconds past the minute reliably lights green LED1, but the signals broadcast during other seconds of the minute do not.
<p>Opamp U4A provides low-impedance drive for the bridged-tee bandpass filter U4B. The filter has a bandpass of about 600 Hz at the 6-dB points and a center frequency of about 2150 Hz. It is designed to avoid aliasing effects with receivers of relatively wide bandpass characteristics. The modem itself is implemented by U2 and its associated circuitry. Resistors R4 and R1 are a 40-dB pad which matches the filter output to the modem input. U2 is a TTL/EIA level converter with integral power supply for bipolar signals. The modem output is available at pin 3 (receive data) of DB25 connector J1.
<p>The TTL PPS signal is connected via J3 to a retriggerable one-shot U3A, which generates a TTL pulse of width determined by potentiometer R7. The pulse width is determined by the bit rate of the attached serial port. In the common case the width is one bit-time, such as 26 us for 38.4 kbps, for example. This appears to the port as a single start bit of zero followed by eight bits of ones and a stop bit of one. The second one-shot U3B generates a 200-ms pulse suitable for driving the amber LED3 as a visual monitor. The output of U3A is converted to EIA levels by U1 and appears at pin 12 (secondary receive data) of J1.
<p>If only the PPS circuit is required, U2 and U4 can be deleted and the gadget box powered from the EIA modem-control signal at pin 20 (terminal ready) of J1, assuming this signal is placed in the on (positive voltage) condition by the computer program. J1 is wired to keep most finicky UARTs and terminal-driver programs happy. If the CHU circuit is required, an external 12-volt AC transformer or 9-12-volt DC supply
connected to J4 is required. Red LED2 indicates power is supplied to the box.
<p>Files
<p>Following is a list of files included in this archive. All files are in PostScript, except the <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><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>

181
html/genkeys.htm
View File

@ -1,181 +0,0 @@
<!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>

32
html/hints.htm
View File

@ -1,32 +0,0 @@
<html><head><title>
Hints and Kinks
</title></head><body><h3>
Hints and Kinks
</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
supplied by various volunteers in the form of mail messages, patches or
just plain word of mouth. Each note applies to a specific computer and
operating system and gives information found useful in setting up the
NTP distribution or site configuration. The notes are very informal and
subject to errors; no attempt has been made to verify the accuracy of
the information contained in them.
<p>Additions or corrections to this list or the information contained in
the notes is solicited. The most useful submissions include the name of
the computer manufacturer (and model numbers where appropriate),
operating system (specific version(s) where appropriate), problem
description, problem solution and submitter's name and electric address.
If the submitter is willing to continue debate on the problem, please so
advise. See the <a href=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>
</address></a></body></html>

39
html/hints/sco.htm
View File

@ -1,39 +0,0 @@
<HTML>
<HEAD>
<TITLE>SCO Unix hints</TITLE>
</HEAD>
<BODY>
<H1>SCO Unix hints</H1>
<H2>Older SCO Unix versions</H2>
<P>
NTP 4.0.x does not run on SCO Unix prior to version 3.2.5.0.0. If you
need NTP on an older SCO Unix system and don't mind to modify your
kernel, use 3.5.91 which has patches for SCO Unix 3.2.4.x. Apply the
kernel modifications as described in
<A HREF="http://www.echelon.nl/en/ntp/sco3-recipe.html">XNTP on SCO
3.2.4.2</A>.
<H2>Compiling NTP</H2>
<P>
Delete the old SCO supplied NTP programs using the &quot;custom&quot;
utility. Run the NTP configure program with CFLAGS=&quot;-b elf -K
<I>processor-type</I>&quot; for best results.
<H2>Running NTP</H2>
<P>
Run &quot;tickadj -As&quot; after every reboot to set the variables
&quot;clock_drift&quot; and &quot;track_rtc&quot; to the right values.
<P>
Run &quot;ntpd&quot; with a high negative nice-value, i.e.
&quot;nice --19 ntpd&quot; for best results.
<H2>More information</H2>
<P>
More information on the way SCO Unix and NTP interact can be found in
<A HREF="http://www.echelon.nl/en/ntp/ntp-on-sco.html">NTP on SCO Unix</A>,
which includes links to precompiled versions of NTP.
<P>
<A HREF="mailto:kees@echelon.nl">Kees Hendrikse</A>, January 1999
</BODY>
</HTML>

153
html/hints/vxworks.htm
View File

@ -1,153 +0,0 @@
<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>

334
html/hints/winnt.htm
View File

@ -1,334 +0,0 @@
<!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>
<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 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>
Reference Clocks</h2>
Refernce clock support under Windows NT is tricky because the IO functions
are so much different. The following reference clocks are supported by
Windows NT:
<p><a href="../driver1.htm">Type 1</a> Undisciplined Local Clock (LOCAL)
<br><a href="../driver29.htm">Type 29</a> Trimble Navigation Palisade GPS
(GPS_PALISADE)
<h2>
Functions Supported</h2>
All NTP functions are supported with some constraints. See the TODO list
below.
<h2>
Accuracy</h2>
Greg Brackley has implemented a fantastic interpolation scheme that improves
the precision of the NTP clock using a realtime thread (is that poetic
or what!) which captures a tick count from the 8253 counter after each
OS tick. The count is used to interpolate the time between operating system
ticks.
<p>On a typical 200+ MHz system NTP achieves a precision of about 5 microseconds
and synchronizes the clock to +/-500 microseconds using the <a href="http://www.trimble.com/products/ntp">Trimble
Palisade</a> as UTC reference. This allows distributed applications to
use the 10 milliseconds ticks available to them with high confidence.
<h2>
Binaries</h2>
Recent InstallShield based executable versions of NTP for Windows NT (i386)
are available from:
<br><a href="http://www.trimble.com/oem/ntp">http://www.trimble.com/oem/ntp</a>
and <a href="http://www.five-ten-sg.com/">http://www.five-ten-sg.com/</a>
<h2>
ToDo</h2>
<ul>
<li>
MD5 authentication causes problems with DNS. If you use encryption/authentication,
you have to use IP numbers in <tt>ntp.conf.</tt></li>
<li>
NMEA refclock support is in development.</li>
<li>
See if precision can be improved by using CPU cycle counter for tick interpolation.</li>
<li>
Make precision time available to applications using NTP_GETTIME API</li>
</ul>
<h2>
Compiling Requirements</h2>
<ul>
<li>
<tt>Windows NT 4.0 or 5.0 (2000)</tt></li>
<li>
<tt>Microsoft Visual C++ 6.0</tt></li>
<li>
Some version of the archiving program <tt>ZIP</tt>.</li>
</ul>
<h2>
Compiling Instructions</h2>
<ol>
<li>
Unpack the NTP-4.x.tar.gz</li>
<li>
Open the .\ports\winnt\ntp.dsw Visual C workspace</li>
<li>
Batch build all projects</li>
</ol>
<h2>
Configuration File</h2>
The default NTP configuration file path is %SystemRoot%<tt>\system32\drivers\etc\.
</tt>(%SystemRoot%
is an environmental variable that can be determined by typing "set" at
the "Command Prompt" or from the "System" icon in the "Control Panel").
<br>Refer to your system environment and <tt>c</tt>reate your<tt> ntp.conf</tt>
file in the directory corresponding to your system&nbsp; installation.
<br><tt>The older &lt;WINDIR>\ntp.conf </tt>is still supported but you
will get a log entry reporting that the first file wasn't found.
<h2>
Installation Instructions</h2>
The <tt>instsrv</tt> program in the instsrv subdirectory of the distribution
can be used to install 'ntpd' as a service and start automatically at boot
time. Instsrv is automatically compiled with the rest of the distribution
if you followed the steps above.
<ol>
<li>
Start a command prompt and enter "instsrv.exe &lt;pathname_for_ntpd.exe>"</li>
<li>
Clicking on the "Services" icon in the "Control Panel" will display the
list of currently installed services in a dialog box. The NetworkTimeProtocol
service should show up in this list. Select it in the list and hit the
"Start" button in the dialog box. The NTP service should start.</li>
<li>
View the event log by clicking on the "Event Viewer" icon in the "Administrative
Tools" group, there should be several successful startup messages from
NTP. NTP will keep running and restart automatically when the machine is
rebooted.</li>
</ol>
You can change the start mode (automatic/manual) and other startup parameters
correponding to the NTP service (eg. location of conf file) also in the
"Services" dialog box if you wish.
<h2>
Removing NTP</h2>
You can also use <tt>instsrv</tt> to delete the NTP service by entering:
"instsrv.exe remove"
<h2>
Command Line Parameters and Registry Entries</h2>
Unlike the Unix environment, there is no clean way to run 'ntpdate' and
reset the clock before starting 'ntpd' at boot time.
<br>NTP will step the clock up to 1000 seconds by default. While there
is no reason that the system clock should be that much off during bootup
if 'ntpd' was running before, you may wish to override this default and/or
pass other command line directives.
<p>Use the registry editor to edit the value for the ntpd executable under
LocalMachine\System\CurrentControlSet\Services\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>
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>
<p><b>Significant Changes:</b>
<ul>
<li>
Fixed I/O problem delaying packet responses which resulted in no-replys
to NTPQ and others.</li>
<li>
The default configuration file path is <tt>&lt;WINDIR>\system32\drivers\etc\ntp.conf.
The old &lt;WINDIR>\ntp.conf </tt>is still supported but you will get a
log entry reporting that the first file wasn't found. The NTP 3.x legacy
<tt>ntp.ini</tt>
file is no longer supported.</li>
</ul>
<b>Known Problems / TODO:</b>
<ul>
<li>
MD5 and name resolution do not yet get along. If you define MD5, you cannot
use DNS names, only IP numbers.</li>
</ul>
<h3>
Last revision 27 July 1999&nbsp; Version 4.0.95.</h3>
This version compiles under WINNT with Visual C 6.0.
<p>Greg Brackley and Sven Dietrich
<p>Significant changes:
<br>-Visual Studio v6.0 support
<br>-Winsock 2.0 support
<br>-Use of I/O completion ports for sockets and comm port I/O
<br>-Removed the use of multimedia timers (from ntpd, others need removing)
<br>-Use of waitable timers (with user mode APC) and performance counters
to fake getting a better time
<br>-Trimble Palisade NTP Reference Clock support
<br>-General cleanup, prototyping of functions
<br>-Moved receiver buffer code to a separate module (removed unused members
from the recvbuff struct)
<br>-Moved io signal code to a separate module
<h3>
Last revision:&nbsp; 20-Oct-1996</h3>
This version corrects problems with building the XNTP
<br>version 3.5-86 distribution under Windows NT.
<p>The following files were modified:
<br>&nbsp;blddbg.bat
<br>&nbsp;bldrel.bat
<br>&nbsp;include\ntp_machine.h
<br>&nbsp;xntpd\ntp_unixclock.c
<br>&nbsp;xntpd\ntp_refclock.c
<br>&nbsp;scripts\wininstall\build.bat
<br>&nbsp;scripts\wininstall\setup.rul
<br>&nbsp;scripts\wininstall\readme.nt
<br>&nbsp;scripts\wininstall\distrib\ntpog.wri
<br>&nbsp;html\hints\winnt (this file)
<p>In order to build the entire Windows NT distribution you
<br>need to modify the file scripts\wininstall\build.bat
<br>with the installation directory of the InstallShield
<br>software.&nbsp; Then, simply type "bldrel" for non-debug
<br>or "blddbg" for debug executables.
<p>Greg Schueman
<br>&nbsp;&nbsp;&nbsp; &lt;schueman@acm.org>
<h3>
Last revision:&nbsp; 07-May-1996</h3>
This set of changes fixes all known bugs, and it includes
<br>several major enhancements.
<p>Many changes have been made both to the build environment as
<br>well as the code.&nbsp; There is no longer an ntp.mak file, instead
<br>there is a buildntall.bat file that will build the entire
<br>release in one shot.&nbsp; The batch file requires Perl.&nbsp; Perl
<br>is easily available from the NT Resource Kit or on the Net.
<p>The multiple interface support was adapted from Larry Kahn's
<br>work on the BIND NT port.&nbsp; I have not been able to test it
<br>adequately as I only have NT servers with one network
<br>interfaces on which to test.
<p>Enhancements:
<br>* Event Logging now works correctly.
<br>* Version numbers now work (requires Perl during build)
<br>* Support for multiple network interface cards (untested)
<br>* NTP.CONF now default, but supports ntp.ini if not found
<br>* Installation procedure automated.
<br>* All paths now allow environment variables such as %windir%
<p>Bug fixes:
<br>* INSTSRV replaced, works correctly
<br>* Cleaned up many warnings
<br>* Corrected use of an uninitialized variable in XNTPD
<br>* Fixed ntpdate -b option
<br>* Fixed ntpdate to accept names as well as IP addresses
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Winsock WSAStartup was
called after a gethostbyname())
<br>* Fixed problem with "longjmp" in xntpdc/ntpdc.c that
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; caused a software exception
on doing a Control-C in xntpdc.
<br>&nbsp;A Cntrl-C now terminates the program.
<p>See below for more detail:
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: SIGINT is not supported for any
Win32 application including
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Windows NT and Windows 95. When a CTRL+C
interrupt occurs, Win32
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operating systems generate a new thread
to specifically handle that
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interrupt. This can cause a single-thread
application such as UNIX,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to become multithreaded, resulting in
unexpected behavior.
<br>&nbsp;
<p>Possible enhancements and things left to do:
<br>* Reference clock drivers for NT (at least Local Clock support)
<br>* Control Panel Applet
<br>* InstallShield based installation, like NT BIND has
<br>* Integration with NT Performance Monitor
<br>* SNMP integration
<br>* Fully test multiple interface support
<br>&nbsp;
<p>Known problems:
<br>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bug in ntptrace - if no Stratum
1 servers are available,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
such as on an IntraNet, the application crashes.
<h3>
Last revision:&nbsp; 12-Apr-1995</h3>
This NTPv3 distribution includes a sample configuration file and the project
<br>makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0
compiler.
<br>Also included is a small routine to install the NTP daemon as a "service"
<br>on a WindowsNT box. Besides xntpd, the utilities that have been ported
are
<br>ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using
a Bancomm
<br>TimeServe2000 GPS receiver clock that acts as a strata 1 NTP server
with no
<br>authentication (it has not been tested with any refclock drivers compiled
in).
<br>Following are the known flaws in this port:
<br>1) currently, I do not know of a way in NT to get information about
multiple
<br>&nbsp;&nbsp; network interface cards. The current port uses just one
socket bound to
<br>&nbsp;&nbsp; INADDR_ANY address. Therefore when dealing with a multihomed
NT time server,
<br>&nbsp;&nbsp; clients should point to the default address on the server
(otherwise the
<br>&nbsp;&nbsp; reply is not guaranteed to come from the same interface
to which the
<br>&nbsp;&nbsp; request was sent). Working with Microsoft to get this
resolved.
<br>2) There is some problem with "longjmp" in xntpdc/ntpdc.c that causes
a
<br>&nbsp;&nbsp; software exception on doing a Control-C in xntpdc. Be
patient!
<br>3) The error messages logged by xntpd currently contain only the numerical
<br>&nbsp;&nbsp; error code. Corresponding error message string has to
be looked up in
<br>&nbsp;&nbsp; "Books Online" on Visual C++ 2.0 under the topic "Numerical
List of Error
<br>&nbsp;&nbsp; Codes".
<p>Last HTML Update: November 17, 1999
<br><a href="mailto://sven_dietrich@trimble.com">Sven_Dietrich@Trimble.COM</a>
</body>
</html>

320
html/howto.htm
View File

@ -1,320 +0,0 @@
<html><head><title>
How to Write a Reference Clock Driver
</title></head><body><h3>
How to Write a Reference Clock Driver
</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>
<p>Reference clock support maintains the fiction that the clock is
actually an ordinary peer in the NTP tradition, but operating at a
synthetic stratum of zero. The entire suite of algorithms used to filter
the received data, select the best clocks or peers and combine them to
produce a local clock correction operate just like ordinary NTP peers.
In this way, defective clocks can be detected and removed from the peer
population. As no packets are exchanged with a reference clock; however,
the transmit, receive and packet procedures are replaced with separate
code to simulate them.
<p>Radio and modem reference clocks by convention have addresses in the
form <tt>127.127.<i>t</i>.<i>u</i></tt>, where <i>t</i> is the clock
type and <i>u</i> in the range 0-3 is used to distinguish multiple
instances of clocks of the same type. Most clocks require a serial port
or special bus peripheral. The particular device is normally specified
by adding a soft link <tt>/dev/device<i>d</i>d</tt> to the particular
hardware device involved, where <tt><i>d</i></tt> corresponds to the
unit number.
<p>The best way to understand how the clock drivers work is to study the
<tt>ntp_refclock.c</tt> module and one of the drivers already
implemented, such as <tt>refclock_wwvb.c</tt>. Routines
<tt>refclock_transmit()</tt> and <tt>refclock_receive()</tt> maintain
the peer variables in a state analogous to a network peer and pass
received data on through the clock filters. Routines
<tt>refclock_peer()</tt> and <tt>refclock_unpeer()</tt> are called to
initialize and terminate reference clock associations, should this ever
be necessary. A set of utility routines is included to open serial
devices, process sample data, edit input lines to extract embedded
timestamps and to perform various debugging functions.
<p>The main interface used by these routines is the
<tt>refclockproc</tt> structure, which contains for most drivers the
decimal equivalents of the year, day, month, hour, second and
millisecond/microsecond decoded from the ASCII timecode. Additional
information includes the receive timestamp, exception report, statistics
tallies, etc. The support routines are passed a pointer to the
<tt>peer</tt> structure, which is used for all peer-specific processing
and contains a pointer to the <tt>refclockproc</tt> structure, which in
turn contains a pointer to the unit structure, if used. For legacy
purposes, a table <tt>typeunit[type][unit]</tt> contains the peer
structure pointer for each configured clock type and unit.
<p>The reference clock interface supports auxiliary functions to support
in-stream timestamping, pulse-per-second (PPS) interfacing and precision
time kernel support. In most cases the drivers do not need to be aware
of them, since they are detected at autoconfigure time and loaded
automatically when the device is opened. These include the
<tt>tty_clk</tt> and <tt>ppsclock</tt> STREAMS modules and
<tt>ppsapi</tt> PPS interface described in the <a href="ldisc.htm">Line
Disciplines and Streams Modules</a> page. The <tt>tty_clk</tt> module
reduces latency errors due to the operating system and serial port code
in slower systems. The <tt>ppsclock</tt> module is an interface for the
PPS signal provided by some radios. The <tt>ppsapi</tt> PPS interface
replaces the <tt>ppsclock</tt> STREAMS module and is expected to become
the IETF standard cross-platform interface for PPS signals. In either
case, the PPS signal can be connected via a level converter/pulse
generator described in the <a href = "gadget.htm"> Gadget Box PPS Level
Converter and CHU Modem</a> page.
<p>By convention, reference clock drivers are named in the form
<tt>refclock_<i>xxxx</i>.c</tt>, where <i>xxxx</i> is a unique
string. Each driver is assigned a unique type number, long-form driver
name, short-form driver name, and device name. The existing assignments
are in the <a href="refclock.htm"> Reference Clock Drivers</a> page
and its dependencies. All drivers supported by the particular hardware
and operating system are automatically detected in the autoconfigure
phase and conditionally compiled. They are configured when the daemon is
started according to the configuration file, as described in the <a
href="config.htm"> Configuration Options </a> page.
<p>The standard clock driver interface includes a set of common support
routines some of which do such things as start and stop the device, open
the serial port, and establish special functions such as PPS signal
support. Other routines read and write data to the device and process
time values. Most drivers need only a little customizing code to, for
instance, transform idiosyncratic timecode formats to standard form,
poll the device as necessary, and handle exception conditions. A
standard interface is available for remote debugging and monitoring
programs, such as <tt>ntpq</tt> and <tt>ntpdc</tt>, as well as
the <tt>filegen</tt> facility, which can be used to record device
status on a continuous basis.
<p>The general organization of a typical clock driver includes a
receive-interrupt routine to read a timecode from the I/O buffer and
convert to internal format, generally in days, hours, minutes, seconds
and fraction. Some timecode formats include provisions for leap-second
warning and determine the clock hardware and software health. The
interrupt routine then calls <tt>refclock_process()</tt> with these data
and the timestamp captured at the on-time character of the timecode.
This routine saves each sample as received in a circular buffer, which
can store from a few up to 60 samples, in cases where the timecodes
arrive one per second.
<p>The <tt>refclock_transmit()</tt> routine in the interface is called
by the system at intervals defined by the poll interval in the peer
structure, generally 64 s. This routine in turn calls the transmit poll
routine in the driver. In the intended design, the driver calls the
<tt>refclock_receive()</tt> to process the offset samples that have
accumulated since the last poll and produce the final offset and
variance. The samples are processed by recursively discarding median
outlyers until about 60 percent of samples remain, then averaging the
surviving samples. When a reference clock must be explicitly polled to
produce a timecode, the driver can reset the poll interval so that the
poll routine is called a specified number of times at 1-s intervals.
<p>The interface code and this documentation have been developed over
some time and required not a little hard work converting old drivers,
etc. Should you find success writing a driver for a new radio or modem
service, please consider contributing it to the common good. Send the
driver file itself and patches for the other files to Dave Mills
(mills@udel.edu).
<h4>Conventions, Fudge Factors and Flags</h4>
<p>Most drivers support manual or automatic calibration for systematic
offset bias using values encoded in the <tt>fudge</tt> configuration
command. By convention, the <tt>time1</tt> value defines the calibration
offset in seconds. For those drivers that support statistics collection
using the <tt>filegen</tt> utility and the <tt>clockstats</tt> file, the
<tt>flag4</tt> switch enables the utility. 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. Should the PPS signal or the prefer
peer fail, the adjustment is frozen and the remaining drivers continue
to discipline the system clock with a minimum of residual error.
<h4>Files Which Need to be Changed</h4>
<p>A new reference clock implementation needs to supply, in addition to
the driver itself, several changes to existing files.
<dl>
<dt><tt>./include/ntp.h</tt>
<dd>The reference clock type defines are used in many places. Each
driver is assigned a unique type number. Unused numbers are clearly
marked in the list. A unique <tt>REFCLK_<i>xxxx</i></tt>
identification code should be recorded in the list opposite its assigned
type number.
<p><dt><tt>./libntp/clocktypes.c</tt>
<dd>The <tt>./libntp/clktype</tt> array is used by certain display
functions. A unique short-form name of the driver should be entered
together with its assigned identification code.
<p><dt><tt>./ntpd/ntp_control.c</tt>
<dd>The <tt>clocktypes</tt> array is used for certain control
message displays functions. It should be initialized with the reference
clock class assigned to the driver, as per the NTP specification
RFC-1305. See the <tt>./include/ntp_control.h</tt> header file for
the assigned classes.
<p><dt><tt>./ntpd/refclock_conf.c</tt>
<dd>This file contains a list of external structure definitions which
are conditionally defined. A new set of entries should be installed
similar to those already in the table. The <tt>refclock_conf</tt>
array is a set of pointers to transfer vectors in the individual
drivers. The external name of the transfer vector should be initialized
in correspondence with the type number.
<p><dt><tt>./acconfig.h</tt>
<dd>This is a configuration file used by the autoconfigure scheme. Add
two lines in the form:
<p><pre>
/* Define if we have a FOO clock */
#undef FOO
</pre>
<p>where FOO is the define used to cause the driver to be included in
the distribution.
<p><dt><tt>./configure.in</tt>
<dd>This is a configuration file used by the autoconfigure scheme. Add
lines similar to the following:
<p><pre>
AC_MSG_CHECKING(FOO clock_description)
AC_ARG_ENABLE(FOO, [ --enable-FOO clock_description],
[ntp_ok=$enableval], [ntp_ok=$ntp_eac])
if test "$ntp_ok" = "yes"; then
ntp_refclock=yes
AC_DEFINE(FOO)
fi
AC_MSG_RESULT($ntp_ok)
</pre>
<p>(Note that <tt>$ntp_eac</tt> is the value from <tt>--
{dis,en}able-all-clocks</tt> for non-PARSE clocks and
<tt>$ntp_eacp</tt> is the value from <tt>--{dis,en}able-parse-
clocks</tt> for PARSE clocks. See the documentation on the autoconf
and automake tools from the GNU distributions.)
<p><dt><tt>./ntpd/Makefile.am</tt>
<dd><p>This is the makefile prototype used by the autoconfigure scheme.
Add the driver file name to the entries already in the
<tt>ntpd_SOURCES</tt> list.
<p>Patches to <tt>automake-1.0</tt> are required for the
autoconfigure scripts to work properly. The file <tt>automake-
1.0.patches</tt> can be used for this purpose.
<p><dt><tt>./ntpd/Makefile.am</tt>
<dd>Do the following sequence of commands:
<p><pre>
automake
autoconf
autoheader
configure
</pre>
<p>or simply run <tt>make</tt>, which will do this command sequence
automatically.
</dl>
<p><h4>Interface Routine Overview</h4>
<dl>
<dt><tt>refclock_newpeer</tt> - initialize and start a reference
clock
<dd>This routine allocates and initializes the interface structure which
supports a reference clock in the form of an ordinary NTP peer. A
driver-specific support routine completes the initialization, if used.
Default peer variables which identify the clock and establish its
reference ID and stratum are set here. It returns one if success and
zero if the clock address is invalid or already running, insufficient
resources are available or the driver declares a bum rap.
<p><dt><tt>refclock_unpeer</tt> - shut down a clock
<dd>This routine is used to shut down a clock and return its resources
to the system.
<p><dt><tt>refclock_transmit</tt> - simulate the transmit procedure
<dd>This routine implements the NTP transmit procedure for a reference
clock. This provides a mechanism to call the driver at the NTP poll
interval, as well as provides a reachability mechanism to detect a
broken radio or other madness.
<p><dt><tt>refclock_sample</tt> - process a pile of samples from the
clock
<dd>This routine converts the timecode in the form days, hours, minutes,
seconds, milliseconds/microseconds to internal timestamp format. It then
calculates the difference from the receive timestamp and assembles the
samples in a shift register. It implements a recursive median filter to
suppress spikes in the data, as well as determine a rough dispersion
estimate. A configuration constant time adjustment
<tt>fudgetime1</tt> can be added to the final offset to compensate
for various systematic errors. The routine returns one if success and
zero if failure due to invalid timecode data or very noisy offsets.
<p>Note that no provision is included for the year, as provided by some
(but not all) radio clocks. Ordinarily, the year is implicit in the Unix
file system and hardware/software clock support, so this is ordinarily
not a problem. Nevertheless, the absence of the year should be
considered more a bug than a feature and may be supported in future.
<p><dt><tt>refclock_receive</tt> - simulate the receive and packet
procedures
<dd>This routine simulates the NTP receive and packet procedures for a
reference clock. This provides a mechanism in which the ordinary NTP
filter, selection and combining algorithms can be used to suppress
misbehaving radios and to mitigate between them when more than one is
available for backup.
<p><dt><tt>refclock_gtlin</tt> - groom next input line and extract
timestamp
<dd>This routine processes the timecode received from the clock and
removes the parity bit and control characters. If a timestamp is present
in the timecode, as produced by the <tt>tty_clk</tt> line
discipline/streams module, it returns that as the timestamp; otherwise,
it returns the buffer timestamp. The routine return code is the number
of characters in the line.
<p><dt><tt>refclock_open</tt> - open serial port for reference clock
<dd>This routine opens a serial port for I/O and sets default options.
It returns the file descriptor if success and zero if failure.
<p><dt><tt>refclock_ioctl</tt> - set serial port control functions
<dd>This routine attempts to hide the internal, system-specific details
of serial ports. It can handle POSIX (<tt>termios</tt>), SYSV
(<tt>termio</tt>) and BSD (<tt>sgtty</tt>) interfaces with
varying degrees of success. The routine sets up the <tt>tty_clk,
chu_clk</tt> and <tt>ppsclock</tt> streams module/line discipline,
if compiled in the daemon and requested in the call. The routine returns
one if success and zero if failure.
<p><dt><tt>refclock_control</tt> - set and/or return clock values
<dd>This routine is used mainly for debugging. It returns designated
values from the interface structure that can be displayed using ntpdc
and the clockstat command. It can also be used to initialize
configuration variables, such as <tt>fudgetimes, fudgevalues,</tt>
reference ID and stratum.
<p><dt><tt>refclock_buginfo</tt> - return debugging info
<dd>This routine is used mainly for debugging. It returns designated
values from the interface structure that can be displayed using
<tt>ntpdc</tt> and the <tt>clkbug</tt> command.
</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>

1198
html/htmlprimer.htm
View File

File diff suppressed because it is too large Load Diff

261
html/index.htm
View File

@ -1,261 +0,0 @@
<!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" 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">
</p>
<hr>
<h4>Introduction</h4>
Note: The software contained in this distribution is available
without charge under the conditions set forth in the <a href=
"copyright.htm">Copyright Notice</a>.
<p>The Network Time Protocol (NTP) is used to synchronize the time
of a computer client or server to another server or reference time
source, such as a radio or satellite receiver or modem. It provides
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 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>
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. 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.</p>
<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 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>
<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>
<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.
<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>
<ul>
<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="genkeys.htm"><tt>ntp-genkeys</tt> - generate public
and private keys</a></li>
</ul>
<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="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>
<ul>
<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">Kernel Model for Precision
Timekeeping</a></li>
<li><a href="kernpps.htm">Kernel Programming Interface for
Precision Time Signals</a></li>
</ul>
<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>

122
html/kern.htm
View File

@ -1,122 +0,0 @@
<!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>
<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>Exploding kernel<br clear="left">
</p>
<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.</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>

24
html/kernpps.htm
View File

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

89
html/ldisc.htm
View File

@ -1,89 +0,0 @@
<html><head><title>
Line Disciplines and Streams Modules
</title></head><body><h3>
Line Disciplines and Streams Modules
</h3><hr>
<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 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 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>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><tt>time_pps_create</tt>
<dd>Creates a PPS interface instance and returns a handle to it.</dd>
<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>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.
<h4><tt>tty_clk</tt> Line Discipline/Streams Module</h4>
<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>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 <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><tt>TIOCDCDTIMESTAMP</tt> ioctl in FreeBSD</h4>
<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 {
struct timeval tv;
u_int serial;
};
</pre>
<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><tt>TIOCSPPS</tt> and <tt>TIOCGETPPSEV</tt> ioctls in Solaris</h4>
<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>Users are cautioned that these ioctls function improperly in Solaris versions prior to 2.8 with patch Generic_108528-02.
<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
html/leap.htm
View File

@ -1,250 +0,0 @@
<!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>

17
html/measure.htm
View File

@ -1,17 +0,0 @@
<html><head><title>
Time and Time Interval Measurement with Application to Computer and
Network Performance Evaluation
</title></head><body><h3>
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>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>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>

279
html/miscopt.htm
View File

@ -1,279 +0,0 @@
<!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>
<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>
<p>We have three, now looking for more.<br clear="left">
</p>
<hr>
<dl>
<dt><tt>broadcastdelay <i>seconds</i></tt></dt>
<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>driftfile <i>driftfile</i></tt></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.
<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>
<dt><tt>enable [auth | bclient | calibrate | kernel | monitor | ntp
| stats]</tt><br>
<tt>disable [auth | bclient | calibrate | kernel | monitor | ntp |
stats</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>
<dl>
<dt><tt>bclient</tt></dt>
<dd>When enabled, this is identical to the <tt>broadcastclient</tt>
command. The default for this flag is <tt>disable</tt>.</dd>
<dt><tt>calibrate</tt></dt>
<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>
<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. The default for this flag is
<tt>enable</tt>.</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 <tt>enable</tt>.</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 <tt>enable</tt>.</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 <tt>enable</tt>.</dd>
</dl>
</dd>
<dt><tt>logconfig <i>configkeyword</i></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>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>
<dd>Thus, a minimal log configuration could look like this:
<p><tt>logconfig=syncstatus +sysevents</tt></p>
<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>
<p><tt>logconfig=syncall +clockall</tt></p>
<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>

255
html/monopt.htm
View File

@ -1,255 +0,0 @@
<html><head><title>
Monitoring Options
</title></head><body><h3>
Monitoring Options
</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>
<tt>ntpd</tt> includes a comprehensive monitoring facility suitable for
continuous, long term recording of server and client timekeeping
performance. See the <tt>statistics</tt> command below for a listing and
example of each type of statistics currently supported. Statistic files
are managed using file generation sets and scripts in the ./scripts
directory of this distribution. Using these facilities and Unix
<tt>cron</tt> jobs, the datacan be automatically summarized and archived
for retrospective analysis.
<h4>Monitoring Commands</h4>
<dl>
<dt><tt>statistics <I>name</I> [...]</tt></dt>
<dd>Enables writing of statistics records. Currently, four kinds of
<I><tt>name</tt></I>statistics are supported.</dd>
<dl>
<dt><tt>loopstats</tt></dt>
<dd>Enables recording of loop filter statistics information. Each update
of the local clock outputs a line of the following form to the file
generation set named <tt>loopstats</tt>:</dd>
<p><dd><tt>50935 75440.031 0.000006019 13.778190 0.000351733 0.013380
6</tt></dd>
<p><dd>The first two fields show the date (Modified Julian Day) and time
(seconds and fraction past UTC midnight). The next five fields show time
offset (seconds), frequency offset (parts per million - PPM), RMS jitter
(seconds), Allan deviation (PPM) and clock discipline time
constant.</dd>
<dt><tt>peerstats</tt></dt>
<dd>Enables recording of peer statistics information. This includes
statistics records of all peers of a NTP server and of special signals,
where present and configured. Each valid update appends a line of the
following form to the current element of a file generation set named
<tt>peerstats</tt>:</dd>
<p><dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605 0.00000
0.00142</tt></dd>
<p><dd>The first two fields show the date (Modified Julian Day) and time
(seconds and fraction past UTC midnight). The next two fields show the
peer address in dotted-quad notation and status, respectively. The
status field is encoded in hex in the format described in Appendix A of
the NTP specification RFC 1305. The final three fields show the offset,
delay and RMS jitter, all in seconds.</dd>
<dt><tt>clockstats</tt></dt>
<dd>Enables recording of clock driver statistics information. Each
update received from a clock driver appends a line of the following form
to the file generation set named <tt>clockstats</tt>:</dd>
<p><dd><tt>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</tt></dd>
<p><dd>The first two fields show the date (Modified Julian Day) and time
(seconds and fraction past UTC midnight). The next field shows the clock
address in dotted-quad notation, The final field shows the last timecode
received from the clock in decoded ASCII format, where meaningful. In
some clock drivers a good deal of additional information can be gathered
and displayed as well. See information specific to each clock for
further details.</dd>
<dt><tt>rawstats</tt></dt>
<dd>Enables recording of raw-timestamp statistics information. This
includes statistics records of all peers of a NTP server and of special
signals, where present and configured. Each NTP message received from a
peer or clock driver appends a line of the following form to the file
generation set named <tt>rawstats</tt>:</dd>
<p><dd><tt>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000
3102453281.58622800031 02453332.540806000 3102453332.541458000</tt></dd>
<p><dd>The first two fields show the date (Modified Julian Day) and time
(seconds and fraction past UTC midnight). The next two fields show the
remote peer or clock address followed by the local address in
dotted-quad notation, The final four fields show the originate, receive,
transmit and final NTP timestamps in order. The timestamp values are as
received and before processing by the various data smoothing and
mitigation algorithms.</dd>
</dl>
<dt><tt>statsdir <I>directory_path</I></tt></dt>
<dd>Indicates the full path of a directory where statistics files should
be created (see below). This keyword allows the (otherwise constant)
<tt>filegen</tt> filename prefix to be modified for file generation
sets, which is useful for handling statistics logs.</dd>
<dt><tt>filegen <I>name</I> [file <I>filename</I>] [type
<I>typename</I>] [link | nolink] [enable | disable]</tt></dt>
<dd>Configures setting of generation file set <I>name</I>. Generation
file sets provide a means for handling files that are continuously
growing during the lifetime of a server. Server statistics are a typical
example for such files. Generation file sets provide access to a set of
files used to store the actual data. At any time at most one element of
the set is being written to. The type given specifies when and how data
will be directed to a new element of the set. This way, information
stored in elements of a file set that are currently unused are available
for administrational operations without the risk of disturbing the
operation of <tt>ntpd</tt>. (Most important: they can be removed to free
space for new data produced.)</dd>
<dd>Note that this command can be sent from the <tt>ntpdc</tt> program
running at a remote location.</dd>
<dl>
<dt><I><tt>name</tt></I></dt>
<dd>This is the type of the statistics records, as shown in the
<tt>statistics</tt> command.</dd>
</dl>
<dd><tt>file <I>filename</I></tt></dd>
<dl>
<dd>This is the file name for the statistics records. Filenames of set
members are built from three concatenated elements
<I><tt>prefix</tt></I>, <I><tt>filename</tt></I> and
<I><tt>suffix</tt></I>:</dd>
<dl>
<dt><I><tt>prefix</tt></I></dt>
<dd>This is a constant filename path. It is not subject to modifications
via the <tt>filegen</tt> option. It is defined by the server, usually
specified as a compile-time constant. It may, however, be configurable
for individual file generation sets via other commands. For example, the
prefix used with <tt>loopstats</tt> and <tt>peerstats</tt> generation
can be configured using the <tt>statsdir</tt> option explained
above.</dd>
<dt><I><tt>filename</tt></I></dt>
<dd>This string is directly concatenated to the prefix mentioned above
(no intervening <tt>/</tt> (slash)). This can be modified using the
<tt>file</tt> argument to the <tt>filegen</tt> statement. No <tt>..</tt>
elements are allowed in this component to prevent filenames referring to
parts outside the filesystem hierarchy denoted by <tt>prefix</tt>.</dd>
<dt><I><tt>suffix</tt></I></dt>
<dd>This part is reflects individual elements of a file set. It is
generated according to the type of a file set.</dd>
</dl>
</dl>
<dd><tt>type <I>typename</I></tt></dd>
<dl>
<dd>A file generation set is characterized by its type. The following
types are supported:</dd>
<dl>
<dt><tt>none</tt></dt>
<dd>The file set is actually a single plain file.</dd>
<dt><tt>pid</tt></dt>
<dd>One element of file set is used per incarnation of a <tt>ntpd</tt>
server. This type does not perform any changes to file set members
during runtime, however it provides an easy way of separating files
belonging to different <tt>ntpd</tt> server incarnations. The set member
filename is built by appending a <tt>.</tt> (dot) to concatenated
<I>prefix</I> and <I>filename</I> strings, and appending the decimal
representation of the process ID of the <tt>ntpd</tt> server
process.</dd>
<dt><tt>day</tt></dt>
<dd>One file generation set element is created per day. A day is defined
as the period between 00:00 and 24:00 UTC. The file set member suffix
consists of a <tt>.</tt> (dot) and a day specification in the form
<tt>YYYYMMdd. YYYY</tt> is a 4-digit year number (e.g., 1992).
<tt>MM</tt> is a two digit month number. <tt>dd</tt> is a two digit day
number. Thus, all information written at 10 December 1992 would end up
in a file named <tt><I>prefix filename</I>.19921210</tt>.</dd>
<dt><tt>week</tt></dt>
<dd>Any file set member contains data related to a certain week of a
year. The term week is defined by computing day-of-year modulo 7.
Elements of such a file generation set are distinguished by appending
the following suffix to the file set filename base: A dot, a 4-digit
year number, the letter <tt>W</tt>, and a 2-digit week number. For
example, information from January, 10th 1992 would end up in a file with
suffix <tt>.1992W1</tt>.</dd>
<dt><tt>month</tt></dt>
<dd>One generation file set element is generated per month. The file
name suffix consists of a dot, a 4-digit year number, and a 2-digit
month.</dd>
<dt><tt>year</tt></dt>
<dd>One generation file element is generated per year. The filename
suffix consists of a dot and a 4 digit year number.</dd>
<dt><tt>age</tt></dt>
<dd>This type of file generation sets changes to a new element of the
file set every 24 hours of server operation. The filename suffix
consists of a dot, the letter <tt>a</tt>, and an 8-digit number. This
number is taken to be the number of seconds the server is running at the
start of the corresponding 24-hour period. Information is only written
to a file generation by specifying <tt>enable</tt>; output is prevented
by specifying <tt>disable</tt>.</dd>
</dl>
</dl>
<dd><tt>link | nolink</tt></dd>
<dl>
<dd>It is convenient to be able to access the current element of a file
generation set by a fixed name. This feature is enabled by specifying
<tt>link</tt> and disabled using <tt>nolink</tt>. If <tt>link</tt> is
specified, a hard link from the current file set element to a file
without suffix is created. When there is already a file with this name
and the number of links of this file is one, it is renamed appending a
dot, the letter <tt>C</tt>, and the pid of the <tt>ntpd</tt> server
process. When the number of links is greater than one, the file is
unlinked. This allows the current file to be accessed by a constant
name.</dd>
</dl>
<dd><tt>enable | disable</tt></dd>
<dl>
<dd>Enables or disables the recording function.</dd>
</dl>
</dl>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

443
html/mx4200data.htm
View File

@ -1,443 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<HTML>
<HEAD>
<TITLE>MX4200 Receiver Data Format</TITLE>
</HEAD>
<BODY>
<h1>MX4200 Receiver Data Format</h1>
<hr>
<h2>Table of Contents</h2>
<ul>
<li><a href="#control">Control Port Sentences</a></li>
<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>
</ul>
<li><a href="#output">Control Port Output Sentences</a></li>
<ul>
<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>
<hr>
<h2><a name="control">Control Port Sentences</a></h2>
<p>The Control (CDU) Port is used to initialize, monitor, and control
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
Association</a>.</p>
<p>Reserved characters are used to indicate the beginning and the end
of records in the data stream, and to delimit data fields within a
sentence. Only printable ASCII characters (Hex 20 through 7F) may be
used in a sentence. <a href="#table_2">Table 2</a> lists the reserved
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>
<code>
$PMVXG,XXX,...................*CK
</code>
<p>
<table border>
<tr> <th>Character <th>Meaning
<tr> <td><code>$</code> <td>Sentence Start Character
<tr> <td><code>P</code> <td>Special ID (P = Proprietary)
<tr> <td><code>MVX</code> <td>Originator ID (MVX = Magnavox)
<tr> <td><code>G</code> <td>Interface ID (G = GPS)
<tr> <td><code>XXX</code> <td>Sentence Type
<tr> <td><code>...</code> <td>Data
<tr> <td><code>*</code> <td>Optional Checksum Field Delimiter
<tr> <td><code>CK</code> <td>Optional Checksum
</table>
<h4><a name="table_2">Table 2. NMEA Sentence Reserved Characters</a></h4>
<table border>
<tr> <th>Character <th>Hex Value <th>Usage
<tr> <td><code>$</code> <td>24 <td>Start of Sentence Identifier
<tr> <td><code>{cr}{lf}</code> <td>0D 0A <td>End of Sentence Identifier
<tr> <td><code>,</code> <td>2C <td>Sentence Delimiter
<tr> <td><code>*</code> <td>2A <td>Optional Checksum Field Delimiter
</table>
<p>Following the start character <code>$</code>, are five characters
which constitute the block label of the sentence. For Magnavox
proprietary sentences, this label is always <code>PMVXG</code>. The
next field after the block label is the sentence type, consisting of
three decimal digits.</p>
<p>The data, delimited by commas, follows the sentence type. Note that
the receiver uses a free-format parsing algorithm, so you need not send
the exact number of characters shown in the examples. You will need to
use the commas to determine how many bytes of data need to be
retrieved.</p>
<p>The notation <code>CK</code> shown in <a href="#table_1">Table 1</a>
symbolically indicates the optional checksum in the examples. The
checksum is computed by exclusive-ORing all of the bytes between the
<code>$</code> and the <code>*</code> characters. The <code>$</code> ,
<code>*</code> and the checksum are not included in the checksum
computation.</p>
<p>Checksums are optional for Control Port input sentences, but are
highly recommended to limit the effects of communication errors.
Magnavox receivers always generate checksums for Control Port output
sentences.</p>
<p>ASCII data characters are transmitted in the following format:</p>
<table border>
<tr> <td> Data Bits <td>8 (msb always 0)
<tr> <td> Parity <td>None
<tr> <td> Stop Bits <td>1
</table>
<p>NULL fields are fields which do not contain any data. They would
appear as two commas together in the sentence format, except for the
final field. Some Magnavox proprietary sentences require that the
format contain NULL fields. mandatory NULL fields are identified by an
'*' next to the respective field.</p>
<hr>
<h2><a name="input">Control Port Input Sentences</a></h2>
These are the subset of the MX4200 control port input sentences sent by
the NTP driver to the GPS receiver.
<hr>
<h3><a name="input_000">$PMVXG,000</a></h3>
<h4>Initialization/Mode Control - Part A</h4>
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>&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>&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>&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>&nbsp <td>&nbsp <td>&nbsp <td>&nbsp
</table>
Example:<br>
<code>$PMVXG,000,,,,,,,,,,*48</code><br>
<code>$PMVXG,000,,,,,5128.4651,N,00020.0715,W,58.04,*4F</code>
<hr>
<h3><a name="input_001">$PMVXG,001</a></h3>
<h4>Initialization/Mode Control - Part B</h4>
Specifies various navigation parameters: Altitude aiding, acceleration
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>&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>&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>&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>
<code>$PMVXG,001,3,,0.1,0.1,10,10,5,U,0*06</code>
<hr>
<h3><a name="input_007">$PMVXG,007</a></h3>
<h4>Control Port Output Configuration</h4>
This message enables or disables output of the specified sentence and
defines the output rate. The user sends this message for each sentence
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>&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>
<hr>
<h3><a name="input_023">$PMVXG,023</a></h3>
<h4>Time Recovery Configuration</h4>
This message is used to enable/disable the time recovery feature of the
receiver. The time synchronization for the 1PPS output is specified in
addition to a user time bias and an error tolerance for a valid pulse.
This record is accepted in units configured for time recovery. If the
back panel contains a 1PPS outlet, the receiver is a time recovery
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>&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>&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>
<hr>
<h3><a name="input_gpq">$CDGPQ,YYY</a></h3>
<h4>Query From a Remote Device / Request to Output a Sentence</h4>
Enables the controller to request a one-time transmission of a specific
block label. To output messages at a periodic rate, refer to input
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>&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>
<hr>
<h2><a name="output">Control Port Output Sentences</a></h2>
These are the subset of the MX4200 control port output sentences
recognized by the NTP driver.
<hr>
<h3><a name="output_000">$PMVXG,000</a></h3>
<h4>Receiver Status</h4>
Returns the current status of the receiver including the operating
mode, number of satellites visible, and the number of satellites being
tracked.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<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>&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>
<hr>
<h3><a name="output_021">$PMVXG,021</a></h3>
<h4>Position, Height, Velocity</h4>
This sentence gives the receiver position, height, navigation mode and
velocity north/east. <em>This sentence is intended for post analysis
applications.</em>
<p>
<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>WGS-84 Latitude <td>DDMM.MMMM<td>Float <td>0-89.9999
<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>&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>
4=2D differential<br>
5=3D differential<br>
<em>Not Navigating</em><br>
51=Too Few Satellites<br>
52=DOPs too large<br>
53=Position STD too large<br>
54=Velocity STD too large<br>
55=Too many iterations for velocity<br>
56=Too many iterations for position<br>
57=3 Sat Startup failed
</table>
Example:<br>
<code>$PMVXG,021,142244.00,5128.4744,N,00020.0593,W,00054.4,0047.4,0000.1,-000.2,03*66</code>
<hr>
<h3><a name="output_022">$PMVXG,022</a></h3>
<h4>DOPs</h4>
This sentence reports the DOP (Dilution Of Precision) values actually
used in the measurement processing corresponding to the satellites
listed. The satellites are listed in receiver channel order. Fields
11-16 are output only on 12-channel receivers.
<p>
<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>&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>
<hr>
<h3><a name="output_030">$PMVXG,030</a></h3>
<h4>Software Configuration</h4>
This sentence contains the navigation processor and baseband firmware
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>&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>
<hr>
<h3><a name="output_101">$PMVXG,101</a></h3>
<h4>Control Sentence Accept/Reject</h4>
This sentence is returned (on the Control Port) for every
<strong>$PMVXG</strong> and <strong>$XXGPQ</strong> sentence that is
received.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<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>&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>
<hr>
<h3><a name="output_523">$PMVXG,523</a></h3>
<h4>Time Recovery Configuration</h4>
This sentence contains the configuration of the time recovery function
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>&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>
<hr>
<h3><a name="output_830">$PMVXG,830</a></h3>
<h4>Time Recovery Results</h4>
This sentence is output approximately 1 second preceding the 1PPS
output. It indicates the exact time of the next pulse, whether or not
the time mark will be valid (based on operator-specified error
tolerance), the time to which the pulse is synchronized, the receiver
operating mode, and the time error of the <strong>last</strong> 1PPS
output. The leap second flag (Field #11) is not output by older
receivers.
<p>
<table border>
<tr> <th>Field <th>Description <th>Units <th>Format <th>Range
<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>&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>&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>
<hr>
</BODY>
</HTML>

1547
html/notes.htm
View File

File diff suppressed because it is too large Load Diff

457
html/ntpd.htm
View File

@ -1,457 +0,0 @@
<!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>
<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>
<p>The mushroom knows all the command line options.<br clear=
"left">
</p>
<hr>
<h4>Synopsis</h4>
<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>
<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.</p>
<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>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>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>
<h4>Poll Interval Control</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>
<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>
<h4>The huff-n'-puff filter</h4>
<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>
<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>
<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>
<h4>Notes</h4>
<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>
<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>
<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>
<h4>Command Line Options</h4>
<dl>
<dt><tt>-a</tt></dt>
<dd>Enable authentication mode (default).</dd>
<dt><tt>-A</tt></dt>
<dd>Disable authentication mode.</dd>
<dt><tt>-b</tt></dt>
<dd>Synchronize using NTP broadcast messages.</dd>
<dt><tt>-c <i>conffile</i></tt></dt>
<dd>Specify the name and path of the configuration file. (Disable
netinfo?)</dd>
<dt><tt>-d</tt></dt>
<dd>Specify debugging mode. This flag may occur multiple times,
with each occurrence indicating greater detail of display.</dd>
<dt><tt>-D <i>level</i></tt></dt>
<dd>Specify debugging level directly.</dd>
<dt><tt>-f <i>driftfile</i></tt></dt>
<dd>Specify the name and path of the drift file.</dd>
<dt><tt>-g</tt></dt>
<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>
<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>

186
html/ntpdate.htm
View File

@ -1,186 +0,0 @@
<!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>
<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>
<p>I told you it was eyeball and wristwatch.<br clear="left">
</p>
<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>
<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><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>
<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>
<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>
<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>
<h4>Command Line Options</h4>
<dl>
<dt><tt>-a <i>key</i></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>
<dt><tt>-B</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>
<dt><tt>-b</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>
<dt><tt>-d</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>
<dt><tt>-e <i>authdelay</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>
<dt><tt>-k <i>keyfile</i></tt></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>
<dt><tt>-o <i>version</i></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>
<dt><tt>-p <i>samples</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>
<dt><i><tt>-q</tt></i></dt>
<dd>Query only - don't set the clock.</dd>
<dt><tt>-s</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>
<dt><tt>-t <i>timeout</i></tt></dt>
<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>

573
html/ntpdc.htm
View File

@ -1,573 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntpdc - special NTP query program</title>
</head>
<body>
<h3><tt>ntpdc</tt> - special NTP query program</h3>
<img align="left" src="pic/alice31.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>This program is a big puppy.<br clear="left">
</p>
<hr>
<h4>Synopsis</h4>
<tt>ntpdc [ -ilnps ] [ -c <i>command</i> ] [ <i>host</i> ] [ ...
]</tt>
<h4>Description</h4>
<tt>ntpdc</tt> is used to query the <tt>ntpd</tt> daemon about its
current state and to request changes in that state. The program may
be run either in interactive mode or controlled using command line
arguments. Extensive state and statistics information is available
through the <tt>ntpdc</tt> interface. In addition, nearly all the
configuration options which can be specified at startup using
ntpd's configuration file may also be specified at run time using
<tt>ntpdc</tt>.
<p>If one or more request options are included on the command line
when <tt>ntpdc</tt> is executed, each of the requests will be sent
to the NTP servers running on each of the hosts given as command
line arguments, or on localhost by default. If no request options
are given, <tt>ntpdc</tt> will attempt to read commands from the
standard input and execute these on the NTP server running on the
first host given on the command line, again defaulting to localhost
when no other host is specified. <tt>ntpdc</tt> will prompt for
commands if the standard input is a terminal device.</p>
<p><tt>ntpdc</tt> uses NTP mode 7 packets to communicate with the
NTP server, and hence can be used to query any compatable server on
the network which permits it. Note that since NTP is a UDP protocol
this communication will be somewhat unreliable, especially over
large distances in terms of network topology. <tt>ntpdc</tt> makes
no attempt to retransmit requests, and will time requests out if
the remote host is not heard from within a suitable timeout
time.</p>
<p>The operation of <tt>ntpdc</tt> are specific to the particular
implementation of the <tt>ntpd</tt> daemon and can be expected to
work only with this and maybe some previous versions of the daemon.
Requests from a remote <tt>ntpdc</tt> program which affect the
state of the local server must be authenticated, which requires
both the remote program and local server share a common key and key
identifier.</p>
<h4>Command Line Options</h4>
Specifying a command line option other than <tt>-i</tt> or <tt>
-n</tt> will cause the specified query (queries) to be sent to the
indicated host(s) immediately. Otherwise, <tt>ntpdc</tt> will
attempt to read interactive format commands from the standard
input.
<dl>
<dt><tt>-c <i>command</i></tt></dt>
<dd>The following argument is interpreted as an interactive format
command and is added to the list of commands to be executed on the
specified host(s). Multiple -c options may be given.</dd>
<dt><tt>-i</tt></dt>
<dd>Force <tt>ntpdc</tt> to operate in interactive mode. Prompts
will be written to the standard output and commands read from the
standard input.</dd>
<dt><tt>-l</tt></dt>
<dd>Obtain a list of peers which are known to the server(s). This
switch is equivalent to <tt>-c listpeers</tt>.</dd>
<dt><tt>-n</tt></dt>
<dd>Output all host addresses in dotted-quad numeric format rather
than converting to the canonical host names.</dd>
<dt><tt>-p</tt></dt>
<dd>Print a list of the peers known to the server as well as a
summary of their state. This is equivalent to <tt>-c
peers</tt>.</dd>
<dt><tt>-s</tt></dt>
<dd>Print a list of the peers known to the server as well as a
summary of their state, but in a slightly different format than the
-p switch. This is equivalent to <tt>-c dmpeers</tt>.</dd>
</dl>
<h4>Interactive Commands</h4>
Interactive format commands consist of a keyword followed by zero
to four arguments. Only enough characters of the full keyword to
uniquely identify the command need be typed. The output of a
command is normally sent to the standard output, but optionally the
output of individual commands may be sent to a file by appending a
<tt>&lt;</tt>, followed by a file name, to the command line.
<p>A number of interactive format commands are executed entirely
within the <tt>ntpdc</tt> program itself and do not result in NTP
mode 7 requests being sent to a server. These are described
following.</p>
<dl>
<dt><tt>? [ <i>command_keyword</i> ]</tt><br>
<tt>help [ <i>command_keyword</i> ]</tt></dt>
<dd>A <tt>?</tt> by itself will print a list of all the command
keywords known to this incarnation of <tt>ntpq</tt>. A <tt>?</tt>
followed by a command keyword will print funcation and usage
information about the command. This command is probably a better
source of information about <tt>ntpq</tt> than this manual
page.</dd>
<dt><tt>delay <i>milliseconds</i></tt></dt>
<dd>Specify a time interval to be added to timestamps included in
requests which require authentication. This is used to enable
(unreliable) server reconfiguration over long delay network paths
or between machines whose clocks are unsynchronized. Actually the
server does not now require timestamps in authenticated requests,
so this command may be obsolete.</dd>
<dt><tt>host <i>hostname</i></tt></dt>
<dd>Set the host to which future queries will be sent. Hostname may
be either a host name or a numeric address.</dd>
<dt><tt>hostnames [ yes | no ]</tt></dt>
<dd>If <tt>yes</tt> is specified, host names are printed in
information displays. If <tt>no</tt> is specified, numeric
addresses are printed instead. The default is <tt>yes</tt>, unless
modified using the command line <tt>-n</tt> switch.</dd>
<dt><tt>keyid <i>keyid</i></tt></dt>
<dd>This command allows the specification of a key number to be
used to authenticate configuration requests. This must correspond
to a key number the server has been configured to use for this
purpose.</dd>
<dt><tt>quit</tt></dt>
<dd>Exit <tt>ntpdc</tt>.</dd>
<dt><tt>passwd</tt></dt>
<dd>This command prompts you to type in a password (which will not
be echoed) which will be used to authenticate configuration
requests. The password must correspond to the key configured for
use by the NTP server for this purpose if such requests are to be
successful.</dd>
<dt><tt>timeout <i>millseconds</i></tt></dt>
<dd>Specify a timeout period for responses to server queries. The
default is about 8000 milliseconds. Note that since <tt>ntpdc</tt>
retries each query once after a timeout, the total waiting time for
a timeout will be twice the timeout value set.</dd>
</dl>
<h4>Control Message Commands</h4>
Query commands result in NTP mode 7 packets containing requests for
information being sent to the server. These are read-only commands
in that they make no modification of the server configuration
state.
<dl>
<dt><tt>listpeers</tt></dt>
<dd>Obtains and prints a brief list of the peers for which the
server is maintaining state. These should include all configured
peer associations as well as those peers whose stratum is such that
they are considered by the server to be possible future
synchonization candidates.</dd>
<dt><tt>peers</tt></dt>
<dd>Obtains a list of peers for which the server is maintaining
state, along with a summary of that state. Summary information
includes the address of the remote peer, the local interface
address (0.0.0.0 if a local address has yet to be determined), the
stratum of the remote peer (a stratum of 16 indicates the remote
peer is unsynchronized), the polling interval, in seconds, the
reachability register, in octal, and the current estimated delay,
offset and dispersion of the peer, all in seconds.
<p>The character in the left margin indicates the mode this peer
entry is operating in. A <tt>+</tt> denotes symmetric active, a
<tt>-</tt> indicates symmetric passive, a <tt>=</tt> means the
remote server is being polled in client mode, a <tt>^</tt>
indicates that the server is broadcasting to this address, a <tt>
~</tt> denotes that the remote peer is sending broadcasts and a
<tt>*</tt> marks the peer the server is currently synchonizing
to.</p>
<p>The contents of the host field may be one of four forms. It may
be a host name, an IP address, a reference clock implementation
name with its parameter or <tt>REFCLK(<i>implementation number</i>,
<i>parameter</i>)</tt>. On <tt>hostnames no</tt> only IP-addresses
will be displayed.</p>
</dd>
<dt><tt>dmpeers</tt></dt>
<dd>A slightly different peer summary list. Identical to the output
of the <tt>peers</tt> command, except for the character in the
leftmost column. Characters only appear beside peers which were
included in the final stage of the clock selection algorithm. A
<tt>.</tt> indicates that this peer was cast off in the falseticker
detection, while a <tt>+</tt> indicates that the peer made it
through. A <tt>*</tt> denotes the peer the server is currently
synchronizing with.</dd>
<dt><tt>showpeer <i>peer_address</i> [...]</tt></dt>
<dd>Shows a detailed display of the current peer variables for one
or more peers. Most of these values are described in the NTP
Version 2 specification.</dd>
<dt><tt>pstats <i>peer_address</i> [...]</tt></dt>
<dd>Show per-peer statistic counters associated with the specified
peer(s).</dd>
<dt><tt>clockinfo <i>clock_peer_address</i> [...]</tt></dt>
<dd>Obtain and print information concerning a peer clock. The
values obtained provide information on the setting of fudge factors
and other clock performance information.</dd>
<dt><tt>kerninfo</tt></dt>
<dd>Obtain and print kernel phase-lock loop operating parameters.
This information is available only if the kernel has been specially
modified for a precision timekeeping function.</dd>
<dt><tt>loopinfo [ oneline | multiline ]</tt></dt>
<dd>Print the values of selected loop filter variables. The loop
filter is the part of NTP which deals with adjusting the local
system clock. The <tt>offset</tt> is the last offset given to the
loop filter by the packet processing code. The <tt>frequency</tt>
is the frequency error of the local clock in parts-per-million
(ppm). The <tt>time_const</tt> controls the stiffness of the
phase-lock loop and thus the speed at which it can adapt to
oscillator drift. The <tt>watchdog timer</tt> value is the number
of seconds which have elapsed since the last sample offset was
given to the loop filter. The <tt>oneline</tt> and <tt>
multiline</tt> options specify the format in which this information
is to be printed, with <tt>multiline</tt> as the default.</dd>
<dt><tt>sysinfo</tt></dt>
<dd>Print a variety of system state variables, i.e., state related
to the local server. All except the last four lines are described
in the NTP Version 3 specification, RFC-1305.
<p>The <tt>system flags</tt> show various system flags, some of
which can be set and cleared by the <tt>enable</tt> and <tt>
disable</tt> configuration commands, respectively. These are the
<tt>auth</tt>, <tt>bclient</tt>, <tt>monitor</tt>, <tt>pll</tt>,
<tt>pps</tt> and <tt>stats</tt> flags. See the <tt>ntpd</tt>
documentation for the meaning of these flags. There are two
additional flags which are read only, the <tt>kernel_pll</tt> and
<tt>kernel_pps</tt>. These flags indicate the synchronization
status when the precision time kernel modifications are in use. The
<tt>kernel_pll</tt> indicates that the local clock is being
disciplined by the kernel, while the kernel_pps indicates the
kernel discipline is provided by the PPS signal.</p>
<p>The <tt>stability</tt> is the residual frequency error remaining
afterthe system frequency correction is applied and is intended for
maintenance and debugging. In most architectures, this value will
initially decrease from as high as 500 ppm to a nominal value in
the range .01 to 0.1 ppm. If it remains high for some time after
starting the daemon, something may be wrong with the local clock,
or the value of the kernel variable <tt>tick</tt> may be
incorrect.</p>
<p>The <tt>broadcastdelay</tt> shows the default broadcast delay,
as set by the <tt>broadcastdelay</tt> configuration command.</p>
<p>The <tt>authdelay</tt> shows the default authentication delay,
as set by the <tt>authdelay</tt> configuration command.</p>
</dd>
<dt><tt>sysstats</tt></dt>
<dd>Print statistics counters maintained in the protocol
module.</dd>
<dt><tt>memstats</tt></dt>
<dd>Print statistics counters related to memory allocation
code.</dd>
<dt><tt>iostats</tt></dt>
<dd>Print statistics counters maintained in the input-output
module.</dd>
<dt><tt>timerstats</tt></dt>
<dd>Print statistics counters maintained in the timer/event queue
support code.</dd>
<dt><tt>reslist</tt></dt>
<dd>Obtain and print the server's restriction list. This list is
(usually) printed in sorted order and may help to understand how
the restrictions are applied.</dd>
<dt><tt>monlist [ <i>version</i> ]</tt></dt>
<dd>Obtain and print traffic counts collected and maintained by the
monitor facility. The version number should not normally need to be
specified.</dd>
<dt><tt>clkbug <i>clock_peer_address</i> [...]</tt></dt>
<dd>Obtain debugging information for a reference clock driver. This
information is provided only by some clock drivers and is mostly
undecodable without a copy of the driver source in hand.</dd>
</dl>
<h4>Runtime Configuration Requests</h4>
All requests which cause state changes in the server are
authenticated by the server using a configured NTP key (the
facility can also be disabled by the server by not configuring a
key). The key number and the corresponding key must also be made
known to xtnpdc. This can be done using the keyid and passwd
commands, the latter of which will prompt at the terminal for a
password to use as the encryption key. You will also be prompted
automatically for both the key number and password the first time a
command which would result in an authenticated request to the
server is given. Authentication not only provides verification that
the requester has permission to make such changes, but also gives
an extra degree of protection again transmission errors.
<p>Authenticated requests always include a timestamp in the packet
data, which is included in the computation of the authentication
code. This timestamp is compared by the server to its receive time
stamp. If they differ by more than a small amount the request is
rejected. This is done for two reasons. First, it makes simple
replay attacks on the server, by someone who might be able to
overhear traffic on your LAN, much more difficult. Second, it makes
it more difficult to request configuration changes to your server
from topologically remote hosts. While the reconfiguration facility
will work well with a server on the local host, and may work
adequately between time-synchronized hosts on the same LAN, it will
work very poorly for more distant hosts. As such, if reasonable
passwords are chosen, care is taken in the distribution and
protection of keys and appropriate source address restrictions are
applied, the run time reconfiguration facility should provide an
adequate level of security.</p>
<p>The following commands all make authenticated requests.</p>
<dl>
<dt><tt>addpeer <i>peer_address</i> [ <i>keyid</i> ] [ <i>
version</i> ] [ <i>prefer</i> ]</tt></dt>
<dd>Add a configured peer association at the given address and
operating in symmetric active mode. Note that an existing
association with the same peer may be deleted when this command is
executed, or may simply be converted to conform to the new
configuration, as appropriate. If the optional <tt>keyid</tt> is a
nonzero integer, all outgoing packets to the remote server will
have an authentication field attached encrypted with this key. If
the value is 0 (or not given) no authentication will be done. The
<tt>version#</tt> can be 1, 2 or 3 and defaults to 3. The <tt>
prefer</tt> keyword indicates a preferred peer (and thus will be
used primarily for clock synchronisation if possible). The
preferred peer also determines the validity of the PPS signal - if
the preferred peer is suitable for synchronisation so is the PPS
signal.</dd>
<dt><tt>addserver <i>peer_address</i> [ <i>keyid</i> ] [ <i>
version</i> ] [ <i>prefer</i> ]</tt></dt>
<dd>Identical to the addpeer command, except that the operating
mode is client.</dd>
<dt><tt>broadcast <i>peer_address</i> [ <i>keyid</i> ] [ <i>
version</i> ] [ <i>prefer</i> ]</tt></dt>
<dd>Identical to the addpeer command, except that the operating
mode is broadcast. In this case a valid key identifier and key are
required. The <tt>peer_address</tt> parameter can be the broadcast
address of the local network or a multicast group address assigned
to NTP. If a multicast address, a multicast-capable kernel is
required.</dd>
<dt><tt>unconfig <i>peer_address</i> [...]</tt></dt>
<dd>This command causes the configured bit to be removed from the
specified peer(s). In many cases this will cause the peer
association to be deleted. When appropriate, however, the
association may persist in an unconfigured mode if the remote peer
is willing to continue on in this fashion.</dd>
<dt><tt>fudge <i>peer_address</i> [ <i>time1</i> ] [ <i>time2</i> ]
[ <i>stratum</i> ] [ <i>refid</i> ]</tt></dt>
<dd>This command provides a way to set certain data for a reference
clock. See the source listing for further information.</dd>
<dt><tt>enable [ <i>flag</i> ] [ ... ]</tt><br>
<tt>disable [ <i>flag</i> ] [ ... ]</tt></dt>
<dd>These commands operate in the same way as the <tt>enable</tt>
and <tt>disable</tt> configuration file commands of <tt>ntpd</tt>.
Following is a description of the flags. Note that only the <tt>
auth</tt>, <tt>bclient</tt>, <tt>monitor</tt>, <tt>pll</tt>, <tt>
pps</tt> and <tt>stats</tt> flags can be set by <tt>ntpdc</tt>; the
<tt>pll_kernel</tt> and <tt>pps_kernel</tt> flags are
read-only.</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>
<dt><tt>bclient</tt></dt>
<dd>Enables the server to listen for a message from a broadcast or
multicast server, as in the <tt>multicastclient</tt> command with
default address. The default for this flag is disable.</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>
<dt><tt>pll</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 is used. See the <a href="refclock.htm">Reference
Clock Drivers</a> page for further information. The default for
this flag is enable.</dd>
<dt><tt>pps</tt></dt>
<dd>Enables the pulse-per-second (PPS) signal when frequency and
time is disciplined by the precision time kernel modifications. See
the <a href="kern.htm">A Kernel Model for Precision Timekeeping</a>
page for further information. The default for this flag is
disable.</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>
<dt><tt>pll_kernel</tt></dt>
<dd>When the precision time kernel modifications are installed,
this indicates the kernel controls the clock discipline; otherwise,
the daemon controls the clock discipline.</dd>
<dt><tt>pps_kernel</tt></dt>
<dd>When the precision time kernel modifications are installed and
a pulse-per-second (PPS) signal is available, this indicates the
PPS signal controls the clock discipline; otherwise, the daemon or
kernel controls the clock discipline, as indicated by the <tt>
pll_kernel</tt> flag.</dd>
</dl>
</dd>
<dt><tt>restrict <i>address mask flag</i> [ <i>flag</i> ]</tt></dt>
<dd>This command operates in the same way as the <tt>restrict</tt>
configuration file commands of <tt>ntpd</tt>.</dd>
<dt><tt>unrestrict <i>address mask flag</i> [ <i>flag</i>
]</tt></dt>
<dd>Unrestrict the matching entry from the restrict list.</dd>
<dt><tt>delrestrict <i>address mask [ ntpport ]</i></tt></dt>
<dd>Delete the matching entry from the restrict list.</dd>
<dt><tt>readkeys</tt></dt>
<dd>Causes the current set of authentication keys to be purged and
a new set to be obtained by rereading the keys file (which must
have been specified in the <tt>ntpd</tt> configuration file). This
allows encryption keys to be changed without restarting the
server.</dd>
<dt><tt>trustedkey <i>keyid</i> [...]</tt></dt>
<dt><tt>untrustedkey <i>keyid</i> [...]</tt></dt>
<dd>These commands operate in the same way as the <tt>
trustedkey</tt> and <tt>untrustedkey</tt> configuration file
commands of <tt>ntpd</tt>.</dd>
<dt><tt>authinfo</tt></dt>
<dd>Returns information concerning the authentication module,
including known keys and counts of encryptions and decryptions
which have been done.</dd>
<dt><tt>traps</tt></dt>
<dd>Display the traps set in the server. See the source listing for
further information.</dd>
<dt><tt>addtrap [ <i>address</i> [ <i>port</i> ] [ <i>interface</i>
]</tt></dt>
<dd>Set a trap for asynchronous messages. See the source listing
for further information.</dd>
<dt><tt>clrtrap [ <i>address</i> [ <i>port</i> ] [ <i>
interface</i>]</tt></dt>
<dd>Clear a trap for asynchronous messages. See the source listing
for further information.</dd>
<dt><tt>reset</tt></dt>
<dd>Clear the statistics counters in various modules of the server.
See the source listing for further information.</dd>
</dl>
<h4>Bugs</h4>
<tt>ntpdc</tt> is a crude hack. Much of the information it shows is
deadly boring and could only be loved by its implementer. The
program was designed so that new (and temporary) features were easy
to hack in, at great expense to the program's ease of use. Despite
this, the program is occasionally useful.
<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>

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