Date: Fri, 09 Nov 2001 13:37:54 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Warner Losh <imp@harmony.village.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Sansonetti Laurent <lorenzo@linuxbe.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: Measuring interrupt latency Message-ID: <200111091837.fA9IbsE19466@whizzo.transsys.com> In-Reply-To: Your message of "Fri, 09 Nov 2001 10:03:11 MST." <200111091703.fA9H3B753981@harmony.village.org> References: <574.1005324178@critter.freebsd.dk> <200111091703.fA9H3B753981@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I did some experiments a few years ago with a FreeBSD 3.x system to try to measure interrupt latency (and latency jitter). The platform was a 233MHz Pentium, and I had a PCI board which implemented a high resolution timer (to 100ns resolution). The PCI board could be programmed to generate an interrupt at some given time, and one PCI bus access to a register on the board would latch the current value of the timer. So, I had the board programmed to generate interrupts every second (at roughly 500ms past the start of the second), and then in the interrupt service routine, grabbed the value of the timer and computed the delay based on how far the timer had advanced past the programmed alarm time. I then updated a histogram of the measured delays. Here's some sample data. The first set of data is where the PCI board asserted an interrupt which wasn't shared with any other peripherals. The second set is where the board was in a different slot, and shared with other devices (in the data shown, it was with an Adaptec 7880 SCSI controller and a UHCI USB controller). non-shared: 5us <= 250831 < 6us 6us <= 751473 < 7us 7us <= 67305 < 8us 8us <= 5032 < 9us 9us <= 1467 < 10us 10us <= 877 < 11us 11us <= 518 < 12us 12us <= 369 < 13us 13us <= 165 < 14us 14us <= 112 < 15us 15us <= 469 < 16us 16us <= 199 < 17us 17us <= 18 < 18us 18us <= 9 < 19us 19us <= 5 < 20us 20us <= 12 < 22us 22us <= 12 < 24us 24us <= 5 < 28us 32us <= 1 < 35us 50us <= 1 < 75us 100us <= 2 < 250us to the shared version: 5us <= 1 < 6us 7us <= 32 < 8us 8us <= 2116 < 9us 9us <= 4468 < 10us 10us <= 92421 < 11us 11us <= 187835 < 12us 12us <= 22369 < 13us 13us <= 5725 < 14us 14us <= 5141 < 15us 15us <= 1073 < 16us 16us <= 188 < 17us 17us <= 130 < 18us 18us <= 134 < 19us 19us <= 122 < 20us 20us <= 469 < 22us 22us <= 80 < 24us 24us <= 45 < 28us 28us <= 11 < 30us 30us <= 6 < 32us 32us <= 10 < 35us 35us <= 18 < 50us 50us <= 3 < 75us 75us <= 1 < 100us 100us <= 5 < 250us The object of this excersise was to try to characterize the jitter in the interrupt response time latency. The primary application for the PCI board (a Datum bc635PCI/bc635CPCI) was to implement high-resolution network interface timestamping. As I mentioned previously, reading this clock is relatively cheap with 3 32 bit PCI bus cycles, and I was capturing timestamps of all the traffic arriving on a network interface. The clock on the board was externally synchronized to UTC using a 1PPS signal and IRIG-B timecode from a GPS synchronized clock, with an ovenized oscillator. I haven't tried to run the numbers again more recently on a more modern kernel. The device driver I did hasn't been ported to the NEWBUS infrastructure in 4.x, which is something I need to get back to doing. Other than CPUs that are much faster, I don't know if there are signifcant differences in kernel-level SPL-induced delays between 3.x and 4.x of the FreeBSD kernels. I've had no experience with any of the 5-current kernels, which are all different.. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111091837.fA9IbsE19466>