Preliminary FAQ -- send updates to

Preliminary FAQ -- send updates to

Post by Rick Thom » Mon, 02 May 1994 23:05:05

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: 1994/05/01 05:30:41 $

I post the accumulation once a month.

It's rough but ready.

Rick Thomas, Manager Supercomputer Remote Access Center
Rutgers University, College of Engineering
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: (Mike Iglesias)
Subject: Re: xntpd: previous time adjustment didn't complete (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 F. Leavell)
Subject: Re: xntpd: previous time adjustment didn't complete

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

>               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: (Mike Iglesias)
Subject: Re: ntpdate: errors when trying to synch to other xntp hosts
Keywords: ntpdate xntp3

a...@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.  


From: Mi...@UDEL.EDU
Subject: Re:  NTP peers


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
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.


From: (William L. Jones)
Subject: Just a few small suggestions!


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: (Geert Jan de Groot)
Subject: Re: Reachability keeps resetting zero after a STEP (Joey Pruett) writes:
>I just recently started trying to use ntp on my sun systems.  I've
>compiled the xntp3 stuff from 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

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 ( offset 0.177012563)
>08:23:00 xntpd: adjust: STEP dropped ( offset 0.248992682)
>08:24:06 xntpd: adjust: STEP dropped ( offset 0.248992682)
>08:25:08 xntpd: adjust: STEP dropped ( offset 0.404627085)
>08:26:12 xntpd: adjust: STEP dropped ( offset 0.404627085)
>08:27:16 xntpd: adjust: STEP dropped ( offset 0.404627085)
>08:28:20 xntpd: adjust: STEP dropped ( offset 0.577525616)
>08:29:24 xntpd: adjust: STEP dropped ( offset 0.757438898)
>08:30:28 xntpd: adjust: STEP dropped ( offset 0.759768605)
>08:31:34 xntpd: adjust: STEP dropped ( offset 0.757438898)
>08:32:36 xntpd: adjust: STEP dropped ( offset 0.757438898)
>08:33:40 xntpd: adjust: STEP dropped ( offset 0.757438898)
>08:34:44 xntpd: adjust: STEP dropped ( offset 0.757438898)
>08:35:48 xntpd: adjust: STEP dropped ( 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 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 event 84 status 9024
>08:36:54 xntpd: system event 4 status c655
>08:36:54 xntpd: peer event 84 status 9024
>08:36:55 xntpd: peer event 84 status 8024
>08:37:56 xntpd: peer 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

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: (Michael J. Corrigan)
Subject: Re: Preliminary FAQ -- send updates to

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    version 2

if the host is still running version 2.

From: (Wayne Folta)
Subject: Re: Preliminary FAQ -- send updates to

>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          (

From: (Rick Thomas)
Subject: Re: Using xntp without radio clock or internet connection?
Keywords: clock ntp internet 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)

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.


From: (Robert L Ullmann)
Subject: Re: Using xntp without radio clock or internet connection?

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

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. :-)


Robert Ullmann          Ar...@World.STD.COM +1 508 879 6994 x226
From: (Joey Pruett)
Subject: What I've learned about sun clocks and ntp
Organization: Test Systems Strategies, Inc., Beaverton, Oregon

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

# 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 Pierson)
Organization: Sun Microsystems (UK) Ltd

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.



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.Pier...@Sun.COM   UKnet:
         I do not speak for SunSoft, Inc or Sun Microsystems, Inc.

From: John C Sager <>

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.


From: Mi...@UDEL.EDU
Subject: Re:  Need a reference clock


Tired ticker has come victim of oxide plow, while has been rehomed to a VAX. Use DNS to resolve its
true address. Ticker 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 ( and 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.


From: k...@SDD.HP.COM (Ken Stone)
Subject: Re: HP version of ntp wanted

> 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  I have it running on over 350 8.X HP-UX
machines on this site alone ... s300/s700/s800 all work.

  -- Ken

From: (Rick Thomas)
Subject: Re: 3 or 9 Internet NTP servers?
Organization: Rutgers Engineering Supercomputer Lab

^% 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.

From: w...@socs.uts.EDU.AU (Wai Yat Wong)
Subject: Re: Help --- xntpd[122]: Previous time adjustment didn't complete ?
Organization: School of Computer Science, UTS

A great thank you to  Anthon Ouwendijk <>

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 ]
        echo    "NTP error, file tickadj missing." >&2
        exit 0
<your-path>/tickadj -s -q

Thanks again, Anthon , all the way from the Netherlands.

From: (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'.

w...@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 for more info.

From: (Rick Thomas)
Subject: Re: what are the /etc/ntp.drift units?

>> 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 <> 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 <> 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 <> 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) <> 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


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) <> (Humour NOT marked)

From: "Louis A. Mamakos, NTP mailing list maintenance" <>
Subject: NTP mailing list vs NTP netnews

