Date: Thu, 03 Jan 2002 21:47:14 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: freebsd-arch@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: SMPng: Interrupt Latency Issues Message-ID: <1744.1010090834@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 04 Jan 2002 07:24:48 %2B1100." <20020104072448.I561@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020104072448.I561@gsmx07.alcatel.com.au>, Peter Jeremy writes:
>On 2002-Jan-03 10:16:53 +0100, Poul-Henning Kamp <phk@critter.freebsd.dk> wrote:
>>There are basically two things to getting good interrupt latency:
>>
>> 1. An architecture making it possible.
>...
>>I think we are on track to #1.
>
>Does this mean FreeBSD is dropping support for PC-compatible hardware? :-)
>(For that matter, PALcode also worsens interrupt latency on the Alpha).
Not it means that we try to avoid standardizing on the lousy performance
of the defacto hardware in the vain hope that future hardware designs
will improve in this respect :-)
The worst culprint on i386 these days is SMM/APM/ACPI.
>>My main contribution will probably be in trying to establish a
>>metrology to document the result, but to the extent time allows I
>>will participate and help where I can.
>
>This needs to be cross-platform. We also need a way for developers
>to measure (at least approximately) interrupt latency without needing
>USD1K timer boards - otherwise they can't assess the impact of any
>changes they make without involving you.
Well, sorry, that is the cheapest way I know of how to do it in a
way which measures the desired quality.
It's a regular PCI card, so it can work in other arch's as long as
they have PCI slots.
>For example, if you're using an i8254 as the master clock, you can
>get a reasonable estimate of interrupt latency by reading the i8254
>counter at the start of hardclock(). This has a (fixed) overhead of
>a couple of usec, a resolution of ~840nsec and can only measure
>clock interrupt latency in specific (though common) configurations.
This proves nothing as the i8254 is integrated in the southbridge
these days and as such seems to get preferential IRQ treatment.
>A more general approach approach is to read the TSC as early as
>possible in the interrupt process and then again at the beginning of
>the device-level interrupt handler.
This doesn't measure the time from the actual external event raising
the interrupt line until the CPU arrives in the interrupt handler.
This bit is the one which is hard to measure without special hardware.
>Both these approaches are probably "Good Enuf" for our purposes. I
>don't believe the object is a hard real-time kernel so a few usec
>slop in the interrupt latency probably doesn't matter. We just need
>to avoid latency spikes in the msec region.
If we want to document our latency, this is not "Good Enuf", but for
the average hacker to use as a guide it could be acceptable.
>As for hardware approaches: A dedicated timer card like the PCI
>Pamette is obviously the best, but most pricey, solution. Maybe one
>of the hardware gurus would like to design and manufacture a simple
>PCI card that is capable of generating an interrupt and lets you read
>a 32-bit time-since-interrupt counter. (Or something a bit fancier
>that generates an interrupt, accepts an acknowledge signal and keeps
>track of the minimum/maximum/mean/median/variance internally). Both
>these approaches can also be done more cheaply and less accurately via
>the parallel port.
The card I use is the HOT1 from www.vcc.com which is a darn bit
cheaper than the Pamette.
A custom card should contain:
A) A binary counter of at least 24 bits running from a
selectable external input or PCI bus clock.
B) A latch which trigger on an external input and captures
a copy of the counter.
C) A chunk of RAM, optionally battery backed, for ktrace, console
or "prestoserve" like use.
D) Add more features as you like: serial console for remote
access, output pin for toggling reset/atx-power etc etc.
A modest sized FPGA chip can do all of this and more.
This card would be not only an excellent test/performance tool but
would also be desirable to have in production systems, increasing
the market a fair bit.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
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?1744.1010090834>