On Sat, Aug 13, 2016 at 10:37:36AM -0700, Rick Moen wrote:
> Please don't run ntpdate.
>
> ntpdate is deprecated upstream (ISC) and will soon get dropped entirely.
> It would be an excellent idea to get used to this.

Thanks for the info. I didn't notice as I've been using rdate -n (because
it was available on some tiny devices and got stuck into my finger memory).

> The default window is not hours but rather 1000 seconds. _But_ there is
> an override, the '-g' switch to ntpd. Thus: 'ntpd -q -g' Quoting the
> manpage:
>

>        -g     Normally, ntpd exits with a message to the system log if the
>               offset exceeds the panic threshold, which is 1000 s by default.
>               This option allows the time to be set to any value without
>               restriction; however, this can happen only once.  If the 
>               threshold is exceeded after that, ntpd will exit with a message
>               to the system log.  This option can be used with the -q and -x
>               options.

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

>        -q     Exit the ntpd just after the first time the clock is set.  This
>               behavior mimics that of the ntpdate program, which is to be
>               retired.  The -g and -x options can be used with this option.
>               Note:  The kernel time discipline is disabled with this option.

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.

> There's also a brain-dead variant protocol called 'SNTP' (Simple Network
> Time Protocol) beloved of Microsoft (i.e., MS-Windows has no NTP
> capability as provided, only SNTP, which got added starting with Windows
> 2000)

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

> and of course the systemd developers _love_ it and are pushing it
> heavily, because (it appears) they're idiot MS-Windows users and don't
> understand technology.

So it does what MS-Windows do, ie, cron-jobbed single-fire adjustments? Not
good, that works only if your clock is reliable but only needed setting once
-- but can't cope with clocks running fast or slow, or (more likely) being
erratic.

> 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? A full-blown NTP server can serve SNTP queries
already.


Meow!
--
An imaginary friend squared is a real enemy.