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

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