Date: Thu, 03 Jan 2002 11:55:50 -0800 From: Terry Lambert <tlambert2@mindspring.com> 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: <3C34B746.85DF32E6@mindspring.com> References: <Pine.BSF.4.30.0201030159530.56510-100000@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack wrote: > To answer my own question, there seems to be about 8us of slop added to > each call to DELAY. 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... It's common practice in software to have timer intervals that mean "at *least* X intervals", and which have a "slop" of 1-3 full intervals, in order to: 1) Read a timer 2) Wait until the timer changes, in order to find an interval boundary in the hardware 3) Read the timer until the delta specified by the user (rounded up to the timer resolution) has passed This would easily explain the "slop" you are seeing. I think what you want is PC hardware to have higher resolution timer hardware that starts calculating the delta from when it's programmed, and causes an interrupt when the delta interval has completed. As it is, PC hardware has some incredibly *low* resolution timers that can interrupt, and then it has *counters*, which you can read. You should consider your application, and probably change the design. The best approach I've been able to come up with for timers is to create reschedulable one-shots that operate using "opportunistic timers" (search Yahoo for this phrase to find the white papers from Rice University in Texas), that use a high resolution counter (the cycle counter). The problem with this is that DELAY() is used a lot during boot and for device probes (actually, you could run some of these in parallel to get a faster boot, if they were using one-shots instead of delay timers), and you have a nice chicken-and-egg problem getting the other clocks synchronized. Probably, the "timecounters" should be the ver first things that are initialized in the OS, after the VM is started, and before the devices are probed; this would be the most flexible approach (as well as hard to implement correctly, unfortunately). -- Terry 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?3C34B746.85DF32E6>