Chris Friesen wrote:
> Joel Becker wrote:
>
>> The issue for CLOCK_MONOTONIC isn't one of resolution. The
>> issue is one of accuracy. If the monotonic clock is ever allowed to
>> have an offset or a fudge factor, it is broken. Asking the monotonic
>> clock for time must always, without fail, return the exact, accurate
>> time since boot (or whatever sentinal time) in the the units monotonic
>> clock is using.
>
>
> I thought that strictly speaking monotonic just meant that it never went
> backwards.
That is implied by the name. What the standard says is that it is a
clock that is not settable and that its units are seconds and
nanoseconds. The standard does not say anything about returning the
same time (which, of course is legal and possible given that the
standard allows the resolution to be as large as 20 ms).
What I am trying to call attention to is that, if we don't base the
clock on the NTP corrected time, the notion of a second used by
CLOCK_MONOTONIC will not be the same as that used by CLOCK_REALTIME.
I think this is a bad thing...
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:35 EST