maximum interrupts/second

I could not find any up to date information using Google
Groups on this question which is quite simply is there a
guideline for the maximum number of interrupts a second
that can be processed by a Windows 2000/XP system running
on a CPU such as an AMD XP-1800+ (approx 1.5 GHz)? The
problem arises because I need to deal with a CBR ATM stream
running at about 7.5 Mbps and the hardware generates an
interrupt for each ATM cell. The math works out to about
20,000 interrupts per second in each direction or 40,000
sustained interrupts/second if I attempt full duplex
communications. Is 40,000 achievable? 20,000? Assume the
machine will be doing very little else while running this
application.

Stephan
Wed Nov 19 13:08:02 CST 2003

I think there is no general rule as to how many (hardware) interrupts
can be generated / handled per second. There are just too many
factors.

As a general rule, however, the number of interrupts per second should
be as small as possible. You seem to be saying this is not for a
production driver/application?

IIRC, some years ago we were able to generate about 30K to 40K IRQ/s
on a Pentium-500 under NT 4.0 (Gigabit Ethernet NIC). We added
Interrupt Moderation to both the hardware and driver such that we can
handle several interrupt events in just one interrupt.

What one usually does in software is to disable the adapter's IRQ line
in the ISR and re-enable it at the end of the DPR (DPC). The DPR is
implemented as a loop that re-reads the adapter's interrupt source
register right before exiting the loop. If there is another interrupt
event waiting to be serviced on the adapter, do not exit the loop.

See also
http://www.microsoft.com/whdc/hwdev/tech/network/NetAdapters-Drvs.mspx

Stephan
---
On Tue, 18 Nov 2003 14:46:01 -0800, "Roger Levy"
<anonymous@discussions.microsoft.com> wrote:

>I could not find any up to date information using Google
>Groups on this question which is quite simply is there a
>guideline for the maximum number of interrupts a second
>that can be processed by a Windows 2000/XP system running
>on a CPU such as an AMD XP-1800+ (approx 1.5 GHz)? The
>problem arises because I need to deal with a CBR ATM stream
>running at about 7.5 Mbps and the hardware generates an
>interrupt for each ATM cell. The math works out to about
>20,000 interrupts per second in each direction or 40,000
>sustained interrupts/second if I attempt full duplex
>communications. Is 40,000 achievable? 20,000? Assume the
>machine will be doing very little else while running this
>application.

Calvin
Thu Nov 20 07:36:21 CST 2003

Hi Stephan,

In a network intensive environment, when receive DPC scans the descriptor

list for received packet in the loop, it has to get out of the loop after

certain number of packet are scanned to limit the time spent in DPC, (in the

case of ndistester performance blast) then my options are:

a) indicate the scanned packets and re-enable the RX interrupt.

b) indicate the scanned packets but keep the RX interrupt disabled, let the

next DPC for Isr (could be tx/rx or anything else) handle the rest of the

packets.

c) indicate the scanned packets but keep the RX interrupt disabled, set a

countdown timer to handle the rest of the packets.

I found different options are good at handling different size of receive

packets. May I know how you handle this in your driver?

Thanks a lot,

Calvin

"Stephan Wolf" <stewo68@hotmail.com> wrote in message
news:q9fnrvsvpo8ef2jrl8ute3ldm3pma1pu50@4ax.com...
> I think there is no general rule as to how many (hardware) interrupts
> can be generated / handled per second. There are just too many
> factors.
>
> As a general rule, however, the number of interrupts per second should
> be as small as possible. You seem to be saying this is not for a
> production driver/application?
>
> IIRC, some years ago we were able to generate about 30K to 40K IRQ/s
> on a Pentium-500 under NT 4.0 (Gigabit Ethernet NIC). We added
> Interrupt Moderation to both the hardware and driver such that we can
> handle several interrupt events in just one interrupt.
>
> What one usually does in software is to disable the adapter's IRQ line
> in the ISR and re-enable it at the end of the DPR (DPC). The DPR is
> implemented as a loop that re-reads the adapter's interrupt source
> register right before exiting the loop. If there is another interrupt
> event waiting to be serviced on the adapter, do not exit the loop.
>
> See also
> http://www.microsoft.com/whdc/hwdev/tech/network/NetAdapters-Drvs.mspx
>
> Stephan
> ---
> On Tue, 18 Nov 2003 14:46:01 -0800, "Roger Levy"
> <anonymous@discussions.microsoft.com> wrote:
>
> >I could not find any up to date information using Google
> >Groups on this question which is quite simply is there a
> >guideline for the maximum number of interrupts a second
> >that can be processed by a Windows 2000/XP system running
> >on a CPU such as an AMD XP-1800+ (approx 1.5 GHz)? The
> >problem arises because I need to deal with a CBR ATM stream
> >running at about 7.5 Mbps and the hardware generates an
> >interrupt for each ATM cell. The math works out to about
> >20,000 interrupts per second in each direction or 40,000
> >sustained interrupts/second if I attempt full duplex
> >communications. Is 40,000 achievable? 20,000? Assume the
> >machine will be doing very little else while running this
> >application.

