Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261411AbVDUO5F (ORCPT ); Thu, 21 Apr 2005 10:57:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261412AbVDUO5F (ORCPT ); Thu, 21 Apr 2005 10:57:05 -0400 Received: from fire.osdl.org ([65.172.181.4]:45794 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S261411AbVDUO5A (ORCPT ); Thu, 21 Apr 2005 10:57:00 -0400 Date: Thu, 21 Apr 2005 07:58:42 -0700 (PDT) From: Linus Torvalds To: Steven Rostedt cc: Russell King , jdavis@accessline.com, Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)] In-Reply-To: <1114080708.5996.16.camel@localhost.localdomain> Message-ID: References: <1114052315.5058.13.camel@localhost.localdomain> <1114054816.5996.10.camel@localhost.localdomain> <20050421095109.A25431@flint.arm.linux.org.uk> <1114080708.5996.16.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1939 Lines: 41 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/