Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

resolve conflicts 

(in this case, throw away all local modifications; I'll start patching
from scratch)
This commit is contained in:
drochner 2003-12-04 16:23:34 +00:00
parent b21928a34e
commit d5e6f1b80b
445 changed files with 36833 additions and 39400 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
dist/ntp/ElectricFence/efence.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: efence.c,v 1.1.1.1 2003/12/04 16:05:20 drochner Exp $ */
/* $NetBSD: efence.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/*
* Electric Fence - Red-Zone memory allocator.

2
dist/ntp/ElectricFence/efence.h vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: efence.h,v 1.1.1.1 2003/12/04 16:05:20 drochner Exp $ */
/* $NetBSD: efence.h,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
#include <sys/types.h>
#include <sys/param.h>

2
dist/ntp/ElectricFence/eftest.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: eftest.c,v 1.1.1.1 2003/12/04 16:05:20 drochner Exp $ */
/* $NetBSD: eftest.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
#include <stdlib.h>
#include <stdio.h>

2
dist/ntp/ElectricFence/page.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: page.c,v 1.1.1.1 2003/12/04 16:05:20 drochner Exp $ */
/* $NetBSD: page.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
#ifdef HAVE_CONFIG_H
# include <config.h>

2
dist/ntp/ElectricFence/print.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: print.c,v 1.1.1.1 2003/12/04 16:05:20 drochner Exp $ */
/* $NetBSD: print.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
#include "efence.h"
#include <stdlib.h>

2
dist/ntp/ElectricFence/tstheap.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: tstheap.c,v 1.1.1.1 2003/12/04 16:05:20 drochner Exp $ */
/* $NetBSD: tstheap.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
#include <stdlib.h>
#include <stdio.h>

24
dist/ntp/README.cvs vendored
View File

@ -1,24 +0,0 @@
To get the NTP distribution via anonymous CVS:
cvs -d :pserver:anoncvs@www.ntp.org:/cvs/ntp login
the password is: anoncvs
cvs -d :pserver:anoncvs@www.ntp.org:/cvs/ntp co ntp
after which the "ntp_update" script in the top-level of the tree should
keep things in synch and properly timestamped.
There are some mailing lists for the NTP CVS distribution. For more
information, send a message to <majordomo@ntp.org> with the "lists" in
the body of the message.
If you get NTP via CVS, you will need to build the release using GNU make
and gcc.
You can then "make dist" to build a release tarball that does not require
GNU make or gcc.
The reason GNU make and gcc are required is because the repository version
of NTP does not have the make dependencies built-in. These dependencies
are created dynamically, and this dynamic process requires GNU make and gcc.

16
dist/ntp/README.des vendored
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.

62
dist/ntp/README.rsa vendored
View File

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

476
dist/ntp/acconfig.h vendored
View File

@ -1,476 +0,0 @@
/* $NetBSD: acconfig.h,v 1.1.1.1 2000/03/29 12:38:44 simonb Exp $ */
/* Package */
#undef PACKAGE
/* Version */
#undef VERSION
/* debugging code */
#undef DEBUG
/* Minutes per DST adjustment */
#undef DSTMINUTES
/* MD5 authentication */
#undef MD5
/* DES authentication (COCOM only) */
#undef DES
/* time_t */
#undef time_t
/* reference clock interface */
#undef REFCLOCK
/* Audio CHU? */
#undef AUDIO_CHU
/* PARSE kernel PLL PPS support */
#undef PPS_SYNC
/* ACTS modem service */
#undef CLOCK_ACTS
/* Arbiter 1088A/B GPS receiver */
#undef CLOCK_ARBITER
/* DHD19970505: ARCRON support. */
#undef CLOCK_ARCRON_MSF
/* Austron 2200A/2201A GPS receiver */
#undef CLOCK_AS2201
/* PPS interface */
#undef CLOCK_ATOM
/* PPS auxiliary interface for ATOM */
#undef PPS_SAMPLE
/* Datum/Bancomm bc635/VME interface */
#undef CLOCK_BANC
/* Diems Computime Radio Clock */
#undef CLOCK_COMPUTIME
/* Chronolog K-series WWVB receiver */
#undef CLOCK_CHRONOLOG
/* Datum Programmable Time System */
#undef CLOCK_DATUM
/* ELV/DCF7000 clock */
#undef CLOCK_DCF7000
/* Dumb generic hh:mm:ss local clock */
#undef CLOCK_DUMBCLOCK
/* Forum Graphic GPS datating station driver */
#undef CLOCK_FG
/* TrueTime GPS receiver/VME interface */
#undef CLOCK_GPSVME
/* Heath GC-1000 WWV/WWVH receiver */
#undef CLOCK_HEATH
/* HOPF 6021 clock */
#undef CLOCK_HOPF6021
/* HP 58503A GPS receiver */
#undef CLOCK_HPGPS
/* Sun IRIG audio decoder */
#undef CLOCK_IRIG
/* Rockwell Jupiter GPS clock */
#undef CLOCK_JUPITER
/* Leitch CSD 5300 Master Clock System Driver */
#undef CLOCK_LEITCH
/* local clock reference */
#undef CLOCK_LOCAL
/* Meinberg clocks */
#undef CLOCK_MEINBERG
/* EES M201 MSF receiver */
#undef CLOCK_MSFEES
/* Magnavox MX4200 GPS receiver */
#undef CLOCK_MX4200
/* NMEA GPS receiver */
#undef CLOCK_NMEA
/* Motorola UT Oncore GPS */
#undef CLOCK_ONCORE
/* Palisade clock */
#undef CLOCK_PALISADE
/* PARSE driver interface */
#undef CLOCK_PARSE
/* Conrad parallel port radio clock */
#undef CLOCK_PCF
/* PCL 720 clock support */
#undef CLOCK_PPS720
/* PST/Traconex 1020 WWV/WWVH receiver */
#undef CLOCK_PST
/* PTB modem service */
#undef CLOCK_PTBACTS
/* DCF77 raw time code */
#undef CLOCK_RAWDCF
/* RCC 8000 clock */
#undef CLOCK_RCC8000
/* Schmid DCF77 clock */
#undef CLOCK_SCHMID
/* clock thru shared memory */
#undef CLOCK_SHM
/* Spectracom 8170/Netclock/2 WWVB receiver */
#undef CLOCK_SPECTRACOM
/* KSI/Odetics TPRO/S GPS receiver/IRIG interface */
#undef CLOCK_TPRO
/* TRAK 8810 GPS receiver */
#undef CLOCK_TRAK
/* Trimble GPS receiver/TAIP protocol */
#undef CLOCK_TRIMTAIP
/* Trimble GPS receiver/TSIP protocol */
#undef CLOCK_TRIMTSIP
/* Kinemetrics/TrueTime receivers */
#undef CLOCK_TRUETIME
/* Ultralink M320 WWVB receiver */
#undef CLOCK_ULINK
/* USNO modem service */
#undef CLOCK_USNO
/* WHARTON 400A Series protocol */
#undef CLOCK_WHARTON_400A
/* WWV audio driver */
#undef CLOCK_WWV
/* VARITEXT protocol */
#undef CLOCK_VARITEXT
/* define if we need to declare int errno; */
#undef DECL_ERRNO
/* define if we may declare int h_errno; */
#undef DECL_H_ERRNO
/* define if it's OK to declare char *sys_errlist[]; */
#undef CHAR_SYS_ERRLIST
/* define if it's OK to declare int syscall P((int, struct timeval *, struct timeval *)); */
#undef DECL_SYSCALL
/* define if we have syscall is buggy (Solaris 2.4) */
#undef SYSCALL_BUG
/* Do we need extra room for SO_RCVBUF? (HPUX <8) */
#undef NEED_RCVBUF_SLOP
/* Should we open the broadcast socket? */
#undef OPEN_BCAST_SOCKET
/* Do we want the HPUX FindConfig()? */
#undef NEED_HPUX_FINDCONFIG
/* canonical system (cpu-vendor-os) string */
#undef STR_SYSTEM
/* define if NetInfo support is available */
#undef HAVE_NETINFO
/* define if [gs]ettimeofday() only takes 1 argument */
#undef SYSV_TIMEOFDAY
/* define if struct sockaddr has sa_len */
#undef HAVE_SA_LEN_IN_STRUCT_SOCKADDR
/* define if struct clockinfo has hz */
#undef HAVE_HZ_IN_STRUCT_CLOCKINFO
/* define if struct sigaction has sa_sigaction */
#undef HAVE_SA_SIGACTION_IN_STRUCT_SIGACTION
/* define if struct clockinfo has tickadj */
#undef HAVE_TICKADJ_IN_STRUCT_CLOCKINFO
/* define if struct ntptimeval uses time.tv_nsec instead of time.tv_usec */
#undef HAVE_TV_NSEC_IN_NTPTIMEVAL
/* Does a system header defind struct ppsclockev? */
#undef HAVE_STRUCT_PPSCLOCKEV
/* define if function prototypes are OK */
#undef HAVE_PROTOTYPES
/* define if setpgrp takes 0 arguments */
#undef HAVE_SETPGRP_0
/* hardwire a value for tick? */
#undef PRESET_TICK
/* hardwire a value for tickadj? */
#undef PRESET_TICKADJ
/* is adjtime() accurate? */
#undef ADJTIME_IS_ACCURATE
/* should we NOT read /dev/kmem? */
#undef NOKMEM
/* use UDP Wildcard Delivery? */
#undef UDP_WILDCARD_DELIVERY
/* always slew the clock? */
#undef SLEWALWAYS
/* step, then slew the clock? */
#undef STEP_SLEW
/* force ntpdate to step the clock if !defined(STEP_SLEW) ? */
#undef FORCE_NTPDATE_STEP
/* synch TODR hourly? */
#undef DOSYNCTODR
/* do we set process groups with -pid? */
#undef UDP_BACKWARDS_SETOWN
/* must we have a CTTY for fsetown? */
#undef USE_FSETOWNCTTY
/* can we use SIGIO for tcp and udp IO? */
#undef HAVE_SIGNALED_IO
/* can we use SIGPOLL for UDP? */
#undef USE_UDP_SIGPOLL
/* can we use SIGPOLL for tty IO? */
#undef USE_TTY_SIGPOLL
/* should we use clock_settime()? */
#undef USE_CLOCK_SETTIME
/* do we want the CHU driver? */
#undef CLOCK_CHU
/* do we have the ppsclock streams module? */
#undef PPS
/* do we have the tty_clk line discipline/streams module? */
#undef TTYCLK
/* does the kernel support precision time discipline? */
#undef KERNEL_PLL
/* does the kernel support multicasting IP? */
#undef MCAST
/* do we have ntp_{adj,get}time in libc? */
#undef NTP_SYSCALLS_LIBC
/* do we have ntp_{adj,get}time in the kernel? */
#undef NTP_SYSCALLS_STD
/* do we have STREAMS/TLI? (Can we replace this with HAVE_SYS_STROPTS_H? */
#undef STREAMS_TLI
/* do we need an s_char typedef? */
#undef NEED_S_CHAR_TYPEDEF
/* include the GDT Surveying code? */
#undef GDT_SURVEYING
/* does SIOCGIFCONF return size in the buffer? */
#undef SIZE_RETURNED_IN_BUFFER
/* what is the name of TICK in the kernel? */
#undef K_TICK_NAME
/* Is K_TICK_NAME (nsec_per_tick, for example) in nanoseconds? */
#undef TICK_NANO
/* what is the name of TICKADJ in the kernel? */
#undef K_TICKADJ_NAME
/* Is K_TICKADJ_NAME (hrestime_adj, for example) in nanoseconds? */
#undef TICKADJ_NANO
/* what is (probably) the name of DOSYNCTODR in the kernel? */
#undef K_DOSYNCTODR_NAME
/* what is (probably) the name of NOPRINTF in the kernel? */
#undef K_NOPRINTF_NAME
/* do we need HPUX adjtime() library support? */
#undef NEED_HPUX_ADJTIME
/* Might nlist() values require an extra level of indirection (AIX)? */
#undef NLIST_EXTRA_INDIRECTION
/* Other needed NLIST stuff */
#undef NLIST_STRUCT
#undef NLIST_NAME_UNION
/* Should we recommend a minimum value for tickadj? */
#undef MIN_REC_TICKADJ
/* Is there a problem using PARENB and IGNPAR (IRIX)? */
#undef NO_PARENB_IGNPAR
/* Should we not IGNPAR (Linux)? */
#undef RAWDCF_NO_IGNPAR
/* Does the compiler like "volatile"? */
#undef volatile
/* Does qsort expect to work on "void *" stuff? */
#undef QSORT_USES_VOID_P
/* What is the fallback value for HZ? */
#undef DEFAULT_HZ
/* Do we need to override the system's idea of HZ? */
#undef OVERRIDE_HZ
/* Do we want the SCO clock hacks? */
#undef SCO5_CLOCK
/* Do we want the ReliantUNIX clock hacks? */
#undef RELIANTUNIX_CLOCK
/* Does the kernel have an FLL bug? */
#undef KERNEL_FLL_BUG
/* Define if you have the TIOCGPPSEV ioctl (Solaris) */
#undef HAVE_TIOCGPPSEV
/* Define if you have the TIOCSPPS ioctl (Solaris) */
#undef HAVE_TIOCSPPS
/* Define if you have the CIOGETEV ioctl (SunOS, Linux) */
#undef HAVE_CIOGETEV
/* Define if you have the TIOCGSERIAL, TIOCSSERIAL, ASYNC_PPS_CD_POS, and ASYNC_PPS_CD_NEG ioctls (linux) */
#undef HAVE_TIO_SERIAL_STUFF
/* Define if you use struct timespec rather than struct timeval (time in ns rather than us) */
#undef HAVE_TIMESPEC
/* Define if you have the interface in the Draft RFC */
#undef HAVE_PPSAPI
/* Do we need to #define _SVID3 when we #include <termios.h>? */
#undef TERMIOS_NEEDS__SVID3
/* Do we have support for SHMEM_STATUS? */
#undef ONCORE_SHMEM_STATUS
/***/
/* Which way should we declare... */
/* adjtime()? */
#undef DECL_ADJTIME_0
/* bcopy()? */
#undef DECL_BCOPY_0
/* bzero()? */
#undef DECL_BZERO_0
/* cfset[io]speed()? */
#undef DECL_CFSETISPEED_0
/* ioctl()? */
#undef DECL_IOCTL_0
/* IPC? (bind, connect, recvfrom, sendto, setsockopt, socket) */
#undef DECL_IPC_0
/* memmove()? */
#undef DECL_MEMMOVE_0
/* memset()? */
#undef DECL_MEMSET_0
/* mkstemp()? */
#undef DECL_MKSTEMP_0
/* mktemp()? */
#undef DECL_MKTEMP_0
/* mrand48()? */
#undef DECL_MRAND48_0
/* nlist()? */
#undef DECL_NLIST_0
/* plock()? */
#undef DECL_PLOCK_0
/* rename()? */
#undef DECL_RENAME_0
/* select()? */
#undef DECL_SELECT_0
/* setitimer()? */
#undef DECL_SETITIMER_0
/* setpriority()? */
#undef DECL_SETPRIORITY_0
#undef DECL_SETPRIORITY_1
/* sigvec()? */
#undef DECL_SIGVEC_0
/* srand48()? */
#undef DECL_SRAND48_0
/* stdio stuff? */
#undef DECL_STDIO_0
/* stime()? */
#undef DECL_STIME_0
#undef DECL_STIME_1
/* strtol()? */
#undef DECL_STRTOL_0
/* syslog() stuff? */
#undef DECL_SYSLOG_0
/* time()? */
#undef DECL_TIME_0
/* [gs]ettimeofday()? */
#undef DECL_TIMEOFDAY_0
/* tolower()? */
#undef DECL_TOLOWER_0
/* toupper()? */
#undef DECL_TOUPPER_0

2
dist/ntp/adjtimed/adjtimed.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: adjtimed.c,v 1.1.1.1 2000/03/29 12:38:45 simonb Exp $ */
/* $NetBSD: adjtimed.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/*************************************************************************/
/* (c) Copyright Tai Jin, 1988. All Rights Reserved. */

