Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Edgar Toernig
On Thu, 21 Apr 2005, Chris Friesen wrote: > > Does mainline have a high precision monotonic wallclock that is not > affected by time-of-day changes? Something like "nano/mico seconds > since boot"? On newer kernels with the posix timers (I think 2.6 - not sure though) there's clock_gettime(CLOC

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Linus Torvalds
On Thu, 21 Apr 2005, Chris Friesen wrote: > > Does mainline have a high precision monotonic wallclock that is not > affected by time-of-day changes? Something like "nano/mico seconds > since boot"? High precision? No. We do have "jiffies since boot". We don't actually expose it anywhere, alt

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Chris Friesen
Linus Torvalds wrote: If you calculate the expected timeout from the time-of-day in the caller, your drift not only goes away, but you'll actually be able to handle things like "oops, the machine is under load so I missed an event". Does mainline have a high precision monotonic wallclock that is n

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Steven Rostedt
On Thu, 2005-04-21 at 07:58 -0700, Linus Torvalds wrote: > > On Thu, 21 Apr 2005, Steven Rostedt wrote: > > > > Thanks, I forgot about the guarantee of "at least" the time requested. > > I took this on because I noticed this in a driver I wrote. With the user > > passing in a timeval for a period

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Linus Torvalds
On Thu, 21 Apr 2005, Steven Rostedt wrote: > > Thanks, I forgot about the guarantee of "at least" the time requested. > I took this on because I noticed this in a driver I wrote. With the user > passing in a timeval for a periodic condition. I noticed that this would > drift quite a bit. Your u

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Steven Rostedt
On Thu, 2005-04-21 at 09:51 +0100, Russell King wrote: [...] > The problem is that when you add a timer, you don't have any idea > which point you're going to be starting your timer at. > > This is why we always round up to the next jiffy when we convert > times to jiffies - this ensures that you

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Russell King
On Wed, Apr 20, 2005 at 11:40:16PM -0400, Steven Rostedt wrote: > Is 11 jiffies correct for 10ms? Consider the 1 jiffy case. How long does waiting one jiffy actually wait? j=01 2 +--+--+--> t A B C D If you start timing one jiffy from A

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-20 Thread Steven Rostedt
On Wed, 2005-04-20 at 22:58 -0400, Steven Rostedt wrote: > I looked into the problem that jdavis had and found that the conversion > of the timeval_to_jiffies was off by one. > > To convert tv.tv_sec = 0, tv.tv_usec = 1 to jiffies, you come up > with an answer of 11 (assuming 1000 HZ). >

[PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-20 Thread Steven Rostedt
I looked into the problem that jdavis had and found that the conversion of the timeval_to_jiffies was off by one. To convert tv.tv_sec = 0, tv.tv_usec = 1 to jiffies, you come up with an answer of 11 (assuming 1000 HZ). Here's the patch: --- ./include/linux/jiffies.h.orig 2005-04-20