Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!KAHALA.SOEST.HAWAII.EDU!bob
From: bob@KAHALA.SOEST.HAWAII.EDU (Bob Cunningham)
Newsgroups: comp.protocols.time.ntp
Subject: Re:  need help with ntpd
Message-ID: <9103201810.AA00909@kahala.soest.hawaii.edu>
Date: 20 Mar 91 18:10:51 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 20


Alliant machines have strange Unix kernels due to their multiprocessing
configurations (two different types of cpus; an FX machine can have
several of each).  In brief, ntpd from the ntp.3.4 distribution just
doesn't work (nor ntpd from any previous distribution).  Nor xntpd.  A
couple of years ago I tried digging in and trying to find out why, but
finally gave up after exhausting my (admittedly meager) knowledge of
the unique internels of the Alliant kernels.

The only good news I have for you is that "ntpdate" (from the xntp
distribution) apparently works just fine.  I've been running that on
our FX/80 (out of crontab, once an hour) for at least 18 months and can
testify that it does the job...though why that works whilst the daemons
don't is still very much a mystery to me.

Since Alliants under load lose a lot of clock ticks (which I'd guess
has to do with cross-processor interrupts disabling clock updates),
running "ntpdate" has been a big win for us.  It's very common to see
adjustments of the order of 1 second an hour needed to catch up with
lost ticks.