2
dist/ntp/arlib/arlib.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: arlib.c,v 1.1.1.1 2003/12/04 16:05:21 drochner Exp $ */
/* $NetBSD: arlib.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/*
* arlib.c (C)opyright 1993 Darren Reed. All rights reserved.

2
dist/ntp/arlib/arlib.h vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: arlib.h,v 1.1.1.1 2003/12/04 16:05:20 drochner Exp $ */
/* $NetBSD: arlib.h,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/*
* arlib.h (C)opyright 1992 Darren Reed.

2
dist/ntp/arlib/arplib.h vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: arplib.h,v 1.1.1.1 2003/12/04 16:05:21 drochner Exp $ */
/* $NetBSD: arplib.h,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/*
* arplib.h (C)opyright 1992 Darren Reed.

2
dist/ntp/arlib/sample.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: sample.c,v 1.1.1.1 2003/12/04 16:05:21 drochner Exp $ */
/* $NetBSD: sample.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
#include <stdio.h>
#include <strings.h>

2
dist/ntp/clockstuff/chutest.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: chutest.c,v 1.1.1.1 2000/03/29 12:38:45 simonb Exp $ */
/* $NetBSD: chutest.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/* chutest.c,v 3.1 1993/07/06 01:05:21 jbj Exp
* chutest - test the CHU clock

2
dist/ntp/clockstuff/clktest.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: clktest.c,v 1.1.1.1 2000/03/29 12:38:45 simonb Exp $ */
/* $NetBSD: clktest.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/* clktest.c,v 3.1 1993/07/06 01:05:23 jbj Exp
* clktest - test the clock line discipline

2
dist/ntp/clockstuff/propdelay.c vendored
View File

@ -1,4 +1,4 @@
/* $NetBSD: propdelay.c,v 1.1.1.1 2000/03/29 12:38:45 simonb Exp $ */
/* $NetBSD: propdelay.c,v 1.2 2003/12/04 16:23:34 drochner Exp $ */
/* propdelay.c,v 3.1 1993/07/06 01:05:24 jbj Exp
* propdelay - compute propagation delays

42
dist/ntp/conf/dewey.conf vendored
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

1163
dist/ntp/config.h.in vendored
View File

File diff suppressed because it is too large Load Diff

25434
dist/ntp/configure vendored
View File

File diff suppressed because it is too large Load Diff

2010
dist/ntp/configure.in vendored
View File

File diff suppressed because it is too large Load Diff

257
dist/ntp/html/Oncore-SHMEM.htm vendored
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>

144
dist/ntp/html/accopt.htm vendored
View File

@ -1,144 +0,0 @@
<HTML><HEAD><TITLE>
Access Control Options
</TITLE></HEAD><BODY><H3>
Access Control Options
</H3><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.
<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>
<DL>
<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>
</DL>
<DD>Default restriction list entries, with the flags <TT>ignore,
ntpport</TT>, for each of the local host's interface addresses are
inserted into the table at startup to prevent the server from attempting
to synchronize to its own time. A default entry is also always present,
though if it is otherwise unconfigured; no flags are associated with the
default entry (i.e., everything besides your own NTP server is
unrestricted).</DD>
<DT><TT>clientlimit <I>limit</I></TT></DT>
<DD>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>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

170
dist/ntp/html/assoc.htm vendored
View File

@ -1,170 +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>Release Notes
</TITLE>
</HEAD>
<BODY>
<H3>
Association Management</H3>
<HR>
<H4>
Association Modes</H4>
This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates
new features and refinements to the NTP Version 3 (NTPv3) algorithms. However,
it continues the tradition of retaining backwards compatibility with older
versions. The NTPv4 version has been under development for quite a while
and isn't finished yet. In fact, quite a number of NTPv4 features have
already been implemented in the current NTPv3, including a number of new
operating modes for automatic server discovery and improved accuracy in
occasionally-connected networks. Following is an extended abstract describing
the new features..
<P>An ephemeral association of some mode is mobilized when a message arrives
from another client or server. For instance, a symmetric-passive association
is mobilized upon arrival of a message from a symmetric- active peer. A
client association is mobilized upon arrival of a broadcast message from
a multicast server or a server message from a manycast server. Ephemeral
associations are demobilized when either (a) the server becomes unreachable
or (b) an error occurs on initial contact before the association is mobilized.
<P>The one exception to (a) and (b) above is when
<TT><A HREF="authopt.htm">autokey</A></TT> is in use and the initial
authentication check fails due to unknown
key identifier or autokey mismatch. This exception is necessary because
the Unix kernel does not bind the local address until the first packet
is received. The result in broadcast mode is a rather painful initial exchange,
where authentication fails until after the first round of messages. The
result in multicast mode is in general fatal, especially if multiple interfaces
are in use. As promiscuous modes such as multicast and manycast require
authentication for reliable and safe operation, autokey is in general useless
with these modes until and if the input/output machinery is overhauled.
<P>Following is a summary of the protocol operations for each mode.
<P>Peer Modes (Active and Passive)
<UL>In these modes, two client/server peers agree to back each other up,
should the synchronization source for either peer fail. One or both peers
is configured in symmetric-active mode using the peer command. Alternatively,
one - the active peer - is configured in this mode and the other, the passive
peer, operates in symmetric-passive mode and requires no prior configuration.
Both association scenarios operate in NTPv4 as in NTPv3; however, several
bugs in the handling of keys and recovery of resources when an active peer
fails, have been corrected in NTPv4. The original NTPv3 authentication
scheme is applicable in this mode, as well as the new NTPv3 autokey scheme.</UL>
Client/Server Modes
<UL>In these modes, a client sends a request to the server and expects
a reply at some future time. The client is configured in client mode using
the server (sic) command; the server requires no prior configuration. The
original NTPv3 authentication scheme is applicable in this mode, as well
as the new NTPv3 autokey scheme.</UL>
Broadcast/Multicast Modes
<UL>In these modes, the server generates messages at intervals specified
by the minpoll subcommand. When using IP multicast addresses, the scope
of the multicast tree is specified by the ttl subcommand in hops. When
using a local interface broadcast address, the scope is limited to the
attached subnet. The client responds to the first message received by waiting
an interval randomized over the minpoll interval, in order to avoid implosions.
Then, it polls the server in burst mode, in order to accumulate data to
reliably set the host clock. This normally results in eight client/server
cycles over a 32-s interval. When the next multicast message is received,
the client computes the offset between the system clock just set and the
apparent time of the multicast message in order to correct the apparent
time in future multicast messages.</UL>
Manycast Mode
<UL>In this mode, a configured client broadcasts a request message as in
client mode to a designated multicast group address. All servers configured
as manycast clients and in ttl range respond with a server reply message.
Each reply mobilizes a persistent client/server association as in client
mode. Then, the NTP intersection and clustering algorithms act to discard
all but the "best" of these associations, which then continue as in client/server
mode.</UL>
<H4>
Burst Mode</H4>
Burst mode can be configured when the network attachment requires an initial
calling or training procedure. Each poll initiates a burst of eight request
messages at intervals randomized over the range 3-5 s. The reply messages
update the clock filter, which then selects the best (most accurate) among
them. When the last reply in the burst is sent, the next reply updates
the client variables and system clock in the usual manner, as if only a
single request/reply cycle had occurred. This mode does produce additional
network overhead and can cause trouble if used indiscriminately. It should
only be used where the poll interval is expected to settle to values above
1024 s.
<H4>
Revised Error Checking</H4>
It is very important to avoid spurious mobilizations from possibly broken
or rogue servers; in particular, to avoid denial-of-service attacks. In
order to resist such attacks, arriving messages that might mobilize ephemeral
associations are carefully screened using a series of eleven sanity checks.
<OL>
<LI>
Duplicate packet. This message is a duplicate of one previously received.</LI>
<BR>&nbsp;
<LI>
Bogus packet. This message did not result from a message previously sent,
or messages have been received out of order.</LI>
<BR>&nbsp;
<LI>
Unsynchronized. The server has not yet stored the previous timestamps.</LI>
<BR>&nbsp;
<LI>
Invalid delay or dispersion. Either the delay or dispersion or both computed
from the message timestamps are above the normal range.</LI>
<BR>&nbsp;
<LI>
Authentication failed. The sent MAC does not match the received MAC, either
due to the wrong key material or damaged message.</LI>
<BR>&nbsp;
<LI>
Server unsynchronized. The server indicates unsynchronized in the leap
bits included in the packet.</LI>
<BR>&nbsp;
<LI>
Server stratum check. The server is operating at a stratum above the normal
range.</LI>
<BR>&nbsp;
<LI>
Delay/dispersion check. The related server packet data values are above
the normal range.</LI>
<BR>&nbsp;
<LI>
Autokey failed. The hash of the current session key does not match the
most recent key identifiers used. (The hash is repeated four times, in
order to recover from lost packets whenever possible.)</LI>
<BR>&nbsp;
<LI>
Access denied. The sender has been blocked by the access control list.</LI>
<BR>&nbsp;
<LI>
Key not found. The key identifier does not match any identifier in the
key list or the key has expired or been revoked.</LI>
</OL>
Failure to pass tests 5-11 is sufficient evidence to discard the packet
without forming an association. However, failure to pass tests 1-4 is not
necessarily grounds to reject the packet, since subsequent packets may
be acceptable. In this case, the association is mobilized, but only the
packet timestamps are stored. For the moment, and until the cryptographic
signature algorithm is available, test 9 is temporarily disabled.
<BR>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<BR>&nbsp;
</BODY>
</HTML>

153
dist/ntp/html/audio.htm vendored
View File

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

278
dist/ntp/html/authopt.htm vendored
View File

@ -1,278 +0,0 @@
<html><head><title>
Authentication Options
</title></head><body><h3>
Authentication Options
</h3><hr>
<H4>Authentication Support</H4>
Authentication support allows the NTP client to verify that the server
is in fact known and trusted and not an intruder intending accidentally
or on purpose to masquerade as that server. The NTPv3 specification
RFC-1305 defines an scheme which provides cryptographic authentication
of received NTP packets. Originally, this was done using the Data
Encryption Standard (DES) operating in Cipher Block Chaining (CBC) mode,
commonly called DES-CBC. Subsequently, this was augmented by the RSA
Message Digest 5 (MD5) using a private key, commonly called keyed-MD5.
Either algorithm computes a message digest, or one-way hash, which can
be used to verify the server has the correct private key and key
identifier.
<p>NTPv4 retains the NTPv3 schemes and, in addition, provides a new
<I>autokey</I> scheme based on reverse hashing and public key
cryptography. Authentication can be configured separately for each
association using the <TT>key</TT> or <TT>autokey</TT> subcommands on
the <TT>peer</TT>, <TT>server</TT>, <TT>broadcast</TT> and
<TT>manycastclient</TT> commands as described in the <A
HREF="config.htm">Configuration Options</A> page.
<P>The authentication options specify the suite of keys, select the key
for each configured association and manage the configuration operations,
as described below. The <TT>auth</TT> flag which controls these
functions can be set or reset by the <TT>enable</TT> and
<TT>disable</TT> configuration commands and also by remote configuration
commands sent by a <TT>ntpdc</TT> program running in another machine. If
this flag is set, persistent peer associations and remote configuration
commands are effective only if cryptographically authenticated. If this
flag is disabled, these operations are effective even if not
cryptographic authenticated. It should be understood that operating in
the latter mode invites a significant vulnerability where a rogue hacker
can seriously disrupt client timekeeping.
<P>The <TT>auth</TT> flag affects all authentication procedures
described below; however, it operates differently if cryptographic
support (<tt>AUTOKEY</tt>) is compiled in the distribution, which is
normally the case. If this support is available and the flag is enabled,
then persistent associations are mobilized in multicast client and
symmetric passive modes and remote configuration commands are effective
only if successfully authenticated. If the support is unavailable and
the flag is enabled, then it is not possible under any conditions to
mobilize persistent associations or respond to remote configuration
commands. The <TT>auth</TT> flag normally defaults to set if
cryptographic support is available and to reset otherwise.
<P>With the above vulnerabilities in mind, it is desirable to set the
<tt>auth</TT> flag in all cases. One aspect which is often confusing is
the name resolution process which maps server names in the configuration
file to IP addresses. In order to protect against bogus name server
messages, this process is authenticated using an internally generated
key which is normally invisible to the user. However, if cryptographic
support is unavailable and the <TT>auth</TT> flag is enabled, the name
resolution process will fail. This can be avoided either by specifying
IP addresses instead of host names, which is generally inadvisable, or
by leaving the flag disabled and enabling it once the name resolution
process is complete.
<H4>Private Key Scheme</H4>
The original RFC-1305 specification allows any one of possibly 65,534
keys, each distinguished by a 32-bit key identifier, to authenticate an
association. The servers involved must agree on the key and key
identifier to authenticate their messages. Keys and related information
are specified in a key file, usually called <TT>ntp.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 ones can be used as passwords for the <TT><A
HREF="ntpq.htm">ntpq</A></TT> and <TT><A HREF="ntpdc.htm">ntpdc</A></TT>
utility programs.
<P>When <TT>ntpd</TT> is first started, it reads the key file and
installs the keys in the key cache. However, the keys must be activated
before they can be used with the <TT>trusted</TT> command. This allows,
for instance, the installation of possibly several batches of keys and
then activating or 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.
<H4>Autokey Schemes</H4>
The original NTPv3 authentication scheme described in RFC-1305 continues
to be supported; however, in NTPv4 an additional authentication scheme
called <I>autokey</I> 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 scheme has several modes of operation corresponding to the various
NTP modes supported. RSA signatures and 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. Multicast and
symmetric 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 <tt>autokey</tt> scheme are
incorporated as a set of files generated by the <a
href=genkeys.htm><tt>ntp_genkeys</tt></a> program, including the DES/MD5
private keys, RSA public/private key pair, and the Diffie-Hellman
parameters. See the <tt>ntp_genkeys</tt> page for a description of the
format and use of these files. They contain cryptographic values
generated by the algorithms of the <tt>rsaref20</tt> package and are in
printable ASCII format. Since the algorithms are seeded by the system
clock, each run of this program will produce a different outcome.
<p>The <tt>ntp.keys</tt> file contains the private DES/MD5 keys. It must
be distributed by secure means to other servers and clients sharing the
same security compartment and made visible only to root. 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. The
<tt>ntp_dh</tt> file contains the Diffie-Hellman parameters. It is
necessary that all servers and clients of a security compartment share a
single <tt>ntp_dh</tt> file, but it does not matter which one. This file
can be distributed using insecure means, since the data are public
values.
<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 configured
<tt>server</tt> or <tt>peer</tt> association requires the public key
file associated with the particular server or peer to be installed at a
default location or as specified by the commands below. In addition,
public key files are required for associations that might be mobilized
by multicast or symmetric servers. These files can be widely distributed
and stored using insecure means, since the data are public values.
<p>Due to the widespread use of interface-specific naming, the host
names used in configured and mobilized associations are determined by
different rules. The <tt>ntp_genkeys</tt> program uses the name returned
by the Unix <tt>gethostname()</tt> library routine and this is the name
normally used when installing the file on some other host. However, the
default name used when configuring an association at run time is the
canonical name returned by the DNS resolver, and this might not be the
same name. The preferred workaround on the host installing the file is
to use the Unix <tt>nslookup</tt> command to determined the canonical
name and install a link from that name to the actual name.
Alternatively, the default can be overriden with by the
<tt>publickey</tt> subcommand of the <tt>server</tt> or <tt>peer</tt>
configuration command.
<p>For other than configured associations that might be mobilized by
multicast servers or symmetric peers, the name is determined directly
from the server or peer as part of the protocol dance that authenticates
the source. The server or peer uses the same <tt>gethostname()</tt>
library routine as the <tt>ntp_genkeys</tt> program, so there is no
confusion.
<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
overriden by the <tt>keysdir</tt> configuration file 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
<tt>/etc</tt>, which is normally not in a shared filesystem. The default
can be overriden by the <tt>subcommand</tt> of the <tt>crypto</tt>
configuration command.
<H4>Authentication Commands</H4>
<DL>
<dt><tt>autokey [<i>logsec</i>]</tt>
<dd>Specifies the interval between regenerations of the session key list
used with the autokey feature. Note that the size of the key list for
each association depends on this interval and the current poll interval.
The default value is 12 (4096 s or about 1.1 hours). For poll intervals
above the specified interval, a session key list with a single entry
will be regenerated for every message sent.</dd>
<DT><TT>controlkey <I>key</I></TT></DT>
<DD>Specifies the key identifier to use with the <TT>ntpq</TT> program,
which uses the standard protocol defined in RFC-1305. This program is
useful to diagnose and repair problems that affect <TT>ntpd</TT>
operation. The <TT><I>key</I></TT> argument to this command is a key
identifier for a trusted key, where the value can be in the range 1 to
65534, inclusive.</DD>
<DT><TT>crypto [privatekey <i>file</i>] [publickey <i>file</i>] [dhparms
<i>file</i>] </TT></DT>
<DD>This command requires the NTP daemon build process be configured
with the RSA library. The presence of this command causes the daemon to
load the host RSA private key file, public key file and Diffie-Hellman
parameter file. If one or more files are left unspecified, the default
names are used as described above. Following are the subcommands:</DD>
<dl>
<dt><tt>privatekey <i>file</tt></i>
<dd>Specifies the directory for the RSA private key file, which
otherwise defaults to <tt>/usr/local/etc<tt>.</dd>
<dt><tt>publickey <i>file</tt></i>
<dd>Specifies the directory for the RSA public key file, which otherwise
defaults to <tt>/usr/local/etc<tt>.</dd>
<dt><tt>dhparms <i>file</tt></i>
<dd>Specifies the directory for the Diffie-Hellman parameters file,
which otherwise defaults to <tt>/usr/local/etc<tt>.</dd>
</dl>
<DT><TT>keys <I>keyfile</I></TT></DT>
<DD>Specifies the file name containing the private encryption keys and
key identifiers used by <TT>ntpd</TT>, <TT>ntpq</TT> and <TT>ntpdc</TT>
when operating in authenticated 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, 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 <TT>ntpdc</TT> utility
program, which uses a proprietary protocol specific to this
implementation of <TT>ntpd</TT>. This program is useful to diagnose and
repair problems that affect <TT>ntpd</TT> operation. The
<TT><I>key</I></TT> argument to this command is a key identifier for a
trusted key, where the value can be in the range 1 to 65534, inclusive.
</DD>
<dt><tt>revoke [<i>logsec</i>]</tt>
<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 encryption key identifiers which are trusted for the
purposes of authenticating peers suitable for synchronization, as well
as keys used by the <TT>ntpq</TT> and <TT>ntpdc</TT> programs. The
authentication procedures require that both the local and remote servers
share the same key and key identifier for this purpose, although
different keys can be used with different servers. The
<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 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>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

253
dist/ntp/html/biblio.htm vendored
View File

@ -1,253 +0,0 @@
<html><head><title>
Protocol Conformance Statement
</title></head><body><h3>
Protocol Conformance Statement
</h3>
<p>The Network Time Protocol (NTP) is used to synchronize the time of
a computer client or server to another server or reference time source,
such as a radio or satellite receiver or modem. It provides accuracies
typically within a millisecond on LANs up to a few tens of milliseconds
on WANs relative to Coordinated Universal Time (UTC), as provided by a
Global Positioning Service (GPS) receiver, for example.
<p>Typical NTP configurations utilize multiple redundant servers and
diverse network paths, in order to achieve high accuracy and
reliability. Some configurations include cryptographic authentication to
prevent accidental or malicious protocol attacks. Information on the NTP
architecture, protocol and algorithms can be found in the following
articles and reports, which are available online. General issues of the
concepts and facilities assumed by NTP are discussed in tne <a
href=exec.htm>Executive Summary - Computer Network Time
Synchronization</a> page, while issues related to the NTP timescale and
pending century are discussed in the <A HREF=y2k.htm> Network Time
Protocol Year 2000 Conformance Statement</A> page, both of which are
included in this document.
<p>Note that network timekeeping technology continues to advance and may
obsolete some of the following documents. For a current list of all
papers, reports, briefings and other documents relevant to the NTP
community, see the <a href=http://www.eecis.udel.edu/~mills>David L.
Mills</a> web page.
<P>The NTP architecture, protocol and algorithm models are described in
<UL>
<li>Mills, D.L. Internet time synchronization: the Network Time
Protocol. <I>IEEE Trans. Communications COM-39, 10</I> (October 1991),
1482-1493. <A
HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf>
PDF</a>. Also in: Yang, Z., and T.A. Marsland (Eds.). <I>Global States
and Time in Distributed Systems</I>. IEEE Computer Society Press, Los
Alamitos, CA, 1994, 91-102.
</UL>
The NTP specification and implementation has evolved over the last two
decades to the current Version 4 of the protocol. This version includes
significant enhancements in accuracy and reliability, as determined by
experience in an estimated total of well over 100,000 clients and
servers in the Internet, while retaining backward compatibility with
previous versions.
<P>This software distribution contains an implementation of the NTP
Version 4 architecture, protocol and algorithms. While a formal
specification of this version is not yet available, this version is
fully compliant with the previous NTP Version 3 specification and
implementation defined in
<UL>
<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>
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</LI>
<P>Mills, D.L. Unix kernel modifications for precision time
synchronization. Electrical Engineering Department Report 94-10-1,
University of Delaware, October 1994, 24 pp. Abstract: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf>
PDF</a>, Body: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf>
PDF</a>. Major revision and update of: Network Working Group Report
RFC-1589, University of Delaware, March 1994. 31 pp. <A
HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</A>
<p><LI>Support for IP Multicasting, as described in</LI>
<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. Clock discipline algorithms for the Network Time Protocol
Version 4. Electrical Engineering Report 97-3-3, University of Delaware,
March 1997, 35 pp. Abstract: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps>
PostScript</A> | <a
HREF=
http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf>
PDF</a>, Body: <A
HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps>
PostScript</A> | <a
HREF=
http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf>
PDF</a>
<P>Mills, D.L. Improved algorithms for synchronizing computer network
clocks. <I>IEEE/ACM Trans. Networks 3, 3</I> (June 1995), 245-254. <A
HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps>
PostScript</A> | <a
HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf>
PDF</a>
<P><LI>Engineered refinements to radio clock drivers and interface code,
as describedin:</LI>
<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</LI>
<P>Mills, D.L., T.S. Glassey, and M.E. McNeil. Coexistence and
interoperability of NTP authentication schemes. Internet Draft
draft-mills-ntp-auth-coexist-00.txt, University of Delaware and Coastek
InfoSys, Inc., November 1997, 8 pp. <A
HREF=http://www.eecis.udel.edu/~mills/memos/draft.txt>ASCII</A>
<P>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>Performance surveys for NTP Version 4 can be found in</LI>
<p><li>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet
timekeeping around the globe. <i>Proc. Precision Time and Time Interval
(PTTI) Applications and Planning Meeting</i> (Long Beach CA, December
1997), 365-371. Paper: <a
href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf>
PDF</a>, Slides: <a
href=
http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm>
HTML</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt>
PowerPoint</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf>
PDF</a></li>
<p><li>Mills, D.L. The network computer as precision timekeeper.
<i>Proc. Precision Time and Time Interval (PTTI) Applications and
Planning Meeting</i> (Reston VA, December 1996), 96-108. Paper: <a
href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf>
PDF</a>, Slides: <a
href=
http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm>
HTML</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps>
PostScript</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt>
PowerPoint</a> | <a
href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf>
PDF</a></li>
</OL>
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

180
dist/ntp/html/build.htm vendored
View File

@ -1,180 +0,0 @@
<HTML><HEAD><TITLE>
Building and Installing the Distribution
</TITLE></HEAD><BODY><H3>
Building and Installing the Distribution
</H3>
<H4>Building and Installing the Distribution</H4>
As a practical matter, every computer architecture and operating system
version seems to be different than any other. The device drivers may be
different, the input/output system may bew idiosyncratic and the
libraries may have different semantics. It is not possible in a software
distribution such as this one to support every individual sysdtem with a
common set of binaries, even with the same system but different
versions. Therefore, it is necessary to configure each system
individually for each system and version, both at compile time and at
run time. In almost all cases, these procedures are completely automatic
and all the newbie user need do is type "make" and the autoconfigure
system does the rest. There are some exceptions, as noted below.
<p>The autoconfigure system inspects the hardware and software
environment and tests for the presence of system header files and the
contents of these files to determine if certain features are available.
When one or more of these features are present, the code is compiled to
use them; if not, no special code is compiled. However, even if the code
is compiled to use these features, the code does a special test at run
time to see if one or more are actually present and avoids using them if
not present. In such cases a warning message is sent to the system log,
but the daemon should still work properly.
Some programs included in this distribution use cryptographic algorithms
to verify server authenticity and credentials. As required by the
International Trade in Arms Regulations (ITAR), now called the Defense
Trade Regulations (DTR), certain cryptographic products and media,
including the Data Encryption Standard (DES), cannot be exported without
per-instance license. For this reason, the DES encryption routine has
been removed from the the current version, even though it is used only
to compute a message digest. Current DTR regulations allow export of the
the MD5 message digest routine, which is in fact the preferred
algorithm, and this is included in the current
version.
<P>The NTP authentication routines conform to the interface used by RSA
Laboratories in the <TT>rsaref20.zip</TT> package, which is downloadable
from <TT>ftp.rsa.com</TT> or via the web at <TT>www.rsa.com</TT>.
Outside the U.S. and Canada, the functionally identical
<TT>rsaeuro.zip</TT> package is available from J.S.A. Kapp and other
sources. The recommended way to integrate the DES routines in either
package with the NTP build procedures is to copy the <TT>desc.c</TT>
file from the <TT>./source</TT> directory in the package to the
<TT>./libntp</TT> directory in the distribution. Then copy the header
files <TT>rsaref.h</TT>, <TT>des.h</TT> and <TT>md2.h</TT> in the
<TT>./source</TT> directory to the <TT>./include</TT> directory. Do not
copy the <TT>global.h</TT> header file; the one in the distribution has
been modified. These steps must be completed before the configuration
process described below.
<H4>Building and Installing under Unix</H4>
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.
<H4>Configuration</H4>
Use the <TT>./configure</TT> command to perform an automatic
configuration procedure. This procedure normally includes the debugging
code, which can be useful in diagnosing problems found in initial test,
and all reference clock drivers known to work with each machine and
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>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.
<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.
<H4>Installation</H4>
As root, use the <TT>make install</TT> command to install the binaries
in the destination directory. You must of course have write permission
on the install destination directory. This includes the programs <TT><A
HREF="ntpd.htm">ntpd</A></TT> (the daemon), <TT><A
HREF="ntpdc.htm">ntpdc</A></TT> (an <TT>ntpd</TT>-dependent query
program), <TT><A HREF="ntpq.htm">ntpq</A></TT> (a standard query
program), <TT><A HREF="ntpdate.htm">ntpdate</A></TT> (an <TT>rdate</TT>
replacement for boot time date setting and sloppy time keeping) and
<TT><A HREF="ntptrace.htm">ntptrace</A></TT> (a utility useful to find
the primary (stratum-1) servers). In some systems, the <TT><A
HREF="tickadj.htm">tickadj</A></TT> (a utility useful to adjust kernel
variables) is installed. If the precision time kernel modifications are
present, the <TT><A HREF="ntptime.htm">ntptime</A></TT> (a utility
useful to debug kernel time functions) is installed.
<P>You are now ready to configure the daemon and start it. You will need
to create a NTP configuration file <TT>ntp.conf</TT> and possibly a
cryptographic key file <TT>ntp.keys</TT>. Directions for doing that are
in the <A HREF="notes.htm">Notes on Configuring NTP and Setting up a NTP
Subnet</A>. The behavior when the daemon starts for the first time can
be counterintuitive. To reduce the level of angst, see the <a
href=quick.htm>Quick Start</a> page. A tutorial on debugging technique
is in <A HREF="debug.htm">NTP Debugging Technique</A>.
<P>If problems peculiar to the particular hardware and software
environment (e.g. operating system -specific issues) are suspected,
browse the <A HREF="hints.htm">Hints and Kinks</A> page.
<P>Bug reports of a general nature can be sent to David Mills <A
HREF="mailto: mills@udel.edu">&lt;mills@udel.edu></A>. Bug reports of a
specific nature on features implemented by the programmer corps
mentioned in the <A HREF="copyright.htm">Copyright</A> page should be
sent directly to the implementor listed in that page, with copy to
mills@udel.edu.
<P><B>Please include the version of the source distribution (e.g., ntp-
4.0.70a) in your bug report.</B>
<P><B>Please include the <B>output</B> of <TT>config.guess</TT> in your
bug report.</B>
<P><B>It will look something like: <TT>pdp11-dec-fuzzos3.4</TT></B>
<P>Additional <TT>make</TT> commands
<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>Home<address><a href="mailto:mills@udel.edu"> David L.
Mills &lt;mills@udel.edu&gt;</a>
</address></body></html>

193
dist/ntp/html/clockopt.htm vendored
View File

@ -1,193 +0,0 @@
<HTML><HEAD><TITLE>
Reference Clock Options
</TITLE></HEAD><BODY><H3>
Reference Clock Options
</H3><HR>
<H4>Reference Clock Support</H4>
The NTP Version 4 daemon supports many different radio, satellite and
modem reference clocks plus a special pseudo-clock used for backup or
when no other clock source is available. Detailed descriptions of
individual device drivers and options can be found in the <A
HREF="refclock.htm">Reference Clock Drivers </A>page. Additional
information can be found in the pages referenced there, including the <A
HREF="rdebug.htm">Debugging Hints for Reference Clock Drivers</A> and <A
HREF="howto.html">How To Write a Reference Clock Driver</A> pages. In
many drivers, support for a PPS signal is available as described in <A
HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A> page. Many
drivers support special line discipline/streams modules which can
significantly improve the accuracy using the driver. These are described
in the <A HREF="ldisc.htm">Line Disciplines and Streams Drivers</A>
page.
<P>A reference clock will generally (though not always) be a radio
timecode receiver which is synchronized to a source of standard time
such as the services offered by the NRC in Canada and NIST and USNO in
the U.S. The interface between the computer and the timecode receiver is
device dependent, but is usually a serial port. A device driver specific
to each reference clock must be selected and compiled in the
distribution; however, most common radio, satellite and modem clocks are
included by default. Note that an attempt to configure a reference clock
when the driver has not been included or the hardware port has not been
appropriately configured results in a scalding remark to the system log
file, but is otherwise non hazardous.
<P>For the purposes of configuration, <TT>ntpd</TT> treats reference
clocks in a manner analogous to normal NTP peers as much as possible.
Reference clocks are identified by a syntactically correct but invalid
IP address, in order to distinguish them from normal NTP peers.
Reference clock addresses are of the form <TT>127.127.<I>t.u</I></TT>,
where <I><TT>t</TT></I> is an integer denoting the clock type and
<I><TT>u</TT></I> indicates the unit number. While it may seem overkill,
it is in fact sometimes useful to configure multiple reference clocks of
the same type, in which case the unit numbers&nbsp; must be unique.
<P>The <TT>server</TT> command is used to configure a reference clock,
where the <I><TT>address</TT></I> argument in that command is the clock
address. The <TT>key</TT>, <TT>version</TT> and <TT>ttl</TT> options are
not used for reference clock support. The <TT>mode</TT> option is added
for reference clock support, as described below. The <TT>prefer</TT>
option can be useful to persuade the server to cherish a reference clock
with somewhat more enthusiasm than other reference clocks or peers.
Further information on this option can be found in the <A
HREF="prefer.htm">Mitigation Rules and the <TT>prefer</TT> Keyword
</A>page. The <TT>minpoll</TT> and <TT>maxpoll</TT> options have meaning
only for selected clock drivers. See the individual clock driver
document pages for additional information.
<P>The stratum number of a reference clock is by default zero. Since the
<TT>ntpd</TT> daemon adds one to the stratum of each peer, a primary
server ordinarily displays stratum one. In order to provide engineered
backups, it is often useful to specify the reference clock stratum as
greater than zero. The <TT>stratum</TT> option is used for this purpose.
Also, in cases involving both a reference clock and a pulse-per-second
(PPS) discipline signal, it is useful to specify the reference clock
identifier as other than the default, depending on the driver. The
<TT>refid</TT> option is used for this purpose. Except where noted,
these options apply to all clock drivers.
<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 latencies, different cable lengths or receiver internal
delay. The specified offset is in addition to the propagation delay
provided by other means, such as internal DIPswitches. Where a
calibration for an individual system and driver is available, an
approximate correction is noted in the driver documentation pages.</DD>
<DT><TT>time2 <I>secs</I></TT></DT>
<DD>Specifies a fixed-point decimal number in seconds, which is
interpreted in a driver-dependent way. See the descriptions of specific
drivers in the <A HREF="refclock.htm">reference clock drivers</A>
page.</DD>
<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.
When a PPS signal is available, a special automatic calibration facility
is provided. If the <tt>flag1</tt> switch is set and the PPS signal is
actively disciplining the system time, the calibration value is
automatically adjusted to maintain a residual offset of zero. Further
information on the <TT>filegen</TT> command can be found in the <A
HREF="monopt.htm">Monitoring Options </A>page.</DD>
</DL>
<DT><TT>pps <I>device</I> [assert|clear] [hardpps]</TT></DT>
<DD>Specifies the name and options for the serial port device to which
the PPS signal is connected. Note, this command replaces use of
<TT>fudge flag3</TT>, which was used for the same purpose in NTPv3. Note
that this command should preceed the <TT>server</TT> and <TT>fudge</TT>
command for the same device. Note also that the <TT>assert</TT>,
<TT>clear</TT> and <TT>hardpps</TT> options are only available if the
<tt>ppsapi</tt> standard PPS interface is available.</DD>
<DL>
<DT><TT>device</TT></DT>
<DD>Specify the device name associated with the PPS signal. The name
must match exactly the link name specified in the driver documentation
page.</DD>
<DT><TT>assert</TT></DT>
<DT><TT>clear</TT></DT>
<DD>Using <TT>assert</TT> or <TT>clear</TT> specifies if the high going
or low going edge of the signal must be used. The default is
<TT>assert</TT>.</DD>
<DT><TT>hardpps</TT></DT>
<DD>This flag is used to tell the kernel that the signal from this
device must be used to drive hardpps().</DD>
<DD>The <TT>assert</TT>, <TT>clear</TT> and <TT>hardpps</TT> options
are only available if the PPSAPI is used.</DD>
</DL>
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

288
dist/ntp/html/config.htm vendored
View File

@ -1,288 +0,0 @@
<HTML><HEAD><TITLE>
Configuration Options
</TITLE></HEAD><BODY><H3>
Configuration Options
</H3>
<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:
<P>Usage: <TT>configure [options] [host]</TT>
<BR>Options: <TT>[defaults in brackets after descriptions]</TT>
<PRE>Configuration
&nbsp; --cache-file=FILE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cache test
results in FILE
&nbsp; --
help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp; print this message
&nbsp; --no-
create&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
do not create output files
&nbsp; --quiet, --silent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not print
`checking...' messages
&nbsp; --
version&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp; print the version of autoconf that created
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
configure
Directory and file names
&nbsp; --prefix=PREFIX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; install
architecture-independent files in
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PREFIX [/usr/local]
&nbsp; --exec-prefix=EPREFIX&nbsp; install architecture-dependent files
in EPREFIX
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[same as prefix]
&nbsp; --
bindir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
user executables in DIR [EPREFIX/bin]
&nbsp; --
sbindir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; system
admin executables in DIR [EPREFIX/sbin]
&nbsp; --libexecdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; program
executables in DIR [EPREFIX/libexec]
&nbsp; --
datadir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; read-
only architecture-independent data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[PREFIX/share]
&nbsp; --sysconfdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; read-only
single-machine data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[PREFIX/etc]
&nbsp; --sharedstatedir=DIR&nbsp;&nbsp; modifiable architecture-
independent data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[PREFIX/com]
&nbsp; --localstatedir=DIR&nbsp;&nbsp;&nbsp; modifiable single-machine
data in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[PREFIX/var]
&nbsp; --
libdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
object code libraries in DIR [EPREFIX/lib]
&nbsp; --includedir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C header
files in DIR [PREFIX/include]
&nbsp; --oldincludedir=DIR&nbsp;&nbsp;&nbsp; C header files for non-gcc
in DIR
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[/usr/include]
&nbsp; --
infodir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; info
documentation in DIR [PREFIX/info]
&nbsp; --
mandir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
man documentation in DIR [PREFIX/man]
&nbsp; --
srcdir=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
find the sources in DIR [configure dir or ..]
&nbsp; --program-prefix=PREFIX prepend PREFIX to installed program names
&nbsp; --program-suffix=SUFFIX append SUFFIX to installed program names
&nbsp; --program-transform-name=PROGRAM run sed PROGRAM on installed
program
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
names
Host type
&nbsp; --
build=BUILD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
configure for building on BUILD [BUILD=HOST]
&nbsp; --
host=HOST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp; configure for HOST [guessed]
&nbsp; --target=TARGET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
configure for TARGET [TARGET=HOST]</PRE>
<PRE>Features and packages
&nbsp; --disable-FEATURE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not include
FEATURE (same as --enable-
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FEATURE=no)
&nbsp; --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
&nbsp; --with-PACKAGE[=ARG]&nbsp;&nbsp; use PACKAGE [ARG=yes]
&nbsp; --without-PACKAGE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not use
PACKAGE (same as --with-PACKAGE=no)
&nbsp; --x-includes=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; X include
files are in DIR
&nbsp; --x-libraries=DIR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; X library files
are in DIR
--enable- and --disable- with options recognized
&nbsp;&nbsp;&nbsp;&nbsp;
debugging&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Include debugging code [enable]
&nbsp;&nbsp;&nbsp;&nbsp; gdt-
surveying&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Include GDT survey code
[disable]
&nbsp;&nbsp;&nbsp;&nbsp;
md5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; Include support for MD5 keys [enable]
&nbsp;&nbsp;&nbsp;&nbsp;
des&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; Include support for DES keys [enable]
&nbsp;&nbsp;&nbsp;&nbsp; all-
clocks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Include
drivers for all reference clocks
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[enable]
&nbsp; Radio Clocks (these are ordinarily enabled, if supported by the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
machine and operating system)
&nbsp;&nbsp;&nbsp;&nbsp;
ACTS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; NIST dialup clock
&nbsp;&nbsp;&nbsp;&nbsp;
ARBITER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; Arbiter 1088A/B GPS receiver
&nbsp;&nbsp;&nbsp;&nbsp;
AS2201&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; Austron 2200A or 2201A GPS receiver
&nbsp;&nbsp;&nbsp;&nbsp;
ATOM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; ATOM clock
&nbsp;&nbsp;&nbsp;&nbsp;
BANCOMM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; BANCOMM clock
&nbsp;&nbsp;&nbsp;&nbsp;
CHU&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; CHU clock
&nbsp;&nbsp;&nbsp;&nbsp;
DATUM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; Datum Programmable Time System
&nbsp;&nbsp;&nbsp;&nbsp;
DCF7000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; ELV/DCF7000
&nbsp;&nbsp;&nbsp;&nbsp;
GPSVME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; GPS-VME Clock
&nbsp;&nbsp;&nbsp;&nbsp;
HEATH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; HeathKit GC-1000 Most Accurate Clock
&nbsp;&nbsp;&nbsp;&nbsp;
HOPF6021&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; HOPF6021 Radio Clock support
&nbsp;&nbsp;&nbsp;&nbsp;
HPGPS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; HP 58503A GPS Time &amp; Frequency receiver
&nbsp;&nbsp;&nbsp;&nbsp;
IRIG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; IRIG (Audio) Clock
&nbsp;&nbsp;&nbsp;&nbsp;
LEITCH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; Leitch CSD 5300 Master Clock System Driver
&nbsp;&nbsp;&nbsp;&nbsp; LOCAL-
CLOCK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local Clock driver
&nbsp;&nbsp;&nbsp;&nbsp;
MEINBERG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Meinberg clocks
&nbsp;&nbsp;&nbsp;&nbsp;
MSFEES&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; MSFEES clock
&nbsp;&nbsp;&nbsp;&nbsp;
MOTO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; Motorola GPS clock
&nbsp;&nbsp;&nbsp;&nbsp;
MX4200&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; MX4200 clock
&nbsp;&nbsp;&nbsp;&nbsp;
NMEA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; NMEA GPS clock
&nbsp;&nbsp;&nbsp;&nbsp;
PARSE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp; PARSE clock code
&nbsp;&nbsp;&nbsp;&nbsp;
PST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp; PST/Traconex 1020 WWV/H receiver
&nbsp;&nbsp;&nbsp;&nbsp;
PTBACTS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; PTB dialup clock support
&nbsp;&nbsp;&nbsp;&nbsp;
RAWDCF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; use raw DCF77 time code
&nbsp;&nbsp;&nbsp;&nbsp;
RCC8000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp; RCC8000 Radio Clock support
&nbsp;&nbsp;&nbsp;&nbsp;
SCHMID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; SCHMID DCF77 clock support
&nbsp;&nbsp;&nbsp;&nbsp;
TRAK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; TRAK 8810 GPS station clock
&nbsp;&nbsp;&nbsp;&nbsp;
TPRO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; KSI/Odetics TPRO/S IRIG Interface
&nbsp;&nbsp;&nbsp;&nbsp;
TRIMTAIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Trimble GPS/TAIP Protocol
&nbsp;&nbsp;&nbsp;&nbsp;
TRIMTSIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Trimble GPS/TSIP Protocol
&nbsp;&nbsp;&nbsp;&nbsp;
TRUETIME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p; Kinemetrics/TrueTime (generic) receiver
&nbsp;&nbsp;&nbsp;&nbsp;
WWVB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; Spectracom 8170 or Netclock/2 WWVB receiver
&nbsp;&nbsp;&nbsp;&nbsp;
USNO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; US Naval Observatory dialup clock
&nbsp; Miscellany
&nbsp;&nbsp;&nbsp;&nbsp; accurate-adjtime&nbsp;&nbsp;&nbsp; The
adjtime() call is accurate
&nbsp;&nbsp;&nbsp;&nbsp;
kmem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp; Read kmem
&nbsp;&nbsp;&nbsp;&nbsp;
tick=VALUE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Force a
value for 'tick'
&nbsp;&nbsp;&nbsp;&nbsp;
tickadj=VALUE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Force a value for
'tickadj'
&nbsp;&nbsp;&nbsp;&nbsp; udp-
wildcard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Use UDP wildcard
delivery
&nbsp;&nbsp;&nbsp;&nbsp; slew-
always&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Always slew the
time
&nbsp;&nbsp;&nbsp;&nbsp; step-
slew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Step
and slew the time
&nbsp;&nbsp;&nbsp;&nbsp; ntpdate-
step&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If ntpdate should step
the time
&nbsp;&nbsp;&nbsp;&nbsp; hourly-todr-sync&nbsp;&nbsp;&nbsp; If we should
sync TODR hourly</PRE>
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

215
dist/ntp/html/confopt.htm vendored
View File

@ -1,215 +0,0 @@
<html><head><title>
Configuration Options
</title></head><body><h3>
Configuration Options
</h3><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.
<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 some options are not
supported by all these commands while autokey and burst modes are
supported by these commands,
their effect in some weird mode combinations can be meaningless
or even destructive.
<dl>
<dt><tt>peer <i>address</i> [key <i>key</i> | autokey | publickey
<i>keyfile</i>] [burst] [version <i>version</i>] [prefer] [minpoll
<i>minpoll</i>] [maxpoll <i>maxpoll</i>]</tt></dt>
<p><dt><tt>server <i>address</i> [key <i>key</i> | autokey | publickey
<i>keyfile</i>] [burst] [version <i>version</i>] [prefer] [minpoll
<i>minpoll</i>] [maxpoll <i>maxpoll</i>] [publickey
<i>keyfile</i>]</tt></dt>
<p><dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey] [burst]
[version <i>version</i>] [minpoll <i>minpoll</i>] [maxpoll
<i>maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
<p><dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey |
publickey <i>keyfile</i>] [burst] [version <i>version</i>] [minpoll
<i>minpoll</i> [maxpoll <i>maxpoll</i>] [ttl <i>ttl</i>] [publickey
<i>file</i>]</tt></dt>
<p><<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.</dd>
<dd><dl>
<dt><tt>server</tt></dt>
<dd>For type s and r addresses, this operates as the NTPv3 server
command, which mobilizes a persistent client mode association. The
<tt>server</tt> command specifies that the local server is to operate in
client mode with the specified remote server. In this mode, the local
server can be synchronized to the remote server, but the remote server
can never be synchronized to the local server.</dd>
<dt><tt>peer</tt></dt>
<dd>For type s addresses (only), this operates as the current <tt>peer
</tt>command, which mobilizes a persistent symmetric-active mode
association, except that additional modes are available. This command
should NOT be used for type <tt>b</tt>, <tt>m</tt> or <tt>r</tt>
addresses.</dd>
<p><dd>The <tt>peer</tt> command specifies that the local server is to
operate in symmetric active mode with the remote server. In this mode,
the local server can be synchronized to the remote server and, in
addition, the remote server can be synchronized by the local server.
This is useful in a network of servers where, depending on various
failure scenarios, either the local or remote server may be the better
source of time.</dd>
<dt><tt>broadcast</tt></dt>
<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this operates
as the current NTPv3 <tt>broadcast </tt>command, which mobilizes a
persistent broadcast mode association, except that additional modes are
available. Multiple commands can be used to specify multiple local
broadcast interfaces (subnets) and/or multiple multicast groups. Note
that local broadcast messages go only to the interface associated with
the subnet specified, but multicast messages go to all interfaces. In
the current implementation, the source address used for these messages
is the Unix host default address.</dd>
<p><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>
<dd>For type <tt>m</tt> addresses (only), this mobilizes a manycast
client-mode association for the multicast address specified. In this
case a specific address must be supplied which matches the address used
on the <tt>manycastserver </tt>command for the designated manycast
servers. The NTP multicast address 224.0.1.1 assigned by the IANA should
NOT be used, unless specific means are taken to avoid spraying large
areas of the Internet with these messages and causing a possibly massive
implosion of replies at the sender. </dd>
<p><dd>The <tt>manycast </tt>command specifies that the local server is
to operate in client mode with the remote server that are discovered as
the result of broadcast/multicast messages. The client broadcasts a
request message to the group address associated with the specified
<i><tt>address </tt></i>and specifically enabled servers respond to
these messages. The client selects the servers providing the best time
and continues as with the <tt>server </tt>command. The remaining servers
are discarded as if never heard.</dd>
</dl>
<dd>Options</dd>
<dl><dd>
<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>At each poll interval, send a burst of eight packets spaced, instead
of the usual one.</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>
<dd>These options specify the minimum and maximum polling intervals for
NTP messages, in seconds to the power of two. The default range is 6 (64
s) to 10 (1,024 s). The allowable range is 4 (16 s) to 17 (36.4 h)
inclusive.</dd>
<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>publickey <I>file</I></TT></DT>
<DD>This command requires the NTP daemon build process be configured
with the RSA library. The command specifies the name of the public key
file for the server or peer. The default name for this file is
<tt>ntpkey_<i>host</i></tt>, where <i>host</i> is the DNS canonical name
of the server or peer. See the <a href=authopt.htm>Authentication
Options</a> page for further information.</dd>
<dt><tt>ttl <i>ttl</i></tt></dt>
<dd>This option is used only with broadcast mode. It specifies the
time-to-live <i><tt>ttl</tt></i> to use on multicast packets. Selection
of the proper value, which defaults to 127, is something of a black art
and must be coordinated with the network administrator.</dd>
<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></dd>
<h4>Auxilliary Commands</h4>
<dl>
<dt><tt>broadcastclient</tt>
<dd>This command directs the local server to listen for and respond to
broadcast messages received on any local interface. Upon hearing a
broadcast message for the first time, the local server measures the
nominal network delay using a brief client/server exchange with the
remote server, then enters the broadcastclient mode, in which it listens
for and synchronizes to succeeding broadcast messages. Note that, in
order to avoid accidental or malicious disruption in this mode, both the
local and remote servers should operate using authentication and the
same trusted key and key identifier.</dd>
<dt><tt>manycastserver <i>address</i> [...]</tt>
<dd>This command directs the local server to listen for and respond to
broadcast messages received on any local interface, and in addition
enables the server to respond to client mode messages to the multicast
group address(es) (type m) specified. At least one address is required,
but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT
be used, unless specific means are taken to limit the span of the reply
and avoid a possibly massive implosion at the original sender.</dd>
<dt><tt>multicastclient [<i>address</i>] [...]</tt>
<dd>This command directs the local server to listen for multicast
messages at the group address(es) of the global network. The default
address is that assigned by the Numbers Czar to NTP (224.0.1.1). This
command operates in the same way as the <tt>broadcastclient</tt>
command, but uses IP multicasting. Support for this command requires
multicast kernel support.</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.
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

209
dist/ntp/html/copyright.htm vendored
View File

@ -1,209 +0,0 @@
<html><head>
<title>Copyright Notice</title>
</head>
<body>
<h3>Copyright Notice</h3>
<P>The following copyright notice applies to all files collectively
called the Network Time Protocol Version 4 Distribution. Unless
specifically declared otherwise in an individual file, this notice
applies as if the text was explicitly included in the file.
<br>
<PRE>
/***********************************************************************
* *
* Copyright (c) David L. Mills 1992-2000 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission *
* notice appear in supporting documentation, and that the name *
* University of Delaware not be used in advertising or publicity *
* pertaining to distribution of the software without specific, *
* written prior permission. The University of Delaware makes no *
* representations about the suitability this software for any *
* purpose. It is provided "as is" without express or implied *
* warranty. *
* *
***********************************************************************
*/
</PRE>
The following individuals contributed in part to the Network Time
Protocol Distribution Version 4 and are acknowledged as authors of this
work.
<OL>
<LI><A HREF="mailto: marka@syd.dms.csiro.au">Mark Andrews
&lt;marka@syd.dms.csiro.au&gt;</a> Leitch atomic clock controller</LI>
<LI><A HREF="mailto: vbais@mailman1.intel.co">Viraj Bais
&lt;vbais@mailman1.intel.com&gt;</a> and <A HREF="mailto:
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: 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: 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: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="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: 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>Home</a>
<address>
<a href="mailto:mills@udel.edu">David L. Mills &lt;mills@udel.edu&gt;</a>
</address>
</body>
</html>

