2003-02-07 18:39:23

by SA

[permalink] [raw]
Subject: interrupt latency k2.4 / i386?


Dear list,

What latency should I expect for hardware interrupts under k2.4 / i386 ?

ie how long should it take between the hardware signalling the interrupt and
the interrupt handler being called?


I am wrting a driver which pace IO with interrupts, generating one interrupt
for after every transfer is done. Looking at the hardware schematics the
interrupts should occur virtually instantly after each transfer but the
driver is waiting ~1ms/ interrupt.

I can use polling instead with busy waits but this seems a bit wasteful.


My interrupt is shared with my graphics card using the non-GPL nvidia driver -
could this be responsible for the delay (any experience with this)?

cat /proc/interrupts
.....
10: 3028 XT-PIC eth0, VIA 82C686A
11: 1117037 XT-PIC nvidia, PI stage <-- my driver
12: 14776 XT-PIC usb-uhci, usb-uhci
.....

Thanks SA


2003-02-07 18:56:27

by Richard B. Johnson

[permalink] [raw]
Subject: Re: interrupt latency k2.4 / i386?

On Fri, 7 Feb 2003, SA wrote:

>
> Dear list,
>
> What latency should I expect for hardware interrupts under k2.4 / i386 ?
>
> ie how long should it take between the hardware signalling the interrupt and
> the interrupt handler being called?
>
>
> I am wrting a driver which pace IO with interrupts, generating one interrupt
> for after every transfer is done. Looking at the hardware schematics the
> interrupts should occur virtually instantly after each transfer but the
> driver is waiting ~1ms/ interrupt.
>
> I can use polling instead with busy waits but this seems a bit wasteful.
>
>
> My interrupt is shared with my graphics card using the non-GPL nvidia driver -
> could this be responsible for the delay (any experience with this)?
>
> cat /proc/interrupts
> .....
> 10: 3028 XT-PIC eth0, VIA 82C686A
> 11: 1117037 XT-PIC nvidia, PI stage <-- my driver
> 12: 14776 XT-PIC usb-uhci, usb-uhci
> .....
>
> Thanks SA
> -

Well there are very great problems with a lot of drivers if you
want good latency, but are sharing interrupts. Many drivers poll
in the ISR! This means that they loop through their ISR code
in some "interrupt mitigation scheme" that some near-do-well taught
in web-page school. This means, that if you share an interrupt,
you are probably screwed. You need to put your board in some slot
where it will either be first on the IRQ chain, or not shared at
all. Typical latencies are around 1.2 microseconds on a 400 MHz
machine, better on faster, sometimes better with two CPUs and an
IOAPIC.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


2003-02-07 19:00:49

by uaca

[permalink] [raw]
Subject: Re: interrupt latency k2.4 / i386?


On Fri, Feb 07, 2003 at 06:47:36PM +0000, SA wrote:
>
> Dear list,
>
> What latency should I expect for hardware interrupts under k2.4 / i386 ?
>
>
>
> ie how long should it take between the hardware signalling the interrupt and
> the interrupt handler being called?

I don't know the hardware part but it depends on how long interrupts are
being disabled (and that depend on the code you use in the kernel) and
that can be measured with akpm's timepeg+intlat patches

http://www.zip.com.au/~akpm/linux/#timepegs

I hope this helps

Ulisses

>
>
> I am wrting a driver which pace IO with interrupts, generating one interrupt
> for after every transfer is done. Looking at the hardware schematics the
> interrupts should occur virtually instantly after each transfer but the
> driver is waiting ~1ms/ interrupt.
>
> I can use polling instead with busy waits but this seems a bit wasteful.
>
>
> My interrupt is shared with my graphics card using the non-GPL nvidia driver -
> could this be responsible for the delay (any experience with this)?
>
> cat /proc/interrupts
> .....
> 10: 3028 XT-PIC eth0, VIA 82C686A
> 11: 1117037 XT-PIC nvidia, PI stage <-- my driver
> 12: 14776 XT-PIC usb-uhci, usb-uhci
> .....
>
> Thanks SA
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers." Pablo Picasso

---> Visita http://www.valux.org/ para saber acerca de la <---
---> Asociaci?n Valenciana de Usuarios de Linux <---