cvs commit: src/sys/kern

Paul Herman pherman at
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
   weren't reset.
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 mailing list