284
dist/ntp/html/debug.htm vendored
View File

@ -1,284 +0,0 @@
<HTML><HEAD><TITLE>
NTP Debugging Techniques
</TITLE></HEAD><BODY><H3>
NTP Debugging Techniques
</H3>
<P>Once the NTP software distribution has been compiled and installed
and the configuration file constructed, the next step is to verify
correct operation and fix any bugs that may result. Usually, the command
line that starts the daemon is included in the system startup file, so
it is executed only at system boot time; however, the daemon can be
stopped and restarted from root at any time. Usually, no command-line
arguments are required, unless special actions described in the
<TT><A HREF="ntpd.htm">ntpd</A></TT> page are required. Once started,
the daemon will begin sending messages, as specified in the
configuration file, and interpreting received messages.
<P>The best way to verify correct operation is using the <TT><A
HREF="ntpq.htm">ntpq</A></TT> and <TT><A HREF="ntpdc.htm">ntpdc</A></TT>
utility programs, either on the server itself or from another machine
elsewhere in the network. The <TT>ntpq</TT> program implements the
management functions specified in Appendix A of the NTP specification <A
HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps"
>
RFC-1305, Appendix A</A>. The <TT>ntpdc</TT> program implements
additional functions not provided in the standard. Both programs can be
used to inspect the state variables defined in the specification and, in
the case of <TT>ntpdc</TT>, additional ones of interest. In addition,
the <TT>ntpdc</TT> program can be used to selectively enable and disable
some functions of the daemon while the daemon is running.
<P>In extreme cases with elusive bugs, the daemon can operate in two
modes, depending on the presence of the <TT>-d</TT> command-line debug
switch. If not present, the daemon detaches from the controlling
terminal and proceeds autonomously. If one or more <TT>-d</TT> switches
are present, the daemon does not detach and generates special output
useful for debugging. In general, interpretation of this output requires
reference to the sources. However, a single <TT>-d</TT> does produce
only mildly cryptic output and can be very useful in finding problems
with configuration and network troubles. With a little experience, the
volume of output can be reduced by piping the output to <TT>grep
</TT>and specifying the keyword of the trace you want to see.
<P>Some problems are immediately apparent when the daemon first starts
running. The most common of these are the lack of a ntp (UDP port 123)
in the host <TT>/etc/services</TT> file. Note that NTP does not use TCP
in any form. Other problems are apparent in the system log file. The log
file should show the startup banner, some cryptic initialization data,
and the computed precision value. The next most common problem is
incorrect DNS names. Check that each DNS name used in the configuration
file responds to the Unix <TT>ping</TT> command.
<P>When first started, the daemon normally polls the servers listed in
the configuration file at 64-second intervals. In order to allow a
sufficient number of samples for the NTP algorithms to reliably
discriminate between correctly operating servers and possible intruders,
at least four valid messages from at least one server is required before
the daemon can set the local clock. However, if the current local time
is greater than 1000 seconds in error from the server time, the daemon
will not set the local clock; instead, it will plant a message in the
system log and shut down. It is necessary to set the local clock to
within 1000 seconds first, either by a time-of-year hardware clock, by
first using the <A HREF="ntpdate.htm"><TT>ntpdate</TT> </A>program or
manually be eyeball and wristwatch.
<P>After starting the daemon, run the <TT>ntpq</TT> program using the
<TT>-n</TT> switch, which will avoid possible distractions due to name
resolution problems. Use the <TT>pe</TT> command to display a billboard
showing the status of configured peers and possibly other clients poking
the daemon. After operating for a few minutes, the display should be
something like:
<PRE>ntpq>pe
remote refid st t when poll reach delay offset disp
===================================================================
+128.4.2.6 132.249.16.1 2 u 131 256 373 9.89 16.28 23.25
*128.4.1.20 .WWVB. 1 u 137 256 377 280.62 21.74 20.23
-128.8.2.88 128.8.10.1 2 u 49 128 376 294.14 5.94 17.47
+128.4.2.17 .WWVB. 1 u 173 256 377 279.95 20.56 16.40
</PRE>
The host addresses shown in the <TT>remote</TT> column should agree with
the DNS entries in the configuration file, plus any peers not mentioned
in the file at the same or lower than your stratum that happen to be
configured to peer with you. Be prepared for surprises in cases where
the peer has multiple addresses or multiple names. The <TT>refid</TT>
entry shows the current source of synchronization for each peer, while
the <TT>st</TT> reveals the stratum, <TT>t</TT> the type (<TT>u</TT> =
unicast, <TT>m</TT> = multicast, <TT>l</TT> = local, <TT>-</TT> = don't
know), and <TT>poll</TT> the polling interval in seconds. The
<TT>when</TT> entry shows the time since the peer was last heard,
normally in seconds, while the <TT>reach</TT> entry shows the status of
the reachability register (see RFC-1305) in octal. The remaining entries
show the latest delay, offset and dispersion computed for the peer in
milliseconds. Note that in NTP Version 4 the dispersion entry includes
only the RMS error component; earlier versions included all components.
<P>The tattletale character at the left margin displays the
synchronization status of each peer. The currently selected peer is
marked <TT>*</TT>, while additional peers designated acceptable for
synchronization, but not currently selected, are marked <TT>+</TT>.
Peers marked <TT>*</TT> and <TT>+</TT> are included in a weighted
average computation to set the local clock; the data produced by peers
marked with other symbols are discarded. See the <TT>ntpq</TT>
documentation for the meaning of these symbols.
<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
<PRE>ntpq>as
ind assID status conf reach auth condition last_event cnt
=========================================================
1 11670 7414 no yes ok candidate reachable 1
2 11673 7614 no yes ok sys.peer reachable 1
3 11833 7314 no yes ok outlyer reachable 1
4 11868 7414 no yes ok candidate reachable 1
</PRE>
Each line in this billboard is associated with the corresponding line
the <TT>pe</TT> billboard above. Next, use the <TT>rv</TT> command and
the respective identifier to display a detailed synopsis of the selected
peer, such as
<PRE>ntpq>rv 11670
status=7414 reach, auth, sel_sync, 1 event, event_reach
srcadr=128.4.2.6, srcport=123, dstadr=128.4.2.7, dstport=123, keyid=1,
stratum=2, precision=-10, rootdelay=362.00, rootdispersion=21.99,
refid=132.249.16.1,
reftime=af00bb44.849b0000 Fri, Jan 15 1993 4:25:40.517,
delay= 9.89, offset= 16.28,
dispersion=23.25, reach=373, valid=8,
hmode=2, pmode=1, hpoll=8, ppoll=10, leap=00, flash=0x0,
org=af00bb48.31a90000 Fri, Jan 15 1993 4:25:44.193,
rec=af00bb48.305e3000 Fri, Jan 15 1993 4:25:44.188,
xmt=af00bb1e.16689000 Fri, Jan 15 1993 4:25:02.087,
filtdelay= 16.40 9.89 140.08 9.63 9.72 9.22 10.79 122.99,
filtoffset= 13.24 16.28 -49.19 16.04 16.83 16.49 16.95 -39.43,
filterror= 16.27 20.17 27.98 31.89 35.80 39.70 43.61 47.52
</PRE>
A detailed explanation of the fields in this billboard are beyond the
scope of this discussion; however, most variables defined in the
specification RFC-1305 can be found. The most useful portion for
debugging is the last three lines, which give the roundtrip delay, clock
offset and dispersion for each of the last eight measurement rounds, all
in milliseconds. Note that the dispersion, which is an estimate of the
error, increases as the age of the sample increases. From these data, it
is usually possible to determine the incidence of severe packet loss,
network congestion, and unstable local clock oscillators. There are no
hard and fast rules here, since every case is unique; however, if one or
more of the rounds show zeros, or if the clock offset changes
dramatically in the same direction for each round, cause for alarm
exists.
<P>Finally, the state of the local clock can be determined using the
<TT>rv</TT> command (without the argument), such as
<PRE>ntpq>rv
status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg
system="UNIX", leap=00, stratum=2, rootdelay=280.62,
rootdispersion=45.26, peer=11673, refid=128.4.1.20,
reftime=af00bb42.56111000 Fri, Jan 15 1993 4:25:38.336,
poll=8, clock=af00bbcd.8a5de000 Fri, Jan 15 1993 4:27:57.540,
phase=21.147, freq=13319.46, compliance=2
</PRE>
The most useful data in this billboard show when the clock was last
adjusted <TT>reftime</TT>, together with its status and most recent
exception event. An explanation of these data is in the specification
RFC-1305.
<P>When nothing seems to happen in the <TT>pe</TT> billboard after some
minutes, there may be a network problem. The most common network problem
is an access controlled router on the path to the selected peer. No
known public NTP time server selectively restricts access at this time,
although this may change in future; however, many private networks do.
It also may be the case that the server is down or running in
unsynchronized mode due to a local problem. Use the <TT>ntpq</TT>
program to spy on its own variables in the same way you can spy on your
own.
<P>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>It has sometimes been the experience that the local clock oscillator
frequency error is too large for the NTP discipline algorithm, which can
correct frequency errors as large as 43 seconds per day. There are two
possibilities that may result in this problem. First, the hardware time-
of-year clock chip must be disabled when using NTP, since this can
destabilize the discipline process. This is usually done using the
<TT><A HREF="tickadj.htm">tickadj</A></TT> program and the <TT>-s</TT>
command line argument, but other means may be necessary. For instance,
in the Sun Solaris kernel, this can be done using a command in the
system startup file.
<P>Normally, the daemon will adjust the local clock in small steps in
such a way that system and user programs are unaware of its operation.
The adjustment process operates continuously as long as the apparent
clock error exceeds 128 milliseconds, which for most Internet paths is a
quite rare event. If the event is simply an outlyer due to an occasional
network delay spike, the correction is simply discarded; however, if the
apparent time error persists for an interval of about 20 minutes, the
local clock is stepped to the new value (as an option, the daemon can be
compiled to slew at an accelerated rate to the new value, rather than be
stepped). This behavior is designed to resist errors due to severely
congested network paths, as well as errors due to confused radio clocks
upon the epoch of a leap second.
<H4>Debugging Checklist</H4>
If the <TT>ntpq</TT> or <TT>ntpdc</TT> programs do not show that
messages are being received by the daemon or that received messages do
not result in correct synchronization, verify the following:
<OL>
<P><LI>Verify the <TT>/etc/services</TT> file host machine is configured
to
accept UDP packets on the NTP port 123. NTP is specifically designed to
use UDP and does not respond to TCP.</LI>
<P><LI>Check the system log for <TT>ntpd</TT> messages about
configuration
errors, name-lookup failures or initialization problems.</LI>
<P><LI>Using the <TT>ntpdc</TT> program and <TT>iostats</TT> command,
verify that the received packets and packets sent counters are
incrementing. If the packets send counter does not increment and the
configuration file includes designated servers, something may be wrong
in the network configuration of the ntpd host. If this counter does
increment and packets are actually being sent to the network, but the
received packets counter does not increment, something may be wrong in
the network or the server may not be responding.</LI>
<P><LI>If both the packets sent counter and received packets counter do
increment, but the <TT>rec</TT> timestamp in the <TT>pe</TT> billboard
shows far from the current date, received packets are probably being
discarded for some reason. There is a handy, undocumented state variable
<TT>flash</TT> visible in the <TT>pe</TT>billboard. The value is in hex
and normally has the value zero (OK). However, if something is wrong,
the bits of this variable, reading from the right, correspond to the
sanity checks listed in Section 3.4.3 of the NTP specification <A
HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps"
>RFC-1305</A>. A bit other than zero indicates the associated sanity
check failed.</LI>
<P><LI>If the <TT>org, rec</TT> and <TT>xmt</TT> timestamps in the
<TT>pe</TT> billboard appear current, but the local clock is not set, as
indicated by a stratum number less than 16 in the <TT>rv</TT> command
without arguments, verify that valid clock offset, roundtrip delay and
dispersion are displayed for at least one peer. The clock offset should
be less than 1000 seconds, the roundtrip delay less than one second and
the dispersion less than one second.</LI>
<P><LI>While the algorithm can tolerate a relatively large frequency
error (up to 500 parts per million or 43 seconds per day), various
configuration errors (and in some cases kernel bugs) can exceed this
tolerance, leading to erratic behavior. This can result in frequent loss
of synchronization, together with wildly swinging offsets. Use the
<TT>ntpdc</TT> program (or temporary configuration file) and <TT>disable
pll</TT> command to prevent the <TT>ntpd</TT> daemon from setting the
clock. Using the <TT>ntpq</TT> or <TT>ntpdc</TT> programs, watch the
apparent offset as it varies over time to determine the intrinsic
frequency error. If the error increases by more than 22 milliseconds per
64-second poll interval, the intrinsic frequency must be reduced by some
means. The easiest way to do this is with the <TT><A
HREF="tickadj.htm">tickadj</A></TT> program and the <TT>-t</TT>
command line argument.</LI>
</OL>
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

