Date: Sun, 1 May 94 10:05:05 EDT [-/+]
From: Rick Thomas <rbthomas@jove.rutgers.edu> [-/+]
Message-Id: <9405011405.AA04620@frogpond.rutgers.edu>
Subject: Preliminary FAQ -- send updates to rbthomas@rutgers.edu [-/+]
Expires: Wed, 1 Jun 1994 00:00:01 EDT
Apparently-To: ntp@ni.umd.edu
X-Keywords: FAQ [-/+]
Everybody talks about how we need a FAQ, but nobody does anything about it.
So I decided to do something about it. Here is the text of several recent
messages that answered questions that everyone agrees should be on a FAQ.
Send updates to me --
Please write it up in a form I can include in the FAQ, and I'll include it.
Note, This is a "non-fat" FAQ. I include stuff from other people that
I think is applicable. I include it as it comes to me, warts and all.
I don't usually write things myself because I don't have the time. I
don't usually edit things unless I write them myself.
Because of the un-edited format, you should read the *whole thing*
before you act on anything you read here. Frequently, later items
contain corrections to earlier items. I have tried to group related
items together, but sometimes that is not possible.
This was last updated $Date: 1995/08/09 18:18:15 $
I post the accumulation once a month.
It's rough but ready.
========================================================================
Rick Thomas, Manager Supercomputer Remote Access Center
Rutgers University, College of Engineering
Internet: rbthomas@jove.rutgers.edu
UUCP: {any backbone site}!rutgers!rbthomas
========================================================================
Standard disclaimers apply. All messages quoted here are the opinions
of their respective authors, and do not necessarily represent the opinions
(if any) of their respective employers, or of the compiler of this FAQ.
If you act on the advice contained herein you do so at your own risk.
Nobody involved makes any warranty.
=============================================================================
From: iglesias@draco.acs.uci.edu (Mike Iglesias) [-/+]
Subject: Re: xntpd: previous time adjustment didn't complete [-/+]
X-Keywords: adjustment [-/+] FAQ [-/+]
rtc@icf.hrb.com (Rob Callahan) writes:
>I am also getting lots (I mean lots) of these messages on all Suns running
>xntpd as a client. An example of the /usr/adm/messages file follows:
>
>Feb 24 10:03:21 lilith last message repeated 48 times
>Feb 24 10:03:30 lilith xntpd[535]: Previous time adjustment didn't complete
Make sure you run tickadj on your Suns before you run xntpd. Here's
how we run tickadj:
tickadj -A -s -q -t 9999
You can leave off the -t 9999 if you want. We find that our Suns drift
less with that setting.
Also, if you don't use a window system on the console, the slow console
proms will make the system loose interrupts and the time will drift.
We *really* need a FAQ for this list. This question gets asked several times
a month. :-(
=============================================================================
From: glenn@athena.cs.uga.edu (Glenn F. Leavell)
Subject: Re: xntpd: previous time adjustment didn't complete [-/+]
X-Keywords: adjustment [-/+] broadcast [-/+] dosynctodr [-/+]
I recently worte:
>We're using xntp3 to broadcast the time on our campus network. Client
>machines accross the network "listen" for the time by running xntpd as:
>
> xntpd -b -f /etc/ntp.drift
>
>Recently, some of our Sun4 users (SunOS 4.1.1) have reported seeing the
>error:
>
> xntpd: previous time adjustment didn't complete
>
>in their syslogs. What would normally cause such a message? Is it serious?
Thanks very much to everyone who responded to my question (both via e-mail
and directly to the net.) The consensus seems to be that the Sun clock
is a very bad one. I was already using 'tickadj -A' to set the value
of tickadj to an optimal value in the running kernel. However, a couple
of other paramaters are also useful (and most likely necessary):
tickadj -A -s -t 9999
The -s option sets the value of dosynctodr to zero in the running kernel.
This has the effect of telling the OS to stop trying correct the clock's
drift (the work is left for xntp!). The -t 9999 option sets the value
of tick in the running kernel to 9999. According to several of the responses
I received, this is a good value for most Suns. However, I have not seen
a complete list.
Thanks again for the help.
=============================================================================
From: iglesias@draco.acs.uci.edu (Mike Iglesias) [-/+]
Subject: Re: ntpdate: errors when trying to synch to other xntp hosts
Keywords: ntpdate xntp3
art@cs.UAlberta.CA (Art Mulder) writes:
> For the most part, everything runs fine, but on some of our
> workstations we get: ``no server suitable for syncronization found''
> when ntpdate runs.
Make sure those systems can convert hostnames to IP addresses at that point
(i.e. make sure everything necessary to use nameservers is up and running
if you are using them), and that any routing that needs to be setup is in
place before you run ntpdate.
> The only solution I have found is to to pick some different hosts for
> ntpdate.
Maybe those hosts can get to the servers that work but not the other ones,
as I mentioned above.
>ps: It would be really nice if some central version numbering scheme
> were set up for xntp3. It would sure make it easier to track.
YES! PLEASE!
=============================================================================
From: Mills@UDEL.EDU [-/+]
Subject: Re: NTP peers
X-Keywords: configuration [-/+] peer [-/+]
chongo,
I do not have the resources to provide individual configuration advice
for a specific installation - there are many thousands of them now. The
ntpd (version 1) distribution has been obsoleted twice over and been
replaced by NTP Version 3. A comprehensive Unix daemon is available
in the compressed tar archive pub/ntp/xntp3.tar.Z on louie.udel.edu.
It includes scads of information on installation, configuration and
peer selection. Other files in the pub/ntp/doc directory on that host
contain probably more than you will ever care to know about timekeeping
in general and, in particular, the file clock.txt, which contains a
list of public stratum-1 and stratum-2 time servers. Happy chime.
Dave
=============================================================================
From: jones@hermes.chpc.utexas.edu (William L. Jones)
Subject: Just a few small suggestions!
Thanks!
We really need a faq for comp.protocols.time.ntp.
When you talk about using tickad on a sun you need to mention that
if you are running Sun OS 4.1.3 you don't need the "-t 9999" on tickadj.
Bill Jones
=============================================================================
From: geertj@ica.philips.nl (Geert Jan de Groot) [-/+]
Subject: Re: Reachability keeps resetting zero after a STEP
X-Keywords: documentation [-/+] dosynctodr [-/+] Mills [-/+] peer [-/+] reset [-/+]
joey@tessi.com (Joey Pruett) writes:
>I just recently started trying to use ntp on my sun systems. I've
>compiled the xntp3 stuff from louie.udel.edu and things kinda run. The
>behavior I am seeing is that everytime a STEP is performed, all the
>servers I talk to have their reachability reset to 0 and everything
>starts over again. This even happens to the LOCAL_CLOCK I configured
>into the server. Any help would be greatly appreciated. I don't
>understand much about ntp yet, so I am probably not understanding
>something...
I have the same problem, but after a note from Dave it now seems to be
solved. Dave, please correct me if I am wrong, and maybe it is a good idea
to include it in the notes files..
The first problem is that SUNs have too much tolerance on their clocks.
Because NTP requires removal of synchonisation to the built-in
NVram clock (that is where tickadj -s option is for, to reset dosynctodr).
Now your SUN really starts drifting, and ntp tries to get up with
that, but because the clock error is high (several hundreds of ppm),
NTP does not succeed at first, and it takes a few days to adjust.
In that time, the SUN will frequently loose synchonisation , which
you can determine by looking at the status words in your log file,
combined with appendix A of RFC1305.
Hence, it is a bad idea to have the SUN synchonize anything else.
Wait for things to stabilize first!
The approach I used is to start xntpd on a new machine (as slave - I didn't
want to confuse the server I used), wait for two or three days, and then
check /etc/ntp.drift. Because xntpd raises or lowers the drift value only a
few ticks per hour, at first xntp is not able to correct the frequency
error. After a while, the time error between your clock and the reference
gets higher and higher and xntpd starts to complain:
>08:21:56 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.177012563)
>08:23:00 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.248992682)
>08:24:06 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.248992682)
>08:25:08 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085)
>08:26:12 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085)
>08:27:16 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.404627085)
>08:28:20 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.577525616)
>08:29:24 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:30:28 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.759768605)
>08:31:34 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:32:36 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:33:40 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:34:44 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
>08:35:48 xntpd: adjust: STEP dropped (16.1.0.22 offset 0.757438898)
Then, after a while, some hold-off timer times out and the time is
SET, no longer ADJUSTED. This is what you see:
>08:36:52 xntpd: adjust: STEP 16.1.0.22 offset 0.821858644
As a result, xntpd declares itself invalid and starts to synchonize:
>08:36:53 xntpd: system event 5 status c043
>08:36:54 xntpd: peer 130.43.2.2 event 84 status 9024
>08:36:54 xntpd: system event 4 status c655
>08:36:54 xntpd: peer 129.189.134.11 event 84 status 9024
>08:36:55 xntpd: peer 127.127.1.5 event 84 status 8024
>08:37:56 xntpd: peer 16.1.0.22 event 84 status 9024
After a while, xntpd synchonizes again and declares healthy again:
>08:42:13 xntpd: system event 3 status 664
and the thing starts over again. In time, these events happen less and
less often, until the drift value is close enough that xntpd is able
to steer the local time within its limits.
The basic idea is to sit on your hands for a few days, don't use the
server (yet) to synchonize others, and see what ntp.drift does.
I find your steps quite huge. Did you run tickadj -As before you started
xntpd?
After that, your offset is probably still too large. Start ntpq, do 'rv'
and look for the frequency offset. Divide by 1000 to get the real
frequency error in ppm, which should be less than +-100 ppm.
Now, you should vary the 'tick' value of tickadj to make the frequency
error (the value in /etc/ntp.drift), or (rv / 1000), less than +-100.
You will find that xntpd synchonizes much more quickly - in my case,
it needed only one time STEP. Suitable values for tick are 9999 +-2
or so. I found that sun4/60's are nearly similar to each other,
sun4/280's too, but there is a severe difference between these families.
It seems that there is a difference in mechanism between sunos 4.1.2
and sunos 4.1.3, but I have not found the details in my news archive.
This is as far as I am now - I'm adjusting tick for various machines.
xntpd no longer complains about time STEPs.
I stress that this knowledge is not my wisdom - Dave Mills helped a lot,
and I am just describing the experience I got by following Dave's hints.
In return, I hope that this message helps others too. Would an xntp
guru care to correct my story? Then, it might be Americanized (I'm
no native English speaker, but you already figured that out :-),
and maybe this information can be added to the xntpd documentation.
I am glad I am not the only one that had the problems you have.
Dave, thanks!
Warning: clock hacking is very addictive. On the other hand, I find it
much fun, so you might want to become addicted too!
Hope this helps,
Geert Jan
=============================================================================
From: corrigan@weber.ucsd.edu (Michael J. Corrigan)
Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu [-/+]
X-Keywords: peer [-/+]
A question I have answered by email a couple of times is:
"My newly installed version 3 xntp can't talk to any of the systems
it used to talk to. What's wrong ?"
You need a line like:
peer host.dom.top version 2
if the host is still running version 2.
=============================================================================
From: folta@cs.umd.edu (Wayne Folta)
Subject: Re: Preliminary FAQ -- send updates to rbthomas@rutgers.edu [-/+]
X-Keywords: bug [-/+]
>Make sure you run tickadj on your Suns before you run xntpd. Here's
>how we run tickadj:
>
> tickadj -A -s -q -t 9999
>
>You can leave off the -t 9999 if you want. We find that our Suns drift
>less with that setting.
I read in c.p.t.ntp that Sun OS 4.1 -- Sun OS 4.1.2 have an off-by-one
bug that requires -t 9999 to fix. Sun OS 4.1.3 and beyond do not have
this problem, is is said.
--
Wayne Folta (folta@cs.umd.edu 128.8.128.8)
=============================================================================
From: rbthomas@frogpond.rutgers.edu (Rick Thomas) [-/+]
Subject: Re: Using xntp without radio clock or internet connection? [-/+]
Keywords: clock ntp internet
X-Keywords: configuration [-/+] dispersion [-/+] fudge [-/+] peer [-/+] prefer
Eric.Boehm@union.edu writes...
> We would like to set up time synchronization for a network of ~500
> hp9000-700 workstations. Unfortunately we don't have a connection to
> the internet (yet) nor do we have a radio clock. Is there any way to
> fool xntpd into thinking it is a stratum 1 server?
>
> Other solutions or suggestions would be appreciated (I am also looking
> at timed).
Well, here's one way...
In xntp (both v2 and v3) there is a pseudo-radio-clock driver that uses
the CPU's own local clock as its time source. Read the docs for how to
compile with this feature turned on. (In v2 you set "-DREFCLOCK
-DLOCALCLOCK" in the Config file. I'm not sure what you do for v3, but
it's probably pretty much the same.) That pseudo-clock can be
configured so that it appears to be at any given stratum from 1 to 15.
Pick one "master" system, and one "backup" system. Configure the
"master" so that its local clock is at stratum 10 and the backup system
so that its local clock is at stratum 12. The master and backup have
their ntp.conf files set up to talk to each other as "peer"s, and all
the rest of the systems' ntp.conf files use both the master and backup
as "server"s. With that configuration, the master will free-run and
all other clocks on the local net (including the backup) will track the
master at stratum 11; unless the master goes down, in which case they
will track the backup at stratum 13 and the backup itself will
free-run. You use different stratum numbers for the master and backup
so the clients don't have two equally attractive choices, each with a
different idea of what time it is.
Thanks to Cary Gray for pointing out that the master and backup need to
be separated by 2 strata, not 1. The reason is (in Cary's words):
> If you configure the local clock for host A a stratum 6 and for B at
> stratum 7, and A and B peer, then B's peers are:
> A at stratum 7 [sync'd to A's clock at stratum 6]
> B's clock at stratum 7
> For any of the NTP implementations, B is almost certain to prefer the
> second peer, which will have lower dispersion and synchronizing distance
> (unless you've done some very careful work with the fudge factors).
>
> I learned this the hard way using ntpd back at Stanford.
>
> Cary
When you finally get a radio clock, it will be at stratum 1 and will
automatically take over as the most attractive source. If you connect
it to your "master", you don't need to change anything (except to turn
on the appropriate driver). You can even leave LOCALCLOCK configured
on the master at stratum 10 as a backup to the radio clock incase it
goes down. If you put the radio clock on another system, you need to
make the obvious changes to the ntp.conf files to have all systems
(including the master and backup) use that machine as (yet another)
server.
If you get an internet connection instead of a radio clock, then have
your master and backup talk (as clients) to a couple of stratum 1 or 2
hosts on the internet (for redundancy, use a different couple of
servers for the backup from the couple you chose to serve the master.)
Leave LOCALCLOCK configured at stratum 10 and 12 as backups incase the
internet connection dies. Leave everybody else unchanged, as clients
of the master and backup machines. That keeps the traffic to the
internet stratum 1 or 2 server down to a minimum.
Best of all is to combine the two approaches; have *both* an internet
connection *and* a radio clock.
That should do it.
Enjoy!
Rick
=============================================================================
From: ariel@world.std.com (Robert L Ullmann)
Subject: Re: Using xntp without radio clock or internet connection? [-/+]
X-Keywords: filter implementation [-/+] peer [-/+] specification [-/+]
I cringe every time I see someone talking about configuring a local-clock
(self-referential clock) at strata like 3 or 4. If you are going to
do it, use 10 and 11 (or similar); it will work perfectly well,
but you don't run the risk of confusing systems that can see your
clocks as well as _real_ strata 3 or 4 sync'd to active radio
clocks.
I'd like to see the code fixed to prevent configuring local-clock
at less than 10. Or better, increasing infinity to 31, and specifying
min local-clock as 16; so a strata of 15 or less implies _real_
time reference. (Whatever _real_ is! :-)
My implementation uses 31 as infinity; as long as the code is careful
not to adjust the clock using samples that had strata larger than the
(immediately) previous sample from the peer, you don't suffer bogus
adjustments as the servers wander out to infinity. (This is a good
idea regardless of the value of infinity.)
Writing an independent implementation to the written specification
without reference to the PD source is instructive; there are real
holes in the protocol specification, as well as interesting improvements
available to things like the filter algorithm. (Yes, I will be telling
about various things I've found as I get time to do it. :-)
Rob
--
Robert Ullmann Ariel@World.STD.COM +1 508 879 6994 x226
=============================================================================
From: joey@tessi.com (Joey Pruett)
Subject: What I've learned about sun clocks and ntp
Organization: Test Systems Strategies, Inc., Beaverton, Oregon
X-Keywords: adjustment [-/+] configuration [-/+] driftfile [-/+] update [-/+]
This is all my opinion about how things work (or should work) and are
by no means authoritative. I assume that the reader understands how to
create the configuration file and have read about tickadj.
This is the procedure that I've come up with to get the clock on
a sun system working pretty well. It is a sun 4/670 running
4.1.2.
# tickadj -s -a 5
This stops the system from resetting the clock from the hardware
clock. If you don't do this, ntp and the hardware clock fight over
the correct time. It also sets the adjtime step to 5 usec which
allows ntp to make a change of 500 usec/sec.
# ntpdate server [server...]
This will set the clock to a semi-sane value. Try to use more
than 1 server.
# xntpd
The ntp server (duh!). Let it run for at least a day, if not
longer. Over that time it should be able to figure out how bad your
clock is. This value is recorded in the driftfile (usually
/etc/ntp.drift) and is updated once an hour. Monitor this and when it
seems to have stabilized for a couple hours, you should be ready. Kill
the ntp server when you're ready to fiddle with things.
Now the value you will want to use for 'tick' is 10000 + int(drift/100).
So if your drift is 213.64, then tick should be 10002, -172.12 would be
9999. Edit the driftfile and remove the hundreds part, so the examples
would be 13.64 and -72.12. I decided that I like having a positive
adjustment, so I add 1 more to tick if the value is still negative, and
then update the driftfile to be 100+olddrift. So, my example of
drift=-72.12, tick=9999 gets turned into drift=27.88, tick=10000.
If the absolute value of drift is not > 100, then you can just use
10000 for tick.
# tickadj -s -a 1 -t <tick value>
# xntpd
Run these and also update rc.local to do the same.
After doing this, ntp will be able to make change things up to
100 usec/sec and the changes can be as small as 1 usec. This keeps
the time as accurate as possible by not accumulating adjustments
until large enough to call adjtime().
And now a question. In the kernel, there is a variable called
'clkdrift' that looks like it might be a trim value. It seems
like things would work much nicer if the kernel could always
be trimming the clock rather than having ntp adjtime() every
second. Does anybody now how this variable is used?
Hopefully, I haven't made a horrible error in my method, or in
my description of it...
=============================================================================
From: sam@ug.uk.sun.com (Sam Pierson)
Subject: Summary: NBS NIST PSTI WWV WWVB GOES
Organization: Sun Microsystems (UK) Ltd
X-Keywords: FAQ [-/+] NIST [-/+] USNO [-/+] WWVB [-/+]
Thanks to all who answered my post about these acronims. I have
summarised all the info I received below in case anyone is interested
in using it in the forthcoming FAQ. I make no claims to the accuracy
of the information, I just collated it. Thanks go to Chris Polk, David
B. Brown, Ross Alexander and Ian Phillipps.
-Sam.
----
BIH Bureau International d'Huere
Organization in Paris France, that keeps track of world time.
GOES Geosynchronous Orbiting Environmental Satellite
A set of satellites that provides weather satellite imaging for
the North American continent. GOES satellites also provide a
timecode that is NIST-traceable and is uplinked by NOAA
(operators of GOES) at Wallops Island, NC. Can be received by
very simple equipment. Carrier is around 137 Mhz. Accuracy
is in the lower milliseconds.
GPS Global Positioning System
A satellite navigation system usable for accurate timekeeping,
Its accuracy range is normally about 100 nanoseconds and the 3D
coverage is getting close to the desired 24 hours a day.
NBS National Bureau of Standards.
This is the old name for the NIST.
NIST National Institute of Standards and Technology
A department of the US Department of Commerce.
Headquarters in Boulder, Co.
Responsible for maintaining reference physical standards such
as time, meter, kg etc.
The civilian counterpart of the USNO (see below).
PSTI Precision Standard Time Inc.
A company that produces a WWV[B] tracking timepiece.
UNSO United States Naval Observatory
Keepers of UTC (Universal Coordinated Time).
WWV Radio station call sign.
American radio station run by the NIST that broadcasts standard
time frequency (and weather ?) information on 2.5, 5, 10, 15,
and 20 MHz from Fort Collins, Colorado.
WWVB Radio station call sign.
60Khz version of WWV.
Sited in Washington DC (?) [Actually Ft Colins CO]
WWVH Radio station call sign.
Hawaii station of WWV service.
---
Sam Pierson -- European Support Services, SunSoft Inc. High Wycombe, UK.
Internet: Sam.Pierson@Sun.COM UKnet: sam.pierson@sun.co.uk
I do not speak for SunSoft, Inc or Sun Microsystems, Inc.
=============================================================================
Subject: none (auto-inserted) [-/+]
From: John C Sager <jcs@zoo.bt.co.uk> [-/+]
X-Keywords: FAQ [-/+] USNO [-/+]
Rick,
Thanks for the FAQ. here are some corrections.
> BIH Bureau International d'Huere
> Organization in Paris France, that keeps track of world time.
Bureau International de L'Heure
^
I believe that this has now become part of the International Bureau
of Weights & Measures (IBWM), another acronym for the list.
> GPS Global Positioning System
> A satellite navigation system usable for accurate timekeeping,
> Its accuracy range is normally about 100 nanoseconds and the 3D
^^^
> coverage is getting close to the desired 24 hours a day.
Make that several hundred ns, due to the effect of Selective Availability.
The absolute maximum should be < 1us.
I believe the spec on |(GPS time - UTC) modulo 1 sec| is < 176ns for the
case where S/A is compensated (military kit).
> UNSO United States Naval Observatory
^^?
> Keepers of UTC (Universal Coordinated Time).
Not really. The IBWM keep UTC as a synthesis of UTC clocks kept by USNO
NPL (National Physical Laboratory (UK)), and other organisations in France,
Germany, Russia & other places. There is generally some small difference
between all these national standards. I understand GPS will be the vehicle for
significantly reducing these differences.
regards,
John
=============================================================================
From: Mills@UDEL.EDU [-/+]
Subject: Re: Need a reference clock
X-Keywords: VAX [-/+]
Dorian,
Tired ticker ncarfuzz.ucar.edu has come victim of oxide plow, while
clepsydra.dec.com has been rehomed to a VAX. Use DNS to resolve its
true address. Ticker dcn5.udel.edu has gone to the great clock in the
sky and several other fuzzbums unnoticed in the swamp have been
eaten by alligators. The remaining ones fuzz on, although some are
grossly overloaded (clock.sura.net and umd1.umd.edu). I would dearly
love to see the fuzzbums retired and replaced with modern silicon,
but for various reasons, squeaky time is not a priority issue with those
that count the beans. In any case and in order to avoid overheating
the tired old silicon and redline DMZs, we should all avoid pecking on
the stratum-1 servers, both fuzz and otherfuzz, unless prepared to
front for a biggish bunch of churlish clients.
Please note the file clock.txt changes on about a monthly basis, so
any file that "came with the distribution" is surely long of tooth.
Dave
=============================================================================
From: ken@SDD.HP.COM (Ken Stone) [-/+]
Subject: Re: HP version of ntp wanted
X-Keywords: adjtimed [-/+] HP-UX [-/+]
> I need some assistance in locating a version of ntp/ntpd for HP-UX V8.x,
> would you be able to point me in the right direction.
The standard xntp3 code works just fine with the addition of a seperate
daemon (adjtimed) to compensate for the lack of adjtime(2). Pick up
the code from louie.udel.edu. I have it running on over 350 8.X HP-UX
machines on this site alone ... s300/s700/s800 all work.
-- Ken
=============================================================================
From: rbthomas@frogpond.rutgers.edu (Rick Thomas) [-/+]
Subject: Re: 3 or 9 Internet NTP servers?
Organization: Rutgers Engineering Supercomputer Lab
X-Keywords: documentation [-/+] peer [-/+]
^% The DEC documentation says:
^% "If your site is connected to the Internet, you should configure three
^% (but no more than three) NTP primary servers at your site that
^% synchronize to three highly accurate (stratum 1 or stratum 2) hosts on
^% the Internet."
^%
^% I may be having a brain fart, but this seems ambiguous. Does
^% each local NTP primary server use three different Internet servers or
^% the same three?
Well, one way of doing it is to have 3 onsite primaries (stratum 3, say)
connected to 4 offsite servers (stratum 2, say) as follows
onsite-1 is client of offsite-a, offsite-b, offsite-c,
and peer to onsite-2, onsite-3
onsite-2 is client of offsite-a, offsite-b, offsite-d,
and peer to onsite-1, onsite-3
onsite-3 is client of offsite-b, offsite-c, offsite-d,
and peer to onsite-1, onsite-2
This spreads your load around and gives you a little extra redundancy, but
not enough to cause severe confusion. Peering onsites with fellow-onsites
makes sure you get consistent time amongst them.
Enjoy!
Rick
============================================================================
From: wai@socs.uts.EDU.AU (Wai Yat Wong)
Subject: Re: Help --- xntpd[122]: Previous time adjustment didn't complete ? [-/+]
Organization: School of Computer Science, UTS
X-Keywords: adjustment [-/+] dosynctodr [-/+]
A great thank you to Anthon Ouwendijk <ouwendyk@prso.pttnwb.nl>
I now have an answer .
Anthon emailed me and explained the following:
|> All my workstations here that are running 'xntpd -b'
|> occasionally have these console messages:
|>
|> xntpd[122]: Previous time adjustment didn't complete
|>
You have Sun workstations, haven't you?
Maybe this is what you are looking for ...
SunOS 4.1.x has a lousy software clock: clock ticks are lost,
and it contains other bugs too.
Therefore SunOS adjusts its software clock to the battery-backup clock
and this plays havoc with the operation of xntpd. (Two captains on
a single ship, fighting for clock-control).
So, on SunOS you have to call 'tickadj -s' (see man-page) after
booting. Tickadj -s turns off the kernel parameter dosynctodr,
that controls SunOS synchronizing to its hardware clock.
The lousy software clock will be adjusted by xntpd.
So .... add the following lines to your ntprc file:
if [ ! -x <your-path>/tickadj ]
then
echo "NTP error, file tickadj missing." >&2
exit 0
fi
<your-path>/tickadj -s -q
Thanks again, Anthon , all the way from the Netherlands.
============================================================================
From: mrapple@quack.kfu.com (Nick Sayer) [-/+]
Subject: Re: Help --- xntpd[122]: Previous time adjustment didn't complete ? [-/+]
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
X-Keywords: bug [-/+] precision [-/+]
wai@socs.uts.EDU.AU (Wai Yat Wong) writes:
><your-path>/tickadj -s -q
While you're at it, that ought to be
<your-path>/tickadj -Aqs
This will also have tickadj compute and install an appropriate value
for tickadj, which allows xntpd to work around a bug in most kernels
having to do with the precision with which adjtime()s are applied
to the clock. See notes.me for more info.
=============================================================================
From: rbthomas@frogpond.rutgers.edu (Rick Thomas) [-/+]
Subject: Re: what are the /etc/ntp.drift units?
X-Keywords: Mills [-/+]
>> What are the units of the /etc/ntp.drift file value? ...
>> What I want is some way to sanity check a drift value. I have systems
>> that lose about 1.1 seconds per day when left to run on their own.
>> What might I expect the drift value to be?
>>
>> chongo <> /\oo/\
I heard a rumor that the units changed between xntp and xntp3. The
rumor went on to say that in xntp (v2 of the protocol) the drift in the
drift file is to be divided by 4096 to get parts per million. I.E.
microseconds of drift per second of time. The rumor went on further
and said that in xntp3 (v3 of the protocol) the units had changed so
that one could read the contents of ntp.drift directly as parts per
million. I think (degree of verification now less than rumor) that ntp
(v1 of the protocol) used the same units as xntp (v2).
Nick Sayer <mrapple@quack.kfu.com> sent me some corrections to my rumor...
%
% Not quite. The drift file under v2 is 4096 parts per unit, not per
% million. So divide by 4096 and multiply by 1e6 and you get
% parts per million.
And Louis A. Mamakos <louie@ni.umd.edu> sent the following addition
%
% Off the top of my head, I believe that ntpd uses the same units as
% xntpv2 does. The format of the file is slightly different, as I
% recall, as the last few computed samples (one per hour) are recorded.
%
% This is from memory; we run xntp3 now and I don't recommend ntpd for
% any new applications.
To which Dave Mills <Mills@udel.edu> adds
%
% The units in the file are in ppm, but the units shown in ntpq are 1000 times
% that amount or in parts in 10^9. Life lurches on.
And Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> adds
% Almost ppm. (I should know, I put it in myself.) The actual unit is
% 2**-20 (a pure number, or seconds per second if you like). I was also
% surprised by the multiply-by-1000 behaviour of ntpq, which is a legacy
% of the Fuzzball era, I think
%
% (The old (xntpd v2) code used a 64-bit fixed-point register. I think
% it was effectively in units of 2**-12, since it was shifted by
% CLOCK_FREQ and applied once every four seconds. That is, the value in
% the drift file grew by a factor of 256.)
There are 86400 seconds in a day, so 100 ppm would be 8.64 seconds per
day.
Rick
============================================================================
From: thorinn@diku.dk
Subject: drift units...
The value in the drift file: I was talking of units. To convert the
value in the xntp v3 drift file, in units of 2**-20, to units of ppm
(10**-6), you have to _divide_ the number by 1.048576 (or multiply it
by 0.95367431640625). In other words, the value is about 5% high.
If I am right (remember, I am not totally certain of this) the older
implementations expressed the value in units of 2**-12. To get ppms,
divide by .004096, or multiply by 244.140625. Or just say that in the
old format, the number was 256 times smaller.
Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
============================================================================
From: "Louis A. Mamakos, NTP mailing list maintenance" <NTP-REQUEST@ni.umd.edu>
Subject: NTP mailing list vs NTP netnews
X-Keywords: FAQ [-/+]
> Thanks, Louie!
>
> Incidentally, to what e-mail address should I send the once-a-month FAQ
> so that the ntp mailing-list gets it as well as the
> comp.protocols.time.ntp netnews group.
>
> Are they gatewayed? It doesn't seems so, but I can't tell for sure.
> Perhaps you could write something for the FAQ on how readers of the
> netnews group can get connected to the mailing-list. If you do, I will
> add something about the netnews group for readers of the mailing-list.
There is a one-way gateway which causes traffic sent to the NTP
mailing list (NTP@NI.UMD.EDU) to be injected into the
comp.protocols.time.ntp newsgroup. This is being done at Apple by
Erik Fair. If I can find some good bidirectional news <-> mail
gateway software, I may consider making a local gateway which operates
in both directions.
I encourage all interested parties to read the USENET newsgroup rather
than subscribe to the mailing list.
louie
AKA: NTP-REQUEST@NI.UMD.EDU
============================================================================
From: wollman@sadye.emba.uvm.edu (Garrett Wollman)
Subject: Re: Previous time adjustment didn't complete
Organization: University of Vermont, EMBA Computer Facility
X-Keywords: adjustment [-/+] syslog [-/+]
In article <9304201216.ZM25019@hansen> chongo@ncd.com writes:
>What changes should make (if any) when xntpd (V3) issues the following
>syslog message:
> Apr 18 14:00:55 hansen xntpd[13203]: Previous time adjustment didn't complete
It really depends on the machine you're using. My machine generally
prints it out only once a day, usually correlated with other system
activity (when I'm re-compiling my kernel, for example, or expiring
news), so I don't worry about it.
>How often to 'too often'? What is 'normal' for a system where all is well?
I'll let others answer the first question. `Normal' is probably `not
at all'; I believe that the messages in my system probably result from
bugs in the interrupt handling code, although I'm not absolutely sure
and I'm not enough of a hardware hacker to look at it and see what
it's doing when this happens.
-GAWollman
============================================================================
From: cudep@csv.warwick.ac.uk (Ian Dickinson)
Subject: Re: time going backwards
Date: 18 May 93 14:03:09 GMT [-/+]
X-Keywords: adjustment [-/+]
In article <C70Dou.6D5@olsen.ch> lindy@olsen.ch (Lindy Foster) writes:
>I expected the behaviour to be more like date -a, where the
>system clock is _gradually_ slowed down using adjtime so there is no
>backwards time jump. This is really important to us, as we receive real
>time data which is date stamped on arrival, and a consistent forward flow
>of time is critical.
I'm making the assumption that it only does this relatively soon after
booting. If this isn't the case, I think you may have other problems.
The best workaround is to run ntpdate as early as possible in the boot
sequence, sleep for however many seconds it would take for the adjtime
call to succeed, call nntpdate again to do some finer adjustment, sleep
again, and then start xntpd. For instance (culled from README.solaris2):
tickadj -s -a 1000
ntpdate -v server1 server2
sleep 20
ntpdate -v server1 server2
sleep 20
tickadj -a 200
xntpd
Your values for tickadj may need changing.
(BTW, the tickadj kernel variable doesn't exist under Solaris 2.2 - what
should one be doing in this case???)
============================================================================
From: lichtin@olsen.ch (Martin Lichtin)
Subject: SUMMARY: Weird NTP behaviour (well, maybe not)
Date: 3 Jun 93 14:22:47 GMT [-/+]
Organization: Olsen & Associates, Zurich, Switzerland
X-Keywords: DCF DST [-/+] PLL [-/+] synchronized [-/+]
My question (basically) was:
> We have a DCF radio clock and are running xtnpd on machine A. There's
> also a machine B, not running xtnpd and time off by 250 seconds
> relative to machine A. I then start up xntpd on machine B (with
> /etc/ntp.conf containing: "server A") .
> A (date;sleep 2) loop says:
> Tue Jun 1 18:40:48 MET DST 1993
> Tue Jun 1 18:40:50 MET DST 1993
> Tue Jun 1 18:36:43 MET DST 1993
> Tue Jun 1 18:36:45 MET DST 1993
> And now, clocks have synchronized. But wasn't this a bit rude?
The common answer was that for time deltas greater than CLOCK_MAX =
128ms, the clock is stepped and then the PLL (Phase-Lock Loop) takes
over.
However, I'm still waiting for someone who knows a way to avoid this
behaviour. Imagine a machine that only receives NTP packets for a few
hours a day. Do I need to set tickadj to a higher value? Can I twiddle
NTP to be less precise and allow correcting bigger offsets?
Martin.
----------------------------------------------------------------------------
The Answers:
Subject: none (auto-inserted) [-/+]
From: John C Sager <jcs@zoo.bt.co.uk> [-/+]
To: lichtin@olsen.ch (Martin Lichtin)
Date: Wed, 2 Jun 93 12:18:50 BST [-/+]
X-Keywords: adjustment [-/+] peer [-/+] PLL [-/+]
Martin,
This is the way xntpd is supposed to work. If the error between the
system clock and the reference derived from the peer(s) it is using is
greater than CLOCK_MAX (128ms) then the clock is stepped to get it to
within a few milliseconds, and then the PLL control takes over. I
suspect this is done because the PLL time constant is so long (some
hours) and underdamped to some degree, that it would take a long time
to settle, and the adjustment capability would be exceeded. With the
recommended value for tickadj, the maximum adjustment rate available
is 500us per second. Adjusting at this rate it would take about 5.5
days to remove a 240 second offset, and the daemon would try to
command far greater rates than this. In practice, the frequency error
measured by the daemon would ramp up to a limit of about 390 ppm where
the daemon assumes something is badly wrong and quits.
John C Sager Mail: B67 G18, BT Labs
--------------------