lkml.org 
[lkml]   [2003]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Clock monotonic a suggestion
Joel Becker wrote:
> On Thu, Mar 20, 2003 at 04:16:13PM -0800, george anzinger wrote:
>
>>Define CLOCK_MONOTONIC to be the same as
>>(gettimeofday() + wall_to_monotonic).
>>...
>>Both clocks will tick at the same rate, even under NTP corrections.
>>The conversion is a simple (well almost simple) add.
>>Both clocks will have the same resolution.
>
>
> 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. This precludes gettimeofday().

To carry this to the absurd, it also precludes most anything other
than a GPS or WWV based clock. If we are to have any clock that is
right (to its resolution) it will require help from NTP or some other
standard (such as GPS). From this point of view we are better off
with gettimeofday() which is NTP corrected.

On might argue for a system the other way around, i.e. the monotonic
clock is NTP corrected and used to derive gettimeofday by adding an
offset. Set time would then just set this offset. I think this would
work, but haven't found a really good argument for doing it this way,
given that we already have gettimeofday set up to use NTP.

Buried in here is a need to rate correct the sub jiffie interpolation
done by gettimeofday, but that has already been pointed out by others
and should be done in any case.

> If the system is delayed (udelay() or such) by a driver or
> something for 10 seconds, then you have this (assume gettimeofday is
> in seconds for simplicity):
>
> 1 gettimeofday = 1000000000
> 2 driver delays 10s
> 3 gettimeofday = 1000000000
> 4 timer notices lag and adjusts

Uh, how is this done? At this time there IS correction for delays up
to about a second built into the gettimeofday() code. You seem to be
assuming that we can do better than this with clock monotonic. Given
the right hardware, this may even be possible, but why not correct
gettimeofday in the same way?

> 5 gettimeofday = 1000000010
>
> In the usual case, if a program calls gettimeofday() between 3
> and 4, the program gets the wrong time. For most programs, this doesn't
> matter. CLOCK_MONOTONIC is designed for those uses where it absolutely
> matters. If an application queries CLOCK_MONOTONIC at 3.5, it must
> return 1000000010, not 1000000000.
>
> Joel

--
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.082 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site