157
dist/ntp/html/driver1.htm vendored
View File

@ -1,157 +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>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>
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>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>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>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>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>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>This driver provides a mechanism to trim the local clock in both time
and frequency, as well as a way to manipulate the leap bits. The <TT>fudge
time1</TT> parameter adjusts the time (in seconds) and the <TT>fudge time2</TT>
parameter adjusts the frequency (in parts per million). Both parameters
are additive and operate only once; that is, each command (as from <TT>ntpdc</TT>)
adds signed increments in time or frequency to the nominal local clock
time and frequency.
<H4>
Monitor Data</H4>
No <TT>filegen clockstats</TT> monitor data are produced by this driver.
<H4>
Fudge Factors</H4>
<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>
<P>Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A></DL>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</BODY>
</HTML>

114
dist/ntp/html/driver10.htm vendored
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
dist/ntp/html/driver11.htm vendored
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
dist/ntp/html/driver12.htm vendored
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
dist/ntp/html/driver16.htm vendored
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
dist/ntp/html/driver18.htm vendored
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
dist/ntp/html/driver19.htm vendored
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
dist/ntp/html/driver2.htm vendored
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>

131
dist/ntp/html/driver20.htm vendored
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>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.
The driver expect 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>The $GPRMC message that the GPS transmits look like this:
<PRE>$GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC&lt;cr>&lt;lf>
&nbsp; POS_UTC&nbsp; - UTC of position. Hours, minutes and seconds. (hhmmss)
&nbsp; POS_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; CC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Checksum (optional)
&nbsp; &lt;cr>&lt;lf> - Sentence terminator.</PRE>
The driver will send a <TT>$PMOTG,RMC,0000*1D&lt;cr>&lt;lf></TT> message
each time a <TT>$GPRMC</TT> string is needed. This is not needed on most
GPS receivers because they automatically send the <TT>$GPRMC</TT> string
every second and will only work on GPS receivers that understand the <TT>$PMOTG</TT>
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 $GPRMC string 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>
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>

129
dist/ntp/html/driver22.htm vendored
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>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 Port: <TT>/dev/pps<I>u</I></TT>; 9600 baud, 8-bits, no parity
<BR>Features: <TT>tty_clk</TT>
<H4>
Description</H4>
This driver furnishes an interface for pulse-per-second (PPS) signals produced
by a cesium clock, radio clock or related equipment. It can be used to
remove accumulated jitter and retime a secondary server when synchronized
to a primary server over a congested, wide-area network and before redistributing
the time to local clients.
<P>In order for this driver to work, the local clock must be set to within
+-500 ms by another means, such as a radio clock or NTP itself. The PPS
signal is connected via a serial port and <A HREF="gadget.htm">gadget box</A>
consisting of a one-shot and RS232 level converter. When operated at 38.4
kbps with a SPARCstation IPC, this arrangement has a worst-case jitter
less than 26 us.
<P>There are three ways in which this driver can be used. The first way
uses the <TT>ppsclock</TT> line discipline and works only for the baseboard
serial ports of the Sun SPARCstation running SunOS 4.x. The PPS signal
is connected via the gadget box to the carrier detect (DCD) line of a serial
port. The signal is activated for this port by a <TT>fudge flag3 1</TT>
command following the <TT>server</TT> command in the configuration file.
This causes the <TT>ppsclock</TT> streams module to be configured for that
port and to capture a timestamp at the on-time transition of the PPS signal.
This driver then reads the timestamp directly by a designated <TT>ioctl()</TT>
system call. This provides the most accurate time and least jitter of any
other scheme. There is no need to configure a dedicated device for this
purpose, which ordinarily is the device used for the associated radio clock.
<P>The second way uses the <TT>tty_clk</TT> line discipline and works for
any architecture supporting a serial port. If after a few seconds this
driver finds no <TT>ppsclock</TT> module configured, it attempts to open
a serial port device <TT>/dev/pps%d</TT>, where <TT>%d</TT> is the unit
number, and assign the <TT>tty_clk</TT> line discipline to it. If the line
discipline fails, no harm is done except the accuracy is reduced somewhat.
The pulse generator in the gadget box must be adjusted to produce a start
bit of length 26 usec at 38400 bps. Used with the <TT>tty_clk</TT> line
discipline, this produces an ASCII DEL character ('\377') followed by a
timestamp at the on-time transition of the PPS signal.
<P>The third way involves an auxiliary radio clock driver which calls the
PPS driver with a timestamp captured by that driver. This use is documented
in the source code for the driver(s) involved.
<H4>
Fudge Factors</H4>
<DL>
<DT>
<TT>time1 <I>time</I></TT></DT>
<DD>
Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0. This parameter can be used to compensate for the UART
and OS delays. Allow about 247 us for UART delays at 38400 bps and about
1 ms for SunOS streams nonsense.</DD>
<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>
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>

178
dist/ntp/html/driver23.htm vendored
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
dist/ntp/html/driver24.htm vendored
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
dist/ntp/html/driver26.htm vendored
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
dist/ntp/html/driver27.htm vendored
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
dist/ntp/html/driver28.htm vendored
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>

1251
dist/ntp/html/driver29.htm vendored
View File

File diff suppressed because it is too large Load Diff

131
dist/ntp/html/driver3.htm vendored
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>

158
dist/ntp/html/driver30.htm vendored
View File

@ -1,158 +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.0<BR>
Reference ID: <TT>GPS</TT><BR>
Driver ID: ONCORE<BR>
Serial Port: <TT>/dev/oncore.serial.0</TT>; &nbsp;9600 baud, 8-bits,
no parity.<BR>
PPS Port: <TT>/dev/oncore.pps.0</TT>;&nbsp; <TT>PPS_CAPTUREASSERT</TT>
required,&nbsp; <TT>PPS_OFFSETASSERT</TT> supported.
<H4>
Description</H4>
This driver supports various models of the <A
HREF="http://www.mot.com/AECS/PNSB/products">Motorola Oncore GPS
receivers</A> as long as they support the <I>Motorola Binary
Protocol</I>.
<P>The three most interesting versions of the Oncore are the "VP",&nbsp;
the "UT+",&nbsp;
and the "Remote" which is a prepackaged "UT+".&nbsp;
The "VP" is no longer available.
The 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>.
<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.
<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 is quite chatty on stdout if ntpd is run with debugging.
<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>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,&nbsp; 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
dist/ntp/html/driver32.htm vendored
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
dist/ntp/html/driver33.htm vendored
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>

54
dist/ntp/html/driver34.htm vendored
View File

@ -1,54 +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>Ultralink Clock</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.34.<i>u</i><br>
Reference ID: <TT>ULINK</TT><br>
Driver ID: <tt>ULINK</tt><br>
Serial Port: <tt>/dev/ulink<i>u</i></tt>; 9600 bps, 8-bits,
no parity<br>
<br>Features: <tt>(none)</tt>
<h4>Description</h4>
This driver supports the Ultralink Model 320 RS-232 powered WWVB receiver. PDF specs available on <a href="http://www.linuxfoundary.com">www.linuxfoundary.com</a>. While the unit may support them, this driver does nothing with leap seconds, quality codes, etc. (though it probably should).
<P>Most of this code is originally from refclock_wwvb.c with thanks. Any mistakes are mine. Any improvements are welcome.
<pre>
The 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 L or T flags.
The M320 also has a 'U' command which returns UT1 correction information. It
is not used in this driver.
</pre>
<hr>
<address><a href="mailto:dstrout@linuxfoundary.com">root</a></address>
<!-- hhmts start -->
Last modified: Tue Sep 14 05:53:08 EDT 1999
<!-- hhmts end -->
</body> </html>

82
dist/ntp/html/driver35.htm vendored
View File

@ -1,82 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<title>Conrad parallel port radio clock</title>
</head>
<body>
<h3>Conrad parallel port radio clock</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.35.<i>u</i><br>
Reference ID: <tt>PCF</tt><br>
Driver ID: <tt>PCF</tt><br>
Parallel Port: <tt>/dev/pcfclock<i>u</i></tt>
</p>
<h4>Description</h4>
<p>This driver supports the parallel port radio clocks sold by <a
href="http://www.conrad-electronic.com/">Conrad Electronic</a> under
order numbers 967602 and 642002. The battery-powered radio clock is
put between a parallel port and your printer. It receives the legal
German time, which is either CET or CEST, from the DCF77 transmitter
and uses it to set internal quartz clock. The DCF77 transmitter is
located near to Frankfurt/Main and covers a radius of more than 1500
kilometers.
<p>The driver requires that the pcfclock device driver be installed.
A device driver for Linux&nbsp;2.2 is available at
<a href="http://home.pages.de/~voegele/pcf.html">the pcfclock driver
page</a>.
</p>
<p>The driver uses C library functions to convert the received
timecode to UTC and therefore requires that the local timezone be
CET/CEST. If your server is not located in Central Europe, you have
to set the environment variable TZ to CET before <tt>ntpd</tt> is
started.</p>
<h4>Monitor Data</h4>
<p>Each timecode is written to the <tt>clockstats</tt> file in the format
<tt>YYYY MM DD HH MI SS</tt>.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt></dt>
<dd>Specifies the time offset calibration factor, in seconds and fraction,
with default 0.0.</dd>
<dt><tt>time2 <i>time</i></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <i>number</i></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
</dd>
<dt><tt>refid <i>string</i></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from one to
four characters, with default <tt>PCF</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
</dl>
<hr>
<address>Andreas Voegele (andreas.voegele@gmx.de)</address>
</body>
</html>

844
dist/ntp/html/driver36.htm vendored
View File

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

75
dist/ntp/html/driver37.htm vendored
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>

126
dist/ntp/html/driver4.htm vendored
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>

159
dist/ntp/html/driver5.htm vendored
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>

