Date: Sun, 02 May 1999 10:04:57 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Subject: Re: FreeBSD interrupt responsetime... Message-ID: <199905021404.KAA57867@whizzo.transsys.com> In-Reply-To: Your message of "Sun, 02 May 1999 12:22:59 %2B0200." <2754.925640579.1@critter.freebsd.dk> References: <2754.925640579.1@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
And for something completely different, I've got some data measured a bit
differently. This is with a 1-Hz periodic interrupt source, multi-user
mode, with a "normal" vs. FAST_INTR service routine.
This is a dump of the buckets kept in the device driver of number of times
that the interrupt service latency was between the intervals listed.
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
The hardware configuration is a 233MHz Pentium MMX based Motorola CPV5000
CompactPCI system board, with a Datum bc635CPCI time and frequency processor
board. The PCI bus this is connected to is one bridge away from the CPU
and is the normal 32 bit wide, 33MHz variety. This system's got an fxp0
ethernet and adaptec SCSI on board. This system was far from idle when
this data was collected, with substantial network and disk activity during
some periods.
(For detail on the hardware, see: http://www.mcg.mot.com/WebOS/omf/GSS/MCG/prod
ucts/proddb/templates/display_datasheet.html?[qrec=0000412+[prodid=CPV5000
http://www.bancomm.com/cbc637cpci.htm )
I program the bc635 to generate an interrupt once each second, at about
500ms past the start of the second. When the interrupt service routine is
invoked, I read the current time out of the board and see how long it took.
I'm more concerned at this point about the varience in response, rather than
the absolute latency; though I would like to improve that. I've been thinking
about ways to instrument to low-level interrupt service code to capture
a timestamp and save it away somewhere prior to the splX() interrupt
scheduling.
Sounds like it would be worth trying to re-do this with a FAST_INTR service
routine to see how much of a difference that would make. I'm using a
-current from early March as the basis of this work, and haven't tried to
merge any of the subsequent changes (newbus, etc.) until that's well
settled down.
louie
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905021404.KAA57867>