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
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,
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
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
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
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
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
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,
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 will
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 user is
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 periodic
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
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, although
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
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).
>
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
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
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).
OK,
18 matches
Mail list logo