242
dist/ntp/html/driver6.htm vendored
View File

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

596
dist/ntp/html/driver7.htm vendored
View File

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

334
dist/ntp/html/driver8.htm vendored
View File

@ -1,334 +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>
<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>
<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>
<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>
<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>
<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>
<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>Home</a><address><a
href="mailto:mills@udel.edu"> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></body></html>

123
dist/ntp/html/driver9.htm vendored
View File

@ -1,123 +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/">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>
<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>

284
dist/ntp/html/exec.htm vendored
View File

@ -1,284 +0,0 @@
<html><head><title>
Executive Summary - Computer Network Time Synchronization
</title></head><body><H3>
Executive Summary - Computer Network Time Synchronization
</h3>
<h4>Introduction</h4>
<p>The standard timescale used by most nations of the world is Universal
Coordinated Time (UTC), which is based on the Earth's rotation about its
axis, and the Gregorian Calendar, which is based on the Earth's rotation
about the Sun. The UTC timescale is disciplined with respect to
International Atomic Time (TAI) by inserting leap seconds at intervals
of about 18 months. UTC time is disseminated by various means, including
radio and satellite navigation systems, telephone modems and portable
clocks.
<p>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.)
<h4>Protocol Design Issues</h4>
<p>The synchronization protocol determines the time offset of the server
clock relative to the client clock. The various synchronization
protocols in use today provide different means to do this, but they all
follow the same general model. On request, the server sends a message
including its current clock value or <i>timestamp</i> and the client
records its own timestamp upon arrival of the message. For the best
accuracy, the client needs to measure the server-client propagation
delay to determine its clock offset relative to the server. Since it is
not possible to determine the one-way delays, unless the actual clock
offset is known, the protocol measures the total roundtrip delay and
assumes the propagation times are statistically equal in each direction.
In general, this is a useful approximation; however, in the Internet of
today, network paths and the associated delays can differ significantly
due to the individual service providers.
<p>The 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>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>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.
<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>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>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.
<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>In the Probabilistic Clock Synchronization (PCS) scheme devised by
Cristian, a maximum error tolerance is established in advance and time
value samples associated with roundtrip delays that exceed twice this
value are discarded. By the above argument, the remaining samples must
represent time values within the specified tolerance. As the tolerance
is decreased, more samples fail the test until a point where no samples
survive. The tolerance can be adjusted for the best compromise between
the highest accuracy consistent with acceptable sample survival rate.
<p>In a scheme devised by Marzullo and exploited in NTP and DTSS, the
worst-case error determined for each server determines a correctness
interval. If each of a number of servers are in fact synchronized to a
common timescale, the actual time must be contained in the intersection
of their correctness intervals. If some intervals do not intersect, then
the clique containing the maximum number of intersections is assumed
correct <i>truechimers</i> and the others assumed incorrect
<i>false<i>tick</i>ers</i>. Only the truechimers are used to adjust the
system
clock.
<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>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>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.
<h4>Further Reading</h4>
<ol>
<p><li>Cristian, F. Probabilistic clock synchronization. In Distributed
Computing 3, Springer Verlag, 1989, 146-158.</li>
<p><li>Digital Time Service Functional Specification Version T.1.0.5.
DigitalEquipment Corporation, 1989.</li>
<p><li>Gusella, R., and S. Zatti. TEMPO - A network time controller for
a distributed Berkeley UNIX system. IEEE Distributed Processing
Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in:
Proc. Summer 1984 USENIX (Salt Lake City, June 1984).</li>
<p><li>Kopetz, H., and W. Ochsenreiter. Clock synchronization in
distributed real-time systems. IEEE Trans. Computers C-36, 8 (August
1987), 933-939.</li>
<p><li>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
presence of faults. JACM 32, 1 (January 1985), 52-78.</li>
<p><li>Marzullo, K., and S. Owicki. Maintaining the time in a
distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-
54.</li>
<p><li>Mills, D.L. Internet time synchronization: the Network Time
Protocol. IEEE Trans. Communications COM-39, 10 (October 1991), 1482-
1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global States and
Time in Distributed Systems, IEEE Press, Los Alamitos, CA, 91-102.</li>
<p><li>Mills, D.L. Modelling and analysis of computer network clocks.
Electrical Engineering Department Report 92-5-2, University of Delaware,
May 1992, 29 pp.</li>
<p><li>NIST Time and Frequency Dissemination Services. NBS Special
Publication432 (Revised 1990), National Institute of Science and
Technology, U.S. Department of Commerce, 1990.</li>
<p><li>Schneider, F.B. A paradigm for reliable clock synchronization.
Department of Computer Science Technical Report TR 86-735, Cornell
University, February 1986.</li>
<p><li>Srikanth, T.K., and S. Toueg. Optimal clock synchronization. JACM
34, 3 (July 1987), 626-645.</li>
<p><li>Stein, S.R. Frequency and time - their measurement and
characterization (Chapter 12). In: E.A. Gerber and A. Ballato (Eds.).
Precision Frequency Control, Vol. 2, Academic Press, New York 1985, 191-
232, 399-416. Also in: Sullivan, D.B., D.W. Allan, D.A. Howe and F.L.
Walls (Eds.). Characterization of Clocks and Oscillators. National
Institute of Standards and Technology Technical Note 1337, U.S.
Government Printing Office (January, 1990), TN61-TN119.</li>
</ol>
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

40
dist/ntp/html/extern.htm vendored
View File

@ -1,40 +0,0 @@
<HTML><HEAD><TITLE>
External Clock Discipline and the Local Clock Driver
</TITLE></HEAD><BODY><H3>
External Clock Discipline and the Local Clock Driver
</H3><HR>
<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>When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon <tt>ntpd</tt> to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail synchronization service fall back to other means, such as a local reference clock or another NTP server. In addition, when the external clock and driver are in control, some means needs to be provided for the clock driver to pass on status information and error statistics to the NTP daemon.
<p>Control and monitoring functions for the external clock and driver are implemented using the Local Clock (type 1) driver and the <tt>ntp_adjtime()</tt> system call. This system call is implemented by special kernel provisions included in the kernel of several operating systems, including Solaris, Digital Unix, FreeBSD and Linux, and possibly others. When the external clock is disabled or not implemented, the system call is used to pass time and frequency information, as well as error statistics, to the kernel. Besides disciplining the system time, the same interface can be used by other applications to determine the operating parameters of the discipline. When the external clock is enabled, <tt>ntpd</tt> does not discipline the system clock, nor does it maintain the error statistics. In this case, the external clock and driver do this using mechanisms unknown to <tt>ntpd</tt>; however, in this case the kernel state variables are retrieved at 64-s intervals by the Local Clock driver and used by the clock selection and mitigation algorithms to determine the system variables presented to other NTP clients and peers. In this way, downstream clients and servers in the NTP subnet can make an intelligent choice when more than one server is available.
<p>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>ntp__enable. set/reset by enable command. enables ntp clock discipline
<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>The ntp_enable and kern_enable are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The pps_update switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The ntp_control switch is set during configuration by interrogating the kernel. If both the kern_enable and ntp_control siwitches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.
<p>The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the ntp_adjtime() system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero
d PLL/
<hr><a href=index.htm>Home</a><address><a
href="mailto:mills@udel.edu"> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></body></html>

107
dist/ntp/html/gadget.htm vendored
View File

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

152
dist/ntp/html/genkeys.htm vendored
View File

@ -1,152 +0,0 @@
<html><head><title>
<tt>ntp_genkeys</tt> - generate public and private keys
</title></head><body><h3>
<tt>ntp_genkeys</tt> - generate public and private keys
</h3><hr>
<h4>Synopsis</h4>
<tt>ntp_genkeys</tt>
<H4>Description</H4>
<p>The cryptographic values used by the <tt>autokey</tt> scheme are
incorporated as a set of four files generated by the
<tt>ntp_genkeys</tt> program, including <tt>ntp.keys</tt> containing the
DES/MD5 private keys, <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. The files contain cryptographic values generated by
the algorithms of the <tt>rsaref20</tt> package and are in printable
ASCII format. Since the algorythms are seeded by the system clock, each
run of this program will produce a different outcome. There are no
options or frills of any sort, although a number of options would seem
to be appropriate.
<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>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>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>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>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>Note: See the file <tt>./source/rsaref.h</tt> in the
<tt>rsaref20</tt> package for explanation of return values, if
necessary.
<H4>Private 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><I><TT>keyno type key</TT></I>
<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>The key may be given in one of three different formats, controlled by
the <I><TT>type</TT></I> character. The three key types, and
corresponding formats, are listed following.
<DL>
<DT><TT>S</TT></DT>
<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.
<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>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

26
dist/ntp/html/hints.htm vendored
View File

@ -1,26 +0,0 @@
<html><head><title>
Hints and Kinks
</title></head><body><h3>
Hints and Kinks
</h3><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. Bash <a href=http:hints>here</a> for a directory listing.
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

195
dist/ntp/html/hints/a-ux vendored
View File

