In an effort to get better resolution and to get CLOCK_MONOTONIC to
better track CLOCK_REALTIME, I would like to do the following:
Define CLOCK_MONOTONIC to be the same as
(gettimeofday() + wall_to_monotonic).
Wall_to_monotonic would be defined at boot time as -(gettimeofday())
at that time and would be updated each time the wall clock is set.
Currently this happens in only three places in the kernel, two in the
wall clock update routine (a leap second can be added or subtracted)
and in settimeofday(). The update of wall_to_monotonic must be done
under the xtime lock, as should the add to convert gettimeofday() to
CLOCK_MONOTONIC.
What this gets us is:
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.
Comments?
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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().
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
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
--
"A narcissist is someone better looking than you are."
- Gore Vidal
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
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.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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).
why don't you simply use asm("rdtsc") ?
(ok, you should make sure that you always ask the same processor and
stuff, but using the built in TSC seems to do everything you want...)
--
CU, / Friedrich-Alexander University Erlangen, Germany
Martin Waitz // [Tali on IRCnet] [tali.home.pages.de] _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet //
tippfehler und ist auch ohne grossbuchstaben gueltig. /
-
Wer bereit ist, grundlegende Freiheiten aufzugeben, um sich
kurzfristige Sicherheit zu verschaffen, der hat weder Freiheit
noch Sicherheit verdient. Benjamin Franklin (1706 - 1790)
Martin Waitz 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).
>
>
> why don't you simply use asm("rdtsc") ?
> (ok, you should make sure that you always ask the same processor and
> stuff, but using the built in TSC seems to do everything you want...)
>
>
I don't really understand how :(
I want a tick on CLOCK_MONOTONIC to be the same size as a tick on
gettimeofday() over the life of the system. I.e. lock step. The only
difference is that CLOCK_MONOTONIC can not be set, so, if we use the
above, wall_to_monotonic must be adjusted when the gettimeofday()
clock is set (but not when it is "adjusted" by NTP).
asm("rdtsc") is, first of all, only useful on x86 platforms,
CLOCK_MONOTONIC is in the POSIX clocks and timers code and in all
platforms. Second, each platform has an equivalent, best guess, way
of filling in the time information below the 1/HZ level (and yes, some
x86 platforms use TSC) already in the gettimeofday() code. Except
that the system settime code is platform dependent, this solution is
platform independent.
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Fri, Mar 21, 2003 at 02:17:44PM +0100, Martin Waitz wrote:
> why don't you simply use asm("rdtsc") ?
> (ok, you should make sure that you always ask the same processor and
> stuff, but using the built in TSC seems to do everything you want...)
It does. That's the point. monotonic_clock() is intended as a
portable and consistent wrapper around such access. Otherwise, any
module that needs such access must do system specific work (TSC on x86,
cyclone on x86-x440, other stuff on S/390, etc). In addition, having
speedstep handling in one place is a good thing.
Joel
--
Life's Little Instruction Book #335
"Every so often, push your luck."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
On Fri, Mar 21, 2003 at 11:18:55AM -0800, george anzinger wrote:
> I don't really understand how :(
>
> I want a tick on CLOCK_MONOTONIC to be the same size as a tick on
> gettimeofday() over the life of the system. I.e. lock step. The only
Ok, I think we're having a terminology problem here. I wasn't
aware that "CLOCK_MONOTONIC" was a POSIX thing, I merely thought you
were speaking of a kconf define for the proposed monotonic_clock()
interface. That interface is a portable and consistent wrapper around
access to things like the TSC and the cyclone timer. Maybe it needs
renaming.
Joel
--
"But all my words come back to me
In shades of mediocrity.
Like emptiness in harmony
I need someone to comfort me."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
On Fri, Mar 21, 2003 at 12:01:13AM -0800, george anzinger wrote:
> 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
No, cycle counters do just fine.
> >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?
monotonic_clock as proposed uses a hardware clock.
Specifically, the TSC on vanilla intel, the Cyclone timer on x440, and
associated clocks on S/390 (to speak of platforms I've visited
recently). Right now, the hangcheck-timer accesses the hardware counter
directly. monotonic_clock is intended as a portable and consistent
accessor instead.
The current gettimeofday() corrects for ~1s. Even if we found a
way to correct for ~1000s or more, there would still be a race between
when the caller reads and when the correction happens. A clock that
reads a hardware counter doesn't have this problem.
If code doesn't need this accuracy, it can just use
gettimeofday().
Joel
--
"Glory is fleeting, but obscurity is forever."
- Napoleon Bonaparte
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
On Fri, 2003-03-21 at 00:01, george anzinger wrote:
> Joel Becker wrote:
> > 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?
Because to to it properly is slow. Right now gettimeofday is all done
with 32bit math. However this bounds us to ~2 seconds of counting time
before we overflow the low 32bits of the TSC on a 2GHz cpu. Rather then
slowing down gettimeofday with 64bit math to be able to handle the crazy
cases where timer interrupts are not handled for more then 2 seconds, we
propose a new interface (monotonic_clock) that provides increased
corner-case accuracy at increased cost.
thanks
-john