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

[Bruce Evans]

On Thu, 23 Nov 2017, Devin Teske wrote:

>> On Nov 23, 2017, at 9:29 AM, Rodney W. Grimes <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
>>
>> [ Charset UTF-8 unsupported, converting... ]
>>> On Thu, Nov 23, 2017 at 7:17 AM, Rodney W. Grimes
>>> <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>>>>> Also we do provide an ntp.conf so ...
>>>>
>>>> We do, a template, all commented out, and does not work for
>>>> machines behind strong firewalls that wont allow ntp out
>>>> to the net but have internal ntp servers that are used for
>>>> such things.
>>>>
>>>> Well maybe not all commented out, I think it defaults to
>>>> some public pools.  I believe it would be missing iburst
>>>> for use with ntp -pg
>>>
>>> Does ntpdate work out of the box in such environments?  If so, how?
>>
>> ntpdate time.nist.gov
>>
>> ntpdate does not need a configureration file, just a command
>> line argument.
>>
>>
>
> At the banks we used to rely on both (in this order) ntpdate running and then ntpd running.

I still rely on this (but I use an old version of ntpd where the removal of
ntpdate is not so advanced).

I think the ntpd developers wanted to remove ntpdate long ago, and thought
that they did not so long ago, but apparently it they didn't because it is
too important for this use.  At best, ntpd would have an option that makes
it behave exactly the same as ntpdate, so removing it would just be a
spelling error.

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.

> Running ntpdate before ntpd meant that on a [re]boot, ntpdate would jump the box to the appropriate time, regardless of how far behind the clock was (think "dead cmos battery" on a system left powered-off for a long time).

Think "any hardware without an atomic local clock".  With an atomic clock,
the initial sync might take as little as 35-40 seconds because the local
clock is more accurate than the remote clock, but ntpd doesn't know that
so it takes about the same time as starting with a pre-synched clock.

The same problem happens after suspend/resume.  With PC cmos clocks, the
time granularity is 1 second.  It is possible to have an accuracy of better
than 1 second by reading and writing the clock on seconds boundaries, but
clock drift is usually seconds per day so no one bothers to do this (except
some of my versions read the clock on seconds boundaries; writing is harder).
The result is that after an immediate reboot, the PC clock always appears
to be off by up to 2 seconds from a 1 second error in reading it and a
1 second error in writing it (average only half as much).  For reboots
after a few hours, add drift of a few seconds.

The same happens for suspend/resume, even after finally fixing the i386
case in acpi.  Old pmtimer code tried harder to restore a correct time
on resume, but only tried to account for drift _before_ suspend.  acpi
on i386 was missing the restore until a year or 2 ago.  The restore was
only done for amd64 using an amd64 ifdef to break it for other arches.
This was fixed by removing the ifdef.  FreeBSD-10 still has the ifdef.

Anyway, the situation is not much better with the restore after resume
than without it.  The only good way to restore the time after suspend
is to run ntpdate in the resume script, just like it should be run at
boot time.  ntpd -q of course doesn't work, since it would take too
long to resync, or might give up if the difference is too large.

I've never seen a resume script that restores the clock (the example
one in /etc does nothing useful except for 15-20 year old pccard hardware).
Suspsend/resume doesn't work on most of my systems so I didn't write
such a script.  I just removed the -x flag that I was using to prevent
ntpd stepping the time.  All steps were supposed to be done by ntpdate
at boot time or later by the sysadmin, but that doesn't work after
suspend/resume since the only good way to fix up even the small 1-2
second error is to step the clock.  -x was too broken to use for fixing
up large differences.  IIRC, it didn't understand its own corrections
and treated these as further drift, so differences of even 128 seconds
blew out to the abort point of 900 seconds.  After fixing this, small
differences just take too long to fix via slews, and differences of 900
seconds still cause aborts (since that is too large to slew and -x
prevents stepping).  But suspend/resume for just 900+ seconds without the
restore in the kernel always causes such differences.  Reboot behaves
better, even without ntpdate, since it always sets the time from the
RTC so the error is usually only a few seconds.

Without -x or any intelligence in the kernel or resume script, in the
usual case where ntpd was running before suspend, it keeps runnning after
resume and eventually syncs the time by stepping it, at least for small
differences.  Perhaps large differences are handled better because they
are obviously wrong.  The steps occur some time after resume so they do
more damage, just like similar steps after reboot without ntpdate.

ntpd -q in /etc/rc.d would probably avoid the steps later, at a cost of
increasing the boot time to 35+ seconds if not days.

> Meanwhile, running ntpd *without* the sync-on-start feature meant we could bounce the ntpd service as necessary and it would always adhere to the limit we set on it -- one hour to prevent syncing on systems which had been manually adjusted by greater than an hour for some one-off instances.

I thought that everyone used ntpdate, but /etc/defaults/rc.conf has had
ntpdate_enable="NO" since at least FreeBSD-5.  There is no trace of ntpd -q
in the boot scripts, so apparently almost everyone gets a slow sync followed
by a step (or slower sync with no step) instead of the slow boot that would
be given by ntpd -q.

I also use ntpdate to help manually sync ntpd much faster than it can do
itself (but in more than 35 seconds).  The method is to stop ntpd and
observe the drift using ntpdate -q.  Before obvserving the drift, set the
drift in the driftfile to 0 and start and stop ntpd again to kill the
current drift adjustements.  Then set the drift in the drift file for the
current temperature to within 1 ppm.  Then start and stop ntpd to apply
the new drift adjusments.  Then set the time using ntpdate -b.  Then run
ntpd normally.

I just tested the normal misbehaviour for booting when ntpdate is not
configured:
- without -q for ntpd, the boot time was fast but the initial offset (after
   rebooting with an offset of a few microseconds) was 769 milliseconds.
   ntpd reduced this by stepping by -769 ms after 38 seconds.
- with -q for ntpd, ntpd hung for 39 seconds before applying a step of
   -359 ms and then exiting.  At least old versions of rc.d don't really
   support -q, so this leaves no ntpd running and even starting it manually
   using its script won't work since the script uses -q from the defaults
   again.

So it seems that a delay of only 35-40 seconds is normal.  ntpd doesn't
really sync, but steps the clock to get close.

The delay doesn't depend much on the driftfile.  My driftfile says 1+ ppm.
Changing this to 0 or 40 or removing the driftfile makes little difference
for the non-boot test of restarting ntpd with -q.

Even ntpd -q that "synced" in 1 second wouldn't be equivalent to ntpdate,
since it doesn't have ntpdate's options.  There are many of these, but I
only use -b and -q.  ntpd has debugging options like -q, but these are
more complicated and perhaps not available during startup.

Bruce