@ -1,195 +0,0 @@
-------------
INTRODUCTION:
-------------
Last revision: 06-Jul-1994
Included in this distribution of XNTP V3 is a configuration file suitable
for use under Apple's A/UX Version 3.x.x There is also one for A/UX 2.0.1
but it has not been fully tested. To make the executables follow the steps
outlined below.
*** NOTE: You must have gcc installed to successfully compile the current
distribution; the native cc supplied with A/UX will NOT correctly compile
this source. See the FAQ in comp.unix.aux for places to obtain gcc from
and how to install it.
----------------------
MAKING XNTPD FOR A/UX:
----------------------
First, you need to create the makefiles (after you've downloaded the
source, of course):
% make clean
% make refconf
After that, you should edit Config.local to make sure that BINDIR is
correct for where you wish the programs to be "installed". The default
(and what I use) is /usr/local/etc. Make sure that DEFS_LOCAL and
CLOCKDEFS are commented out! Presently, only the LOCAL_CLOCK/REFCLOCK
clock is used and supported.
After this is done (you should be told that your system is A/UX 3), make
'xntpd' (the options to 'gcc' are held in compilers/aux3.gcc):
% make
I do not normally use the `make install' option and so have not verified its
compatibility with A/UX. Rather, I pull out each of the executables and
place them in the locally appropriate locations.
---------------
STARTING XNTPD:
---------------
At this point you need to set things up so that 'xntpd' is started upon
boot-up. You can do this in 1 of 2 ways: either add entries in /etc/inittab
or, more ideally, create and use an /etc/rc.local file. Since rc.local is
what I recommend, here's how you do it:
By default, A/UX doesn't have rc.local, so you'll need to add the following to
/etc/inittab:
net6:2:wait:/etc/syslogd # set to "wait" to run a syslog daemon
+ jmj0:2:wait:/etc/rc.local 1>/dev/syscon 2>&1 # Local stuff
dbg2::wait:/etc/telinit v # turn off init's verbose mode
Now, the look of a sample /etc/rc.local is as follows:
#!/bin/sh
:
: rc.local
:
# @(#)Copyright Apple Computer 1987 Version 1.17 of rc.sh on 91/11/08 15:56:21 (ATT 1.12)
# Push line discipline/set the device so it will print
/etc/line_sane 1
echo " "
echo "Entering rc.local..."
set `/bin/who -r`
if [ "$7" = 2 ]
then
/bin/echo " now setting the time..."
/usr/local/etc/ntpdate -s -b <host.domain>
sleep 5
#
# start up 'xntpd' if we want
#
if [ -f /etc/ntp.conf ]
then
/bin/echo " setting tick and tickadj..."
/usr/local/etc/tickadj -t 16672 -a 54
sleep 5
/bin/echo " starting xntpd..."
/usr/local/etc/xntpd <&- > /dev/null 2>&1
sleep 5
fi
#
fi
echo "Leaving rc.local..."
There are a few things to notice about the above:
o When run, 'ntpdate' forces your clock to the time returned by the
host(s) specified by <host.domain> (you'll need to replace this
be the IP address(es) of your timehosts. This is good since it gets
things close to start off with. You can use more than one time
server.
o 'tickadj' is also called. This does two things: changes the
default value of 'tick' (which the the amount of time, in ms, that
is added to the clock every 1/60 seconds) and changes the value
of 'tickadj' which the the amount that is added or subtracted
from 'tickadj' when adjtime() is called.
Now Mac clocks are pretty bad and tend to be slow. Sooo, instead of
having A/UX add the default of 16666ms every 1/60th of a second, you
may want it to add more (or less) so that it keeps better time. The
above value works for me but your "best" value may be different and
will likely require some fooling around to find the best value. As a
general rule of thumb, if you see 'xntpd' make a lot of negative clock
adjustments, then your clock is fast and you'll need to _decrease_
the value of 'tick'. If your adjustments are positive, then you need
to increase 'tick'. To make a guess on how fast/slow your clock is,
use 'ntpdate' to sync your clock. Now watch 'xntpd' and see how it
operates. If, for example, it resets your clock by 1 second every 30
minutes, then your clock is (1/(30*60)) is about 0.056% off and you'll
need to adjust 'tick' by 16666*0.00056 or about 9 (i.e. 'tick' should
be ~16675 if slow or ~16657 if fast)
A/UX's default value of 'tickadj' is 1666 which is too big for
'xntpd'... so it also needs to be adjusted. I like using larger
values then the recommended value of 9 for 'tickadj' (although not
anything near as big as 1666) since this allows for quick slews
when adjusting the clock. Even with semi-large values of 'tickadj'
(~200), getting 5ms (1/200 s) accuracy is easy.
Finally, before A/UX and 'xntpd' will work happily together, you need to
patch the kernel. This is due to the fact that A/UX attempts to keep the
UNIX-software clock and the Mac-hardware clock in sync. Neither the h/w or
the s/w clock are too accurate. Also, 'xntpd' will be attempting to adjust
the software clock as well, so having A/UX muck around with it is asking
for headaches. What you therefore need to do is tell the kernel _not_ to
sync the s/w clock with the h/w one. This is done using 'adb'. The
following is a shell script that will do the patch for you:
#! /bin/sh
adb -w /unix <<!
init_time_fix_timeout?4i
init_time_fix_timeout?w 0x4e75
init_time_fix_timeout?4i
$q
!
This must be done _every_ time you create a new kernel (via newconfig or
newunix) or else 'xntpd' will go crazy.
--------
HISTORY:
--------
John Dundas was the original porter of 'xntpd' and a lot of the additions
and A/UX-ports are from him. I got involved when I wanted to run 'xntpd'
on jagubox. It was also around this time that the base-patchlevel of
'xntpd' changed relatively (the so-called "jones" version). Since then,
I've been maintaining 'xntpd' for A/UX for the xntp development team
The original kernel patch (which patched 'time_fix_timeout') was from
Richard Todd. I suggest patching 'init_time_fix_timeout' which prevents
'time_fix_timeout' from even being called.
----------------
TECHNICAL NOTES:
----------------
o As configured (see machines/aux3), 'xntpd' will log messages via syslogd
using the LOC_LOCAL1 facility. I would suggest the following in
/etc/syslog.conf:
local1.notice /usr/adm/ntpd-syslog
o As mentioned above, the clocks on A/UX and Macs are kinda bad. Not
only that, but logging in and out of the MacOS mode as well as
extensive floppy use causes A/UX to drop and lose clock interupts
(these are sent every 1/60th of a second). So, if you do these
activities a lot, you find out that you lose about 300ms of time
(i.e., you become 300ms slow). 'xntpd' default way of handling this
is to called 'settimeofday()' and step the clock to the correct
time. I prefer having 'xntpd' slew the clock back into line by
making gradual adjustments to the clock over a coupla minutes
or so. It's for this reason that SLEWALWAYS is defined in
include/ntp_machine.h for SYS_AUX3. It's also for this reason than
I like larger values of 'tickadj'.
Good luck! If you have problems under A/UX feel free to contact me (e-mail
is preferred).
--
Jim Jagielski | "That is no ordinary rabbit... 'tis the
jim@jagubox.gsfc.nasa.gov | most foul, cruel and bad-tempered
NASA/GSFC, Code 734.4 | rodent you ever set eyes on"
Greenbelt, MD 20771 | Tim the Enchanter

76
dist/ntp/html/hints/aix vendored
View File

@ -1,76 +0,0 @@
Problem with recent ANSI compilers
On some systems, including AIX, the compiler quits on the ntp_refclock.c
file when processing the refclock_report() routine. The problem, which
is eithre a feature or a bug, has to do with an unwanted promotion of
the u_char argument to an int and a failure of the compiler to recognize
the preceding prototype. A workaround is to use ANSI syntax to delare
the arguments. Since ANSI compilers are not universally available, this
syntax can't be used in the stock distribution.
(Message # 60: 2884 bytes, New)
Date: Sat, 19 Aug 1995 13:20:50 -0400
From: "R. Bernstein" <rocky@panix.com>
Newsgroups: comp.protocols.time.ntp
to: mills@udel.edu
return-receipt-to: rocky@panix.com
Subject: time and AIX 3.2.5 raw tty bug
This posting isn't strictly about NTP, any program that may stop the
clock or set the clock backwards is subject to the AIX 3.2.5 bug.
On AIX 3.2.5, there is a bug in the tty driver for a raw device which
may crash the box under certain conditions: basically a read() on a
raw tty in effect, a character was read but not as many as specified
by VMIN when a read timeout occurred. VTIME specifies the timeout. See
the AIX manual page on termios.h or that include file. for Information
on VMIN (or MIN) VTIME (or TIME).
A remedy other than to not use raw tty's is to apply patch U435110.
Details of the problem report follow.
> ABSTRACT:
> IX43779: TRAP IN PSX_TIMEO
>
> ORIGINATING DETAILS:
> Stacktrace shows:
> IAR: 01460214 posixdd:psx_timeo + 8bf4: ti 4,r12,0x0
> *LR: 014601a0 posixdd:psx_timeo + 8b80
> 00212c60: 014604f4 posixdd:psx_timer + 8ed4
> 00212cc0: 0144b74c ttydd:tty_do_offlevel + 4284
> 00212d20: 000216fc .i_offlevel + 8c
> 00212d70: 00021d78 .i_softint + c8
> 00001004: 00008714 .finish_interrupt + 80
>
> RESPONDER SUMMARY:
> AIX asserted in psx_timeo(). Reason for the assert was that
> the current time was behind psx_ctime. Since this state
> can occur when the current time is changed after a character
> is received but before the VTIME interbyte timer pops, we
> should not assert on this.
>
> RESPONDER CONCLUSION:
> Removed the requirement that current time > psx_ctime by
> adding a new L_ntimersub macro that is used instead of the
> ntimersub macro in time.h. Also added a test for (current
> time - psx_ctime) being negative, in that case we do not
> adjust the new timeout.
>
> Reported to Correct a PTF in Error: NO
> Reported as a Highly pervasive problem: NO
>
> PE Apar?: NoPE
> Hiper Apar?: NoHiper
> Status: CLOSED PER
> Component Name: AIX V3 FOR RS/6
> Version: 320
> Component ID: 575603001
> Submitted: 94/05/03
> Closed: 94/05/05
> ChangeTeam: TX2527
>
> APAR FIXED BY: U431696 U432151 U432844 U432870 U432979
> U433049 U433081 U433459 U433876 U433906 U434598 U434453
> U434672 U434737 U435110

65
dist/ntp/html/hints/bsdi vendored
View File

@ -1,65 +0,0 @@
hints/bsdi
Author: Bdale Garbee, bdale@gag.com
Last revision: 27Oct94 (Paul Vixie)
Included in this distribution of XNTP is a configuration file suitable
for use with BSDI's BSD/OS 1.1 (formerly BSD/386 1.1). On this system,
the "cc" command is GCC 1.4x rather than PCC or GCC 2.x. It is imperative
that "cc" be used since it predefines the symbol __bsdi__; if you want to
use another compiler you will need to add -D__bsdi__ to catch the various
#ifdef's required for this system.
The Kinemetrics/Truetime GPS-TM/TMD driver is known to work on this system.
The GPS-805 and GOES should also work fine. Hell, they should all work fine
but it's hard to test very many locally.
Due to BNR2's strict interpretation of POSIX and XNTP's use of SIGIO, BSD/OS
can only handle one refclock per daemon. We're working this out with the
system architects.
The config file is machine/bsdi, and the following steps should be all that
are required to install and use the bits.
Note that you will need GNU sed; the version supplied with BSD/OS 1.1 loops
endlessly during "make refconf". Likewise you should get GNU make, which
the instructions below assume that you have put in /usr/local/bin/gnumake.
To build the software:
rm -f Config.local
gnumake refconf
gnumake MAKE=gnumake
To install the software:
gnumake install
This will place all of the executables in /usr/local/etc. The config
file is expected to be /usr/local/etc/xntp.conf and the key file for
the optional authentication is /etc/ntp.keys.
Craft a config file and a key file, and put them in the right places.
There is information on how to do this elsewhere in the documentation,
the only thing I'll mention is that I put the drift file in
/var/log/ntp.drift, and the authdelay on my 486DX/50 system is
0.000064. Your mileage will vary, learn to use the authspeed tools
if you're going to authenticate.
In the file /etc/rc.local, make sure that the invocation of ntpd is
commented out, and add an invocation of xntpd. Here's what I'm using:
echo -n 'starting local daemons:'
if [ -f /etc/ntp.keys -a -f /usr/local/etc/xntp.conf ]; then
echo -n ' xntpd'; /usr/local/etc/xntpd
fi
#XXX# echo -n ' ntpd'; /usr/libexec/ntpd -t
At this point, you should be good to go. Try running /usr/local/etc/xntpd and
using ntpq or xntpdc to see if things are working, then pay attention the next
time you reboot to make sure that xntpd is being invoked, and use ntpq or
xntpdc again to make sure all is well.
Enjoy!

13
dist/ntp/html/hints/changes vendored
View File

@ -1,13 +0,0 @@
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> (xntpd/refclock_parse.c):
- Added support to supply power from RS232 with CLOCK_RAWDCF.
Known to work with Linux 1.2.
- Made Linux ignore parity errors with CLOCK_RAWDCF.
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> (parse/util/dcfd.c):
- Removed conflicting prototype for Linux (sscanf)
- Corrected spelling error
- Made Linux ignore parity errors.
- Added support to supply power from RS232 with CLOCK_RAWDCF.
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> (parse/util/testdcf.c):
- Made Linux ignore parity errors.

40
dist/ntp/html/hints/decosf1 vendored
View File

@ -1,40 +0,0 @@
Some major changes were necessary to make xntp v3 run on the DEC Alpha
hardware running DEC OSF/1. All "long" and "u_long" declarations and
casts in the code were changed to "LONG" and "U_LONG" and a new header
file (include/ntp_types.h) was added. The new header file defines
LONG as int and U_LONG as u_int for the Alpha hardware and as long
and u_long for anything else. A couple of #ifs where changed in
ntpq and xntpdc to get the result of a signal defined correctly. The
Config.decosf1 file built the programs here with no problems.
I don't have a radio clock here, so none of that code has been tested.
I have run xntpd, xntpdc, xntpres, ntpq, ntpdate, and tickadj under
DEC OSF/1 v1.2-2 (BL10).
Mike Iglesias Internet: iglesias@draco.acs.uci.edu
University of California, Irvine BITNET: iglesias@uci
Office of Academic Computing uucp: ...!ucbvax!ucivax!iglesias
Distributed Computing Support phone: (714) 856-6926
Support for NTP Version 2 is included with the current OSF/1 release. If
you are upgrading to NTP Version 3 with this distribution, you should not
use the xntpd or ntpq programs that come with the OSF/1 release. The
older programs should be replaced by the newer programs of the same name,
either in situ or via a link to a tranquil spot like /usr/local/bin. The
make install script in the this distribution don't work due to a silly
install program incompatibility, so you will need to copy the programs by
hand.
Don't use the setup utility to install or configure the xntpd installation,
as it will cheerfully clobber your painstakingly crafted ntp.conf program.
However, assuming you put this file in /etc/ntp.conf, you can use the
/sbin/init.d/xntpd script to start and stop the daemon.
This distribution compiles with nominal mumur with the stock cc compiler
that comes with OSF/1.
Dave Mills
Electrical Engineering Department
Unibergisty of Delabunch
mills@udel.edu

54
dist/ntp/html/hints/decosf2 vendored
View File

@ -1,54 +0,0 @@
Problems with DEC OSF/1 V2.0
Compilation using gcc fails with ntp_config.c. The problem is an apparent
error in the /usr/include/sys/procset.h and /usr/include/sys/wait.h
include files.
cowbird:/usr/include/sys# diff -c wait.h.orig wait.h
*** wait.h.orig Tue Feb 22 02:41:38 1994
--- wait.h Thu Aug 25 14:52:57 1994
***************
*** 298,304 ****
#else
_BEGIN_CPLUSPLUS
! extern int waitid(idtype_t, id_t, siginfo_t *, int);
_END_CPLUSPLUS
#endif /* _NO_PROTO */
--- 298,304 ----
#else
_BEGIN_CPLUSPLUS
! extern int waitid(idtype_t, pid_t, siginfo_t *, int);
_END_CPLUSPLUS
#endif /* _NO_PROTO */
cowbird:/usr/include/sys# diff -c procset.h.orig procset.h
*** procset.h.orig Tue Feb 22 02:41:44 1994
--- procset.h Thu Aug 25 14:43:52 1994
***************
*** 86,95 ****
*/
idtype_t p_lidtype; /* The id type for the left set. */
! id_t p_lid; /* The id for the left set. */
idtype_t p_ridtype; /* The id type of for right set. */
! id_t p_rid; /* The id of the right set. */
} procset_t;
--- 86,95 ----
*/
idtype_t p_lidtype; /* The id type for the left set. */
! pid_t p_lid; /* The id for the left set. */
idtype_t p_ridtype; /* The id type of for right set. */
! pid_t p_rid; /* The id of the right set. */
} procset_t;
Also, if using gcc from the freeware disk, either replace syscall.h
in the directory /usr/local/lib/gcc-lib/alpha-dec-osf1/2.3.3/include
or replace with a link to /usr/include/sys/syscall.h.

15
dist/ntp/html/hints/freebsd vendored
View File

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

158
dist/ntp/html/hints/hpux vendored
View File

@ -1,158 +0,0 @@
Last update: Sun Mar 13 15:05:31 PST 1994
This file hopefully describes the whatever and however of how to get xntp
running on hpux 7.0 and later s300. s400, s700, and s800.
First off, all the standard disclaimers hold here ... HP doesn't have anthing
to do with this stuff. I fool with it in my spare time because we use it and
because I like to. We just happen to have a lot of HP machines around here :-)
Xntpd has been in use here for several years and has a fair amount of mileage
on various HP platforms within the company. I can't really guarantee bug fixes
but I'd certainly like to hear about bugs and I won't hestitate to look at
any fixes sent to me.
Now lets talk OS. If you don't have 7.0 or later, pretty much hang it up now.
This stuff has run here on pretty much everything from 8.0 upward on s300,
s700, and s800. It is known to run on 7.0 s300/s400 but all reports are
from the field and not my personal experience.
If you are lucky enough to have a s300 or s400 with 9.03, then you no longer
have to worry about adjtimed as HP-UX now has adjtime(2). The rest of you
will have to wait on 10.0 which will have adjtime(2) and a supported though
a bit older version of xntpd.
Next, let me explain a bit about how this stuff works on HP-UX's that do not
have adjtime(2). The directory adjtime contains libadjtime.a and the adjtimed
daemon. Instead of the adjtime(2) system call, we use a library routine to
talk to adjtimed thru message queues. Adjtimed munges into /dev/kmem and
causes the clock to skew properly as needed. PLEASE NOTE that the adjtime
code provided here is NOT a general replacement for adjtime(2) ... use of
this adjtime(3)/adjtimed(8) other than with xntpd may yield very odd results.
What to do to get this stuff running ?
* If you are running an OS less than 10.0 or do not have a s300/s400
with 9.03 or better
-> cd machines
-> vi hpux
-> (change -DSYS_HPUX=? to match whatever you are running [7,8,9])
-> cd ..
* Say "make makeconfig"
* Say "make", sit back for a few minutes.
* cd authstuff
* Say "./authcert < certdata" and check the output. Every line should
end with "OK" ... if not, we got trouble.
* Now try "./authspeed auth.samplekeys". What we want to
remember here is the "authentication delay in CPU time"
* cd ..
* Say "make install"
* I'd suggest reading the xntp docs about now :-) ... seriously !!
* One thing I have added to this version of xntpd is a way to select
config files if you are sharing /usr/local thru NFS or whatever.
If the file /usr/local/etc/xntp.conf happens to be a directory, the
files in that directory are searched until a match is found. The
rules for a match are:
1. Our hostname
2. default.<machine id> (as in default.375 or default.850)
3. default
* Ok, make sure adjtimed is running (just start it up for now with
"/usr/local/etc/adjtimed"). Using -z as an option will get you
a usage message.
* Now start up xntpd and watch it work.
* Make sure that adjtimed gets started at boot right before xntpd.
We do this in /etc/netbsdsrc. They must both run as root !!
Possible problems ?
* On some 320's and 835's we have had to run adjtimed with "-p 45" or
so to get rid of syslog messages about "last adjust did not finish".
* At 9.0, there is a problem with DIAGMON (patch available from the
response center) which causes it to delete the message queue that
adjtimed/xntpd use to communicate. (see next note for result)
* Xntpd has been known to get really ticked off when adjtime() fails
which is usually only while running the emulation code on HP-UX.
When it gets mad, it usually jumps the clock into never never land.
Possible reasons for this are adjtimed being killed or just never
started or adjtimed being completely swapped out on a really busy
machine (newer adjtimed try to lock themselves in memory to prevent
this one).
Anything else ... just drop me a line at ken@sdd.hp.com
Received: from louie.udel.edu by huey.udel.edu id aa14418; 15 Jun 95 9:19 EDT
Received: from host5.colby.edu (host-05.colby.edu) by host-04.colby.edu with ESMTP (1.37.109.15/Colby 1.1)
id AA165442355; Thu, 15 Jun 1995 09:19:16 -0400
Received: by host5.colby.edu (1.37.109.15/Colby 1.1)
id AA056252339; Thu, 15 Jun 1995 09:18:59 -0400
Date: Thu, 15 Jun 1995 09:18:59 -0400 (EDT)
From: "Jeff A. Earickson" <jaearick@colby.edu>
To: Mills@huey.udel.edu
Subject: More minor bugs in xntp3.4s
In-Reply-To: <9506150022.aa12727@huey.udel.edu>
Message-Id: <Pine.HPP.3.91.950615083549.4557A-100000@host5.colby.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Dave,
After reading the hpux hints file, I realized I didn't install or
start adjtimed. In the course of doing this, I discovered that:
--> $(TOP) is not defined in adjtime/Makefile, so "make install" can't
find the install.sh script.
--> "make install" from the main Makefile never goes into the adjtime
directory, so I added the following two lines into the install
target of the main Makefile:
@echo installing from adjtime
@cd adjtime && $(MAKE) $(MFLAGS) MFLAGS="$(MFLAGS)" MAKE="$(MAKE)" install
This twiddle may not be right for all systems, but it got adjtimed
installed for me.
You might also want to add to the hpux hints file that one way to
fire things up at boot time is to add the following lines to the localrc
function of /etc/rc:
#---daemons for Network Time Protocol (version 3.4s)
#---note that adjtimed is only needed for HP-UX 9.X, not 10.0
#---adjtimed must be running or xntpd won't work right...
if [ -x /usr/local/bin/adjtimed ]; then
/usr/local/bin/adjtimed -r & echo -n ' adjtimed'
if [ -x /usr/local/bin/xntpd ]; then
/usr/local/bin/xntpd & echo -n ' xntpd'
fi
fi
I discovered that the "-r" option of adjtimed is needed to clear out any
trash from a previous execution of it. Otherwise adjtimed quietly dies
and leaves xntpd in the lurch...
Thanks for the help.
** Jeff A. Earickson, Ph.D PHONE: 207-872-3659
** Senior UNIX Sysadmin, Information Technology EMAIL: jaearick@colby.edu
** Colby College, 4214 Mayflower Hill, FAX: 207-872-3555
** Waterville ME, 04901-8842
On Thu, 15 Jun 1995 Mills@huey.udel.edu wrote:
> Jeff,
>
> Read the hpux file in the hints directory.
>
> Dave
>

5
dist/ntp/html/hints/linux vendored
View File

@ -1,5 +0,0 @@
The kernel PLL interface is broken, I know.
Update RSN.
Torsten
(duwe@informatik.uni-erlangen.de)

119
dist/ntp/html/hints/notes-xntp-v3 vendored
View File

@ -1,119 +0,0 @@
Notes for NTP Version 3
This version operates in much the same manner as Version 2 with the
following changes and additions:
1. The protocol machinery operates in conformance with the RFC1305 NTP
Version 3 specification. The most visible characteristic of this
version is that the poll intervals for all polls, even selected
ones, is significantly increased. This is especially desirable when
serving a large client population. This implementation supports
previous versions as non-configured peers; for version-2 configured
peers a "version 2" keyword should be included on the "peer" line.
2. The configuration file has a new keyword: statfile <file>, where
<file> is the name of a statistics file." When present, each clock
update generates an entry of the form:
<day> <sec>.<frac> <addr> <status> <offset> <delay> <disp>
where <day> is the modified Julian day, <sec>.<frac> is the time of
day, <addr> is the peer address and <status> is the peer status.
The <offset>, <delay> and <disp> are the measured offset, delay and
dispersion, respectively, of the peer clock relative to the local
clock. About once per day the current file is closed and a new one
created with names <file>.<gen>, where <gen> starts at one and
increments for each new generation.
3. A number of additional platforms are supported. See ./Config file
for details.
4. A driver for the TrueTime 468DC GOES Synchronized Clock is
included. This driver (refclock_goes.c) should also work for other
TrueTime radio clocks, since all use the same format.
5. A replacement driver for the Spectracom 8170 WWVB Synchronized
Clock is included. This driver (refclock_wwvb.c) (a) does not
require a 1-pulse-per-second signal, (b) supports both format 0
(original 8170) and format 2 (Netclock/2 and upgraded 8170), (c)
can be connected to more than one computer and (d) automatically
compensates for all serial baud rates.
6. A driver for the German time/frequency station DCF77 is included.
This requires a special STREAMS module.
7. In Version 2 special line-discipline modules were required for the
CHU and WWVB drivers. This code continues to work in Version 3,
although it is no longer needed for the WWVB driver. However, this
code does not work under STREAMS, as used in SunOS 4.1.1.
Equivalent STREAMS modules are supplied with Version 3.
8. Support for an external 1-pulse-per-second (pps) signal is
provided. The signal is connected to a serial port (see
xntpd/ntp_loopfilter.c for details). When present the leading edge
of the pulse establishes the on-time epoch within an interval
established by the selected radio clock or other NTP time server.
Use of the pps is indicated when the tattletale displayed by ntpq
changes from "*" to "o".
9. The clock-selection and poll-update procedures have been modified
slightly in order to achieve better performance on high speed LANs
with compromise in performance on typical WANs.
10. In order to comply with U.S. Commerce Department regulations, the DES
encryption routine lib/authdes.c cannot be exported. For exportable
versions of this distribution a DES-encrypted version of this routine
lib/authdes.c.des is included along with an unencrypted version
lib/authdes.c.export, which allows normal operation, but without the
NTP authentication feature. Further information is available in the
lib/authdes.c.export file.
11. As an alternative to the DES-based authentication mechanism, an
implementation of the RSA Message Digest 5 algorithm is provided.
(see applicable copyright information in the library files).
12. A driver for the Magnavox MX4200 GPS clock.
13. A STREAMS module which captures carrier-detect data-lead transitions to
connect a precision source of 1-pps, yet avoid the ugly overhead in the
usual STREAMS processing. See the ppsclock subdirectory.
14. Support for the Apple A/UX operating system and enhanced support for the
Hewlet-Packard HP/UX operating system. See the various README and Config
files for further information.
See the COPYRIGHT file for authors and copyright information. Note that some
modules in this distribution contain copyright information that supersedes
the copyright information in that file.
If I missed something or neglected to give due credit, please advise.
David L. Mills
University of Delaware
31 May 1992, amended 23 July 1992, 25 October 1992
Bugs and notes
A bug in the original tty_clk_STREAMS.c module has been fixed.
The poll-interval randomization feature of poll_update (in
xntpd/ntp_proto.c) has been extended to apply when the poll interval is
increased, as well as reduced. This spreads the update messages in time
and helps avoid unpleasant bursts of messages.
In the clock_select algorithm the peers selected for combining are
limited to those survivors at the lowest stratum, not the entire list.
This helps avoid whiplash when large numbers of peers are at the same
stratum.
The number formerly displayed by ntpq as "compliance" is now the time
constant of integration.
The DNS resolver xntpd/ntp_intres.c is now integrated into xntpd, making
configuration of multiple hosts easier.
System and peer event are now written to the system log at priority
LOG_INFO.
The leap-second code was fixed to avoid broadcasting leap warnings on
all except the last day of June and December.

105
dist/ntp/html/hints/parse vendored
View File

@ -1,105 +0,0 @@
Compilation:
Usual thing: rm -f Config.local ; make for vanilla
make refconf for reference clock (e. g. DCF77)
Directory contents:
hints/PARSE - this file
xntpd/refclock_parse.c
- reference clock support for DCF77/GPS in xntp
parse/parse.c
- Reference clock data parser framework
parse/parse_conf.c
- parser configuration (clock types)
parse/clk_meinberg.c
- Meinberg clock formats (DCF U/A 31, PZF 535, GPS166)
parse/clk_schmid.c
- Schmid receiver (DCF77)
parse/clk_rawdcf.c
- 100/200ms pulses via 50 Baud line (DCF77)
parse/clk_dcf7000.c
- ELV DCF7000 (DCF77)
parse/clk_trimble.c
- Trimble SV6 GPS receiver
If you want to add new clock types please check
with kardel@informatik.uni-erlangen.de. These files
implement the conversion of RS232 data streams into
timing information used by refclock_parse.c which is
mostly generic except for NTP configuration constants.
parse/Makefile.kernel
- *SIMPLE* makefile to build a loadable STREAMS
module for SunOS 4.x / SunOS 5.x systems
parse/parsestreams.c
- SUN Streams module (loadable) for radio clocks
This streams module is designed for SunOS 4.1.X.
parse/parsesolaris.c
- SUN Streams module (loadable) for radio clocks.
This streams module is designed for SunOS 5.x
Beware this is still new - so it might crash
your machine (we have seen it working, though).
parse/parsetest.c
- simple test program for STREAMS module. Its so simple,
that it doesn't even set TTY-modes, thus they got to
be correct on startup - works for Meinberg receivers
parse/testdcf.c
- test program for raw DCF77 (100/200ms pulses)
receivers
include/parse.h - interface to "parse" module and more
include/parse_conf.h
- interface to "parse" configuration
include/sys/parsestreams.h
- STREAMS specific definitions
scripts/support
- scripts (perl & sh) for statistics and rc startup
the startup scripts are used in Erlangen for
starting the daemon on a variety of Suns and HPs
and for Reference Clock startup on Suns
These scripts may or may not be helpful to you.
Supported clocks:
Meinberg DCF U/A 31
Meinberg PZF535/TCXO (Software revision PZFUERL 4.6)
Meinberg PZF535/OCXO (Software revision PZFUERL 4.6)
Meinberg GPS166 (Software version for Uni-Erlangen)
ELV DCF7000 (not recommended - casual/emergency use only)
Conrad DCF77 receiver (email: time@informatik.uni-erlangen.de)
+ level converter
TimeBrick (email: time@informatik.uni-erlangen.de)
Schmid Receiver Kit
Trimble SV6 GPS receiver
Addresses:
Meinberg Funkuhren
Auf der Landwehr 22
31812 Bad Pyrmont
Germany
Tel.: 05281/20 18
FAX: 05281/60 81 80
ELV Kundenservice
Postfach 1000
26787 Leer
Germany
Tel.: 0491/60 08 88
Walter Schmidt
Eichwisrain 14
8634 Hombrechtikon
Switzerland
If you have problems mail to:
time@informatik.uni-erlangen.de
We'll help (conditions permitting)

35
dist/ntp/html/hints/refclocks vendored
View File

@ -1,35 +0,0 @@
This is a short overview for the reference clocks currently supported
by xntp V3. (Ultimate wisdom can be obtained from xntpd/refclock_*.c
this file was derived from that information - unfortunately some comments
in the files tend to get stale - so use with caution)
Refclock address Type
127.127.0.x no clock (fails to configure)
127.127.1.x local clock - use local clock as reference
127.127.2.x no clock (fails to configure)
127.127.3.x PSTI 1010/1020 WWV Clock
127.127.4.x SPECTRACOM WWVB receiver 8170 and Netclock/2
127.127.5.x Kinimetric Truetime 468-DC GOES receiver
127.127.6.x IRIG audio decode (Sun & modified BSD audio driver)
127.127.7.x CHU Timecode (via normal receiver & Bell 103 modem)
127.127.8.x PARSE (generic driver for a bunch of DCF/GPS clocks
can be extended for other clocks too)
8.0-3 Meinberg PZF535/TCXO
8.4-7 Meinberg PZF535/OCXO
8.8-11 Meinberg DCF U/A 31
8.12-15 ELV DCF7000
8.16-19 Walter Schmid DCF receiver (Kit)
8.20-23 Conrad DCF77 receiver module + level converter (Kit)
8.24-27 TimeBrick (limited availability ask
time@informatik.uni-erlangen.de)
8.28-31 Meinberg GPS166
8.32-35 Trimble SV6 GPS receiver
127.127.9.x MX4200 GPS receiver
127.127.10.x Austron 2201A GPS Timing Receiver
127.127.11.x Kinemetrics Truetime OM-DC OMEGA Receiver
127.127.12.x KSI/Odetecs TPRO-S IRIG-B / TPRO-SAT GPS
127.127.13.x Leitch: CSD 5300 Master Clock System Driver
127.127.14.x MSFEES
127/127.15.x TrueTime GPS/TM-TMD
127.127.16.x Bancomm GPS/IRIG Ticktock
127.127.17.x Datum Programmable Time System

56
dist/ntp/html/hints/rs6000 vendored
View File

@ -1,56 +0,0 @@
15.7.1993
xntp3 compiles now again on AIX. I have disabled prototyping and added
the switch -D_NO_PROTO which disables prototyping in the system include
files.
Matthias Ernst maer@nmr.lpc.ethz.ch
--------------------------------------------------------------------------------
Xntp version 3 now support the cc compiler for AIX.
The Config.aix will now use cc by default. You can still compile xntp
with the bsd compiler by changing "COMP= cc" to "COMP= bsdcc" and
and removing the "-DSTUPID_SIGNAL" option from the "DEFS" option.
xntp and tickadj was also modified so that the value of tickadj is read
form the kernel and can be set by tickadj. For now I would not set
tickadj below 40 us.
Bill Jones
jones@chpc.utexas.edu
-------------------------------------------------------------------------------
This is a modified version of xntp version 3 for the RS6000. It works for
AIX 3.2 and these are the same changes as have been applied tothe version 2
implementation of xntp. It works fine for us but I have not tested all of
the features, especially the local clock support for the RS6000 is not tested
at all.
Matthias Ernst, ETH-Zuerich, Switzerland - maer@nmr.lpc.ethz.ch
--------------------------------------------------------------------------------
Here the original README.rs6000 for the version 2 implementation:
A hacked version of xntp for the IBM RS/6000 under AIX 3.1 can be found
in xntp.rs6000.tar.Z. [ if still available at all - Frank Kardel 93/12/3 ]
This will not work on older versions of AIX due to a kernel bug; to find
out whether you have the kernel bug, compile and run testrs6000.c (see
comments in the code for instructions).
xntp and testrs6000 require "bsdcc" to compile. This is simply another
entry point into the xlc compiler with various options set for BSD
compatibility. If your system does not have bsdcc, do the following:
link /bin/bsdcc to /bin/xlc
put the following into /etc/xlc.cfg:
* BSD compatibility
bsdcc: use = DEFLT
crt = /lib/crt0.o
mcrt = /lib/mcrt0.o
gcrt = /lib/gcrt0.o
libraries = -lbsd, -lc
proflibs = -L/lib/profiled,-L/usr/lib/profiled
options = -H512,-T512, -qlanglvl=extended, -qnoro, -D_BSD, -D_NONSTD_TYPES, -D_NO_PROTO, -tp,-B/lib/

39
dist/ntp/html/hints/sco.htm vendored
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>

74
dist/ntp/html/hints/sgi vendored
View File

@ -1,74 +0,0 @@
adjtime, tick and tickadj:
--------------------------
The SGI value for HZ is 100 under Irix 4, with the system clock running
in nominal mode (ftimer off), so the value for tick is 10000 usec.
Tickadj is a bit more tricky because of the behaviour of adjtime(),
which seems to try to perform the correction over 100-200 seconds, with
a rate limit of 0.04 secs/sec for large corrections. Corrections of
less than 0.017 seconds generally complete in less than a second,
however.
Some measured rates are as follows:
Delta Rate (sec/sec)
> 1 0.04
0.75 0.04
0.6 0.004
0.5 0.004
0.4 0.0026
0.3 0.0026
0.2 0.0013
0.1 0.0015
0.05 0.0015
0.02 0.0003
0.01 0.015
Strange. Anyway, since adjtime will complete adjustments of less than
17msec in less than a second, whether the fast clock is on or off, I
have used a value of 150usec/tick for the tickadj value.
Fast clock:
-----------
I get smoother timekeeping if I turn on the fast clock, thereby making
the clock tick at 1kHz rather than 100Hz. With the fast clock off, I
see a sawtooth clock offset with an amplitude of 5msec. With it on,
the amplitude drops to 0.5msec (surprise!). This may be a consequence
of having a local reference clock which spits out the time at exactly
one-second intervals - I am probably seeing sampling aliasing between
that and the machine clock. This may all be irrelevant for machines
without a local reference clock. Fiddling with the fast clock doesn't
seem to compromise the above choices for tick and tickadj.
I use the "ftimer" program to switch the fast clock on when the system
goes into multiuser mode, but you can set the "fastclock" flag in
/usr/sysgen/master.d/kernel to have it on by default. See ftimer(1).
timetrim:
---------
Irix has a kernel variable called timetrim which adjusts the system
time increment, effectively trimming the clock frequency. Xntpd could
use this rather than adjtime() to do it's frequency trimming, but I
haven't the time to explore this. There is a utility program,
"timetrim", in the util directory which allows manipulation of the
timetrim value in both SGI and xntpd native units. You can fiddle with
default timetrim value in /usr/sysgen/master.d/kernel, but I think
that's ugly. I just use xntpd to figure out the right value for
timetrim for a particular CPU and then set it using "timetrim" when
going to multiuser mode.
Serial I/O latency:
-------------------
If you use a local clock on an RS-232 line, look into the kernel
configuration stuff with regard to improving the input latency (check
out /usr/sysgen/master.d/[sduart|cdsio]). I have a Kinemetrics OM-DC
hooked onto /dev/ttyd2 (the second CPU board RS-232 port) on an SGI
Crimson, and setting the duart_rsrv_duration flag to 0 improves things
a bit.
12 Jan 93
Steve Clift, CSIRO Marine Labs, Hobart, Australia (clift@ml.csiro.au)

320
dist/ntp/html/hints/solaris-dosynctodr.html vendored
View File

@ -1,320 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<!-- Sun Template V4.0 9/9/98 -->
<HTML>
<HEAD>
<TITLE>Symptoms and Resolutions Article 19195</TITLE>
<META NAME="GENERATOR" CONTENT="Sun Microsystems, Inc.">
<META HTTP-EQUIV="content-type" CONTENT="text/html;charset=iso-8859-1">
<!-- INSERT YOUR META TAGS HERE -->
<META NAME="PUBLISHED_DATE" CONTENT="">
<META NAME="KEYWORDS" CONTENT="">
<META NAME="DESCRIPTION" CONTENT="">
<!-- END META TAGS -->
<LINK REL="Stylesheet" TYPE="text/css" HREF="/style.css" TITLE="Style">
</HEAD>
<!--stopindex-->
<BODY BGCOLOR="#FFFFFF" LINK="#666699" ALINK="#FFFFFF">
<TABLE WIDTH="623" BORDER="0" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD COLSPAN="2" VALIGN="TOP" WIDTH="623">
<IMG BORDER="0" SRC="/images/homebuy.gif" WIDTH="149" HEIGHT="32" ALT="Home * Buy * My Sun(sm)" USEMAP="#lefttop"><IMG BORDER="0" SRC="/images/globalnavbar.gif" WIDTH="474" HEIGHT="32" ALT="sun.com Global Sections" USEMAP="#topnav"></TD>
</TR>
<TR>
<TD COLSPAN="2" VALIGN="TOP" WIDTH="623">
<!-- TITLEBAR IMAGE: INSERT CUSTOMIZED TITLEBAR IMAGE BELOW -->
<A HREF="http://www.sun.com/"><IMG BORDER="0" SRC="/images/sunlogo.gif" WIDTH="149" HEIGHT="72" ALT="Sun Microsystems"></A><IMG BORDER="0" SRC="/images/titlebar/doc.title.gif" WIDTH="474" HEIGHT="72"></TD>
</TR>
<!-- Begin Search Elements -->
<TR VALIGN="top">
<TD BGCOLOR="#666699">
<TABLE BORDER="0" WIDTH="157" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD BGCOLOR="#666699" COLSPAN="2" WIDTH="157" VALIGN="TOP"><IMG BORDER="0" SRC="/images/search/contract/search1.gif" WIDTH="157" HEIGHT="16" ALT="Search SunSolve"></TD>
</TR>
<TR>
<TD VALIGN="top" ALIGN="center" WIDTH="141" BGCOLOR="#666699"><FORM ACTION="search.pl" METHOD="POST"><FONT SIZE="2"><INPUT TYPE="text" NAME="zone_32" SIZE="14"></FONT><input type=hidden name=mode value=results><BR>
<INPUT TYPE="image" SRC="/images/search/contract/search5.gif" BORDER="0" NAME="Search"><IMG SRC="/images/cg_clear.gif" ALT="" WIDTH="2" HEIGHT="1" BORDER="0" HSPACE="29" VSPACE="0"><BR>
<A HREF="search.pl?mode=advanced"><IMG BORDER="0" SRC="/images/search/contract/search3.gif" WIDTH="144" HEIGHT="16" ALT="Advanced Search"></A><BR>
<A HREF="search.pl?mode=product"><IMG SRC="/images/search/contract/search4.gif" BORDER="0" ALT="Product Search" WIDTH="144" HEIGHT="19"></A><BR>
<A HREF="show.pl?target=help/search_tips"><IMG SRC="/images/search/contract/search6.gif" BORDER="0" ALT="Search Tips" WIDTH="144" HEIGHT="27"></A></TD>
<TD ALIGN="right"><IMG SRC="/images/search/contract/search2.gif" ALT="" WIDTH="13" HEIGHT="117" BORDER="0"></TD>
</TR>
<!-- End Search Elements -->
<!-- Begin User Personalization (Must limit to 10 Characters)-->
<TR>
<TD COLSPAN="2"><TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="157"><TR><TD COLSPAN="3" ALIGN="right"><IMG SRC="/images/home_con/welcom_1.gif" ALT="" WIDTH="156" HEIGHT="4" BORDER="0"></TD></TR>
<TR><TD BGCOLOR="#333366"><IMG SRC="/images/home_con/welcom_2.gif" ALT="" WIDTH="17" HEIGHT="19" BORDER="0"></TD><TD BGCOLOR="#333366" VALIGN="middle"><NOBR><FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" COLOR="#99CC33" SIZE="-2">sopko</FONT></NOBR></TD><TD BGCOLOR="#333366" ALIGN="right"><A HREF="edit-user-form.pl?viewmode=contractuser"><IMG SRC="/images/home_con/welcom_3.gif" ALT="Edit" WIDTH="45" HEIGHT="19" BORDER="0"></A></TD></TR>
</TABLE>
</TD>
</TR>
<!-- End User Personalization -->
<TR>
<TD COLSPAN="2" ALIGN="right" VALIGN="top" WIDTH="157" BGCOLOR="#666699"><IMG BORDER="0" SRC="/images/ssolvecontents.gif" WIDTH="157" HEIGHT="37" ALT="Contents Of SunSolve"><BR>
<!-- PILLS: CHANGE THE PILL FOR CURRENT SECTION TO THE HIGHLIGHTED PILL -->
<!-- Beginning of Nav area -->
<A HREF="show.pl?target=patches/patch-access" onmouseover="window.status='All Public Patches'; return true" onmouseout="window.status=''; return true">
<IMG BORDER="0" SRC="/images/nav/p1.gif" WIDTH="157" HEIGHT="19" ALT="All Public Patches"></A><BR>
<A HREF="suncourier.pl" onmouseover="window.status='Submit a Service Order'; return true" onmouseout="window.status=''; return true">
<IMG BORDER="0" SRC="/images/nav/p5.gif" WIDTH="157" HEIGHT="19" ALT="Submit a Service Order"></A><BR>
<A HREF="show.pl?target=resources/tools" onmouseover="window.status='Diagnostic Tools'; return true" onmouseout="window.status=''; return true">
<IMG BORDER="0" SRC="/images/nav/p4.gif" WIDTH="157" HEIGHT="19" ALT="Diagnostic Tools"></A><BR>
<A HREF="show.pl?target=help/collections" onmouseover="window.status='Support Docs.'; return true" onmouseout="window.status=''; return true">
<IMG BORDER="0" SRC="/images/nav/cp2.gif" WIDTH="157" HEIGHT="19" ALT="Support Docs."></A><BR>
<A HREF="show.pl?target=resources/y2k" onmouseover="window.status='Y2K Central'; return true" onmouseout="window.status=''; return true">
<IMG BORDER="0" SRC="/images/nav/p3.gif" WIDTH="157" HEIGHT="19" ALT="Y2K Central"></A><BR>
<A HREF="show.pl?target=security/sec" onmouseover="window.status='Security Information'; return true" onmouseout="window.status=''; return true">
<IMG BORDER="0" SRC="/images/nav/p2.gif" WIDTH="157" HEIGHT="19" ALT="Security Information"></A><BR>
<br><table cellpadding="0" cellspacing="0" border="0" width="157">
<tr><td width="8">&nbsp;</td><td width="149">
<table cellpadding="0" cellspacing="0" border="0">
<BR><tr><td><BR><img src="/images/line.gif" alt="------" width="140" height="11" border="0"><br>
<A HREF="mark.pl"
onmouseover="window.status='Marked Docs.';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Marked Docs.</FONT></A><BR>
<A HREF="notify.pl"
onmouseover="window.status='Notifications';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Notifications</FONT></A><BR>
<A HREF="/plain-cgi/show.pl?target=home_con"
onmouseover="window.status='Low Graphics';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Low Graphics</FONT></A><BR>
<A HREF="show.pl?target=link"
onmouseover="window.status='SunSolve Servers';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">SunSolve Servers</FONT></A><BR>
<A HREF="show.pl?target=about_sunsolve"
onmouseover="window.status='About SunSolve';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">About SunSolve</FONT></A><BR>
<A HREF="feedback.pl"
onmouseover="window.status='Contact Us';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Contact Us</FONT></A><BR>
<A HREF="show.pl?target=help/sitemap"
onmouseover="window.status='Site Map';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Site Map</FONT></A><BR>
<A HREF="show.pl?target=article/article"
onmouseover="window.status='Articles';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Articles</FONT></A><BR>
<A HREF="show.pl?target=home_con"
onmouseover="window.status='Home';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Home</FONT></A><BR>
<A HREF="show.pl?target=help/faq"
onmouseover="window.status='Help';return true"
onmouseout="window.status='';return true">
<font class="locallink" color="#dddddd">Help</FONT></A><BR>
<br></td></tr></table></td></tr></table>
<!-- End of Nav area -->
</FORM>
<br><br><!-- some spacers -->
</TD>
</TR>
</TABLE>
</TD>
<TD VALIGN="TOP" WIDTH="466">
<!--startindex-->
<!-- ============ -->
<!-- MAIN CONTENT -->
<!-- ============ -->
<table width=100% cellpadding=16 cellspacing=0 border=0>
<tr>
<td width=100% valign=top>
<CENTER><FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" SIZE="2">
[&nbsp;<a href="retrieve.pl?type=0&doc=srdb%2F19195&display=plain">Printer Friendly Page</a>&nbsp;]
[&nbsp;<b>Was this document useful? <a href="retrieve.pl?type=0&doc=srdb/19195&vote=yes">Yes</a> or <a href="retrieve.pl?type=0&doc=srdb/19195&vote=no">No</a></b>&nbsp;]<br>[&nbsp;<a href="notify.pl?action=add&doc=srdb%2F19195&type=synopsis">Notify if Document Changes</a>&nbsp;]
[&nbsp;<a href="mark.pl?action=add&doc=srdb%2F19195&type=0">Mark Document for Download</a>&nbsp;]<br>[&nbsp;<a href="notify.pl">View/Edit Notifications</a>&nbsp;]
[&nbsp;<a href="mark.pl">View/Edit Marked Documents</a>&nbsp;]<br></FONT></CENTER><br>
<SCRIPT Language="JavaScript">
<!-- Hide javascript from older browsers
function jump()
{
var ctl = document.docform.jumplist;
location.href = ctl.options[ctl.selectedIndex].value;
}
// End hiding contents -->
</SCRIPT>
<a name="top">
<form name="docform"><div align=center><font size=2> Jump to <select name="jumplist" size=1 onchange="jump();"></font><option value="#Hardware">Hardware</option>
<option value="#Product">Product</option>
<option value="#Product-Area">Product Area</option>
<option value="#Synopsis">Synopsis</option>
<option value="#Problem-Description">Problem Description</option>
<option value="#Document-Content">Document Content</option>
<option value="#Problem-Solution">Problem Solution</option>
<option value="#SRDB-ID">SRDB ID</option>
<option value="#OS">OS</option>
</select></div></form>
<table width=100% cellpadding=2 cellspacing=0 border=0>
<tr bgcolor=#666699><td><font size=2 color=#ffffff><b>SRDB ID</b></font></td>
<td bgcolor=#ffffff><font size=2>&nbsp;</font></td>
<td><font size=2 color=#ffffff><b>Synopsis</b></font></td>
<td bgcolor=#ffffff><font size=2>&nbsp;</font></td>
<td><font size=2 color=#ffffff><b>Date</b></font></td>
</tr>
<tr bgcolor=#CCCCE7><td><font size=2><b>19195</b></font></td>
<td bgcolor=#ffffff><font size=2>&nbsp;</font></td>
<td><font size=2><b>Upgraded to 2.6, using xntpd, but the system clock is drifting. Worked fine</b></font></td>
<td bgcolor=#ffffff><font size=2>&nbsp;</font></td>
<td><font size=2><b>4 Sep 1999</b></font></td>
</tr>
</table><br clear>
<table width=100% cellpadding=2 cellspacing=0 border=0><tr bgcolor=#999999>
<td><font size=2 color=#ffffff><b><a name=Problem-Description>Problem Description</a></b></font></td>
<td align=right><b><a href="#top"><font size=2 color=#ffffff>Top</font></a></b></td></tr></table>
<pre>Ever since upgrading to Solaris 2.6, the system clock has been drifting and
there are messages like 'synchronisation lost', 'Previous time adjustment
didn''t complete' and 'time reset (step)' a lot in the /var/adm/messages
file. The system either was previously working fine with the freeware
xntpd or the configuration was copied from another system that was
using the freeware version.
-- 23-Apr-99 08:22 US/Eastern --</pre><table width=100% cellpadding=2 cellspacing=0 border=0><tr bgcolor=#999999>
<td><font size=2 color=#ffffff><b><a name=Problem-Solution>Problem Solution</a></b></font></td>
<td align=right><b><a href="#top"><font size=2 color=#ffffff>Top</font></a></b></td></tr></table>
<pre>The common lore for setting up xntpd on Solaris using
the freeware version included the warning to set the
kernel variable <font color=red>dosynctodr</font> to 0 in the /etc/system
file thus: set <font color=red>dosynctodr</font>=0
When using NTP on Solaris 2.6 or later, the kernel
variable MUST be left at the default value of 1. Prior
to 2.6 this variable controlled whether or not to rein
in the softclock using the hardware clock, with the result
that NTP and the hardware clock would fight for control of
the soft clock; thus before 2.6 you had to set <font color=red>dosynctodr</font>
to 0. At 2.6, every system call that adjusts the softclock
also sets the hard clock, thus while NTP controls the soft
clock, the hard clock is also controlled. Setting
<font color=red>dosynctodr</font> to 0 reverts the behavior back to the pre 2.6
defaulkt behavior, having exactly the opposite effect
as that intended.
Do not set <font color=red>dosynctodr</font> to 0.</pre><table width=100% cellpadding=2 cellspacing=0 border=0>
<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Product-Area>Product Area</a></b></font></td>
<td bgcolor=#cccccc valign=top width=75%><font size=2>Bundled Network</font></td></tr>
<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Product>Product</a></b></font></td>
<td bgcolor=#cccccc valign=top width=75%><font size=2>NTP</font></td></tr>
<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=OS>OS</a></b></font></td>
<td bgcolor=#cccccc valign=top width=75%><font size=2>Solaris 2.6</font></td></tr>
<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Hardware>Hardware</a></b></font></td>
<td bgcolor=#cccccc valign=top width=75%><font size=2>Ultra 2</font></td></tr>
<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Document-Content>Document Content</a></b></font></td>
<td bgcolor=#cccccc valign=top width=75%><font size=2>with freeware xntpd.</font></td></tr>
</table><br clear>
<font size=2><a href="#top">Top</a></font><br><br>
</td></tr></table>
<!-- =================== -->
<!-- END OF MAIN CONTENT -->
<!-- =================== -->
<!--stopindex-->
<!-- DON'T CHANGE INFORMATION OTHER THAN titlebar BELOW THIS LINE -->
<!-- Altered Table Structure from Template to format properly with new design -->
</TD>
</TR>
<TR>
<TD>&nbsp;</TD>
<TD VALIGN="top">
<center>
<IMG SRC="/images/cg_grey_line.gif" ALT="" WIDTH="466" HEIGHT="2" BORDER="0"><BR>
<IMG SRC="/images/cg_clear.gif" ALT="" WIDTH="1" HEIGHT="2" BORDER="0" HSPACE="0" VSPACE="4">
</center>
<CENTER>
<FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" SIZE="2">
[ <A HREF="edit-user-form.pl?viewmode=contractuser">Edit Account</A> ]
[ <A HREF="show.pl?target=patches/patch-access">Patches</A> ]
[ <A HREF="suncourier.pl">Submit a Service Order</A> ]<br>
[ <A HREF="show.pl?target=resources/tools">Diagnostic Tools</A> ]
[ <A HREF="show.pl?target=help/collections">Support Docs.</A> ]
[ <A HREF="show.pl?target=resources/y2k">Y2K Central</A> ]
[ <A HREF="show.pl?target=security/sec">Security Information</A> ] <br>
[ <A HREF="show.pl?target=link">SunSolve Servers </A> ]
[ <A HREF="show.pl?target=about_sunsolve">About SunSolve</A> ]
[ <A HREF="feedback.pl">Contact Us</A> ]
[ <A HREF="show.pl?target=help/sitemap">Site Map</A> ]
[ <A HREF="show.pl?target=article/article">Articles</A> ]
[ <A HREF="show.pl?target=home_con">Home</A> ]
[ <A HREF="show.pl?target=help/faq">Help</A> ]
</FONT>
</CENTER>
<!-- MAPS -->
<MAP NAME="lefttop">
<AREA SHAPE="rect" HREF="http://www.sun.com/MySun/" ALT="My Sun" COORDS="89,0 149,32">
<AREA SHAPE="rect" HREF="show.pl?target=home_con" ALT="Home" COORDS="0,0 42,32">
<AREA SHAPE="rect" HREF="http://www.sun.com/sales/" ALT="Buy" COORDS="54,0 78,32">
</MAP>
<MAP NAME="topnav">
<AREA SHAPE="rect" HREF="http://www.sun.com/java/" ALT="Java Technologies" COORDS="4,0,67,32">
<AREA SHAPE="rect" HREF="http://www.sun.com/products-n-solutions/" ALT="Products and Solutions" COORDS="74,0,141,32">
<AREA SHAPE="rect" HREF="http://www.sun.com/service/" ALT="Support, Education, and Consulting" COORDS="148,0,249,32">
<AREA SHAPE="rect" HREF="http://www.sun.com/tech/" ALT="Technology and Research" COORDS="261,0,324,32">
<AREA SHAPE="rect" HREF="http://www.sun.com/developers/developers.html" ALT="For Developers" COORDS="334,0,396,32">
<AREA SHAPE="rect" HREF="http://www.sun.com/corporateoverview/" ALT="Corporate Information" COORDS="406,0,482,32">
</MAP>
<!-- INSERT titlebar HREFS BELOW -->
<MAP NAME="titlebar">
<!-- LINK TO SEC HOME Removed because no longer needed on this template -->
<AREA SHAPE="rect" HREF="/visual/home/" ALT="SunSolve Online(tm)" COORDS="0,21,215,51"> <!-- LINK TO CURRENT PILL HOME -->
</MAP>
<!-- begin copyright notice -->
<BR>
<CENTER>
<FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" COLOR="#999999" SIZE="2">
<br>
Copyright 1994-1999 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.
<br>
All rights reserved.
<a href="http://www.sun.com/share/text/SMICopyright.html">Legal Terms</a>.
<a href="http://www.sun.com/privacy/">Privacy Policy</a>.
</font>
</CENTER>
<!-- end copyright notice -->
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

143
dist/ntp/html/hints/solaris.html vendored
View File

@ -1,143 +0,0 @@
<HTML>
<HEAD>
<TITLE>Solaris hints and kinks</TITLE>
</HEAD>
<BODY>
Information on compiling and executing ntpd under Solaris.
<BR>
Last Updated: Sun Jun 21 01:32:18 EDT 1998,
John Hawkinson,
<! -- This is deliberately not a mailto -- > &lt;jhawk@MIT.EDU&gt;
<P>
If you're not running Solaris 2.5.1 or later, it is likely
that you will have problems; upgrading would be a really good plan.
<P>
<H3>All Solaris versions</H3>
<P>
We have a report that says starting with Solaris 2.6 we should leave
<I>dosynctodr</I> alone.
<A HREF="solaris-dosynctodr.html">Here is the report</A>.
<P>
Proper operation of ntp under Solaris may require setting the kernel
variable <I>dosynctodr</I> to zero (meaning "do not synchronize the clock
to the hardware time-of-day clock"). This can be done with the
tickadj utility:
<BLOCKQUOTE><TT>
tickadj -s
</TT></BLOCKQUOTE>
If you prefer, it can also be done with the native Solaris kernel debugger:
<BLOCKQUOTE><TT>
echo dosynctodr/W0 | adb -k -w /dev/ksyms /dev/mem
</BLOCKQUOTE></TT>
<P>
Or, it can also be set by adding a line to /etc/system:
<BLOCKQUOTE><TT>
set dosynctodr = 0
</BLOCKQUOTE></TT>
<P>
Instead of the <I>tick</I> kernel variable, which many operating
systems use to control microseconds added to the system time every
clock tick (c.f. <A HREF="../notes.htm#frequency_tolerance">Dealing
with Frequency Tolerance Violations</A>), Solaris has the variables
<I>nsec_per_tick</I> and <I>usec_per_tick</I>.
<P>
<I>nsec_per_tick</I> and <I>usec_per_tick</I> control the number of
nanoseconds and microseconds, respectively, added to the system clock
each clock interrupt. Enterprising souls may set these based on
information collected by ntpd in the <CODE>/etc/ntp.drift</CODE> file
to correct for individual hardware variations.
<P>
On UltraSPARC systems, <I>nsec_per_tick</I> and <I>usec_per_tick</I>
are ignored in favor of the <I>cpu_tick_freq</I> variable, which
should be automatically be determined by the PROM in an accurate
fashion.
<P>
In general, the same ntp binaries should not be used across multiple
operating system releases. There is enough variation in the core operating
system support for timekeeping that a rebuild of ntpd for the idiosyncracies
of your specific operating system version is advisable.
<P>
It is recommended that ntp be started via a script like <A
HREF="solaris.xtra.S99ntpd">this one</A>, installed in
<CODE>/etc/init.d/ntpd</CODE> with a symbol link from
<CODE>/etc/rc2.d/S99ntpd</CODE>.
<H3>Solaris 2.6</H3>
<P>
Solaris 2.6 adds support for kernel PLL timekeeping, but breaks this
support in such a fashion that using it worse than not. This is <A
HREF="solaris.xtra.4095849"> SUN Bug ID 4095849</A>, and it is not yet
fixed as of June 1998.
<P>
<H3>Solaris 2.5 and 2.5.1</H3>
<P>
On UltraSPARC systems, calculation of <I>cpu_tick_freq</I> is broken
such that values that are off by significant amounts may be used
instead. This unfortunately means that ntpd may have severe problems
keeping synchronization. This is <A HREF="solaris.xtra.4023118"> SUN Bug ID
4023118</A>. Bryan Cantrill <! -- &lt;bmc@eng.sun.com&gt; --> of Sun
posted <A HREF="solaris.xtra.patchfreq">patchfreq</A>, a workaround script,
to comp.protocols.time.ntp in March of 1997.
<P>
<HR>
<H2>OLD DATA</H2>
<STRONG>I can't vouch for the accuracy the information below this
rule. It may be significantly dated or incorrect.</STRONG>
<P>
<P>
<H3>Solaris 2.2</H3>
<P>
Solaris 2.2 and later contain completely re-written clock code to
provide high resolution microsecond timers. A benefit of the
re-written clock code is that adjtime does not round off its
adjustments, so ntp does not have to compensate for this
rounding. Under Solaris 2.2 and later, ntp #define's
<CODE>ADJTIME_IS_ACCURATE</CODE>, and does not look for the <I>tickadj</I>
kernel variable.
<P>
<H3>Solaris 2.1</H3>
(This originally written by William L. Jones &lt;jones@chpc.utexas.edu&gt;)
<P>
Solaris 2.1 contains fairly traditional clock code, with <I>tick</I>
and <I>tickadj</I>.
<P>
Since settimeofday under Solaris 2.1 only sets the seconds part of timeval
care must be used in starting xntpd. I suggest the following start
up script:
<BLOCKQUOTE><TT>
tickadj -s -a 1000
<BR>ntpdate -v server1 server2
<BR>sleep 20
<BR>ntpdate -v server1 server2
<BR>sleep 20
<BR>tickadj -a 200
<BR>xntpd
</TT></BLOCKQUOTE>
The first tickadj turns of the time of day clock and sets the tick
adjust value to 1 millisecond. This will insure that an adjtime value
of at most 2 seconds will complete in 20 seconds.
<P>
The first ntpdate will set the time to within two seconds
using settimeofday or it will adjust time using adjtime.
<P>
The first sleep insures the adjtime has completed for the first ntpdate.
<P>
The second ntpdate will use adjtime to set the time of day since the
clock should be within 2 seconds of the correct time.
<P>
The second tickadj set the tick adjust system value to 5 microseconds.
<P>
The second sleeps insure that adjtime will complete before starting
the next xntpd.
<P>
I tried running with a tickadj of 5 microseconds with out much success.
200 microseconds seems to work well.
<P>
<HR>
Prior versions of this file had major text contributed by:
<MENU>
<LI>Denny Gentry &lt;denny@eng.sun.com&gt;
</MENU>
<BODY>
</HTML>

36
dist/ntp/html/hints/solaris.xtra.4023118 vendored
View File

@ -1,36 +0,0 @@
Bug Id: 4023118
Category: kernel
Subcategory: other
State: integrated
Synopsis: sun4u doesn't keep accurate time
Description:
[ bmc, 12/20/96 ]
The clock on a sun4u drifts unacceptably. On a typical 143 mHz Ultra,
the clock took 1.0001350 seconds to count 1 second. While this may seem
trivial, it adds up quickly. In this case, the TOD chip will have to
pull the clock forward by 2 seconds every 4 hours and 7 minutes.
This drift rate is so high, that the clock is close to being too broken
for NTP to guarantee correctness (in order for NTP's mechanism to work,
it must be assured that the local clock drifts no more than 20 ms in 64
seconds; this particular 143 mHz Ultra will drift by nearly 9 ms in that
period). This problem has been reproduced on virtually all sun4u
classes.
The fundamental problem lies in the kernel's perception of ticks per
second. The PROM is responsible for determining this figure exactly,
and the kernel extracts it into the variable cpu_tick_freq. On sun4u's,
this number is disconcertingly round: 143000000, 167000000, 248000000,
etc. Indeed, a simple experiment revealed that these numbers were
quite far from the actual ticks per second. Typical was the 143 mHz
Ultra which was discovered to tick around 142,980,806 (+/- 10) times
per second.
Work around:
Integrated in releases: s297_27
Duplicate of:
Patch id:
See also:
Summary:

74
dist/ntp/html/hints/solaris.xtra.4095849 vendored
View File

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

21
dist/ntp/html/hints/solaris.xtra.S99ntpd vendored
View File

@ -1,21 +0,0 @@
#!/bin/sh
if [ $1 = "start" ]; then
if [ -x /usr/local/bin/xntpd ]; then
echo "Starting NTP daemon, takes about 1 minute... "
# dosynctodr may need to be left alone as of with Solaris 2.6
# The following line is unnecessary if you turn off
# dosynctodr in /etc/system.
/usr/local/bin/tickadj -s
/usr/local/bin/ntpdate -v server1 server2
sleep 5
/usr/local/bin/xntpd
fi
else
if [ $1 = "stop" ]; then
pid=`/usr/bin/ps -e | /usr/bin/grep xntpd | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'`
if [ "${pid}" != "" ]; then
echo "Stopping Network Time Protocol daemon "
/usr/bin/kill ${pid}
fi
fi
fi

