Date: Thu, 3 Jan 2002 20:07:52 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mike Silbersack <silby@silby.com> Cc: <freebsd-arch@FreeBSD.ORG> Subject: Re: DELAY accuracy Re: cvs commit: src/sys/dev/usb uhci.c Message-ID: <20020103194429.T15755-100000@gamplex.bde.org> In-Reply-To: <Pine.BSF.4.30.0201030159530.56510-100000@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jan 2002, Mike Silbersack wrote: > On Wed, 2 Jan 2002, Mike Silbersack wrote: > > > This commit log started me wondering about DELAY usage in the kernel. > > Looking around, we do have a decent amount of such calls. Most of the > > calls seem to be for 100 us or less, with some as short a 1 us. These > > times seem short, but looking at sys/i386/isa/clock.c, I see that we time > > based off the i8254 timer chip, rather than the processor's TSC. As such, > > are we actually reaching microsecond accuracy, or is the delay actually > > taking longer than expected in many of these cases? > > To answer my own question, there seems to be about 8us of slop added to > each call to DELAY. This is very machine-dependent. On i386's, DELAY(1) reads an i8254 counter twice. This takes a minimum of about 2.5 usec per call. The general overhead of DELAY() is quite large on slow machines (IIRC, DELAY(1) takes about 15 usec on a 486/33, half for reading the counter and half for general overhead). > This seems irrelevant for calls of 100 or 1000, but > changes timing quite a bit on calls between 1 and 10. So, it looks like > rewriting DELAY so that it spin-waits on the TSC for delays of less than > 100 might be useful. Maybe when I get some time... Sorry, this wouldn't be useful. As for sleep(3), system activity may lengthen the delay by an indeterminate amount, unless you disable interrupts, which would be bad. Slow machines may take longer than 1 usec just to call DELAY(). Code should be written to not depend on DELAY() being very accurate. OTOH, the i386 DELAY() could be written better using microuptime(undoc). It would then be much simpler (except possibly for complications to make it work at boot time), and more accurate (except for small intervals on slow machines). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020103194429.T15755-100000>