Quoting Adam Borowski (kilob...@angband.pl): > 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'." r...@linuxmafia.com -- pyellman McQ! (4x80) _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
