From owner-freebsd-bugs Tue Jan 25 4: 1:50 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 937D414CF1 for ; Tue, 25 Jan 2000 04:01:44 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (qmail 30345 invoked from network); 25 Jan 2000 12:01:40 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 25 Jan 2000 12:01:40 -0000 Date: Tue, 25 Jan 2000 23:01:38 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Peter Jeremy Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/13644 In-Reply-To: <200001242210.OAA66513@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Jan 2000, Peter Jeremy wrote: > On 2000-Jan-25 04:02:28 +1100, Mikhail Teterin 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