🚀 go-pugleaf

In article <1992Nov10.081846.11087@csus.edu> eps@cs.sfsu.edu writes:

>standalone "home" machine), you'll need to hook it to the
>network temporarily so it can "learn" what its natural
>tendency is.  (If NeXT is shipping systems with software
>preinstalled, why don't they do this as part of burn-in???
>Or does it change as the hardware ages?)

This is a rather interesting suggestion; to just have [x]ntpd apply
corrections based on /etc/ntp.drift rather than attempting to
synchronize to a clock reference.  I can't say off the top of my head
if it will actually work this way or not... interesting.

In any case, it takes 24 hours or more to really compute an accurate
drift-rate sample that I'd leave in the file.  It is not clear that
its possible during manufacturing to compute this offset; better to
spend an extra $5 or $10 to buy a higher quality crystal, put trimmer
cap on the crystal and adjust it with a frequency counter.

Further, I believe that the drift rate would be OK for moderate
duration time-server outages, but there is a noticable difference in
the computed drift rate which is corrolated with the temperature in
the room.  This is to be expected, as the quartz crystal on the CPU
will vary slightly in frequencey based on the temperature.  At on
time, when I was doing active development on ntpd, I calibrated the
drift rate to the room temperature; it lagged by a few hours, but you
could tell how warm it was in my office by looking at the drift rate.

For xntpd, the /etc/ntp.drift file is in units of parts-per-million;
ntpd uses as somewhat more wierd unit size.  If you are contemplating
doing any serious timekeeping, I recommend that you trash the older
NeXT supplied stuff (ntp, ntpd, ntpdc) that Mike Petry and myself did
here at the University of Maryland and get `xntpd' instead; that's
what I use.  Look on LOUIE.UDEL.EDU in /pub/ntp.  It doesn't do
netinfo, so its much easier to configure by just editing the
/etc/ntp.conf file.

louie