cvs commit: src/sys/kern
pherman at frenchfries.net
Sun Dec 5 11:11:04 PST 2004
On Sun, 5 Dec 2004, Matthew Dillon wrote:
:On an additional note -- and I suppose anything at this point is
:nitpicking -- would it be worthwhile to preserve the original
:drift? Take an extreme example with the current code with a
:machine booted at 12:00:00 when the clock adds a second every 30
:seconds compared to a reference clock:
No, because the 'drift' isn't necessarily just a drift. When you
boot a machine, for example, ntp will throw in a short-lived speed
up or slow down to get the clock synchronized, but that doesn't
necessarily mean that the clock is actually running slow or fast.
Agreed. "drift" is probably the wrong word.
The example I gave was for the case of a fast running clock that
does have drift. However, even in the example where the clock just
needs to be synchronized once and only once, the case is still the
same: the boottime isn't exactly what it says. How much is it
off? The amount that was added/subtracted to basetime. That is
what basetime is for.
I'll just add that because uptime (the w(1) uptime, that is) must
be monotonicaly increasing, the difference between boottime and
basetime *must* be preserved. Otherwise, w(1) uptime may jump back
a bit if (basetime - boottime) > 0 before settimeofday() is called.
When the time is stepped, this sort of correct has to be reset as
well. Also, ntpd expects it, and things would go haywire if it
I'm not suggesting touching basetime, just boottime.
It may seem pedantic, but it is actually an case *for* the
distiction between boottime & basetime; the reason for basetime's
existence. In essense, boottime (relative to basetime, of course)
is the mechanism to correct gd_time_seconds (be it drift correction
just one time corrected.)
More information about the Commits