Quoting Adam Borowski (kilobyte@???):

> Cool, so running ntp twice, once for the big jump, then for long-term
> stabilization, is not needed.

Yr. welcome!

> So it's better than ntpdate: on discrepanties on the order of a few
> seconds, ntpdate used slew instead of step to "gently" change the
> time; this is a bad idea if you're about to run ntpd or something that
> needs good time immediately after calling ntpdate.

The ISC NTP suite is very flexible. Most problems I see people having
are things like 'sync failed because of too big a jump', which means
someone was using its (conservative) defaults and neither looking in the
logfiles nor in the manpage.

(I'd still suggest also taking a look at OpenNTPd. I don't yet
know enough about OpenNTPd's details to answer detailed questions,
whereas ISC NTPd is extremely familiar, from work. The latter is kind
of like ISC's BIND9; not something I'm enthusiastic about, but I have a
lot of history with it.)

> SNTP _is_ adequate for single-fire adjustments. It's a compatible subset of
> proper NTP.

I do not concur, e.g., SNTP cannot handle a set of upstream time hosts,
only a single one. This is IMO a bit pathetic, and the wiser course of
action is to ignore it and use real NTP software.

> So it does what MS-Windows do, ie, cron-jobbed single-fire
> adjustments?

I'm not well briefed on all of the particulars of what any specific
implementation of SNTP does. I took a ten-minute look at some of the
basic protocol's design omissions, said to myself 'Someone has to be
joking', and went back to real NTP.

> > ISC's NTP Project reference implementation's developers are, with
> > what I hope is reluctance and a sense of resignation, in the middle
> > of developing a 'sntpd' piece, but I wouldn't touch it on a dare.
>
> Why would they do so?

Even though ISC are only a short bicycle ride from me, I am unable to
read their minds. ;->

-- 
Cheers,                         "On the Internet, no one knows you're a dog --
Rick Moen                       unless you type 'woof, woof, woof'."
rick@???                                               -- pyellman
McQ! (4x80)