Stephan
Thu Nov 20 17:48:07 CST 2003

There are several options. First one needs to think about what a
"heavy load" condition means and what system behaviour should be
achieved.

It is clear that full network load can always lead to missed packets.
Thus, one needs to define a "good behaviour". I think "good" is if all
of the following applies, in the order of precedence (high to low):

- mouse still moves

- network connections (file shares etc.) still work

- programs can be started

- multimedia apps. show no dropouts

Both the number of interrupts per second and the time spent in the DPC
play a major role here. It is always a good idea not to stay "too
long" in a DPC, say 10ms at most. AFAIK, MS would prefer <1ms. MS also
suggests to move as much of the work as possible to a worker thread
running at PASSIVE_LEVEL instead of doing all the work at
DISPATCH_LEVEL. Not actually a good idea in current NDIS (<=5)
miniports. But you could give it a try *if* your miniport is
deserialized, see NdisScheduleWorkItem() (work items are a no-go for
serialized miniports).

If the NIC supports interrupt moderation, you should enable it when
network and/or system load exceed a certain maximum, see e.g
NdisGetCurrentProcessorCpuUsage(). That is, set your card to only
request an interrupt after e.g. 5 packets have been sent/received *or*
some wait timer times out.

When the maximum DPC time has elapsed (e.g. 10ms), re-enable adapter
IRQs and leave the DPC. If your adapter supports software issued
interrupts, let it raise one. Otherwise, do not clear the interrupt
conditions yet.

I think it is never a good idea to not enable the RX interrupt as you
cannot rely on other interrupts (TX etc.) to occur.

Leaving the DPC is absolutely necessary so the DPCs of other
devices/drivers can run. True for uni-processor systems but also a
very good idea for multi-processor systems.

If your card does not support interrupt moderation, leaving the DPC
will usually immediately fire another interrupt and thus re-schedule
your DPC. Note that there is no way around that as NDIS won't let you
schedule a DPC yourself (i.e. there is no NdisXxx() function for that
purpose). Thus, only the ISR can tell NDIS to schedule the DPC.

Another option is to set a timer and handle all interrupt events in
the timer callback. Also not actually a good idea as the timer
granularity is ways to low (e.g. 10ms). But if your hardware has a
timer you can use that one instead.

The overall behaviour of the interrupt handler should vary depending
on the value returned by NdisSystemProcessorCount().

There is probably much more to say. All I can say there is IMHO no
"standard" solution.

HTH, Stephan
---
On Thu, 20 Nov 2003 08:36:21 -0500, "Calvin Guan"
<ndisnewREMOVE_THE_CAPITALS@yahoo.com> wrote:

>Hi Stephan,
>
>In a network intensive environment, when receive DPC scans the descriptor
>
>list for received packet in the loop, it has to get out of the loop after
>
>certain number of packet are scanned to limit the time spent in DPC, (in the
>
>case of ndistester performance blast) then my options are:
>
>a) indicate the scanned packets and re-enable the RX interrupt.
>
>b) indicate the scanned packets but keep the RX interrupt disabled, let the
>
>next DPC for Isr (could be tx/rx or anything else) handle the rest of the
>
>packets.
>
>c) indicate the scanned packets but keep the RX interrupt disabled, set a
>
>countdown timer to handle the rest of the packets.
>
>I found different options are good at handling different size of receive
>
>packets. May I know how you handle this in your driver?
>
>Thanks a lot,
>
>Calvin