🚀 go-pugleaf

In article <9104021624.aa17693@ncrcom.DaytonOH.NCR.COM>
debbieg@smokey.sandiego.NCR.COM writes:
>I hesitate to post this as I know it is not the intended use of NTP,
>however, it does seem to work really well to keep an isolated network 
>of systems sync'ed to each other.

I think your hesitation is unwarranted; I quite agree that NTP is really
very useful even without access to the Real Time (tm), and your
suggestion of using ntpdate solves (I think - haven't tried it yet) the
remaining problem I had, how to achieve reliable redundancy in a setup
like this. Also, from a number of recent submissions here, it seems
there is quite some interest in this, and I certainly hope I don't
offend anyone by sharing some of my experiences...

I was already using the principle you suggested, i.e. N "masters" with
escalating stratum for their local clocks, and I also believe I have a
good grip on the other half of the problem - the Fine Art of tweaking
the 'time1' value to achieve a) correction of difference wrt whatever
reference for real time is available and b) minimum of "steady state"
drift away from real time. If anyone's interested, I have a script that,
given an observed difference wrt real time, does the calculations and
tweaking with the aid of a couple of small programs and at(1).

Regarding a) above I don't believe it is advisable to ever manipulate
the system clock directly when xntpd is running - there are certainly
situations where an xntpd synced to the local clock will abandon it in
favor of other servers at higher strata, subsequently reversing the
change made to the local clock. It would be nice to know exactly which
these situations are, presumably relevant factors include number of
other servers, their agreement with each other vs disagreement with the
local clock, difference in stratum levels, mode (active/passive etc).
I *think* there is an alternate solution for the reliable redundancy
problem in there somewhere, but I haven't found it.

As for getting real time from some dialup service (I have local access
to one of those too), I (obviously) don't know much about the internals
of xntpd, but it seems to me that writing a clock driver for this is
less than ideal - a program that won't do DNS lookups because of the
disruption that blocking on such can cause would presumably not
appreciate waiting for a dialing sequence to complete, and inserting a
separate process or somesuch to do the dialing asynchronously will
probably cause a lot of precision to be lost. What I did was to write a
simple program to dial up the service and compute the difference wrt the
local clock, and then (if it was deemed too big) feed the difference to
the abovementioned script. This can of course all be automated, which I
have done with good results - the local clock is typically within +/-
20ms of the time reported by the dialup service, with few adjustments
required.

--Per Hedeland
per@erix.ericsson.se  or
per%erix.ericsson.se@uunet.uu.net  or
...uunet!erix.ericsson.se!per