interrupt latency k2.4 / i386?

interrupt latency k2.4 / i386?

[SA]

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

Re: interrupt latency k2.4 / i386?

[Richard B. Johnson]

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.

Re: interrupt latency k2.4 / i386?

[uaca]

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 majordomo@vger.kernel.org
> 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		<---