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>