* Clock monotonic a suggestion @ 2003-03-21 0:16 george anzinger 2003-03-21 2:50 ` Joel Becker 2003-03-21 13:17 ` Martin Waitz 0 siblings, 2 replies; 11+ messages in thread From: george anzinger @ 2003-03-21 0:16 UTC (permalink / raw) To: john stultz, linux-kernel 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 george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 0:16 Clock monotonic a suggestion george anzinger @ 2003-03-21 2:50 ` Joel Becker 2003-03-21 5:53 ` Chris Friesen 2003-03-21 8:01 ` george anzinger 2003-03-21 13:17 ` Martin Waitz 1 sibling, 2 replies; 11+ messages in thread From: Joel Becker @ 2003-03-21 2:50 UTC (permalink / raw) To: george anzinger; +Cc: john stultz, linux-kernel 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: joel.becker@oracle.com Phone: (650) 506-8127 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 2:50 ` Joel Becker @ 2003-03-21 5:53 ` Chris Friesen 2003-03-21 8:10 ` george anzinger 2003-03-21 8:01 ` george anzinger 1 sibling, 1 reply; 11+ messages in thread From: Chris Friesen @ 2003-03-21 5:53 UTC (permalink / raw) To: Joel Becker; +Cc: george anzinger, john stultz, linux-kernel 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: cfriesen@nortelnetworks.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 5:53 ` Chris Friesen @ 2003-03-21 8:10 ` george anzinger 0 siblings, 0 replies; 11+ messages in thread From: george anzinger @ 2003-03-21 8:10 UTC (permalink / raw) To: Chris Friesen; +Cc: Joel Becker, john stultz, linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 2:50 ` Joel Becker 2003-03-21 5:53 ` Chris Friesen @ 2003-03-21 8:01 ` george anzinger 2003-03-21 19:43 ` Joel Becker 2003-03-21 20:53 ` john stultz 1 sibling, 2 replies; 11+ messages in thread From: george anzinger @ 2003-03-21 8:01 UTC (permalink / raw) To: Joel Becker; +Cc: john stultz, linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 8:01 ` george anzinger @ 2003-03-21 19:43 ` Joel Becker 2003-03-21 20:53 ` john stultz 1 sibling, 0 replies; 11+ messages in thread From: Joel Becker @ 2003-03-21 19:43 UTC (permalink / raw) To: george anzinger; +Cc: john stultz, linux-kernel 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: joel.becker@oracle.com Phone: (650) 506-8127 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 8:01 ` george anzinger 2003-03-21 19:43 ` Joel Becker @ 2003-03-21 20:53 ` john stultz 1 sibling, 0 replies; 11+ messages in thread From: john stultz @ 2003-03-21 20:53 UTC (permalink / raw) To: george anzinger; +Cc: Joel Becker, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1217 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 0:16 Clock monotonic a suggestion george anzinger 2003-03-21 2:50 ` Joel Becker @ 2003-03-21 13:17 ` Martin Waitz 2003-03-21 19:18 ` george anzinger 2003-03-21 19:44 ` Joel Becker 1 sibling, 2 replies; 11+ messages in thread From: Martin Waitz @ 2003-03-21 13:17 UTC (permalink / raw) To: linux-kernel 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 13:17 ` Martin Waitz @ 2003-03-21 19:18 ` george anzinger 2003-03-21 19:46 ` Joel Becker 2003-03-21 19:44 ` Joel Becker 1 sibling, 1 reply; 11+ messages in thread From: george anzinger @ 2003-03-21 19:18 UTC (permalink / raw) To: Martin Waitz; +Cc: linux-kernel 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 george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 19:18 ` george anzinger @ 2003-03-21 19:46 ` Joel Becker 0 siblings, 0 replies; 11+ messages in thread From: Joel Becker @ 2003-03-21 19:46 UTC (permalink / raw) To: george anzinger; +Cc: Martin Waitz, linux-kernel 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: joel.becker@oracle.com Phone: (650) 506-8127 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Clock monotonic a suggestion 2003-03-21 13:17 ` Martin Waitz 2003-03-21 19:18 ` george anzinger @ 2003-03-21 19:44 ` Joel Becker 1 sibling, 0 replies; 11+ messages in thread From: Joel Becker @ 2003-03-21 19:44 UTC (permalink / raw) To: linux-kernel 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: joel.becker@oracle.com Phone: (650) 506-8127 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-03-21 20:51 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-21 0:16 Clock monotonic a suggestion george anzinger 2003-03-21 2:50 ` Joel Becker 2003-03-21 5:53 ` Chris Friesen 2003-03-21 8:10 ` george anzinger 2003-03-21 8:01 ` george anzinger 2003-03-21 19:43 ` Joel Becker 2003-03-21 20:53 ` john stultz 2003-03-21 13:17 ` Martin Waitz 2003-03-21 19:18 ` george anzinger 2003-03-21 19:46 ` Joel Becker 2003-03-21 19:44 ` Joel Becker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).