Re: interrupt latency ?

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Mon, 10 February 2003 11:20:54 -0500, Richard B. Johnson wrote:
> On Mon, 10 Feb 2003, [iso-8859-1] J?rn Engel wrote:
> 
> > Write a simple handler for parport or so, that is called when line #1
> > toggles from low to high and responds by pulling line #2 from low to
> > high.
> > Now hook up a signal generator and an oszilloscope and measure the
> > time from signal generation to the physical reaction.
> 
> Yes, and you will find that you can replicate a square-wave, through
> the hardware and software up to about 50 kHz with a 400 MHz Pentium
> if you disconnect your network during the tests.
> 
> My tests, several years ago, in the ISR simply XOR-ed a saved
> copy of bit zero with `1` to toggle it and wrote it out the
> data port. This would occur at every IRQ7, generated by hitting
> bit 2 of the control port with a function generator. This should
> produce a symmetrical /2 when you look at bit 0. You can line up
> the starting 'high' of the function generator, with either a high or
> low of bit one (because it's /2) and measure the time, which from
> my notebook looks like 1.2 to 1.4 microseconds on a 400MHz machine.
> 
> You can increase the interrupt rate until the machine is no longer
> able to keep up. This usually occurs around 110 kHz or higher.

1.2us translates to 800kHz or 500 clock cycles. That is a good
response time.
110kHz max rate translates to 3500 clock cycles for the complete
interrupt path. This means that the return path takes six times longer
to complete than the initialisation path. Odd.

Somehow, I get this feeling that linux could still do better. 500
cycles is already better than the 2000 we observed, but most of that
should come from the different architecture.

An assembler interrupt handler that saves registers, tweaks a couple
of bits, restores registers and gets the hell out of here should be in
the order of 100 cycles, maybe less. Why is linux wasting all this
time?

Jörn

-- 
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra