Date: Tue, 25 Jan 2000 23:01:38 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/13644 Message-ID: <Pine.BSF.4.21.0001252240440.661-100000@alphplex.bde.org> In-Reply-To: <200001242210.OAA66513@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Jan 2000, Peter Jeremy wrote: > On 2000-Jan-25 04:02:28 +1100, Mikhail Teterin <mi@aldan.algebra.com> wrote: > > It does not explain the consistent 9-10 msecs excess. > > _That_ might be a bug. The select(2) delay is converted from a struct > timeval into ticks by tvtohz(). This routine rounds up to the next > tick and then adds 1 to the result (in both -stable and -current). > The `+1' would seem to be incorrect - even if you want to allow for > the current tick, a more reasonable estimate would be 0.5, not 1. It is correct. The next tick may expire 1 usec after tvtohz() completes its calculation. Therefore, to ensure waiting for as little as 2 usec, tvtohz() must first round up 2 usec to 1 tick and then add 1. There is a tradeoff between efficiency and accuracy. The most accurate method (not counting spinloops, etc.) is to underestimate a tick or two, and then check whether the timeout has expired on wakeup. This may cost 2 context switches, and does cost one microtime() call for each premature wakeup, and maybe another microtime() call before the initial sleep. A slightly less accurate method is to determine the time until the next clock tick and take it into account in calculation. > Based on a quick check, both Solaris 2.5 and Digital Unix (aka Tru64) > 4.0D don't include this one tick over-estimate. Other systems could easily get this wrong :-). I fixed it in FreeBSD and got it fixed in Linux. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001252240440.661-100000>