> 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 (N...@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.



From: (Garrett Wollman)
Subject: Re: Previous time adjustment didn't complete
Organization: University of Vermont, EMBA Computer Facility

In article <9304201216.ZM25019@hansen> 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.


From: (Ian Dickinson)
Subject: Re: time going backwards
Date: 18 May 93 14:03:09 GMT

In article <> (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

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: (Martin Lichtin)
Subject: SUMMARY: Weird NTP behaviour (well, maybe not)
Date: 3 Jun 93 14:22:47 GMT
Organization: Olsen & Associates, Zurich, Switzerland

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

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?

The Answers:

From: John C Sager <>
To: (Martin Lichtin)
Date: Wed, 2 Jun 93 12:18:50 BST


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

From: Frank Kardel <>
Date: Wed, 2 Jun 93 13:41:01 +0200

Please let the daemon run all the time. Then it will be able to keep
the time with 128ms and all is well. NTP is not designed for casual use.

Frank Kardel

From: Mi...@UDEL.EDU
Date: 5 Jun 93 19:30:05 GMT

Rick & Co.,

A few comments on your faq compendium follow. Sorry I don't have the
photonic bandwidth to eyeball the ntp newsgroup directly.

All Sun4s I know of have the local oscillator frequency at least
100 ppm fast, so the -t 9999 argument to tickadj is almost always
required. It is a good idea to get this right, whether 9999 or
something else, as the residual error affects the actual jitter
of the clock, as well as the frequency error should the NTP daemon
be interrupted for some reason. It is always the case that dosynctodr
should be disabled. While I haven't laid paw to SunOS 4.1.3 yet,
I doubt it is any different than 4.1.1 in these areas.

Rob Ullmann mentions an untainted implementation ex spec. I would very
much like to hear of such adventures and what holes remain in the
spec. It will also help the case if and when the spec is advanced
beyond the present Draft Standard status. Frankly, my experience in
promoting the present status has left me rather disenchanted with
the standards process, so advancement is not high on my agenda.

I don't think you want to meddle with clkdrift; it causes the differenct
between the tod clock and system clock to be displayed, if more than
one tick apart. In fact, if dosynctodr is NOT reset, xntp will not work
at all.

Fixup on anachronisms: So far as I know, NIST is headquartered in
Gaithersburg, MD, WWV and WWVB transmitters are at Ft Collins, CO.
Conventional wisdom (as opposed to Politically Correct) is that
USNO keeps the time and NIST keeps the frequency, but each reads
each other's timekeeper's notices. As for GPS time relative to UTC
time, you need to be equally delicate on turf. GPS receivers keep
GPS time as coordinated within GPS and may not split the weenieseconds
with respect to UTC. Without the military codes, GPS users are not
expected to achieve accuracies much better than LORAN-C, allegedly
0.25 nm or well over a microsecond. Don't believe it; with a good
timing receiver, 5-7 satellite averaging, a decent local timebase
and occasional discipline to LORAN-C, I'm getting better than 100
ns almost all of the time. This is verified by cesium oscillator
calibrated to USNO and is much better than early civilian GPS


From: (Christopher Jackson - Special Projects)
Date: 6 Jun 93 14:55:16 GMT
Organization: Sun Microsystems, Columbia MD

In article <> Mi...@UDEL.EDU writes:
>All Sun4s I know of have the local oscillator frequency at least
>100 ppm fast, so the -t 9999 argument to tickadj is almost always
>required. It is a good idea to get this right, whether 9999 or
>something else, as the residual error affects the actual jitter
>of the clock, as well as the frequency error should the NTP daemon
>be interrupted for some reason. It is always the case that dosynctodr
>should be disabled.

This is not quite correct.  While our oscillators are not perfect
(otherwise there'd be no need for NTP, right? :-) ), the consistent
100ppm error is due to software, rather than hardware.  Previous
versions of SunOS 4.X had a bug where the real-time clock register was
initialized to one less than the proper value.  The clock interrupt
thus fired one tick too early, and the system clock gained an extra
1us every 10 ms.

>While I haven't laid paw to SunOS 4.1.3 yet,
>I doubt it is any different than 4.1.1 in these areas.

This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which
the -t 9999 adjustment should no longer be necessary.  (Yes, you
do still need to disable dosynctodr.)

Chris Jackson  <>

From: (Tony Luck)
Date: 8 Jun 93 17:42:11 GMT
Organization: Fujitsu Open Systems Solutions, Inc. (Don Lewis) writes:
>I'm not so sure it is fixed.  Our two Sparc 2's are running 4.1.2,
>and with the  -t 9999 adjustment, they are off by 19ppm and 34ppm.
>Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm.
>This is a small sample, but the 106ppm error is more than I would
>have expected.

A few more data points about how far out some Sun4's crystals can be.  Most
of these are IPXen, with a couple of SPARCstation2's, and a 4/690 and 4/330.
All are running SunOS 4.1.2

        ntp.drift       tick
        =========       ====
        -89.83615       10000
        -73.36331       10000
        -72.51350       9998
        -66.32201       10000
        -64.02086       10000
        -62.21976       10000
        -55.62454       10000
        -54.74640       10000
        -50.99059       10000
        -6.39066        10000
        -4.19466        9998
        -1.12428        9999
        9.57497         9999
        12.04364        10000
        22.07689        9999
        39.67384        9999
        51.66208        9999

>From these numbers, it looks to me like 106ppm is well within the range of

speeds that Sun4 crystals actually run.

A while back somebody posted a suggestion of running xntpd for a few days,
then look at the drift file.  If the absolute value is too big (>100?) then
kill the xntpd daemon.  If the drift value is negative, you should reduce
'tick', if it is positive, then increase 'tick' ... add/subtract 100 to the
value in the drift file for every point that you change tick, then start a
new xntpd daemon.

Sounds like the FAQ should tell people to start at "-t 9999" on pre-4.1.3
systems ... but be prepared to tune a point or two on all Suns.

-Tony Luck

From: (Nick Sayer)
Date: 10 Jun 93 10:56:31 GMT
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'. (Don Lewis) writes:
>In article <1ut0gk$> (Christopher Jackson - Special Projects) writes:
>>This bug (Sun Bug 1094383) is fixed in SunOS 4.1.3, under which
>>the -t 9999 adjustment should no longer be necessary.  (Yes, you
>>do still need to disable dosynctodr.)
>I'm not so sure it is fixed.  Our two Sparc 2's are running 4.1.2,
>and with the  -t 9999 adjustment, they are off by 19ppm and 34ppm.
>Our 10/41 running 4.1.3 without the -t 9999 adjustment is off by 106ppm.
>This is a small sample, but the 106ppm error is more than I would
>have expected.

I think the bug was sun4c specific, but the fix was applied to all
Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3
need to have tick incremented by one. sigh.

The best thing to do is do it on an individual basis. If your clock
is off by more than 50 ms, increment/decrement tick until it isn't.

From: (Christopher Jackson - Special Projects)
Date: 13 Jun 93 15:26:00 GMT
Organization: Sun Microsystems, Columbia MD

In article <> (Nick Sayer) writes:
>I think the bug was sun4c specific, but the fix was applied to all
>Sun 4 platforms in 4.1.3. Which means that sun4ms running 4.1.3
>need to have tick incremented by one. sigh.

Well, it turns out that Mr. Sayer is correct; the bug is not completely fixed
for sun4m machines.

The clock initialization for sun4, sun4c, and sun4m platforms was broken in
4.1.2.  A fix was made to all three platforms for 4.1.3.  Unfortunately, the
sun4m clock is a little different from the sun4/sun4c clock, and the fix needs
to be a little different as well.  The result is that in 4.1.2, sun4 and sun4c
were 100ppm fast, while sun4m was 50ppm fast; in 4.1.3, sun4 and sun4c are no
longer broken, but sun4m is 50ppm slow.  (Since it's 50ppm, not 100ppm, you
can't really fix this with the -t flag.)

A bug has just been filed on this, and it will hopefully be fixed in a future
release of SunOS.  In the meantime, the exceptionally brave may wish to try
the following patch.

        This patch is for sun4m machines running 4.1.3 only; sun4s and sun4cs
        don't need it, and applying it to earlier 4.X releases will probably
        result in a crash.

        THIS IS NOT AN OFFICAL SUN PATCH; if it trashes your system, melts
        your disks, or turns your hair green, don't complain to me or to the
        Answer Center.  Caveat Emptor.

The patch:
        cp /vmunix /vmunix.bak
        adb -w /vmunix
        startrtclock+2c?W 110007a0
        startrtclock+34?W 90122480
        startrtclock+3c?W 912a2009
        startrtclock+40?W 1000000
        startrtclock+44?W 1000000

If anyone actually tries this, I would be interested to hear how much it helps.

Chris Jackson  <>

From: (Amos Shapira)
Subject: Re: help with ntp
Date: 26 Jun 93 16:04:34 GMT
Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel

j...@TAO.UNIV-PARIS8.FR (Jean Mehat) writes:

   I would like which version of ntp, xntp etc... is the most current one?
   We are running a small network of sun4 on the internet (< 10 machines).
   I have been said that time synchronisation is an important issue in
   security. I am somewhat lost between various releases of Network Time
   Protocol. Can you give me a pointer to the most recent release (like a
   ftp site & directory) ?

   Jean Mehat, universite de Paris 8 Vincennes a Saint Denis,, (1) 49 40 64 03, (1) 49 40 67 83 (fax)

As far as I followed it,  the most recent *released* version is 3.1,  the
"home site" of xntp is directory /pub/ntp.
You will find there also some alpha releases of a newer version.

The drawback of this site is that it is located inside the U.S. and therefore
you can't take advantage of the DES code it can use (you still can have the
MD5 code).  A release with DES which is located outside the U.S. is available
on file /hpux/Networking/xntp-3.1.tar.Z.  This is the one
I'm running a few months by now and it seems to work greate.



From: (Nick Sayer)
Subject: Re: NTP for Mac?
Date: 6 Jun 93 16:40:17 GMT
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'. (Nick Sayer) writes:
>I remember hearing some time ago about an NTP control panel or INIT
>for Macs. Is this true? What's it called and where can I ftp it?
>Thanks in advance.

Thanks to Randy Bush who not only pointed me towards, but mailed
me a copy of "Network Time", a control panel that does exactly

From: Mi...@UDEL.EDU
Subject: Re:  Leap second?
Date: 30 Jun 93 20:00:25 GMT

The fuzzballs are now so overloaded that I can't reach in and set the
leap bits manually. Between the smoke and steam of the xntp-alpha
stuff, new radio drivers and busted radios, not to mention new kernels
with leap stuff built in, I decided my bandwidth for this particular
leap event had been exceeded. Most of the radio services you mention
already have leap-warning bits and at least some of the clocks (CHU and
WWVB) do decode them in xntp-alpha. The problem here is that I haven't
completed the xntp-kernel interface for the kernels I have modified to
handle the leap event correctly. Standard kernels will of course not
bump the time until at least one update has been seen from the source.

From: (Dan Warburton)
Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715
Date: 7 Jul 93 16:28:08 GMT
Organization: FAA Technical Center, Pomona, NJ (Dan Warburton) writes:
> (Ian Ringrose) writes:
>>I having problems getting "ntpdate" to work on a HP-UX 9 system, I have not
>>set up any config files, but have started "adjtimed".
>>When I do:
>>        # ./ntpdate
>>I get:
>>        ./ntpdate: no server suitable for synchronization found
>>When I do:
>>        # ./ntpdate -d
>Yes, it seems that is might work. I have the same problem. I have
>just tested with my Internet firewall down and things seem to work.
>There must be a back socket that needs access.
>Is there any one out there that Knows what port and protocal TCP or UPD
>this back channel might be? I'll check the sources, but would like
>confirmation of my guess.

OK, here's my answer: ntp uses a udp back port of 123 on my Internet fire
wall (a cisco router) my access list needed the following:

!ntp network time protocal
access-list 101 permit udp eq 123

This allows udp access to port 123 from anywhere on the internet to any host
on my Class B address space.

P.S. Maybe this should go into the FAQ?
Dan Warburton

From: (Tom Dunigan)
Subject: Re: ntpdate version 3.1 on HP-UX A.09.01 A 9000/715
Date: 7 Jul 93 20:44:37 GMT
Organization: Oak Ridge National Laboratory

In debug mode, ntpdate uses a non-privileged port number for its "source
UDP port" to do the query.  When not in debug mode, ntpdate uses port 123
as its source port.  Some systems (Ultrix), or maybe its the xnptd version,
refuse to reply to the 123-port request.
        Tom Dunigan

From: (Adam W. Feigin)
Subject: Re: syslog() bogosity
Date: 29 Jul 93 13:32:36 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH (Jim Jagielski) writes:
> (Ed McGuire) writes:
>>The virtually identical syslog code found in each
>>of these processes should be consolidated, but before I do that, has
>>it been cleaned up already in the alpha?
>Why not in the main ntp*.h include file do a:
>    #ifdef LOG_DAEMON
>    #undef LOG_DAEMON
>    #endif
>    #define LOG_DAEMON LOG_LOCAL0
>Or maybe put this in Config...

Ugh. Its in there already as of xntp-alpha. All you need to do is to
change the DEFS line in your config file, and add the following:

-DLOG_NTP=LOG_(insert your favorite syslog facility here)

Its not really documented in the Config file anywhere, and I can't
remember where I came across it, but it does work. I just checked, and
it looks like I gleaned this from the code in xntpd/ntp_control.c
(line 1724) and xntpd/ntpd.c (line 190).

Subject: NTP FAQ: update for Sony
Date: Thu, 05 Aug 1993 10:31:25 +0200

A little while ago I posted a request for help to run xntdp on Sony News.
Everybody agreed the answer was worth an entry in the FAQ.

This is a summary of the answers I got:

The problem is that Sony boxes do not take care of leap seconds correctly.
xntpd seems to synchronize well, but the date program pretends the clock
is 14 seconds off.

The solution is to remove the MET file in /etc/zoneinfo with all its links
and to replace it with a good one (sun's for example) and then to
restart inetd.

If you are in another time zone, you might have to change some other files.

Thanks to:

Heiko Trautwein <>:

> hello,
> on our SONY Workstations ( mips and mc68030 ) we had this problem too,
> the clock differs 14 or 15 seconds from all the other clocks, if
> timezone is MET, if you change the timezone to e.g. GMT the clocks
> are in time.
> So I think the GMT timezone is corrupt and copied the MET file from
> one of our Sun's on the Sony, and clocks where synched.

>    Heiko (John C Sager) & (Tony Luck)

- Show quoted text -

> In article <230vca$>, (Tony Luck) writes:
> > (durand alain denis) writes:

> > >I'm trying to install xntp-alpha on various machine on our network.
> > >It's just fine for sun's, but for sony mips, it's really wierd.

> > I think that this was discussed a couple of months ago ... as far as I recall
> > the problem is that the Sony systems have a table of the leap seconds so that
> > that can try to be really clever about telling you the time.  As a result,
> > they have a different idea of how many seconds there have been since 1970.
> > This confuses xntp somehow (maybe its date conversion code doesn't match the
> > libc ctime() stuff?) ... and the net result is that xntp sets the time to
> > a value that ctime() says is some number of seconds out (depending on how
> > many leap seconds ctime() is trying to account for).

> NTP ticks UTC, as do most Unix boxes, so at each leap second, it, and the
> Unix clock, get stepped appropriately. This is explained at length by Dave
> Mills in rfc1305 pages 76-79.
> There was some discussion on this group some time ago as to whether NTP
> should tick TAI, and the corrections done for leap seconds in the same
> manner as timezone & DST corrections are currently done (as the Sony
> box seems to do). At the time I argued that the current system is more
> convenient for most users, and the small number who need TAI can do the
> reverse correction at their own expense.

> > Can't recall whether anyone had a fix for this though ... if anyone does, its
> > probably worth an entry in the FAQ.

> I would agree an entry in the FAQ migh prevent future puzzlement.

        - Alain Durand.
From: (Alan Barrett)
Subject: Re: NTP for Novell????????
Date: 10 Aug 93 00:44:36 GMT
Organization: Elec. Eng., Univ. Natal, Durban, S. Africa (Mark F. Vickers) writes:

> Is there an NTP client for Novell???

This question should be in the FAQ, but is not there.  I usually email
replies to this question, but will post this time.

I don't know of an NTP implementation for Novell, but I do know of two
ways of synchronising the times of Novell servers using the RFC 868
time protocol (commonly called "rdate").

* There is an RDATE NLM from Murkworks that allows the Novell fileserver
  to synchronise its time from an rdate server.  Available from

* Brad Clements' Charon mail/lpr gateway can synchronise its time
  from an rdate server, and can set the times of the attached Novell
  fileservers using some Novell method.  Available from

Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
From: (Tony Luck)
Subject: Re: Problems with xntpdc and ntpq in xntp(3.1)
Date: 12 Aug 93 17:19:07 GMT
Organization: Fujitsu Open Systems Solutions, Inc. (Christopher B. Moore) writes:

>well under control.  But I'm having trouble running ntpq and xntpdc to
>get a look at what's going on.  Both programs fail with the message:
>ntp/udp: unknown service.  Can someone suggest what I might have done

I think that "ntp" is one of the well known services that Sun forgot to
put in /etc/services.  Just add the line:

ntp             123/udp                         # Network Time Protocol

to /etc/services (For some bizarre reason this file is controlled by
NIS (formerly yellow pages), so if you are in the unfortunate situation
of using NIS you need to add this line to /etc/services on your server
and run ypmake/yppush/whatever).

-Tony Luck <>

From: (Patrick Schoo)
Subject: Re: Problems with xntpdc and ntpq in xntp(3.1)
Date: 16 Aug 93 10:08:16 GMT
Organization: University of Limburg, Maastricht (Tony Luck) writes:
>I think that "ntp" is one of the well known services that Sun forgot to
>put in /etc/services.  Just add the line:
>ntp         123/udp                         # Network Time Protocol
>to /etc/services (For some bizarre reason this file is controlled by
>-Tony Luck <>

Sun didn't forget to put ntp in /etc/services, they just use the wrong
protocol (tcp instead of udp). In my original services file this line
was included (SunOS 4.1.1).

ntp             123/tcp                         # Network Time Protocol

Does anyone know if this is a bug, or if there is a specific reason for

Patrick Schoo (

From: (Geert Jan de Groot)
Date: 13 Aug 93 20:48:26 GMT
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands

Mi...@UDEL.EDU writes:
>The offset looks too high. Note the frequency slowly climing, which
>suggests the usual problem with SPARCs. Your /etc/rc.local file should look
>something like this:
>if [ -f /usr/local/bin/tickadj ]; then
>        /usr/local/bin/tickadj -t 9999 -a 5 -s & echo -n ' tickadjusted'
>if [ -f /usr/local/bin/xntpd ]; then
>        /usr/local/bin/xntpd & echo -n ' xntpd'
>This assumes SunOS 4.1.1. I am told, but have not confirmed, that 4.1.3
>has a bugfix which removes the necessity for the -t 9999 above. Then,
>I am told that Sun 5.x has a new bug which requires -t 10001. Your
>mileage may vary.

I found the offset to be CPU-specific. That means, when I needed
to have one CPU replaced, I had to re-find the right 'tick' value
for that specific board. It looks like the clocks are just
made with a larger tolerance than NTP can handle.

For each box running xntp, I build a file /etc/ntp.tick that contains
the tick value. I have values between 9997 and 10001, just to keep
the offset between +- 100 ppm on 4/280, 4/490, 4/690, 4/60, 4/65..
For a new CPU, I just set ntp.tick to 9999, let xntp run a day,
change ntp.tick if the offset is out of range, re-start xntp,
and retry. This usually stabilizes withing a few days.
If the offset is much too high (>250ppm), I found that xntp does
not obtain lock at all. These are all 4.1.3 machines.

Geert Jan

From: (Russell Mosemann)
Subject: Re: NTP for VMS
Date: 24 Aug 93 19:32:28 GMT
Organization: Concordia College, Seward, NE writes:
>I have been reading this group for a few months now and have never seen
>mention of a version of NTP for VAX/VMS. I also checked the archives at
>UDEL.EDU. Did I miss is or is there no version for VAX/VMS?

   There is no version that I know of unless you use Multinet.  I am
finishing a port of ntpdate to VMS.  I need to smooth out the code in
a couple of places and document it, but for the most part it is done.
When it is complete, I will submit it to the archives.  Watch this space
for further news.
   If I get really exicted some day, I might try to port xntpd to VMS,
but that won't happen for at least a year.
Russell Mosemann     Concordia College      Voice: (402) 643-7445
Computing Center     Seward, NE 68434       Fax:   (402) 643-4073
From: (Mike Iglesias)
Subject: Re: NTP for VMS
Date: 24 Aug 93 23:02:37 GMT
Organization: University of California, Irvine

Both Wollongong and Multinet support NTP for VMS.  Wollongong is ntp v1,
and I believe that Multinet is also.

Mike Iglesias                        Internet:
University of California, Irvine     BITNET:      iglesias@uci
Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
Distributed Computing Support        phone:       (714) 856-6926

From: Mi...@UDEL.EDU
Subject: Re:  xntp problem
Date: 25 Aug 93 00:00:22 GMT


The ntpdc works with NTP Version 1 implementations (ntpd) and not
Version 2 nor Version 3 implementations (xntp, xntp3, xntp-jones).
The equivalent program for the latter implementation is xntpdc included
in the xntp3, xntp-jones distributions. This program also works with
the Version 2 implemenation. Having said this, the program of choice
to fondle v2 and v3 implementations is ntpq in the xntp3, xntp-jones
distribution. This program conforms to the NTP Version 2/3 specifications
rfc-1119, rfc-1305, respectively and should work with other implementations
now coming online. The xntpdc program is very implentation dependent and
nto likely to work with any other implementation.


From: dk...@CISCO.COM (Dave Katz)
Date: 6 Sep 93 20:32:42 GMT

I did a little monitoring of churchy (a cisco IGS) which is filling in
at a peer address that was idle for some months.

In 20 minutes, 650 NTP requests were received from 106 hosts.

Three sites had seven peers chiming with churchy.

A number of the peers are running version 1 NTP.

Looks like mucho cruft out there...

Subject: Novell server time module available
Date: 14 Sep 93 17:58:24 GMT
Organization: Penn State University

There is now a directory on FTP.OTC.PSU.EDU which contains
information and software for synchronizing time on Novell
Netware servers with a Network Loadable Module (NLM) that
uses the unix "rdate" protocol. This NLM will allow Netware
servers to synchronize their time to time servers (eg:
CLOCK.PSU.EDU) within one second of accuracy.

This is not an implementation of Network Time Protocol (NTP),
which could provide better accuracy. Novell has committed
to that effort through the Distributed Time Service (DTS)
portion of OSF's Distributed Computing Environment (DCE).
An announcement on that from Novell will probably not happen
before the first quarter of 1994. Delivery schedule is even
more uncertain at this point.
(Feel free to correct me if you know something more current. :-)

*I don't speak for Penn State, Novell, or anyone else... *

The following is an information file included in the directory:

--- enclosed file follows ---

Info on files in /pub/ntp/ms_dos/novell on

rdatenlm.txt   This file. ASCII text.   PKZIPed (tm) RDATE.NLM and README.TXT. Binary file.

--- beginning of README.TXT (extracted from RDATENLM.ZIP) ---

This package contains an RDATE NLM for Novell Netware 386 (tm)
    |Permission is hereby granted for this archive to be distributed via|
    |BBS, Compuserve, Anonymous FTP and any other means so long as no   |
    |fee is charged for distribution and all components of this archive |
    |remain together.                                                   |
The RDATE NLM is Copyright (c) 1992 MurkWorks, All Rights Reserved.

RDATE.NLM  - 10/12/92

** This is free software **

MurkWorks has provided this NLM to the Novell user community at no charge.

        The RDATE NLM allows the supervisor to synchronize the time
        of a Novell NW386 file server with the time of a nearby
        Unix host (or any other host which supports the time protocol).


From: (John C Sager)
Subject: Re: any reason for ntp/tcp service?
Date: 21 Sep 93 09:19:07 GMT
Organization: BT Laboratories, Martlesham, Ipswich, UK

In article <>, (Darrin P Cardani) writes:

> Several of our /etc/services files listed ntp as a tcp service only, or
> as a udp and tcp service. The ones that listed it as tcp only, didn't work,
> so I fixed them by changing it to udp. Is there any reason to include tcp
> service, though? I have seen it on 2 platforms so far.

SunOS 4 /etc/services files are/were all like this, probably due to a misunderstanding at Sun. Dunno about other manufacturers. As you say,
a change to udp will fix it.

John C Sager                                    Mail:   B67 G18, BT Labs
Email:                   Martlesham Heath
Tel:            +44 473 642623                          IPSWICH  IP5 7RE
Fax:            +44 473 637614                          England
Disclaimer:     This is me, not BT.

From: (Paul Eggert)
Subject: Re: Puzzled about leap seconds
Date: 22 Sep 93 02:29:03 GMT
Organization: Twin Sun Inc, El Segundo, CA, USA (Thomas Sandford) writes:

        I think it means that ntp maintains the clock as though leap
        seconds do not exist.

I'm not quite sure what you mean, but if you mean that NTP forgets
past leap seconds, you're correct.

        Therefore on a system running ntp your timezone file must *not*
        contain any leap second entries.

That depends on what you mean by ``your timezone file''.  If you're
maintaining an astronomical application synchronized with NTP, there's
a good chance you will need a leap second database (if NTP suffices at
all).  But if you're merely maintaining a Unix (or, more precisely, a
Posix.1) host, then you probably don't need leap second entries, since
Posix.1 pretends that leap seconds don't exist and this maps
conveniently into NTP's fire-and-forget leap second handling.

        Also could you enlighten my ignorance. What exactly is TAI?

The quick answer is that TAI is Temps Atomique International, i.e.
International Atomic Time.  UTC = TAI + (integral leap second corrections).

The exact answer is a bit much to cover in a Usenet article, but here's
my best shot.  TAI is established on the basis of clock comparison data
supplied to the Bureau International des Poids et Mesures by
timekeeping labs around the world.  It is a coordinate time scale
defined in a geocentric reference frame with the SI second as realized
on the rotating geoid as the scale unit, i.e. it is not a proper time
scale if you take relativity into account.  To find out exactly what
TAI is, see B. Guinot and C. Thomas, ``The establishment of
International Atomic Time'', BIPM Annual Report of Time Section 1, part
D (1989).  More accessible reports appear in Metrologia 24, 195-198
(1987), Metrologia 28, 57-63 (1991), and Proc IEEE 79, 894-905 (1991).

From: (Jean Beland)
Subject: Re: NTP-client for MAC
Date: 24 Sep 93 14:38:48 GMT
Organization: Hydro-Quebec

Another NTP client for Macintosh is "Network Time 2.0", from Peter
Resnick. Available by anonymous FTP at sumex (shareware).

Jean Beland                 | Institut de Recherche d'Hydro-Quebec
Chercheur / Research Worker | 1800 Montee Ste-Julie,
tel: (514) 652-8076         | Varennes, Quebec, CANADA.  J3X 1S1
fax: (514) 652-8424         | Internet: <>

From: (Charlie Mingo)
Subject: Re: NTP-client for MAC
Date: 26 Sep 93 04:56:50 GMT

In article <>,

Rick Thomas <> wrote:

>Seriously, could somebody put it up for anonymous FTP?  If I had a place
>to point to, I'd put a notice of it in the FAQ.

I posted a copy to  It should appear in a few days.

From: (Tim Seaver)
Subject: SunOS zs serial port delays
Date: 24 Sep 93 16:25:03 GMT
Organization: CONCERT Network

This may be old news to most of you running STREAMS kernel
drivers for radio clocks on Sun workstations, but I don't recall
it being mentioned before. In the course of tracking down a
30 millisecond variation in timestamps on our WWVB radio
clock PPS signal, I discovered that, by default, SunOS only
services the zs serial port receive buffers every 3 clock ticks.
There's an internal flag used with the mouse port that allows
immediate interrupts, but I could find no way to set it from
user mode (other than by patching the kernel with adb once the
port is open). What this seems to imply is that every radio clock
kernel module running under SunOS on the zs serial ports should
do a

putctl1(WR(q)->q_next, M_CTL, MC_SERVICEIMM)

in the module open routine to pass the MC_SERVICEIMM (service
immediately) flag to the zs serial driver. In the xntp3
distribution, the dcf77 driver does set this, but the other
kernel modules don't. Setting this flag dropped a 30 millisecond
variation in our PPS timestamps to under 100 microseconds and
quite often under 10 microseconds over 5-10 second intervals.


From: (Piete Brooks)
Subject: Re: XNTP3 on a Sun-3
Date: 27 Sep 93 21:44:55 GMT
Organization: U of Cambridge Computer Lab, UK

In article <28739v$> (Ian Dickinson) writes:
>Could anyone provide correct values for Sun4m SunOS4 and Sun4d SunOS5 please?

* -20 for the former (well, that's what I use).

>I don't know how to calculate these values so far.

* The code I use (in my clock driver) just finds the time to read the clock.
* Old Sun4s increment the usec each time the clock is read, then suddenly
* jumps up 20ms. So this is a plausible kind of guess as to what it might
* approximate to ...

* Try it a few times, or better still, just keep reading the clock and printing
* the deltas.  If you have multicast, look at the code to check the idle time
* of an MBone mrouted -- it's tweaked to do go fast -- microtime makes quite a
* change :-)

/* Find the precision of the system clock by reading it */
#define USECS   1000000
#define MINSTEP 5       /* some systems increment uS on each call */
#define MAXLOOPS (USECS/9)
static int ees_get_precision()
        struct timeval tp;
        struct timezone tzp;
        long last;
        int i;
        long diff;
        long val;
        gettimeofday(&tp, &tzp);

        last = tp.tv_usec;
        for (i=0; i< 100000; i++) {
                gettimeofday(&tp, &tzp);
                diff = tp.tv_usec - last;
                if (diff < 0) diff += USECS;
                if (diff > MINSTEP) break;
                last = tp.tv_usec;
                "I: ees: precision calculation given %duS after %d loop%s",
                diff, i, (i==1) ? "" : "s");

        if (i == 0)             return -20 /* assume 1uS */;
        if (i >= MAXLOOPS)   return EESPRECISION /* Lies ! */;
        for (i=0, val=USECS; val > 0; i--, val /= 2) if (diff > val) return i;
        return EESPRECISION /* Lies ! */;


Subject: Re: network time server recommendations?
Date: 27 Sep 93 18:35:02 GMT
Organization: Boston College

In article <>, writes:

> I'm interested in dedicated Network Time Servers, specifically their relative
> price/performance/reliability information.  I've seen an ad for Bancomm's
> Tymserve(tm) box in a recent trade journal, but have nothing to which to
> compare it.  Any help would be appreciated.  Since this question is likely to
> have been asked many times in the past, a reference to when it was last
> discussed would give me a place to start.

I guess I spoke/wrote too quickly.  I just found a list of timecode receivers
currently available on the market in CLOCK.TXT  Any experiences and/or
recommendations would still be welcomed.

Boston College Computer Center                    Internet:
140 Commonwealth Ave.                               Bitnet: armand@bcvms
Chestnut Hill, MA 02167

From: Mi...@UDEL.EDU
Date: 1 Oct 93 18:33:07 GMT


See the file clock.txt in the pub/ntp/doc directory on for
a comprehensive list of public primary and secondary servers, along with
advice on how to set up a local NTP subnet. Advice can also be found in
the doc directory of the xntp3.3.tar.Z distribution in the pub/ntp
directory on louie.


From: (Denton Gentry)
Subject: Re: tickadj -A on Solaris
Date: 4 Oct 93 17:55:02 GMT
Organization: Sun Microsystems Computer Corp

In article, (Ian Dickinson) writes:

>That's the 'problem' - Solaris 2.2 has been fixed to work correctly.
>You only need to call tickadj with the -s flag to turn off dosynctodr,
>tickadj doesn't exist anymore and tick is correct.

  You can also turn off dosynctodr in the /etc/system file, by putting in a line as follows:
set dosynctodr=0
  (Just on general principles, to avoid mucking around in a running kernel with tickadj -s).


From: (Peter Whisker)
Subject: Re: NTP for DOS?  (We've done everything else...)
Date: 12 Oct 93 11:02:03 GMT
Organization: Logica DCG Ltd.

In article <> (Tom Fitzgerald) writes:
>From: (Tom Fitzgerald)
>Subject: NTP for DOS?  (We've done everything else...)
>Date: Tue, 5 Oct 1993 03:22:29 GMT
>Macs and Novell servers are covered - but how about DOS clients?  Anyone
>have NTP client code for them?  Even a simple boot-time ntpdate equivalent
>would be welcome.
>This should probably be in the FAQ too, if someone has an answer to it.

Perhaps this might help ...

;**             USING PDCLKSET TO SET THE PC SOFTWARE CLOCK             **
;**                                                                     **
;** PDCLKSET sets the time and date of the PC clock using a TIME server.**
;** To do so, the following information is required:                    **
;**                                                                     **
;** - This clients unique IP number.                                    **
;** - The IP number of an UDP/IP time server (most Unix systems).       **
;** - The time zone offset from UTC (GMT) at this place.                **
;** - If daylight saving (summer) time is used, which algorithm to use. **
;**                                                                     **
;** All the above info can be supplied as arguments to PDCLKSET. If any **
;** of the first three are missing, it will send a BOOTP request to try **
;** to find the missing info. If you are not using BOOTP you probably   **
;** must use gateway and mask arguments too. Except for client IP number**
;** and network mask, arguments to PDCLKSET override BOOTP info.        **
;** Using a BOOTP server is highly recommended, freeware code exists    **
;** for Unix systems and MSDOS PCs.                                     **
;**                                                                     **
;** BOOTP can not supply which dst algorithm to use; also, zone offset  **
;** can't always be trusted. So, in practice, zone offset and dst algo- **
;** rithm (if applicable) are required arguments. On the other hand,    **
;** these parameters will stay the same all around the year, no need to **
;** change the setup.                                                   **
;**                                                                     **
;** If PDCLKSET finds more than one time server (sum of arguments and   **
;** BOOTP fields) and the first one does not answer, it will try the    **
;** other servers. The same applies for gateways.                       **
;**                                                                     **
;** It is very hard to get accurate info on all the dst algorithms used **
;** all over the world, so the one you choose, you should test out. Use **
;** the alter argument to add or subtract time and days, and check that **
;** the dst switch occurs correctly. When using the alter argument, the **
;** date and time is displayed as usual, but the PC clock is not set.   **
;** If you find any errors, mail me the correct info to my mail address **
;** below. If you want to, you can customize your own dst algorithm,    **
;** see detailed info below.                                            **
;**                                                                     **
;** PDCLKSET talks to the network card via a packet driver. If you have **
;** more than one packet driver, it will use the first one (lowest      **
;** packet interrupt number) unless you use the pktintno argument.      **
;** I have only tested PDCLKSET with Ethernet or Ethernet simulating    **
;** packet drivers. I have one report that it works with S&K FDDI   **
;** interfaces, if so it should work for token ring too, but I've got   **
;** no confirmation on that.                                            **
;**                                                                     **
;** Running through remote bridges or slip links may require longer     **
;** than default timeouts. Add the number of extra seconds you need     **
;** with the argument LongerTimeout= time.                              **
;**                                                                     **
;** If you want to omit the "End of pdclkset..." msg, add Flag=128    **
;**                                                                     **
;** In AUTOEXEC.BAT you should first load the packet driver, then call  **
;** PDCLKSET. It is very small (13 kbyte) and executes fast, so you will**
;** not notice any delay. PDCLKSET is not memory resident and does not  **
;** use any CONFIG.SYS devices, so no memory is wasted. Use TERMIN.COM  **
;** if you want to unload the packet driver. See call syntax below.     **
;** Note: If you always log into a Novell server after a boot, you      **
;** don't need this program, the PC clock will be set from the server.  **
;** However, if you are the supervisor, use PDCLKSET+SRVTIME to set it  **
;** (available at     **
;**                                                                     **
;**             USING PDCLKSET TO SET A TIMEZONE VARIABLE               **
;**                                                                     **
;** PDCLKSET can also assign the proper normal or dls timezone name to  **
;** an environment variable (TZ is used by most systems). Argument      **
;** "Zone= #" will assign numeric zones to TZ (like TZ=+0100). If you **
;** want anything else, use the alternative syntax, e.g.                **
;** "Zone= tzone=MET,METDST" will set TZONE=MET or METDST.            **
;**                                                                     **
;**             SYNTAX AND EXAMPLES FOR TIMESETTING                     **
;**                                                                     **
;**   (time is [- | +] [<hours>h] [<minutes>m] [<seconds>[s]] )       **
;**                                                                     **
;** pdclkset                    (displays a usage message)      or      **
;**                                                                     **
;** pdclkset b[ootp]            (only if dst not used)  or              **
;**                                                                     **
;** pdclkset [o[ffset]=time]                                            **
;**                                                                     **
;**          [d[aylightsave]=PAC | USA | CUB | CHIL | BRZ | GBR |       **
;**                          W_EU | M_EU | E_EU | LIBY | EGY | TURK |   **
;**                          ISR | IRAN | PRC | ROK | AUS | TASM |      **
;**                          NSW | LHI | NZE |                          **
;**                          FrTime,FrWeekDay,FrDayOfYear,              **
;**                          ToTime,ToWday,ToDayOfYr,AddTime]           **
;**                                                                     **
;**          [z[onename]= # | varible=normalname,dlsname                **
;**                                                                     **
;**          [i[pnr]=n.n.n.n]  [t[imservers]=n.n.n.n[,n.n.n.n[,...]]]   **
;**                                                                     **
;**          [m[ask]=n.n.n.n  g[ateways]=n.n.n.n[,n.n.n.n[,...]]]       **
;**                                                                     **
;**          [p[ktintno]=hexnr]  [a[lter]=days,time]  [f[lags]=flagnr]  **
;**                                                                     **
;**          [l[ongertimeout]=time]                                     **
;**                                                                     **
;**                                                                     **
;** All arguments to pdclkset must be on the same line, no continuation.**
;** For arguments to BAT files, use ":" instead of "=" and ";" instead    **
;** of "," .                                                          **
;**                                                                     **
;** Valid flags for this mode:                                          **
;**   128 = half quiet (skip the End of pdclkset line if no errors)     **
;**                                                                     **
;** Examples:                                                           **
;**                                                                     **
;** pdclkset o= -1h d=M_EU z=#   (my IP nr and timeserver(s) from BOOTP)**
;**                                                                     **
;** pdclkset offs=6h dst=USA zonename= tz=CST,CDT  (sets TZ=CST or CDT) **
;**                                                                     **
;** pdclkset o=8h  d=PAC  ip=  ts=  (BOOTP not used)**
;**                                                                     **
;** pdclkset o=-9h30m t= i= g= m=     **
;**                                                                     **
;**                                                                     **
;** Part of an AUTOEXEC.BAT file may look like this:                    **
;**                                                                     **
;**     \net\wd8003e -w 0x7d 3 0x280 0xd000     (install packet driver) **
;**     \net\winpkt 0x7c 0x7d                   (install winpkt driver) **
;**     \net\pdclkset o=-1h d=M_EU z=#          (set PC clock and TZ)   **
;**                                                                     **
;** If you don't want to keep the paket drivers in memory, add the      **
;** following line:                                                     **
;**                                                                     **
;**     \net\termin 0x7c                        (remove packet drivers) **
;**                                                                     **
;** If you just need timesetting, use pdclksml instead of pdclkset.     **
;**                                                                     **
;**             WHERE TO GET IT FROM                                    **
;**                                                                     **
;** Current version of PDCLKSET can be obtained by anonymous FTP from   **
;** or from                **
;** or from Novell **
;** server LUSTORFS/ARC:PUB\NETWORK\PDCLKSET\PDCLKxxx.ZIP               **
;** (Netware access only in Lund and around).                           **
;** Major releases will also be available on and **
;** its mirror archive sites in the msdos.pktdrvr directory.            **
;**                                                                     **
;*                                                                       *
;* Jan Engvald, Lund University Computing Center                         *
;* ____________________________________________________________________  *
;*   Address: Box 783               E-mail:    *
;*            S-220 07 LUND    Earn/Bitnet: xjeldc@seldc52               *
;*            SWEDEN          (Span/Hepnet: Sweden::Gemini::xjeldc)      *
;*    Office: Soelvegatan 18        VAXPSI: psi%2403732202020::xjeldc    *
;* Telephone: +46 46 107458         (X.400: C=se; A=""; P=Sunet; O=lu;         *
;*   Telefax: +46 46 138225                 OU=ldc; S=Engvald; G=Jan)    *
;*     Telex: 33533 LUNIVER S                                            *
;*                                                                       *

Peter Whisker
From: Mi...@UDEL.EDU
Subject: Re:  Looking for NTP for SVR4
Date: 12 Oct 93 01:51:44 GMT


Yes, the latest xntp3.3 has a SVR4 port. There is quite a bit of
information in the various README and man pages scattered through the
directories. Most directories have READMEs describing the contents.
The build process is mostly automated, unless you have an oddball
Unix port. For even more information, see the pub/ntp/doc directory


From: (Barry Schaede)
Subject: Re: Looking for NTP for SVR4
Date: 12 Oct 93 19:04:10 GMT
Organization: U. of Az. Center for Comp. & Info. Tech.

In article <9310112134.AA07630@fender>, a...@DEVNULL.MPD.TANDEM.COM (Ashvini Nangia) says:

>tex deleted...
>        I'm also interested in using a "radio-clock" as the external
>        time source. If you have any information or tips as to where
>        I can get the hardware (who sells it in the US) that would
>        be very helpful.    

We purchased the UTS-10, which is a radio receiver with display and an
RS-232 port from Odetics.  Their address is:

        Odetics - Precision Time Division
        1515 South Manchester Avenue
        Anaheim, Ca. 92802-2907
        Phone 714-758-0400

From: (Amos Shapira)
Subject: clockdiff - measure difference in clock among UNIX machines
Date: 19 Oct 93 17:58:48 GMT
Organization: Inst. of Comp. Sci., Hebrew University, Jerusalem, Israel


Here is a small programme to measure the difference in the clocks among
machines across an Internet network.

It consists on just one file so I didn't bother to package it or anything.

It is also available for anonymous ftp on host file
/pub/network/clockdiff.c.gz (in Gzip format).

I don't know how accurate this programme is,  will appreciate any feedback.

Read the comments at the beginning for more info.


[[ It was 500 lines long, so I deleted it -- get it from FTP or send mail
to Amos -- Rick]]
From: (Rick Thomas)
Date: Fri, 22 Oct 93 17:27:03 EDT
Subject: RE -- What I've learned about sun clocks and ntp

In a previous article, (Joey Pruett) says --

%>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).

I have a couple of comments based on talking with a friend of
mine who has a Solbourne with a particularly horrible clock.

First, the formula Joey gives is appropriate for xntp version 3, only.
The units of the number reported in the drift file changed between
version 2 and version 3.  For those of us still running version 2 (or
-- horrors! -- version 1) there is a different formula.

The version 3 "drift" value is reported in part per million.  "Tick" is
parts per 10000, so the "100" in Joey's formula comes from
        1000000/10000 = 100

(As a side note, the "parts-per-million" is really "parts per 2^20", so
the "real" value of the denominator should be 104.8576, but who's counting?)

The version 1 and 2 "drift" value is in parts per 4096.  "Tick" is still
parts per 10,000, so we use 4096/10000 = 0.4096 as the denominator in
these cases.

Hence, for ntp (v1) and xntp (v2), the correct "tick" value for use in
the "tickadj -t <tick>" is 10000 + int (drift/0.4096)

Second, you can tell if the drift value has stabilized by looking in
your /var/adm/messages file (or wherever else you have configured the
syslog deamon to put messages from xntpd) for hourly historical drift
values.  This advice is independent of which version of the software
you are using.


From: (John A. Dundas III)
Date: Sun, 14 Nov 1993 13:25:13 -0800
Subject: Macintosh NTP Client

Could you please add the following to the NTP FAQ?  Thanks...John Dundas

Another NTP client for the Macintosh is 'NTP Client' by John Dundas.  This
shareware is available at a number of archives; use archie to search for
'macntp'.  This software features the ability to use NTP over either UDP/IP
or AppleTalk.  (Special servers are required for AppleTalk.  The author
currently has servers implemented for Macintosh, VAX/VMS (AppleTalk for VMS),
and A/UX.  Contact the author for more details at

From: (Torsten Duwe)
Subject: Re: xntpd 3.3a on Linux: stuck?
Keywords: tickadj, Linux, PC
Date: 24 Nov 93 13:35:34 GMT
Organization: CSD., University of Erlangen

>>>>> "HPA" == H Peter Anvin N9ITP <> writes:

    HPA> However, when /etc/ntp.drift reached the value -100.0000 is got
    HPA> firmly stuck, [...]

Yes, +-100 ppm is the limit, as you might know. One of the boxes I run Linux
on (a 486dx33, OPTI cs) gets as bad as -330 ppm. How do I know ? tick
adjustment - see below...

    HPA> tickadj just gives me "The value of tick is silly", this is after
    HPA> making a link from /vmunix to /usr/src/linux/zBoot/zSystem.

Right - this would be the way to do old-fashioned, ugly /dev/kmem-ing in
Linux, but even if you don't get errors it still wouldn't work. tick gets
reset to 10000 every tick :-(. Looks like you're another customer for the
hwtickadj for PCs I am (about) to write. It is going to do outb()s to adjust
the divider value in the timer chip. Temporary workaround: fix the divider in
linux/include/linux/timex.h (line 67:CLOCK_TICK_RATE) in steps of 100 (the
resolution that gets fed into the divider). +100 compensates for approx.
-83.8 ppm drift. After recompiling and booting the new kernel you should be

Hope that helps

 Torsten Duwe | /etc/init: respawn failed.
 Friedrich-Alexander-Universitdt Erlangen-N|rnberg | fork license for
 Informatik IV (Betriebssyteme, verteilte Systeme) | uid 0 has expired.

From: (Kim H|glund)
Subject: Re: HP problem with ntp
Date: 30 Nov 93 08:45:57 GMT
Organization: Department of Computer Science, U of Copenhagen (Darrin P Cardani) writes:

>I have a handful of hp's running hp_ux90 which are losing sync like crazy
>for some reason. We have several hp's running hp_ux90, which are running
>fine. For some reason these few machines (all on different subnets, all
>able to reach their broadcasters) are losing sync several times a day.
>Has anyone heard of this, and does anyone know of a solution? They're logging
>several thousand messages a day. Any help would be greatly appreciated.

Several people (including myself) have experienced this with xntpd v3.3.
For the time being I believe the solution is to use xntpd version 3.1.

From: (Scott Reynolds)
Subject: Re: HP problem with ntp
Date: 30 Nov 93 19:36:46 GMT
Organization: Plexus Corp. -- Neenah, Wisconsin

In <> (Kim H|glund) writes:

> (Darrin P Cardani) writes:
>>I have a handful of hp's running hp_ux90 which are losing sync like crazy
>>for some reason. [...]
>Several people (including myself) have experienced this with xntpd v3.3.
>For the time being I believe the solution is to use xntpd version 3.1.

I have been running xntpd-3.3b for the last week with no ill effects on both
the 400 series HP-UX 9.0 and 700 series HP-UX 9.01 platforms.  You might
consider giving this a try.  Don't forget to install (and run!) adjtimed.
Note that the config script will understand the OS as v8, not v9.
Scott Reynolds
Assistant System Adminstrator
Technology Group, Inc.

From: (Philip Gladstone)
Subject: Re: request for example kernel PLLs
Date: 12 Dec 93 23:20:50 GMT
Organization: Citicorp

Duane Voth ( wrote:

: So, can anyone send me an example of a proper adjtime() (or ntp_adjtime())
: system call?  Maybe even something with a PLL attached?  We are running a
: USL SVR4 kernel here.  Please, no actual copyrighted code.

You might like to look at the Linux kernel that includes a PLL clock
implementation that seems to work. Look at your local Linux archive
for sources or try

Philip Gladstone - Consultant
Citicorp Global Information Network
I don't speak for Citicorp. I presume that somebody else does!

From: (Duane Voth)
Subject: Re: ntp black box?
Date: 10 Dec 93 22:56:13 GMT
Organization: TANDEM Computers, Inc (MPD)

In article <>, (Brad Huntting) writes:

> I'm looking for a dedicated "plug-n-play" stratum 1 ntp server to
> attach to ethernet or fiddi.

> Does such a beast exist?

Yes.  I know of two from one company, there should be a couple more companies
offering these things too...

The Bancomm division of DATUM INC. sells:

        a) Tymserve 2000 LAN Time Server         $ 8,500
        b) BC700LAN GPS Network Time Server      $12,700

You can get Global Positioning System receivers for both (prices quoted
include GPS) to make it truely worthy of a stratum 1 server: accuracies
quoted are less than +/- 2 usecs of UTC.  If you have an IRIG time code
source near by you can skip the GPS option and knock off $2k-$4k.  The
BC700 appears to free-run at 0.5ppm with an oven option to go to 0.002ppm!
(thats right 2x10e-9!)  Can't seem to find a ppm spec on the Tymserve -
it may not free-run at all.

Bancomm is in San Jose, CA   1-800-348-0648

I have not used one of these yet but hope to soon.

Date: Wed, 22 Dec 93 16:58:34 EST
From: (Rick Thomas)
Subject: Re:  faster scrolling on raw SPARCstation screen

Here is the NVRAM patch that speeds up scrolling on Sun4c bare consoles
by copying the FORTH console driver into (fast) RAM, instead of allowing
it to execute out of (slow) ROM.  It incidentally fixes (most) of the
dropped interrupts that cause "last adjustment didn't complete".

Heed the warnings!  Do NOT use this with early ROM revisions!



PS -- don't despair if you have a ROM rev below 2.2.  Latest rev ROMs
can be purchased from SUN for a cost of about US$50.

> Date: Sun, 2 Jan 1994 21:47:41 -0800
> From: Nick Sayer <>

> I didn't see any mention of this...

> You can make a vast improvement both in the clock accuracy and the speed
> of the ROM console (at the cost of 200K of RAM or so) with this (works
> only with boot ROM rev 2.0 or higher, which should be available on
> any sparc apart from the sun4_ kernel architecture. I just got an
> upgrade for my SS1+ that bumped it up from 1.mumble to 2.9!):

::::::::::::::: cut here and make an executable file ::::::::::::::::::::::
#! /bin/sh

echo 'Be VERY careful -- install this ONLY on machines with PROM revision 2.2'
echo 'or higher.  This will cause very unpeasant hangs in lower revs.  "Very'
echo 'unpleasant" means "refuses to boot and may require a service call to'
echo 'get it fixed."  On PROM revs equal to or later than 2.2, you can use'
echo 'the "<L1>-N" sequence to set all EEPROM values back to factory default.'
echo '(Hold down the <L1> key and the "N" key while the power is turned on.)'
echo ''
echo 'got that?'
echo 'Answer "yes" to continue.'

read answer
if [ "$answer" != "yes" ]
exit 1

eeprom 'nvramrc=probe-all install-console
: cache-page dup pgmap@ cacheable swap pgmap! ;
up@ cache-page
here origin do i cache-page pagesize +loop

eeprom 'use-nvramrc?=true'

exit 0
::::::::::::::: cut here and make an executable file ::::::::::::::::::::::

From: (Ken Stone)
Subject: Re: adjtimed dies on HP-UX 9.0 (s800)
Date: 23 Dec 93 21:29:30 GMT
Organization: Hewlett Packard, San Diego Division

In article <> (John O'Shaughnessy) writes:
>I've installed xntp 3.1 on an HP 9000-845 running HP-UX 9.0.
>It builds just fine, and when launched manually, runs just fine.
>I've included the following in the /etc/netbsdsrc startup file:

>  /usr/local/etc/adjtimed -r
>  /usr/local/etc/xntpd

>Both startup OK, but adjtimed dies immediately, with the following line
>in syslog:

>  Dec 22 18:06:16 a00308 adjtimed[188]: read message: Identifier removed

Geez ... maybe this oughta go in the FAQ ?

In a stock 9.X s700/s800 systems, there is a bug in DIAGMON that causes
it to trash all message queues when it starts up.  The possible solutions
range as follows ....

    a. Get the DIAGMON patch from the response center ....

    b. Start adjtimed/xntpd shortly after DIAGMON (ie not in netbsdrc)

    c. Just don't run DIAGMON (ie comment it out in /etc/rc)

And life will be much better ...

  -- Ken


From: Mi...@UDEL.EDU
Subject: Culturally correct chime
Date: 1 Jan 94 21:37:43 GMT


A problem previously mentioned and often casually ignored has come to
the point I must vigorously protest; and, I suspect my problem may
be generic to a bunch of other places. It has to do with the use of
private, unannounced server resources. I have several private time
servers here used for experiment and local service, one of which is
being hounded by over 50 unapproved rascals, 12 of which from the
same net(!). That breaks several of the culturally correct expectations
spoused in the file clock.txt frequently announced to this list. I'd like
these rascals to go away, especially as this host is used for all kinds
of experiments and sometimes tells awful time. I'd rather not be more
specific; but, if anybody is punching net 128.4 clocks other than
public primary servers ( and
( and secondary server (, I`d
sure like them to contact me first.

On a related matter, cultural correctness calls for no more than two
clients from any net to gang up on any single primary server. On rackety
I see as many as 19 clients from the same net! It may be time, as I
had to do in the fuzzballs, to put code in the NTP daemon that enforces
this. It's a terrible idea in the first place, since it ...

read more »