>> In my case, I had an adjustment large enough that I didn't want to
>> wait for the slow one-or-two-percent slew tickadj tends to use;

Unstated but implicit is that I also didn't want a step adjustment,
such as date, rdate, or ntpdate would produce.  I probably could have
and maybe should have tolerated it.

> There's a good reason for `ntpdate' being in the xntp distribution.
> In general, you should run it before you start xntpd.

In general, agreed.

>> One thing on my it-would-be-nice-to-do-someday list is to look at
>> extending things so that the clock tick size is kept in [tiny units]
> There's a piece of code in recent xntpd distributions that's supposed
> to simulate a phase locked loop.  Supposedly after the PLL settles it
> keeps very precise time.  I haven't tried it.

Me neither - but it would require that xntpd be running, that the loop
have settled, and that you have continuous connectivity with your
source of chime.  Once an accurate clock tick size is determined,
assuming the crystal doesn't drift, you can set and forget, without
needing xntpd running or even connectivity to the net.  (One thing I've
occasionally dreamed of is a wristwatch which takes sub-minute time
adjustments as data from which to deduce the low bits of its crystal's
frequency, so that after you resync it to an accurate source (like the
radio time signal, or your NTP-synced computer), you longer need to
keep resetting it as it drifts.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu