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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/