From: "Matthew D. Healy, Ph.D." <Matthew.Healy@yale.edu>
Date: Mon, 2 Mar 1998 09:58:29 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: An inexpensive but accurate time source?
X-Keywords: PPS [-/+]
Lee Reynolds, Software Release Engineer wrote in message
<34FAB03B.D426ED89@fluent.com>...
>I recently picked up an interesting toy - the DeLorme "Tripmate"
...
>I know that the GPS birds carry extremely accurate clocks - the Tripmate
>is capable of getting that datastream - has anyone
You are correct that in order to perform its navigational functions
at all, any GPS must have an internal time reference that is accurate
to within well under a microsecond.
However, the problem with virtually all mass-market consumer GPS
devices is that there is no easy means of getting external access to
that internal clock reference.
Most mass-market GPS units do have a time display. Most do include
time of day in their NEMA output signals.
However, updating the screen display and NEMA output is a very low
priority task for the CPU inside that GPS: it spends most of its cycles
keeping its internal reference locked-in to the birds, and uses what
cycles it can spare for updating its output, on the assumption that if
it is a few hundred milliseconds late in updating the display, the user
will not care, but if it cannot keep in sync with the birds it cannot do
its primary function at all.
Therefore, the signals visible outside the device might be delayed by
as much as a second relative to that extremely accurate internal time
reference -- and the offset varies unpredictably.
In order to get NTP-quality time information from a GPS, you must
either purchase a higher-end model that includes a special PPS
(pulse-per-second) output, or else assemble your own from an OEM
board. The first of these options requires significant money, as I do
not know of a mass-market device with this feature. The second is
not much more expensive than a consumer GPS, but requires that
you be able to read schematic diagrams and willing to use a
soldering iron.
From: !panderson!@westpac.com.au (Peter Anderson) [-/+]
Date: Tue, 03 Mar 1998 04:15:52 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: GPS clock year 2000 testing
X-Keywords: Arbiter [-/+]
Hi all,
I was a bit stumped on how I was going to do year 2000 testing on our NTP
infrastructure. I mean how do you setup a year 2000 testing set of GPS
satellites?
We have two Arbiter 1092B GPS receiver clocks connected to two SUN Sparc5
(Solaris 2.5.1) and running xntpd 3-5.90.1.
Arbiter have stated that all their GPS receivers handle GPS week 1024 & year
2000 correctly, so (hopefully) no issues there.
Therefore to simulate the GPS clock ticking over to year 2000 I have written a
simple perl script to emulate a Arbiter GPS clock.
I've had to modify xntpd (ntp_io.c, ntp_refclock.c & refclock_arbiter.c) to
handle using a named pipe as i/o rather than a serial line and sometimes xntpd
rips stuff off the pipe queue before my perl script sees it. Other than that
it works OK. (probably should have just written a program to read/write to a
serial port on another machine would have been easier)
The whole lot is a bit bodgy and was probably a waste of time, but if your
managers are like mine, they don't believe anything is y2k compliant until
tested in-house.
If anyone is interested send me an email and I'll send you my stuff. I'm
sure it would be easy to modify for other brand GPS clocks too.
I don't make any guarantees on any code I give out, therefore only use it on a
TESTING machine!
Peter Anderson
Senior Communications Analyst
Westpac Banking Corporation
From: James Kirkpatrick <jimkirk@uwyo.edu> [-/+]
Date: Thu, 05 Mar 1998 13:17:29 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Datum, True Time ntp servers [-/+]
X-Keywords: Datum [-/+] update [-/+]
Charles Klement wrote:
>
> Hello,
>
> I am looking to implement a dedicated NTP server at our site. Browsing
> the net, I have run across two products that look very interesting. The
> First is the "Datum Tymeserve-2100" and the other is the "True Time
> NTS-100"
>
> I am interested in hearing from anyone who has used either or both of
> these. Are they decent products?
>
> -charles
We use the Tymserve 2100 (GPS) and are basically happy with it. Ours will
sometimes hang but a firmware update would probably fix it (haven't installed
it because the installation procedure has about 14 steps and the hangs are
no big deal to us).
Jim
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 5 Mar 1998 16:29:37 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: IGEL clock - accuracy?
X-Keywords: Datum [-/+] PPM [-/+] precision [-/+] TrueTime [-/+]
Dag Bakke <dagb@oslo.sgi.com> writes:
>I am searching for a clock which gives me 0.5 PPM accuracy and would
>very much like suggestions for suitable hardware.
Best bet would be a bus-card (PCI, VME, S-Bus, and ISA are the ones
I know about) that synchronizes to GPS. You will need one per
machine, since NTP cannot deliver that degree of precision. They
cost, typically, in the range of of US$[1-3]K. Some (but not all) also
deliver precision location information, as well as time.
Check out the web pages for Datum, TrueTime, and Odetics.
Good luck!
Rick
From: Ruediger Eckhard <Ruediger.Eckhard@oen.siemens.de> [-/+]
Date: Fri, 06 Mar 1998 14:44:16 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Nasty fast clock (Sol 2.5) - can it be tamed??? [-/+]
This is a multi-part message in MIME format.
--------------727B0504E9C5825800A803FB
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
X-Keywords: cpu_tick_freq [-/+] PPS [-/+] SCO [-/+] stability [-/+] syslog [-/+]
Gregory Bond wrote:
> We have one of our Solaris 2.5.1 machines (a Ross SparcPlug cpu
> module) that has a shocking clock that runs about 1% (yes, that's
> 10,000ppm) fast. It's sync'd to a stratum-3 server that has good-
> enough-for-our-purposes time (under 1/2 sec is what I'm aiming for -
> I'm not too ambitious!)
>
> An extract from the syslog shows it's gaining time at a shocking rate
> and getting lotsa of step time adjustments. This is Ugly on a
> production system that is supposed to be providing timestamps to
> important transactions....
>
> I've turned off dosyntodr with no noticable improvement. Anything
> else I can try (short of moving to a new machine)?
>
> And on a related note, has anyone any comments about the xntpd shipped
> with 2.6? Can I just get a NMEA-compatible GPS and plug it in and
> run? What about the PPS stuff?
>
> Mar 5 12:39:15 gallows xntpd[251]: offset -8.384604 freq -683.17308 comp 0
> Mar 5 13:24:37 gallows xntpd[251]: ** adjust: STEP 192.43.186.5 offset -23.523669243 **
> Mar 5 13:39:15 gallows xntpd[251]: offset -4.449414 freq -683.17308 comp 0
> Mar 5 13:42:45 gallows xntpd[251]: ** adjust: STEP 192.43.186.5 offset -8.946010590 **
> Mar 5 13:59:49 gallows xntpd[251]: ** adjust: STEP 192.43.186.5 offset -6.605636597 **
> Mar 5 14:16:53 gallows xntpd[251]: ** adjust: STEP 192.43.186.5 offset -6.285675526 **
>
> --
> Gregory Bond ITG Australia Ltd, Melbourne, Australia
> <mailto:gnb@itga.com.au> <http://www.bby.com.au/~gnb>
> From: bruce@itga.com.au (Do not use this address. It catches junk email.)
> From: bruce@bby.com.au, bruce@melba.bby.com.au (So do these ones)
There is an unofficial patch from SUN, posted a year ago on this news
group.
Basically you have to patch the cpu_tick_freq kernel variable to the real
frequency as shown in the attachment. The question is how to figure out the
frequency, if xntp can't synchronise :-(
The bad side is, that this patch helped to bring down the drift from 260 to
-39 on my machine, but not better.
My machines' real frequency is 166965574. If I patch to this frequency, I
got a ppm of -39. I increased the frequency and detected, that the ppm
value found by xntp jumps between patched values of 166965595 and 166965600
from -39 to +45. So there is a huge granularity involved. But at least it
is possible to bring the drift into an area that xntp can deal with.
Maybe some day somebody can write some cookbook for adjusting the clock
frequency on the different machine types. I regard this to be the first
step to set up a ntp network. A small ppm value is one of the first steps
to ensure stability if the primary source goes away for some reason, isn't
it?
I have now set up a network consisting of linux, Solaris 2.3 and 2.5.1 as
well as SCO 3.2v5.0.4. Solaris 5.3 is ok at 1 ppm, Linux is at 16, but
Solaris 5.5.1 has a drift of -39 ppm and the SCO machines of -70.
Rüdiger
--
Ruediger Eckhard Siemens AG, OeN BN AP 22
Tel.: +49 89 722 34197 Fax: +49 89 722 27431
Email: Ruediger.Eckhard@oen.siemens.de
--------------727B0504E9C5825800A803FB
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
X-Keywords: cpu_tick_freq [-/+]
#!/bin/ksh
#set -x
#
# 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
--------------727B0504E9C5825800A803FB
From: Unknown Author <none> (auto-inserted) [-/+]
Subject: none (auto-inserted) [-/+]
#!/usr/local/bin/tcsh
set verbose on
foreach host (aruba curacao hawaii )
rsh $host /usr/local/bin/fgrep freq /var/adm/log/ntp.log |tail -120 > $host.ntp.freq
end
foreach host (bali wsrave4)
rsh -l bunje $host fgrep freq /var/adm/log/ntp.log |tail -120 > $host.ntp.freq
end
rsh Datentechnik fgrep freq /var/log/ntp.log |tail -120 > Datentechnik.ntp.freq
--------------727B0504E9C5825800A803FB--
From: rcp@interaccess.com.fake (Bob Perschau)
Date: Fri, 06 Mar 1998 14:31:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Datum, True Time ntp servers [-/+]
X-Keywords: Datum [-/+] HPUX [-/+] implementation [-/+] mainframe [-/+] MVS [-/+] TrueTime [-/+]
In article <Pine.GSO.3.95.980304125716.16148B-100000@roslyn.tc.fluke.com>,
Charles Klement <cjk@tc.fluke.com> wrote:
>
>Hello,
>
>I am looking to implement a dedicated NTP server at our site. Browsing
>the net, I have run across two products that look very interesting. The
>First is the "Datum Tymeserve-2100" and the other is the "True Time
>NTS-100"
>
>I am interested in hearing from anyone who has used either or both of
>these. Are they decent products?
>
>-charles
>
We've had our NTS-100 for a few months now. Plug-and-play time synchronization!
Right now I'm using it on the network connection only. Shortly I'll be putting
a Linux PC on the 1PPS serial port. Right now we're syncing a mixture of
VAX-VMS, HPUX, NT, and Linux boxes. The only box I can't touch is the IBM-MVS
mainframe.
I haven't had to call for any support yet, so I'm not sure how that is. I did
however call for some pre-sales support to get some specs. They emailed me a
copy of the manual and answered all of my questions including those directed
toward their SNMP implementation.
No ties to TrueTime, just a satisfied customer
.fake is not part of my email address
Bob Perschau
Panduit Corp.
From: Bob Rubendunst <softm@softm.com>
Date: Mon, 09 Mar 1998 16:24:36 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.unix.aix
Subject: Re: Connecting serial clock (Meinberg DCF77C51) to AIX 4.1.5?
X-Keywords: AIX [-/+] DCF [-/+] Meinberg [-/+] SCO [-/+] Windows [-/+]
Klaus Kusche wrote:
>
> I'm trying to connect a Meinberg DCF77C51 DCF receiver to
> an RS/6000 system running AIX 4.1.5 via serial line.
> I used an ordinary 9-to-25 pin serial cable
> (the same kind used with PC's).
>
> Then, I configured /dev/tty1 on that serial adapter, using
> the baud rate etc. given in the Meinberg manual, with smitty.
>
> Next, I wanted to check if any data is received, but failed:
> A "cat /dev/tty1" or similar commands gave no error, but also no
> data: The command seems to hang forever. The "cu" command recommended
> in the Meinberg manual returned immediately with
> cu: 0835-028 The connection failed. NO DEVICES AVAILABLE.
> (I verified that there was no getty etc. on that tty)
You may need to put a "direct" entry in the /usr/lib/uucp/Devices file
for the tty1 device. Try the line
Direct tty1 - 9600 direct
You might also check in smitty to make sure that tty1's login setting is
set to disable. (This prevents getty from making the port busy.)
Bob Rubendunst
Soft Machines
Communications software for AIX, AMOS, Windows NT, and SCO Unix
http://wwww.softm.com
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 9 Mar 1998 17:15:43 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: I'm looking for a master clock source
X-Keywords: TrueTime [-/+]
>In article <6dfcvc$iqv@newsops.execpc.com>, Phil Walenta
><pwalenta@deluxedata.com> wrote:
>> I have a
>>budget to implement whatever software and hardware I need to perform
>>time synch services. My (obvious?) preference is to use NTP.
>> I just need a master time
>>source. I wish to purchase a device to do this, but I literally have no
>>clue as to what device to get. I'm looking for suggestions as to what
>>kind of device to use.
>>
Phil,
There are a couple of "GPS-in/NTP-over-ethernet-out" boxes available.
The TrueTime NTS-100 is one. Take a look at
<http://www.truetime.com/DOCS/TThomeFRM.html>
and
<http://www.truetime.com/DOCS/NTNTS_100.pdf>
There are others.
They're not cheap, as GPS receivers go (around US$5K), but your
message made it sound like you could afford top-of-the-line if it
made your job less of a hassle. One of these is definitely the least
hassle. Take it out of the box, plug it in, connect it to your
network, turn it on, configure a couple of parameters (mainly IP
address) using the front pannel, and that's all there is to it.
Enjoy!
Rick
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 9 Mar 1998 17:36:07 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd 3 on Solaris 2.x
X-Keywords: WWVB [-/+]
Arnaud Girsch <agirsch@OASysGroup.com> writes:
:Now ... I've heard that several times in various places .... but is it
:"normal" that sources based on GPS and WWVB are so far from each other
:.... I mean, I see an offset of .010 or .015 between stratum 1
:servers.
:Since my upstreams take from GPS or WWVB, it somtimes create problems
:jumping from one to another ...
It depends on how "close" (network topology -wise) you are to your
stratum 1 servers. Long (and frequently asymmetrical) paths between
machines can lead to large dispersions and (especially in the case of
asymmetrical paths) wide discrepancy between the offsets.
As the internet grows (and grows, and grows...) this becomes more of a
problem. I see >10 ms differences frequently. That's why it pays to
have your own local stratum 1 machine, on-campus.
Rick
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 9 Mar 1998 17:41:31 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Isolated Server and Client Config
Thomas Alex <melakon@lucifer.com> writes:
>I am looking for recommendations on how configure XNTP (3-5.92) servers
>and clients in an isolated network.
>Any recommendations and suggestions (ie. what is an appropriate starting
>ntp.conf server config) would be most appreciated.
Take a look at <http://www.cs.rutgers.edu/~rbthomas/> for a set of
slides from a talk I gave on "NTP - Theory and Practice" that covers
setting up a campus NTP network.
Rick
From: Carl Brewer <c.brewer@abm.com.au> [-/+]
Date: Tue, 10 Mar 1998 11:54:15 +1000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: 2.6, 3.5.92 and ELC now working
X-Keywords: PLL [-/+]
Thanks to Gregory Bond (for forwarding me Bruce Bartram's cookbook).
My ELC was having terrible problems with a home-compiled 3.5.92,
but that's because I hadn't gotten rid of the PLL, HAVE_NTP_GETIME
or HAVE_NTP_ADJTIME definitions in config.h after configure
put them in there.
A recompile (and reboot :-/ ) later and my clock is happy.
The recompile didn't go too smoothly, gcc 2.8.0 barfed at some
point (I can provide details if anyone's interested) but it
did build me a new xntpd before it aborted, so for now I'm
up and running without cron ntpdating for me, and I'll look into the
compile failure "at my leisure".
Can anyone enlighten me as to why I had to do that to get it
working? I know Sun did some stuff for NTP in the kernel in
2.6, but didn't actually use it in their supplied NTP deamon
(3.4y I believe), which is odd, I reckon. Is that was causes the
above fix to be required? Does 4.x deal with 2.6 without
requiring hand-hacking? What's new in 4.x anyway? There's nothing
about it on the webpage that I could find.
thanks to everyone for your help.
Date: Fri, 16 Jan 1998 09:24:05 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: mills@udel.edu
Subject: Re: (Fwd) Re: ntp-4.0.71 - PLL run amok, loopstats at 11
Message-ID: <199801160924.aa24330@huey.udel.edu>
X-Keywords: PPS [-/+] precision [-/+]
Ulrich,
Something else is happening. The PPS signal is not used if it doesn't
exist. See the 0x0100 bit - if it ain't set, the kernel is not indulged.
The same default is used here and in all alpha machines to my knowledge,
both with and without PPS support. Of course, I can only test with
Sun, HP and Digital machines. As I said in my original post, DO NOT
use Solaris 2.6 kernels with precision time - the kernels are broken.
The best way to defeat that is to rename the /usr/include/sys/timex.h
to something else.
Dave
Date: Thu, 22 Jan 1998 10:45:43 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: Dave Mills <mills@huey.udel.edu>, "Kristofer T. Karas" <ktk@ktk.bidmc.harvard.edu>
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature. [-/+]
Message-ID: <199801221045.aa23629@huey.udel.edu>
X-Keywords: STA_FLL [-/+]
Ulrich,
Here's what's doing you in. In ntp_loopfilter.c
if (flladj > plladj)
ntv.status |= STA_FLL;
Comment out that code and see if that fixes it.
Dave
Date: Thu, 22 Jan 1998 10:55:09 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: "Kristofer T. Karas" <ktk@ktk.bidmc.harvard.edu>
Cc: mills@huey.udel.edu, ulrich.windl@rz.uni-regensburg.de
Subject: Re: ntp4.0.71/linux - seems "success" a bit premature. [-/+]
Message-ID: <199801221055.aa23650@huey.udel.edu>
X-Keywords: dispersion [-/+] jitter [-/+]
Kris,
Welcome to the wonderful world of statistics. To do it right, you have
to consider the sum of offsets to the primary reference clock. This amounts
to an n-fold convolution, taking into account the means and variance
at each stage. I chose to avoid the messy integrations involved and
retain only the mean offset between each server and client. The dispersion
estimate is meant as a poor-boy statistic for estimated error and does
include the mean offset of the server relative to its own server.
There is another reason to do it my way. Should you include the server's
estimated offset to its source, the net offsets would get real noisy and
lead to substantial jitter near the leaves of the tree. You could reduce
that by extensive averaging, but you eventually run up agains the Allan
inflection and random-walk instability.
Dave
Date: Mon, 2 Mar 1998 09:49:10 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: stenn@whimsy.udel.edu
Cc: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>, mills@udel.edu
Subject: Re: (Fwd) Re: PLL control bug in 3-5.9x? [-/+]
Message-ID: <199803020949.aa14619@huey.udel.edu>
X-Keywords: FLL [-/+]
Harlan,
The FLL code was already disabled for all ports. The kernel should be
disabled for Solaris 2.6 only. I have yet to hear from Sun on my proposal
to fix 2.6.
Dave
Date: Mon, 2 Mar 1998 10:34:16 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: Dave Mills <mills@huey.udel.edu>, stenn@whimsy.udel.edu, Juha Sarlin <juha@c3l.tyreso.se>, hpa@transmeta.com
Subject: Re: (Fwd) Re: PLL control bug in 3-5.9x? [-/+]
Message-ID: <199803021034.aa14894@huey.udel.edu>
X-Keywords: adjustment [-/+] FLL [-/+] poll [-/+] PPS [-/+] synchronized [-/+]
Ulrich,
You scratch an old itch. The problem with NTPv4 is a still unresolved
problem in some cases where the discipline loop comes unstuck with
time constants greater than 10. Note that, for convenience, the time
constant is now numerically equal to the poll interval. That's a scaling
issue for convenience and has nothing to do with the actual use of these
numbers. From past experience, taming instabilities of this kind is
excruciatingly painful, since it requires simulation and experiment
over the entire envelope of possible scenarios. I intend to do that,
but not at this particular moment. The kernel of course has not changed
with NTPv4 and the interface is intended to be the same. However, the
new FLL design requires direct interaction with the frequency, at least
if some adjustment based on FLL data is required. This is also a delicate
scheme, since it requires the coefficient of the frequency variable
to be accurately known. I don't know if all kernels have the same
frequency scaling as my mods for Sun and Digital. I need to verify that
assumption.
The ntp_adjtime() is quite anal retentive; however, not all errors should
be considered fatal. What I intended the applications to notice is the
cases where the clock is not synchronized and also to notice the expected
error and maximum error. Whether the PPS signal is present or not should
be considered a soft error, for example.
Dave
Date: Tue, 3 Mar 1998 15:21:16 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: "Kristofer T. Karas" <ktk@ktk.bidmc.harvard.edu>
Cc: juha@c3l.tyreso.se, Ulrich.Windl@rz.uni-regensburg.de, mills@udel.edu
Subject: Re: Report on using ntp-4.0.72 under Linux-2.0 [-/+]
Message-ID: <199803031521.aa26332@huey.udel.edu>
X-Keywords: MAXTC [-/+]
Kris,
If the Linux code is close to my model code in kernel.tar, you have
increased the maximum averaging time from 1024 seconds to 4096 seconds.
I doubt very much that your loop will stay locked if the room ambient
temperature changes quickly. That may be acceptable in face of better
suppression of large phase noise, but I am skeptical.
My kernel model has no MAXTC, although the original ntp_loopfilter.c
did. What's going on here?
The NTPv4 kernel model is identical to NTPv3, at least for the present.
Dave
Date: Wed, 4 Mar 1998 10:17:11 EST [-/+]
From: Dave Mills <mills@huey.udel.edu> [-/+]
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: Dave Mills <mills@huey.udel.edu>, juha@c3l.tyreso.se, Ulrich.Windl@rz.uni-regensburg.de, mills@udel.edu, j@rkdvmks1.ngate.uni-regensburg.de
Subject: Re: Report on using ntp-4.0.72 under Linux-2.0 [-/+]
Message-ID: <199803041017.aa03200@huey.udel.edu>
X-Keywords: implementation [-/+] MAXTC [-/+] poll [-/+]
Ulrich,
The intent of the original MAXTC in the reference kernel implementation
documented in kernel.tar is to vary over he range 0-6 corresponding
to a poll interval range 2^4 through 2^10. The actual values were
determined by extensive simulation, as documented in kernel.tar and
the simulator program there. The MAXTC was chosen mainly to prevent
the time constant increasing beyond 2^6 when the poll interval is
increased beyond 1024 s for modems. It probably is not a good idea to
insert additional sanity checks in the interface code (ntp_adjtime()
does not do this), as this just adds additional layers of things that
break and confuse folks.
Dave
Date: Mon, 16 Mar 1998 11:22:38 -0700 [-/+]
From: bwb@etl.noaa.gov (Bruce Bartram 303-497-6217) [-/+]
Message-Id: <199803161822.LAA28527@mickey>
To: Ulrich.Windl@rz.uni-regensburg.de
Subject: correction to "taming the wild tick"
X-Keywords: dosynctodr [-/+] logconfig [-/+] nsec_per_tick [-/+] syslog [-/+]
Howdy,
I just noticed that I swapped the signs of ntp.drift in my "taming the
wild tick" I sent you over the weekend. Attached it the corrected version.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
----- taming the wild tick
Taming the wild tick (written about Solaris, but applicable elsewhere)
This is my "cookbook" that was mentioned recently.
For a sparc CPU (not ultra or x86) with Solaris 2.5 and the
newer (3-5.90 or later) tickadj, you can change the basic clock
rate by:
tickadj -sA -t <nsec_per_tick>
I'd start by looking in /etc/system to see if there is anything wierd
grep per_tick /etc/system
A reboot is needed for any changes to take effect. I always save
an unchanged version and read the man pages about how to reboot without
reading /etc/system before hacking away.
I'd measure the basic clock rate by
tickadj -s # make sure dosynctodr is off
kill <xntpd PID> # make things simple
ntpdate -d server >file
sleep 1000
ntpdate -d server >>file
Since ntpdate should be able to measure to a few ms, a 1000 second
interval should get the rate to a few ppm, which is a good first guess.
With a freq error as large as you report, I'd calculate
new nsec_per_tick = ( 1 + delta_offset / delta_time ) * 10^7
and then "tickadj -sA -t <new nsec_per_tick>". Then "rm ntp.drift" and
restart the daemon to see if things are better.
If it starts to work better, watch it for a few days, pick the most
common ntp.drift value (I have "logconfig +allstatistics" in my ntp.conf
and watch syslog daemon.info to pick a value). I'd then calculate
best guess nsec_per_tick = current nsec_per_tick ( 1 + ntp.drift/2^20 )
The ntp.drift value is positive if the host is slow, negative if the
basic rate is fast and the ntp.drift is in parts/2^20. The drift is
added to the host's time each second by the xntp daemon.
From: david dalton <dalton@hpindht.cup.hp.com>
Message-Id: <199804132215.PAA11672@hpindht.cup.hp.com>
Subject: Re: (Fwd) NTP Primer Available [-/+]
To: ulrich.windl@rz.uni-regensburg.de (Ulrich Windl)
Date: Mon, 13 Apr 1998 15:15:01 PDT [-/+]
In-Reply-To: <1B7121642D14@rkdvmks1.ngate.uni-regensburg.de>; from "Ulrich Windl" at Apr 9, 98 7:43 am
Reply-To: dalton@cup.hp.com
X-Keywords: ACTS [-/+] adjustment [-/+] antenna [-/+] Bancomm [-/+] broadcast [-/+] CHU [-/+] Cisco [-/+] configuration [-/+] Datum [-/+] DCF [-/+] DCF77 [-/+] delay [-/+] dialup [-/+] dispersion [-/+] driftfile [-/+] FAQ [-/+] fudge [-/+] HP-UX [-/+] IRIG [-/+] maxpoll [-/+] Meinberg [-/+] Mills [-/+] minpoll [-/+] monitor [-/+] MSF [-/+] multicast [-/+] NIST [-/+] NMEA [-/+] PARSE [-/+] peer [-/+] poll [-/+] PPS [-/+] precision [-/+] prefer [-/+] reachable [-/+] RFC1305 [-/+] Spectracom [-/+] stability [-/+] synchronized [-/+] syslog [-/+] timezone [-/+] Trimble [-/+] TrueTime [-/+] USNO [-/+] WWV [-/+] WWVB [-/+]
Ulrich,
Here is a shar of a plain text file derived from my NTP Primer. Please do
put it in the FAQ and we will advertise it all around.
[Auto-converted text follows (this is really a forgery ;-) Ulrich Windl]
NTP Time Services on HP-UX
Network Time Protocol
RFC1305
David Dalton
Hewlett-Packard Company
19420 Homestead Road
Cupertino CA 95014
408/447-0000
dalton@cup.hp.com
What Is NTP?
The Network Time Protocol is a family of programs that are used to adjust
the system clock on your computer and keep it synchronized with external
sources of time. Time data is requested from outside sources (radio clock,
network timeservers) and delivered to clients within your domain. It is
designed to provide accuracy in the microsecond to millisecond range with
hardware available in the mid 1990s.
NTP was developed by Dr David Mills at the University of Delaware. Excellent
information is available at their website:
http://www.eecis.udel.edu/~ntp
ntpdate vs xntpd
Depending on your needs, you may choose to have your system clock updated
periodically (with a cron job) or to run the full-time daemon that continually
adjusts your system clock and keeps it synchronized at all times. The periodic
approach (ntpdate) is simpler and more robust, but accuracy is limited and it
can lead to small jumps in time. The continuous approach (xntpd) is harder to
set up and very finicky about network service quality, but provides the best
accuracy and the smoothest operation.
Sources of Time
The passage of time is a fact of life, something that we have no control over.
But time of day is a human construct, and the official definition of
time-of-day is regulated and distributed by the US Naval Observatory and BIH
(Bureau International d'Huere) by international agreement. The most common
distribution mechanisms are radio signals (terrestrial and satellite broadcast),
phone/modem, and computer networks.
Having your own radio receiver provides the ultimate accuracy, and there are
no worries about network delays, congestion, or outages. But the radio
receivers are expensive, typically US$1000 to US$10000, and so very few people
have them. The popular radio methods are:
GPS Global Positioning System (satellite)
WWV (terrestrial North America)
DCF77 (terrestrial Europe)
MSF (terrestrial Britain)
On the Internet there are many public timeservers available for you to connect
to, and they will provide NTP services free on a limited basis. This is the
most popular method (due to low cost), and this is the main benefit provided
by NTP. There are also public timeservers that provide dialup access through
a modem. A very popular one is operated by the US Government in Boulder
Colorado (NIST), getting thousands of phone connections each day. There are
similar free services in other countries, and there are some premium services
that provide better accuracy for a fee.
If you are not connected to the Internet and cannot justify the expense of a
radio receiver, there is a way to declare some of your NTP machines to be
timeservers anyway, and have them serve time to the rest of your closed domain.
This is not highly recommended because there is no real synchronization to the
real world, but it is possible to keep the system clocks of all of the
computers in your domain very close to each other this way. Sometimes close
together is enough.
Configuring Your First Server
Before doing anything else, you should install the latest version of NTP. The
version that ships with HP-UX 10.x is old and has numerous limitations. It
does not support the HP GPS clocks. The latest version of NTP is contained in
PHNE_11019.
Your first task is to choose a source of time. The four choices are network
timeservers, radio receivers, dialup/modem, or the local clock impersonator.
NETWORK TIMESERVERS:
In large organizations there may already be network timeservers in operation
near you, so consult your system administrators for these. Otherwise look at
the list of public time servers and choose three (or more) that are nearby
geographically. If you are in London, it would usually not be wise to choose
timeservers in Australia or Brazil. You can evaluate the network distance
between you and these servers by running the "/usr/sbin/ntptrace" command for
each of the servers. Here are some examples from HP's internal network
(these machines are not available to the public):
# /usr/sbin/ntptrace cupertino.cns.hp.com
cupertino.cns.hp.com: stratum 2, offset -0.021505, synch distance 0.09186
listo.hp.com: stratum 1, offset -0.028593, synch distance 0.04030, refid`WWVB'
This shows that the machine "cupertino.cns.hp.com" is a stratum 2 timeserver
at synch distance 0.09186 (seconds, smaller is better), and it is served by
another machine "listo.hp.com" which is a stratum 1 timeserver (with radio
clock WWVB) at an additional synch distance of 0.04030. Compare this with:
# /usr/sbin/ntptrace boise.cns.hp.com
boise.cns.hp.com: stratum 2, offset -0.008381, synch distance 0.13771
listo.hp.com: stratum 1, offset -0.000661, synch distance 0.04251, refid `WWVB'
This machine "boise.cns.hp.com" is farther away at synch distance 0.13771, so
it is less desirable than "cupertino.cns.hp.com" even though they are both
stratum 2 and ultimately served by the same timeserver "listo.hp.com".
The "ntptrace" command will continue over many strata: For example:
# ntptrace cosl4
cosl4: stratum 5, offset 0.022003, synch distance 0.24033
te897-01.cup.hp.com: stratum 4, offset 0.014292, synch distance 0.17822
hpuxps.cup.hp.com: stratum 3, offset 0.006833, synch distance 0.13556
cupertino.cns.hp.com: stratum 2, offset 0.005313, synch distance 0.07320
listo.hp.com: stratum 1, offset 0.010896, synch distance 0.02277, refid 'WWVB'
#
You must choose a minimum of one timeserver, and it is a good idea to choose
three or more for redundancy. More on redundancy later. Then put lines like
this at the end of your "/etc/ntp.conf" file:
server big_serv.my_domain.my_org.com
server med_serv.my_domain.my_org.com
server little_serv.my_domain.my_org.com
RADIO RECEIVERS:
To set up the HP58503A GPS receiver for NTP, you must have the receiver and
antenna installed, and connected to a serial port on the HP-UX machine. Put
these lines at the end of your "/etc/ntp.conf" file:
server 127.127.26.1
#fudge 127.127.26.1 time1 -0.955 # s700
#fudge 127.127.26.1 time1 -0.930 # s800
Uncomment the correct "fudge" line for your architecture. Then make a link to
the device file that corresponds to the serial port you are connecting to the
GPS unit:
/usr/bin/ln -s /dev/tty0p0 /dev/hpgps1
Other radio receivers are very similar. Each one talks to a particular clock
driver (#26 for HP GPS) and uses a particular device name (/dev/hpgps1 for HP
GPS). The full list of drivers and devices is shown in the appendix.
DIALUP/MODEM
server 127.127.18.1
This method works just like a radio clock, with driver #18. You must have a
modem and telephone connection, and the system will make a call to NIST in
Boulder, Colorado. The cost of a one minute phone call in the dead of night
is reasonable, and it is possible to limit the calls to one per day or one
per week. The system must be able to make the long distance call unattended,
so this method works best in North America.
UNDISCIPLINED LOCAL CLOCK:
server 127.127.1.1
fudge 127.127.1.1 stratum 10
This is a hack to allow a machine to use its own system clock as a reference
clock, i.e., to free-run using no outside clock discipline source. This is
useful if NTP is to be used in an isolated environment with no radio clock or
NIST modem or Internet connection available. 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.
Starting the NTP Daemon
Edit the file "/etc/rc.config.d/netdaemons" and set the variable called
NTPDATE_SERVER to be some working NTP server that is reachable. This will run
the "/usr/sbin/ntpdate" command just before the NTP daemon is started, and
bring your system clock very close to the other server to start. This
enormously improves stability at startup. Examples:
NTPDATE_SERVER=cupertino.cns.hp.com
NTPDATE_SERVER=15.13.108.1
NTPDATE_SERVER="cupertino.cns.hp.com paloalto.cns.hp.com"
Then set the XNTPD variable to one. This will cause the daemon to be started
automatically when your system makes the transition from run level 1 to 2.
Example:
XNTPD=1
Now start the daemon using the startup script:
sbin/rc2.d/S660xntpd start
You can stop the daemon at any time using the same script:
sbin/rc2.d/S660xntpd stop
but older versions of the script do not always find and kill the daemon
process correctly. You can always locate the process using "ps" and kill it
with "kill -9":
ps -ef | grep ntp
kill -9 xntpd_pid_here
Verifying Correct Operation
First verify that the daemon process is actually running:
ps -ef | grep ntp
If it is not running, examine /var/adm/syslog/syslog.log for NTP error messages.
We'll cover some common startup error messages a little later. If the daemon is
actually running, then we use the client query programs "/usr/sbin/ntpq" and
"/usr/sbin/xntpdc" to monitor its health. Run the command "/usr/sbin/ntpq -p"
and you will see output looking something like this:
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWV 0 l 124 64 377 0.00 -0.234 2.01
relay.hp.com listo 2 u 875 1024 377 13.84 4.912 4.88
cosl4.cup.hp.co listo. 2 u 876 1024 377 4.38 -4.468 3.95
paloalto.cns.hp listo 2 u 885 1024 377 5.84 0.762 2.18
chelmsford.cns. listo. 2 u 883 1024 377 89.45 2.160 11.40
atlanta.cns.hp. listo 2 u 881 1024 377 63.20 -2.545 0.99
colorado.cns.hp listo. 2 u 883 1024 377 38.71 -1.110 2.01
boise.cns.hp.co listo 2 u 875 1024 377 32.88 -2.015 2.23
Good health is a combination of high "reach", low "offset", and low "disp".
The display above is from a very healthy NTP stratum 1 server with excellent
network connections. The numbers will all be poor when the daemon is first
started up, and should all improve dramatically during the first 15 minutes
of operation. You will have problems if the "disp" number does not drop
below 100 and stay low.
If "reach" stays at 0 and/or "disp" stays at 16000 it means that the server
in question is not responding to queries from your machine. For example:
remote refid st t when poll reach delay offset disp
=========================================================================
*GPS_HP(1) .GPS. 0 l 48 64 377 0.00 0.516 4.91
hpisrhw 0.0.0 16 - - 1024 0 0.00 0.000 16000.0
hpuxps.cup.hp.c cu 3 u 467 1024 377 7.20 -12.430 15.67
This machine "hpisrhw" is not responding to NTP queries, but we can't tell
why from here. Perhaps the daemon process "xntpd" is not running on "hpisrhw"
or was recently started up and has not yet stabilized. Perhaps the network
link between the local machine and "hpisrhw" is down. Perhaps the LAN card
on the local machine is not working. But there are two other sources of time
that are working correctly, so the local machine is still in relatively good
shape.
Here is an example from a machine that is not healthy:
remote refid st t when poll reach delay offset disp
=========================================================================
big_srv 17.8.5.7 2 u 3 512 17 312.87 -249.15 1960.85
This machine only has one source of time, "big_srv", and it is having trouble
making queries. The "reach" is very low, indicating that packets are being
dropped on the network. The "disp" is far above the safe threshold of 100,
indicating that even the packets that do arrive are very unreliable. It is
important to realize that the problems are out on the network, not with NTP.
Network service quality is very important to NTP, and these indicators are
showing terrible network service quality. The daemon is trying as hard as it
can, but the "offset" is currently 249 milliseconds, and that is considered a
large number in the world of NTP. A system with a normal Ethernet connection
should be able to keep "offset" below 50 and "disp" below 100 all the time.
Broadcast Mode
Broadcast mode can be used when the accuracy requirements of the clients are
modest. Broadcast mode makes client configuration very easy because it
eliminates the configuration file on the client. Just start the client's
daemon up with "xntpd -b" and it will listen for servers broadcasting packets
on the local network. This can work fairly well if Cisco routers are used as
the broadcast servers (see the Cisco section below), but other servers are
possible too. It is still necessary to configure your servers somewhere, and
you will probably need more servers to cover your network topology well in
broadcast mode, but the decrease in administration effort for the clients
makes this worthwhile. Simply put the broadcast line in the configuration
file of the servers:
broadcast broadcast_addr
where "broadcast_addr" is the broadcast address of the local subnet.: For my
server at 15.13.108.1 the broadcast address is 15.13.108.255. A machine with
multiple LAN cards needs a separate line in "/etc/ntp.conf" for each card:
broadcast 15.13.108.255
broadcast 15.13.109.255
broadcast 15.13.110.255 # potentailly a long list
Error Messages
No Server suitable for synchronization found
This message indicates that the NTP server is not responding for some reason.
Packets were sent out, but no reply ever came back. Perhaps the server
machine is down, or the network link is broken or extremely congested.
Perhaps the NTP daemon died on the server and has not been restarted. Or
perhaps the NTP daemon on the server was recently restarted and has not yet
locked on to its time sources. Modern versions of NTP take between 5 and 15
minutes after startup of the daemon to synchronize, and they will not respond
to client requests during this time.
Last adjustment did not complete
This message is nothing to worry about. It means that NTP is trying to make
a slew adjustment bigger than your system's maximum slew rate allows in one
clock tick, so the remainder is pushed to the next clock tick. This is
handled automatically and the user or sysadmin hardly knows the difference.
You will often see this message in the first hour after the NTP daemon is
started. If you continue to see it after a few days of steady operation, then
you probably have a very drifty system clock or are losing contact with your
network timeservers.
Synchronization lost
This message indicates that NTP has cleared all of the statistics registers
and has begun the startup procedure of evaluating all available timeservers
and choosing the "best" one. This message appears whenever a step adjustment
(greater than 128 milliseconds) is made, since the step leaves the system
unsynchronized by definition. If your system is making a lot of step
adjustments, it probably means that you have network congestion problems.
Run "ntpq -p" and examine the dispersion statistics.
Planning Your NTP Hierarchy
Loading of the NTP servers is not usually a problem until configurations get
very large. The speed of CPUs and networks circa 1998 is much faster than
when NTP was first designed, and they continue to get faster every year. A
single NTP server on a modern CPU can easily support 1000 clients on an
Ethernet network (but you would want to have at least three servers for
redundancy). Large organizations will have even more. Besides redundancy,
the main idea is to keep the distance between server and client within
reasonable bounds. This distance has several possible contributors: physical
distance, network speeds, number of hops (routers). For example, if your
client is located in Britain it is not a good idea to choose a server that is
in Australia (due to physical distance). An X.25 network operating over a
modem is not going to perform well compared to Ethernet (due to network speed).
A server that is many subnets away (even though physically close by) will not
perform as well as one that is on the same subnet as the client (due to router
hops). All of these things can be evaluated using the command "ntptrace",
keeping in mind that measurements outside the 128 millisecond window indicate
trouble approaching.
A simple NTP setup would have three main servers, which are synchronized to
low stratum public timeservers or to radio clocks (or a combination). These
servers should also peer with each other, in case some of the outside sources
fail. A configuration file for one of these main servers would look like this:
/etc/ntp.conf for a server named "ntp_srv_A"
server 127.127.26.1 prefer # HP GPS clock
fudge 127.127.26.1 time1 -0.955 # HP GPS clock
server 127.127.1.1 # local clock in case of disaster
fudge 127.127.1.1 stratum 10 # show poor stratum
server 192.216.191.10 # smart1.svi.org Stanford University open access stratum-2
server 193.2.69.11 # biofiz.mf.uni-lj.s University of Ljubljana, Slovenia
server 149.156.4.11 # info.cyf-kr.edu.pl CYFRONET, Krakow, Poland
server 130.88.203.12 # ntp2d.mcc.ac.uk Univ of Manchester, England
peer ntp_srv_B
peer ntp_srv_C
driftfile /etc/ntp.drift
The "server" lines can use hostname or IP address, and hostname is usually
preferred. The machine in this example would operate as a stratum-1 server
when the GPS clock is working, or move down to stratum-3 if the GPS clock is
not present. It will always prefer the lowest stratum server available. If
there are several choices available at the lowest stratum it will select the
"best" one based on delay, offset, and dispersion. The sources that are not
selected are continuously monitored and held in reserve in case of other
failures. The daemon will automatically move to a better server if deemed
necessary.
This machine also peers with "ntp_srv_B" and "ntp_srv_C", which should have
similar configurations. The difference is that each peer should have a unique
list of outside servers, no duplications. The peers should all be under your
control. The peers will continue to work with each other even if all of the
outside servers fail. These three peer machines then act as the servers for
the next level in your NTP hierarchy. All the machines at the next level can
have the same configuration file:
/etc/ntp.conf for clients
server ntp_srv_A
server ntp_srv_B
server ntp_srv_C
server 127.127.1.1 # local clock in case of disaster
fudge 127.127.1.1 stratum 10 # show poor stratum
If you have a need for more strata or more than 500 clients, simply put more
machines in the top level group (ntp_srv_A in the example above), and then
configure as many group-of-three clients as you need (typically one group per
physical site or building). Then have those group-of-three machines act as
the servers for clients that are nearby. It is possible to have up to 15
strata, but even very large organizations can operate nicely with just 3 or 4
strata. Don't put in any more complexity than you really need for robustness.
Cisco Routers
Cisco routers (IOS 10 and later) have NTP built in, and can be used to
distribute time throughout your networks in polled or broadcast mode. The
concept is the same as configuring a Unix NTP server: get time from some
source(s) and distribute it to nearby clients. Because routers typically
serve multiple subnets, a single router can serve time to every client on
every subnet that it is connected to and simplify the administration of NTP.
Consult the operations manual of your router for specific configuration
instructions.
Redundancy
A robust NTP setup would have three main servers, located in different
buildings (or even different cities), each of which has three unique sources
of time with diverse paths. It is vital to carefully consider the issues of
robustness and reliability when selecting sources of synchronization. Don't
synchronize more than one server in a particular administrative domain to the
same server outside that domain. Such a practice invites common points of
failure.
Details of ntpq and xntpdc
remote refid st t when poll reach delay offset disp
=========================================================================
*GPS_HP(1) .GPS. 0 l 48 64 377 0.00 0.516 4.91
hpuxps.cup.hp.c cuperti 3 u 467 1024 377 7.20 -12.430 15.67
Now let's go over the meaning of each of the column headings in the ntpq
output and the measurements that go with them. Keep in mind that the most
important columns are the "reach", "offset", and "dispersion". In particular,
"dispersion" reveals the quality of the network service, which the time service
depends on VERY HEAVILY. Many NTP problems really turn out to be network
congestion problems.
remote SERVER NAME
This is the name of the NTP server. It is usually another UNIX machine
(could be HP, DEC, SUN, anything), but could also be an external reference
clock like GPS or WWVB radio clock or even a modem.
The character in the left margin indicates the fate of this peer in the
clock selection process. The codes mean:
"*" selected for synchronization
"#" selected for synchronization but distance exceeds maximum
"o" selected for synchronization, PPS signal in use
"+" included in the final selection set
"x" designated falseticker by the intersection algorithm
"." culled from the end of the candidate list
"-" discarded by the clustering algorithm
"blank" discarded due to high stratum and/or failed sanity checks
refid REFERENCE IDENTIFICATION
Usually the IP address of the server or the name of the external clock, but
can also be a router between the client and server. Not important for our
purposes.
st STRATUM
This is a measure of distance to the true source of time. The HPGPS clock is
stratum=0, the NTP daemon attached to the GPS clock is stratum=1, and others
(one more step away) are considered stratum=2 by all of their clients.
t TYPE
The possible types are:
l local (such as a GPS clock)
u unicast (this is the most common type)
m multicast
b broadcast
- netaddr (usually 0)
when
How long ago (in seconds) was the last response from this server?
Not very important.
poll POLL PERIOD
How often (in seconds) are we making a query to this server? 512 seconds
(approx 8 minutes) and 1024 seconds (approx 17 minutes) are very popular for
network connections, but a machine with an external clock (like GPS) should
poll the clock every 64 seconds or less.
The poll period can be specified with the "minpoll" and "maxpoll" directives,
but it is better to let the daemon adjust it as needed. After stabilizing
at startup this number will move automatically to 1024 for network servers
and 64 for external reference clocks.
reach REACHABILITY larger is better
How successful are we in reaching the server?
This is an 8 bit shift register with the most recent probe in the 2^0 position.
Thus 001 indicates the most recent probe was answered, 357 indicates one probe
was not answered, and 377 indicates all of the recent probes have been
answered.
delay ROUND TRIP TIME smaller is better
How long (in milliseconds) did it take for the reply packet to come back when
we sent a query to the server?
offset TIME DIFFERENCE smaller is better
How far apart (in milliseconds) are the server's clock and the client's clock?
This is the principal measure that the customer is interested in. When this
number exceeds 128 then NTP makes a big adjustment (and the message
"synchronization lost" appears in the logfile).
disp DISPERSION smaller is better
How much does the "offset" measurement vary between samples? How repeatable
is the "delay" measurement? This is an error bound estimate. It is based on:
precision delay/2 age of measurement / 86400
When dispersion exceeds 100 (milliseconds) it is very difficult for the
daemon to keep the clock synchronized. This "dispersion" number is a primary
measure of network service quality. A slow X25 network not only has a
sizeable round trip time, but the round trip time has large variation from
one query to the next. This is very bad for timekeeping purposes, because it
makes the "offset" very hard to calculate. The real job of NTP is to manage
the "offset" value and minimize it.
System Configuration Files
If you haven't done this already, I recommend setting these two variables in
/etc/rc.config.d/netdaemons:
export NTPDATE_SERVER=reliable_server # optional with GPS clock
export XNTPD=1
Set up your "/etc/ntp.conf" file with this line so that it recognizes the
HP GPS clock with driver number 26:
server 127.127.26.1 prefer minpoll 6 # HP GPS clock
Also in the "/etc/ntp.conf" file, a time constant needs to be set depending
on the type of computer and interface, and GPS receiver baud rate. Add one
of these lines (uncommented) for your CPU:
#fudge 127.127.26.1 time1 -0.955 # s700
#fudge 127.127.26.1 time1 -0.930 # s800
The "server" and "fudge" lines will probably be near the end of your
"/etc/ntp.conf" file, but you can add other "server" lines for other clocks
or other network time sources (for redundancy). Then use this command to
start and stop the daemon by hand (done automatically for you at reboot):
/sbin/rc2.d/S660xntpd start | stop
Timezones
Timezones are not actually relevant to NTP, but they always get mentioned.
NTP operates in UTC (Coordinated Universal Time, the modern successor to
Greenwich Mean Time) and knows nothing of timezones or Daylight Savings Time
or Summer Time or any of that nonsense. It is the responsibility of the
local operating system (and possibly the shell) to sort these things out, and
HP-UX provides for this with the kernel parameter known as "timezone" , the
system file "/etc/TIMEZONE", and the shell variable "TZ". The kernel
parameter is easy to set using SAM (System Administration Manager). The
"/etc/TIMEZONE" file can be set by running:
/sbin/set_parms timezone
The users can set their own shell variables. The complete list of timezones
can be found in "/usr/lib/tztab", along with the dates of the summertime
switch for some years. Remember that the actual summertime switch is set by
the local government, and so it changes from year to year, not always in a
logical pattern. It is always subject to change for future years.
===========================================================
Below is some ntpq data from my own NTP test machine, beginning at daemon
startup and continuing for about 24 hours. The first several examples are at
approx 5 minute intervals. You could gather some excellent data like this
from your own machine with a cronjob that runs every 5 or 10 minutes that
executes this command:
/usr/sbin/ntpq -p >> /tmp/ntpq_data
You can see that the dispersion starts out artificially high and then quickly
drops as real data is accumulated. On the third measurement the daemon has
declared the radio clock to be stable and repeatable enough to be the selected
server, and the * appears next to the WWVB_SPEC name. This is also when the
syslog message "synchronized to WWVB_SPEC" appears.
Notice that the "poll" figures adjust automatically, rising from 64 to 1024
seconds for the network time servers. The radio clock "poll" stays at 64
seconds because the cost of polling the dedicated hardware is very low.
ntpq> peers
remote refid st t when poll reach delay offset disp
=========================================================================
WWVB_SPEC(1) .WWVB. 0 l 100 64 3 0.00 7.828 7886.32
relay.hp.com listo 2 u 3 64 7 9.77 7.507 3890.03
cosl4.cup.hp.co listo. 2 u 3 64 7 3.48 16.229 3884.57
paloalto.cns.hp listo 2 u 3 64 7 5.08 21.023 3883.29
chelmsford.cns. listo 2 u 3 64 7 87.81 20.565 3882.32
atlanta.cns.hp. listo 2 u 3 64 7 63.78 19.660 3896.33
colorado.cns.hp listo 2 u 3 64 7 41.53 19.945 3882.54
boise.cns.hp.co listo. 2 u 3 64 7 34.52 12.610 3885.73
remot refi st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB. 0 l 65 64 377 0.00 4.115 20.22
relay.hp.com listo 2 u 32 64 377 12.53 10.927 8.62
cosl4.cup.hp.co listo 2 u 32 64 377 3.43 3.377 7.13
paloalto.cns.h listo 2 u 32 64 377 5.34 7.733 7.68
chelmsford.cns. listo 2 u 32 64 377 85.97 7.086 13.73
atlanta.cns.hp. listo 2 u 32 64 377 63.83 6.719 7.87
colorado.cns.hp listo 2 u 32 64 377 41.18 6.390 9.02
boise.cns.hp.co listo 2 u 32 64 377 34.53 2.931 15.61
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB. 0 l 114 64 377 0.00 37.623 12.77
relay.hp.com listo 2 u 225 512 377 6.93 34.052 10.79
cosl4.cup.hp.co listo 2 u 226 512 377 4.18 29.385 13.21
paloalto.cns.hp listo 2 u 235 512 377 9.80 33.487 11.61
chelmsford.cns. listo 2 u 233 512 377 88.79 30.462 9.66
atlanta.cns.hp. listo 2 u 231 512 377 67.44 32.909 12.86
colorado.cns.hp listo 2 u 233 512 377 43.70 30.077 18.63
boise.cns.hp.co listo 2 u 224 512 377 33.42 31.682 8.54
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB. 0 l 96 64 377 0.00 41.279 4.29
relay.hp.com listo 2 u 207 1024 377 38.88 56.319 27.47
cosl4.cup.hp.co listo 2 u 208 1024 377 6.36 35.910 13.03
paloalto.cns.hp listo 2 u 217 1024 377 5.80 40.161 12.37
chelmsford.cns. listo 2 u 215 1024 377 90.36 38.449 12.68
atlanta.cns.hp. listo 2 u 213 1024 377 64.09 37.787 11.25
colorado.cns.h listo 2 u 215 1024 377 44.07 38.568 17.72
boise.cns.hp.co listo 2 u 206 1024 377 67.37 54.712 26.61
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB. 0 l 87 64 377 0.00 39.299 3.69
relay.hp.com listo 2 u 6 1024 377 65.48 67.331 24.52
cosl4.cup.hp.co listo 2 u 7 1024 377 4.32 35.311 6.41
paloalto.cns.hp listo 2 u 16 1024 377 80.37 1.781 32.01
chelmsford.cns. listo 2 u 14 1024 377 88.87 34.785 6.35
atlanta.cns.hp. listo 2 u 12 1024 377 63.16 36.973 5.52
colorado.cns.hp listo 2 u 14 1024 377 42.08 37.187 8.74
boise.cns.hp.co listo 2 u 5 1024 377 36.00 38.077 13.23
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB. 0 l 118 64 377 0.00 29.347 3.07
relay.hp.com listo 2 u 869 1024 377 65.48 67.331 24.52
cosl4.cup.hp.co listo 2 u 870 1024 377 4.32 35.311 6.41
paloalto.cns.hp listo 2 u 879 1024 377 80.37 1.781 32.01
chelmsford.cns. listo 2 u 877 1024 377 88.87 34.785 6.35
atlanta.cns.hp. listo 2 u 875 1024 377 63.16 36.973 5.52
colorado.cns.hp listo 2 u 877 1024 377 42.08 37.187 8.74
boise.cns.hp.co listo 2 u 868 1024 377 36.00 38.077 13.23
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB. 0 l 122 64 377 0.00 23.105 2.35
relay.hp.com listo 2 u 425 1024 377 7.80 25.924 29.69
cosl4.cup.hp.co listo 2 u 426 1024 377 4.96 23.267 10.71
paloalto.cns.hp listo 2 u 435 1024 377 8.15 25.546 16.92
chelmsford.cns. listo 2 u 433 1024 377 93.98 25.996 8.64
atlanta.cns.hp. listo 2 u 431 1024 377 64.48 24.259 11.31
colorado.cns.hp listo 2 u 433 1024 377 42.33 24.952 11.75
boise.cns.hp.co listo 2 u 424 1024 377 51.56 28.568 12.30
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB. 0 l 109 64 377 0.00 17.206 3.51
relay.hp.com listo 2 u 988 1024 377 7.80 25.924 29.69
cosl4.cup.hp.co listo 2 u 989 1024 377 4.96 23.267 10.71
paloalto.cns.hp listo 2 u 998 1024 377 8.15 25.546 16.92
chelmsford.cns. listo 2 u 996 1024 377 93.98 25.996 8.64
atlanta.cns.hp. listo 2 u 994 1024 377 64.48 24.259 11.31
colorado.cns.hp listo 2 u 996 1024 377 42.33 24.952 11.75
boise.cns.hp.co listo 2 u 987 1024 377 51.56 28.568 12.30
THE NEXT DAY
remote refid st t when poll reach delay offset disp
=========================================================================
*WWVB_SPEC(1) .WWVB 0 l 77 64 377 0.00 -0.428 1.94
relay.hp.com listo 2 u 764 1024 377 17.11 -6.332 5.20
cosl4.cup.hp.co listo 2 u 765 1024 377 5.08 -4.378 0.49
paloalto.cns.hp listo 2 u 774 1024 377 7.80 -2.625 2.29
chelmsford.cns. listo 2 u 777 1024 377 91.67 -2.011 5.66
atlanta.cns.hp. listo 2 u 775 1024 377 64.39 -2.457 87.01
colorado.cns.hp listo 2 u 783 1024 377 43.12 -0.855 3.22
boise.cns.hp.co listo 2 u 774 1024 377 42.60 1.471 5.58
Details on HP58503A GPS Clock
Be sure there is a device file entry for the HP GPS receiver at the physical
port connected to it. The device file name should be /dev/hpgps1, with all of
the same attributes as the /dev/tty* location. You can create a new device
using "mknod", or you can just link to an existing device using "ln".
On a s700 it typically looks like this:
crw-rw-rw- 1 bin bin 1 0x010000 Sep 26 10:51 /dev/hpgps1
crw--w--w- 2 bin bin 1 0x010000 Aug 16 15:25 /dev/tty1p0
On a s800 it typically looks like this:
crw-rw-rw- 1 bin bin 193 0x000100 Jul 22 14:59 /dev/hpgps1
crw--w--w- 1 bin bin 193 0x000100 Jul 22 14:59 /dev/tty0p1
Plug the serial cable from the GPS clock into the serial port of a s700 or
s800. You can interrogate the GPS and verify proper cable connection using
"cu -l/dev/hpgps1 dir" if you have made an entry in /usr/lib/uucp/Devices.
If you get no response whatsoever from "cu" then you probably have the wrong
cable. Note: you cannot use the "cu" trick while the NTP daemon is running
and talking to the GPS clock.
Press return a few times and you should get a prompt of the form "scpi>"
or "E-xxx>".
Type the following scpi command in response to this prompt ...
:SYSTEM:STATUS?
The result of this should be a screen full of GPS status looking like this:
----------------------------- Receiver Status ------------------------------
SYNCHRONIZATION .......................................... [ Outputs Valid ]
SmartClock Mode ________________________ Reference Outputs ________
>> Locked to GPS TFOM 3 FFOM 0
Recovery 1PPS TI +33.4 ns relative to GPS
Holdover HOLD THR 1.000 us
Power-up Holdover Uncertainty _Predict 5.9 us/initial 24 hrs
ACQUISITION .............................................[ GPS 1PPS Valid]
Satellite Status _______________________ Time____________________________
Tracking: 6 Not Tracking: 1 UTC 16:26:27 29 Jul 1996
PRN El Az SS PRN El Az GPS 1PPS Synchronized to UTC
4 50 293 208 24 15 306 ANT DLY 0 ns
7 28 227 97 Position________________________
14 46 84 186 MODE Hold
18 5 194 214 25 18 39 128 LAT N 37:20:08.782
29 65 100 232 LON W 122:00:33.631
ELEV MASK 10 deg HGT + 44.30 m (MSL)
HEALTH MONITOR ...................................................... [ OK ]
Self Test: OK | Int Pwr: OK Oven Pwr: OK OCXO: OK EFC: OK GPS Rcv: OK
Detailed explanation of this output is beyond the scope of this text, but the
student can certainly decode latitude, longitude, elevation, and current time.
Remember that if you get even one character of output, then the GPS clock and
the serial cable are probably OK.
APPENDIX 1: Radio Clocks
ACTS - use NIST dialup clock as reference
AS2201 - Austron 2200A or 2201A GPS receiver
DATUM - use Datum Programmable Time System
HEATH - HeathKit GC-1000 Most Accurate Clock (Not on HP-UX)
HPGPS - HP 58503A GPS Time & Frequency receiver
LEITCH - Leitch CSD 5300 Master Clock System Driver
LOCAL_CLOCK - use local clock as reference
MOTO - Motorola GPS clock
PARSE - GENERIC refence clock driver
DCF77:
Meinberg DCF U/A 31, PZF 535
Schmid DCF77 receiver
ELV DCF7000
Raw DCF77 signal (100/200ms pulses)
HOPF 6021
GPS:
Meinberg GPS 166
Trimble GPS (TAIP Protocol)
Trimble GPS (TSIP Protocol)
[no kernel support yet]
MSF:
Radio Clock RCC8000 MSF Receiver
PST - PST/Traconex 1020 WWV/H receiver
PTBACTS - use PTB dialup clock as reference
TRAK - TRAK 8810 GPS station clock
TRUETIME - Kinemetrics/TrueTime (generic) receiver
WWVB - Spectracom 8170 or Netclock/2 WWVB receiver
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)
t = driver number (#26 for HP GPS)
u = clock number (almost always 1 unless using driver #8)
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 Trak 8820 GPS Receiver /dev/traku
127.127.3.x PSTI/Traconex 1020 WWV/WWVH Receiver /dev/wwvu
127.127.4.x SPECTRACOM WWVB rcvr 8170 and Netclock/2 /dev/wwvu
127.127.5.x Kinimetric Truetime 468-DC GOES receiver /dev/trueu
127.127.6.x IRIG audio decode (not on HP-UX)
127.127.7.x CHU Timecode (not on HP-UX) /dev/chuu
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 /dev/refclock-0
8.4-7 Meinberg PZF535/OCXO /dev/refclock-4
8.8-11 Meinberg DCF U/A 31 /dev/refclock-8
8.12-15 ELV DCF7000 /dev/refclock-12
8.16-19 Walter Schmid DCF receiver (Kit) /dev/refclock-16
8.20-23 Conrad DCF77 receiver module + level converter (Kit)
8.24-27 TimeBrick /dev/refclock-24
8.28-31 Meinberg GPS166 /dev/refclock-28
8.32-35 Trimble SV6 GPS receiver /dev/refclock-32
127.127.9.x MX4200 GPS receiver (not on HP-UX)
127.127.10.x Austron 2201A GPS Timing Receiver /dev/gpsu
127.127.11.x Kinemetrics Truetime OM-DC OMEGA Receiver ???
127.127.12.x KSI/Odetecs TPRO-S IRIG-B / TPRO-SAT GPS /dev/tprou
127.127.13.x Leitch CSD 5300Master Clock System Driver ???
127.127.14.x MSFEES (not on HP-UX) ???
127.127.15.x TrueTime GPS/TM-TMD (aliased to #5)
127.127.16.x Bancomm GPS/IRIG Ticktock ???
127.127.17.x Datum Programmable Time System ???
127.127.18.x NIST Modem Time Service (not on HP-UX 9.x) /dev/actsu
127.127.19.x Heath WWV Receiver (not on HP-UX) /dev/heathu
127.127.20.x NMEA (GPS) Receiver /dev/gpsu
127.127.21.x VME GPS Receiver (not on HP-UX) /dev/ppsu
127.127.22.x PPS Clock Discipline (not on HP-UX) /dev/ppsu
127.127.23.x PTB Modem Time Service (not on HP-UX 9.x) /dev/ptbu
127.127.24.x USNO Modem Time Service (not on HP-UX 9.x) /dev/cuau
127.127.25.x aliased to #5 TrueTime
127.127.26.x Hewlett Packard 58503A GPS Receiver /dev/hpgps1
For a good time, call NIST: (303) 494-4774
=============================================================================
From: bwb@etl.noaa.gov (Bruce Bartram 303-497-6217) [-/+]
Date: Tue, 10 Mar 1998 17:31:33 -0700 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: xntpd...
Howdy,
I stopped posting to the newsgroup a while back because I was getting
a heap of spam. When I finally get to bringing up a different newsreader
and get my munging in shape, I'll return. I've been responding by email
to quite a few posters, especially Solaris 2.5 and newbies.
Here is a copy of the email I recently sent to Gregory Bond. I doubt
its "greatness", it was just a summary of how to cajole a host with
a bad drift to get past the initial startup and some Solaris 2.5
notes about how to trim a sparc Solaris 2.5 box.
Bruce
-----
From: Unknown Author <none> (auto-inserted) [-/+]
To: gnb@itga.com.au (Gregory Bond)
Subject: Re: Nasty fast clock (Sol 2.5) - can it be tamed??? [-/+]
Newsgroups: comp.protocols.time.ntp
X-Keywords: dosynctodr [-/+] jitter [-/+] logconfig [-/+] NMEA [-/+] nsec_per_tick [-/+] PLL [-/+] PPS [-/+] syslog [-/+]
Howdy,
For a sparc CPU (not ultra or x86) with Solaris 2.5 and the
newer (3-5.90 or later) tickadj, you can change the basic clock
rate by:
tickadj -sA -t <nsec_per_tick>
I'd start by looking in /etc/system to see if there is anything wierd
grep per_tick /etc/system
A reboot is needed for any changes to take effect. I always save
an unchanged version and read the man pages about how to reboot without
reading /etc/system before hacking away.
I'd measure the basic clock rate by
tickadj -s # make sure dosynctodr is off
kill <xntpd PID> # make things simple
ntpdate -d server >file
sleep 1000
ntpdate -d server >>file
Since ntpdate should be able to measure to a few ms, a 1000 second
interval should get the rate to a few ppm, which is a good first guess.
With a freq error as large as you report, I'd calculate
new nsec_per_tick = ( 1 + delta_offset / delta_time ) * 10^7
and then "tickadj -sA -t <new nsec_per_tick>". Then "rm ntp.drift" and
restart the daemon to see if things are better.
If it starts to work better, watch it for a few days, pick the most
common ntp.drift value (I have "logconfig +allstatistics" in my ntp.conf
and watch syslog daemon.info to pick a value). I'd then put calculate
best guess nsec_per_tick = current nsec_per_tick ( 1 + ntp.drift/2^20 )
The ntp.drift value is positive if the host is fast, negative if the
basic rate is slow and the ntp.drift is in parts/2^20.
For an ultra, I've attached a long old thread on trimming ultras in 2.5x,
but I don't have any experience here.
About Solaris 2.6, the newsgroup wisdom seems to be:
the provided version is 3.4y, old but useable
don't let ./configure enable PLL or HAVE_NTP_ADJTIME, HAVE_NTP_GETIME
(a reboot is reported necessary to undo troubles)
there might be a lot of jitter on the refclock lines (10ms)
Most cheap handheld GPS units don't output the NMEA on the second and don't
work for NTP. Some modules are reported to work. rooth@dimensional.com
has posted an ongoing thread about making PPS cook on Solaris 2.6, but
he isn't there yet.
Happy chiming
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
-----
In article <wwg1kxyfnm.fsf@itga.com.au> you wrote:
: We have one of our Solaris 2.5.1 machines (a Ross SparcPlug cpu
: module) that has a shocking clock that runs about 1% (yes, that's
: 10,000ppm) fast. It's sync'd to a stratum-3 server that has good-
: enough-for-our-purposes time (under 1/2 sec is what I'm aiming for -
: I'm not too ambitious!)
: An extract from the syslog shows it's gaining time at a shocking rate
: and getting lotsa of step time adjustments. This is Ugly on a
: production system that is supposed to be providing timestamps to
: important transactions....
: I've turned off dosyntodr with no noticable improvement. Anything
: else I can try (short of moving to a new machine)?
: And on a related note, has anyone any comments about the xntpd shipped
: with 2.6? Can I just get a NMEA-compatible GPS and plug it in and
: run? What about the PPS stuff?
[ horizontal snip vvv "gallows xntpd" to fit on an 80 char line ]
: Mar 5 12:39:15 [251]: offset -8.384604 freq -683.17308 comp 0
: Mar 5 13:24:37 [251]: ** adjust: STEP 192.43.186.5 offset -23.523669243 **
: Mar 5 13:39:15 [251]: offset -4.449414 freq -683.17308 comp 0
: Mar 5 13:42:45 [251]: ** adjust: STEP 192.43.186.5 offset -8.946010590 **
: Mar 5 13:59:49 [251]: ** adjust: STEP 192.43.186.5 offset -6.605636597 **
: Mar 5 14:16:53 [251]: ** adjust: STEP 192.43.186.5 offset -6.285675526 **
: --
: Gregory Bond ITG Australia Ltd, Melbourne, Australia
: <mailto:gnb@itga.com.au> <http://www.bby.com.au/~gnb>
: From: bruce@itga.com.au (Do not use this address. It catches junk email.)
: From: bruce@bby.com.au, bruce@melba.bby.com.au (So do these ones)
-----old long thread about trimming ultra in 2.5x
[SNIP]
From: Gregory Bond <gnb@itga.com.au> [-/+]
To: bwb@etl.nospam.gov (Bruce Bartram 303-497-6217)
Subject: Re: Nasty fast clock (Sol 2.5) - can it be tamed??? [-/+]
X-Keywords: adjustment [-/+]
Thanks a lot, that is most comprehensive. I've tried a few of the 1000-sec
timing runs and are getting variable results with deltas around +6.5sec/
1000sec. I'll have a go at the tickadj adjustment and see if I can't fix it
enough for ntp to go into slew mode. We are also investigating changing the
CPU module with another more-or-less identical machine that is doing a less
clock-critical job and seems to have a better rtc.
Thanks again.
Greg.