🚀 go-pugleaf

Apologies to comp.protocols.time.ntp readers if this problem is either
(a) obvious or (b) boring.

Executive summary: how do I synchronise a network with the Internet
servers if I only have a demand-dial link, not a permanently connected one?

We run a small network of UNIX boxes, mainly running things like SunOs V4,
in which we use xntp V3.3 to keep a decent local idea of time for the
purposes of logging events and doing things like "make".

The structure of the network's ntp subnet is straightforward: every machine
is running xntpd.  One machine (yankee, a Sun-3) has "the clock" (its xntpd
synchronises with 127.127.1.10) and the rest synchronise to it.  This
met our first set of objectives (time-like behaviour of the local clocks)
fairly easily.  Of course, the machines don't know whether the time they hold
in common is correct in any sense, but they do end up closely synchronised.

Recently, we got a dial-up connection to the Internet, and it occurred to me
that it would be useful to make use of the net time servers to get our
internal network running on "real" time as well as just being internally
consistent.  Our IP supplier runs a stratum 2 service, so we don't even have
to go far afield to get "good enough" time for our purposes.  We are running
the dialup service off the same Sun-3 that our ntp subnet synchronises off,
so it seemed reasonable to try and do the synchronisation of our net by
running ntpdate each time we connect.  This would, I thought, slew the
local clock on yankee and the rest of the network would follow. (Obviously,
I didn't want to tell yankee's xntpd about the internet time servers because
it would end up prodding them rather often to find out what the time is,
and the implied local telephone calls are not free round here.  Not to mention
that there may be a 50-second asymmetric delay for the ntp packets because
of dialling the phone.)

Unfortunately, ntpdate won't set the clock on yankee if it notices that
the ntp port is in use (xntpd is running).  I can't stop the xntpd on
yankee or the rest of my network won't be able to synchronise with it.

Next, I tried running ntpdate in debug mode, which tells me what adjustment
it would like to make.  I tried to apply this adjustment using "date -a"
to slew the clock slowly round to the new value, but I get some "adjustment
didn't complete" messages from xntpd, presumably because, even though it is
taking its time from the local clock on yankee, it is also continuously
"correcting" that local time (by zero-size adjustments) to correct for the
(zero) drift it believes it has (!)

Next, I tried using "rdate" rather than "ntpdate" to get the time from the
network servers.  Although this works in the sense that yankee's time (and
therefore the network time) is now always within a couple of seconds of the
rest of the world, it is very jittery and the machines sometimes even run
backwards a half second or so.  Nasty.

I'm out of clues at this point.  Is what I am doing really such a misuse of
xntp that no-one has been through this before?  Any suggestions welcome
(except the ones about buying a permanent internet link to replace our
demand-dial one, and the ones about buying a radio clock...)

	-- Ian