Messages in this thread | | | Date | Thu, 21 Apr 2005 07:58:42 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)] |
| |
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 doing things wrong. If he wants a non-drifting clock, he should look at _realtime_ and then always re-calculate the "how long do I want to sleep" from that. Because even if the kernel was able to do all offsets with nanosecond precision and wake you up _exactly_, you'd still be drifting because of the time spent in between calls (and scheduling events etc).
> I guess I need to write my own timeval_to_jiffies > conversion so that i remove the added jiffy. For this case, I actually > want a true rounded value to the closest jiffy.
No, if you're looking at reliable wall-clock time, you really need to use wall-clock, not successive time offsets. The time offsets will always drift: you can make the drift small enough that your particular application doesn't happen to care (or, quite often - make it drift in a _direction_ you don't happen to care about), but it's still wrong.
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".
Yes, it gets slightly more complicated (and a _lot_ more complicated if your app needs to do something special for the missed case, like dropping data and re-syncing, which is common in things like video or sound streaming), but the fact is, it's just the right thing to do.
Linus - 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/
| |