Erik E. Fair <fair@clock.org> writes:

>Having precisely the divorce between interval timers and Correct Time of
>Day is a good thing, for all the reasons Dennis mentioned, and more. I
>think he's had a terrific idea. This is good systems design.

<aargh>  

I'm not disagreeing.  I've even offered to help get at least part of
this into the NetBSD code-base.

I'm just pointing out that as soon as one divorces the "real time" as
measured by interval timers, and by the Correct Time of Day, that
*some* applications* really need to wait for an interval as measured
by Correct Time Of Day .  Dennis is punting on apps that want to sleep
until a specific *real time*, not for an *interval*.  You're right
that I'm objecting to that.

I'm also querying how far the implicit proposal to use "interval time"
for all or most kernel timestamps.  For e.g,.  network protocol
retransmit timers or timeouts, (a case dear to my heart), using
"interval time" is indubitably the wrong thing to do.
For inode timestamps I think it's equally clearly the wrong thing to do.

I'm also disagreeing that Dennis' proposed *impelmentation* of this
separation -- fudging boottime to maintain an invariant, to allow
comparison of Correct-TOD timestamps and  Interval-Time timestamps

	*** for the current settimeofday() epoch ***

is, indeed, neat system design.   I'd be glad to have though of it myself.
I  don't beleive it doesn't work as claimed.


Specifically, I don't see how it works when comparing times from
*different* settimeofday epochs -- i.e., comparing "interval time"
timestamps to Correct Time Of Day timestamps, acrosss more than one
settimeofday() call.  bootime can be correct for only *one*
settimeofday() epoch, and there can (and will) be Current-time-of-Day
timestamps from more than one settimeofday() call.

Erik's observation that NetBSD systems often steps clocks, due to
running on hardware with busted clock hardware or using NTP with
overloaded networks, makes that problem worse, not better. The more
frequently a clock is stepped, the more Correct-TOD timestamps will be
from the previous Correct-TOD epoch, and will therefore be
incommensurate with Interval-Time, even *with* Dennis' invariant.

For reference, an earlier message of mine has another description of
the problem case I was thinking of. I've sketched out of what might be
a *complete*, but ludicrously overweight, solution to the problem,
which may be the clearest exposition of what I think is missing.

If Dennis' proposal does indeed work in such situations, I will both
humbly apologize, and be very grateful for an explanation of how that
works.  I just don't see how it can. , without either versioning all
Correct-TOD timestamps, or adjusting all Correct-TOD timestamps from
the previous Correct-TOD era -- not just boottime -- each and every
time the clock is stepped.