svn commit: r326095 - head/usr.sbin/bsdinstall/scripts

[Ian Lepore]

On Fri, 2017-11-24 at 22:25 +1100, Bruce Evans wrote:
> On Thu, 23 Nov 2017, Devin Teske wrote:
> [...]
> 
> ntpdate's man page claims this, but is wrong AFAIK.  It says that the
> functionality of ntpdate is now available in ntpd(8) using -q.  However
> ntpdate -q is far from having equivalent functionality.  According to both
> testing of the old version and its current man page, it does the same slow
> syncing as normal ntpd startup, and just exits after this and doesn't
> daemonize while doing this.  With the old version, this step takes 35-40
> seconds starting with the time already synced to withing a few microseconds
> (by a previous invocation of ntpd), while ntpdate syncs (perhaps not so
> well) with a server half the world away in about 1 second.
> 

Ahh, the good ol' days, when ntpdate was fast by default.  Not
anymore...

unicorn# time ntpdate ntp.hippie.lan
24 Nov 15:21:31 ntpdate[734]: adjust time server [...] offset -0.000123 sec
0.013u 0.006s 0:06.13 0.1%      192+420k 0+0io 0pf+0w

If you want the fast old sub-second behavior these days, you have to
add -p1.  Or, better yet, use sntp -r <server>.

I'm not sure where you're coming up with numbers like "35 seconds" for
ntpd to initially step the clock.  The version we're currently
distributing in base takes the same 6-7 seconds as ntpdate (assuming
you've used 'iburst' in ntp.conf).  That's true in the normal startup
case, or when doing ntpd -qG to mimic ntpdate.

If there is an ntpd.drift file, ntpd is essentially sync'd as soon as
it steps.  If there is not, it does a clock step, then does 300 seconds
of frequency training during which the clock can drift pretty far off-
time.  It used to be possible to shorten the frequency training
interval with the 'tinker stepout' command, but the ntpd folks
decoupled that (always inapproriately overloaded) behavior between
stepout interval and training interval.  There is no longer any way to
control the training interval at all, which IMO is a serious regression
in ntpd (albeit noticed primarily by those of us who DO have an atomic
clock and get a microsecond-accurate measurement of frequency drift in
just 2 seconds).

-- Ian