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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