85
dist/ntp/html/hints/solaris.xtra.patchfreq vendored
View File

@ -1,85 +0,0 @@
#!/bin/ksh
#
# File: patchfreq
# Author: Bryan Cantrill (bmc@eng.sun.com), Solaris Performance
# Modified: Sat Apr 26 04:00:59 PDT 1997
#
# This is a little script to patch a 5.5 or 5.5.1 kernel to get around
# the cpu_tick_freq inaccuracy. Before running this script, one must
# know the true frequency of one's CPU; this can be derived by NTP,
# or by observing the clock relative to the time-of-day chip over a
# long period of time (the TOD will pull system time when it drifts
# by more than two seconds).
#
# Patching a kernel can render a machine unbootable; do not run this
# script unless you are prepared to accept that possibility. It
# is advisable to have a backout path (e.g. net booting, an alternate
# boot disk, an installation CD) should your machine fail to boot.
#
# This is not a product of Sun Microsystems, and is provided "as is",
# without warranty of any kind expressed or implied including, but not
# limited to, the suitability of this script for any purpose.
#
if [ $# -eq 0 ]; then
echo "Usage: $0 cpu_tick_freq [ alternate_kernel ]"
exit 1
fi
cpu_tick_freq=$1
kernel=/platform/sun4u/kernel/unix
if [ $# -eq 2 ]; then
kernel=$2
fi
if [ ! -w $kernel ]; then
echo "$0: Cannot open $kernel for writing."
exit 1
fi
arch=`echo utsname+404?s | adb $kernel | cut -d: -f2`
if [ ! $arch = "sun4u" ]; then
echo "Patch only applies to sun4u"
exit 1
fi
rel=`echo utsname+202?s | adb $kernel | cut -d: -f2`
if [ ! $rel = "5.5" ] && [ ! $rel = "5.5.1" ]; then
echo "Patch only applies to 5.5 or 5.5.1..."
exit 1
fi
nop="1000000" # nop
store_mask="ffffe000" # mask out low 13 bits
store="da256000" # st %o5, [%l5 + offset]
instr=`echo setcpudelay+34?X | adb $kernel | cut -d: -f 2 | nawk '{ print $1 }'`
if [ $instr = $nop ]; then
echo "Instruction already patched..."
else
let masked="(16#$store_mask & 16#$instr) - 16#$store"
if [ $masked -ne 0 ]; then
echo "Couldn't find instruction to patch; aborting."
exit 1
fi
if ! echo setcpudelay+34?W $nop | adb -w $kernel 1> /dev/null
then
echo "adb returned an unexpected error; aborting."
fi
fi
echo "Patching cpu_tick_freq to $cpu_tick_freq..."
if ! echo cpu_tick_freq?W 0t$cpu_tick_freq | adb -w $kernel 1> /dev/null; then
echo "adb returned an unexpected error; aborting."
exit 1
fi
echo "$kernel successfully patched."
exit 0

15
dist/ntp/html/hints/sun4 vendored
View File

@ -1,15 +0,0 @@
Notes on CPU clock oscillator tolerance with SunOS 4.1.1 and 4.1.3
A bug in SunOS 4.1.1 results in the kernel time losing 1 microsecond
per tick of the system clock. The bug was fixed (bugid 1094383) for
SunOS 4.1.1 and corrected in SunOS 4.1.3. The easiest way to fix this
is to replace the 4.1.1 binary clock.o with the corresponding 4.1.3
binary. Without this change it is necessary to use the tickadj program
included in this distribution with the -t 9999 option.
The tickadj option will work in all cases except when the kernel has
been modified to correct the CPU clock oscillator frequency using a
1-pps signal from a precision source. The bugfix must be installed for
this wrinkle to work properly.
Dave Mills (mills@udel.edu)

8
dist/ntp/html/hints/svr4-dell vendored
View File

@ -1,8 +0,0 @@
Notes on the DELL SVR4.
You should use -DSETTIMEOFDAY_BROKEN.
Philip.Gladstone@mail.citicorp.com
(XXX But there is no checking for SETTIMEOFDAY_BROKEN in the code)

33
dist/ntp/html/hints/svr4_package vendored
View File

@ -1,33 +0,0 @@
Date: Wed, 12 Apr 1995 12:42:03 +0100
Message-ID: <513.797686923@concurrent.co.uk>
From: Andy Chittenden <asc@concurrent.co.uk>
Dave
Here is a uuencoded, compressed tar file. The only file I've
changed is Makefile - I've included the full file rather than diffs.
There are some new files as well:
xntp shell script that starts up ntp during boot up
(the packaging stuff creates links to it so it comes
up at run level 2). As with all svr4 start/stop
scripts, it takes one parameter which is either
start or stop. It assumes that ntp.conf is in
/etc/inet/ntp.conf (where it should be on svr4
machines).
prototype describes the file contents of the package.
You might like to review its contents to
see whether you want to include any other
files or remove some. NB I've made the man
pages go into 1m as they should on svr4.
preinstall runs before installation takes place. It
ensures that ntp is down if it is up before
installing a replacement package
postinstall starts up ntp after package installation.
preremove brings down ntp before removing the package.
You create a package using "make package". This creates a file
called xntp.pkg. To install this package, you use
"pkgadd -d `pwd`/xntp.pkg xntp". This will start up ntp if
/etc/inet/ntp.conf exists. If you don't want the package anymore, use
"pkgrm xntp". I have tested this on Solaris 2.4.

4
dist/ntp/html/hints/todo vendored
View File

@ -1,4 +0,0 @@
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>:
Any change in a source file in the lib directory causes all files to
be recompiled (because the objects are removed). Add a better rule for
make to update the library. Maybe just remove "-rm -f $?".

18
dist/ntp/html/hints/vxworks.html vendored
View File

@ -1,18 +0,0 @@
<HTML>
<HEAD>
<TITLE>vxWorks Port of NTP</TITLE>
</HEAD>
<BODY LINK="#00008B" VLINK="#8B0000">
<H1>VxWorks port of NTP </H1>
<P>Please look at the <A HREF="../vxworks.htm">Vxworks file</A> in the html directory.
<P>Casey Crellin</A> <BR>
<A HREF="mailto:casey@csc.co.za">casey@csc.co.za</A> </P>
<P><BR>
</P>
</BODY>
</HTML>

322
dist/ntp/html/hints/winnt.htm vendored
View File

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

315
dist/ntp/html/howto.htm vendored
View File

@ -1,315 +0,0 @@
<html><head><title>
How to Write a Reference Clock Driver
</title></head><body><h3>
How to Write a Reference Clock Driver
</h3><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>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

1198
dist/ntp/html/htmlprimer.htm vendored
View File

File diff suppressed because it is too large Load Diff

197
dist/ntp/html/index.htm vendored
View File

@ -1,197 +0,0 @@
<html><head><title>
The Network Time Protocol (NTP) Distribution
</title></head><body><h3>
The Network Time Protocol (NTP) Distribution
</h3>
<H4>Introduction</H4>
Note: The software contained in this distribution is available without
charge under the conditions set forth in the <A
HREF=copyright.htm>Copyright Notice</A>.
<P>The Network Time Protocol (NTP) is used to synchronize the time of a
computer client or server to another server or reference time source,
such as a radio or satellite receiver or modem. It provides client
accuracies typically within a millisecond on LANs and up to a few tens
of milliseconds on WANs relative to a primary server synchronized to
Coordinated Universal Time (UTC) via a Global Positioning Service (GPS)
receiver, for example. Typical NTP configurations utilize multiple
redundant servers and diverse network paths, in order to achieve high
accuracy and reliability. Some configurations include cryptographic
authentication to prevent accidental or malicious protocol attacks.
<P>Background information on computer network time synchronization can
be found on the <A HREF=exec.htm>Executive Summary - Computer Network
Time Synchronization</A> page. Discussion on protocol conformance issues
and interoperability with previous NTP versions can be found in the <A
HREF=biblio.htm>Protocol Conformance Statement</A> page. Discussion on
year-2000 issues can be found in the <A HREF=y2k.htm>Year 2000
Conformance Statement page</A>. Background information, bibliography and
briefing slides suitable for presentations can be found in the <A
HREF=http://www.eecis.udel.edu/~mills/ntp.htm> Network Time
Synchronization Project</A> page.
<H4>Building and Installing NTP</H4>
The <A HREF=build.htm>Building and Installing the Distribution
</A>page presents an overview of the procedures for compiling the
distribution and installing it on a typical client or server. The build
procedures inspect the system hardware and software environment and
automatically select the appropriate options for that environment. While
these procedures work with most computers and operating systems marketed
today, exceptions requiring manual intervention do exist, as documented
in the <A HREF=config.htm>Configuration Options </A>and <A
HREF=release.htm>Release Notes </A>pages.
<P>Bringing up a NTP primary server requires a radio or satellite
receiver or modem. The distribution includes hardware drivers for over
two dozen radio clocks and modem services. A list of the particular
receivers and modem drivers supported in the distribution is given in
the <A HREF=refclock.htm>Reference Clock Drivers </A>page. For most
popular workstations marketed by Digital, Sun and Hewlett Packard, as
well as widely available Unix clones such as FreeBSD and Linux, the
automatic build procedures select all drivers that run on the target
machine. While this increases the size of the executable binary
somewhat, individual drivers can be included or excluded using the
configure utility documented in the Configuration Options page.
<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>However, in order to participate in the existing NTP synchronization
subnet and obtain accurate, reliable time, it is usually necessary to
construct an appropriate configuration file, commonly called
<TT>ntp.conf</TT>, which establishes the servers and/or external
receivers or modems to be used by this particular machine. Directions
for constructing this file are in the <A HREF=notes.htm>Notes on
Configuring NTP and Setting up a NTP Subnet </A>page. However, in many
common cases involving simple network topologies and workstations, the
file data can be specified entirely on the command line.
<P>The most important factor in providing accurate, reliable time is the
selection of modes and servers to be used in the configuration file. NTP
support for one or more computers is normally engineered as part of the
existing NTP synchronization subnet. The existing NTP subnet consists of
a multiply redundant hierarchy of servers and clients, with each level
in the hierarchy identified by stratum number. Primary servers operate
at stratum one and provide synchronization to secondary servers
operating at stratum two and so on to higher strata. In this hierarchy,
clients are simply servers that have no dependents.
<P>The NTP subnet in early 1998 includes 70 public primary (stratum 1)
servers synchronized directly to UTC by radio, satellite or modem and
located in every continent of the globe, except Antarctica (soon).
Normally, client workstations and servers with a relatively small number
of clients do not synchronize to primary servers. There are 106 public
secondary (stratum 2) servers synchronized to the primary servers and
providing synchronization to a total in excess of 100,000 clients and
servers in the Internet. The current lists are maintained in the <A
HREF=http://www.eecis.udel.edu/~mills/ntp/index.htm>Information on Time
and Frequency Services</A> page, which is updated frequently. There are
numerous private primary and secondary servers not normally available to
the public as well. You are strongly discouraged from using these
servers, since they sometimes hide in little ghettos behind dinky links
to the outside world and your traffic can bring up expensive ISDN lines,
causing much grief and frustration.
<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>.
<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=ntp.htm>NTP Reference Library</A></LI>
<LI><A HREF=copyright.htm>Copyright Notice</A></LI>
<LI><A HREF=exec.htm>Executive Summary - Computer Network Time
Synchronization</A></LI>
<LI><A HREF=biblio.htm>Protocol Conformance Statement</A></LI>
<LI><A HREF=y2k.htm>Year 2000 Conformance Statement</A></LI>
<LI><A HREF=notes.htm>Notes on Configuring NTP and Setting up a NTP
Subnet</A></LI>
<LI><A HREF=release.htm>NTP Version 4 Release Notes</A></LI>
<LI><A HREF=build.htm>Building and Installing the
Distribution</A></LI>
<LI><A HREF=config.htm>Configuration Options</A></LI>
<LI><A HREF=debug.htm>NTP Debugging Techniques</A></LI>
<LI><A HREF=refclock.htm>Reference Clock Drivers</A></LI>
<LI><A HREF=patches.htm>Patching Procedures</A></LI>
<LI><A HREF=hints.htm>Hints and Kinks</A></LI>
<LI><A HREF=porting.htm>Porting Hints</A></LI>
</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>A Kernel Model for Precision Timekeeping</A></LI>
<LI><A HREF=kernpps.htm>A Kernel Programming Interface for Precision
Time Signals</A></LI>
</ul>
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

51
dist/ntp/html/kern.htm vendored
View File

@ -1,51 +0,0 @@
<HTML><HEAD><TITLE>
A Kernel Model for Precision Timekeeping
</TITLE></HEAD><BODY><H3>
A Kernel Model for Precision Timekeeping
</H3><HR>
<P>The technical memorandum: <I>A Kernel Model for Precision
Timekeeping</I><A
HREF="http://www.eecis.udel.edu/~mills/database/memos/memo96b.ps">
(PostScript) </A>describes an engineering model which implements a
precision time-of-day function for a generic operating system. The model
is based on the principles of disciplined oscillators using phase-lock
loops (PLL) and frequency-lock loops (FLL) often found in the
engineering literature. The model uses a hybrid PLL/FLL discipline
algorithm implemented in the kernel. The hybrid loop provides automatic
time and frequency steering with update intervals from a few seconds to
over one day.
<P>The hybrid PLL/FLL has been implemented in the Unix kernels for
several workstations, including those made by Sun Microsystems, Digital
and Hewlett Packard. Currently, the modifications are in licensed
kernels for Digital Unix 4.0 and Sun Solaris 2.6. Since these specific
implementations involve modifications to licensed code, they cannot be
provided directly. Inquiries should be directed to the manufacturer's
representatives. In addition to the licensed kernels, the hybrid PLL/FLL
has been implemented in the nonlicensed kernels for Linux and FreeBSD.
The engineering model for these implementations, including a simulator
with code segments almost identical to the implementations, but not
involving licensed code, is available via the web at <A
HREF="http://www.eecis.udel.edu/~mills/ntp/ntp">kernel.tar.Z</A> or by
anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
<P>The model changes the way the system clock is adjusted in time and
frequency, as well as provides mechanisms to discipline its time and
frequency to an external precision timing source, such as a pulse-per-
second (PPS) signal. The model incorporates a generic system-call
interface for use with the Network Time Protocol (NTP) or similar time
synchronization protocol. The NTP software daemons for Version 3
<TT>xntpd</TT> and Version 4&nbsp; <TT>ntpd</TT> operate with this model
to provide synchronization limited in principle only by the accuracy and
stability of the external timing source. There are two new system calls
defined in the model, <TT>ntp_gettime()</TT>, which returns a structure
including the current time, estimated error and maximum error, and
<TT>ntp_adjtime()</TT>, which provides a means to adjust kernel
variables, including the current time and frequency offsets. Further
information on the calling sequences and variable definitions are in the
<TT>/usr/include/sys/timex.h</TT> file.&nbsp;
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>

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