lkml.org 
[lkml]   [1998]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NE2000 slow interrupts safe?
On Fri, 17 Apr 1998, Richard Gooch wrote:

> Following up on this again, this time with tests using 2.1.90
> (previous tests were with 2.0.33).
> Rogier Wolff writes:
> > Richard Gooch wrote:
> >
> > > On my tests I noticed quite a spread of times. When I send short
> > > packets, then yes, the times are around a few hundred
> > > microseconds. However, for longer packets, I was getting up to 2
> > > milliseconds. And my measurements were consistent with the results
> > > other were getting with pSOS. I first instrumented almost the whole
> > > interrupt handler, then later just instrumented the block transfer
> > > routine and got the same results.
> >
> > Rule-of-thumb calculation: ISA bus cycle costs 1 us (one microsecond).
> > 1500 bytes -> 750 transfers (Ne2000 is 16bit card) -> 750 us.
> >
> > I'd say 2000 us is quite long, 300 us is a pretty fast.
> >
> > I guess that you can have ne2000's that are slower than others. Maybe
> > 300 us was a PCI card?
>
> The test was done with an ISA card. I've re-run the tests on a Pentium
> 200 MMX with an ISA NE2000 card (el cheapo). The 8390 interrupt
> service routine often takes 4 ms. The ne_block_input() function takes
> around 1.1 ms. This is when I'm sending a megabyte of data to the
> machine using TCP, so the EtherNet packets should be close to 1500
> bytes. The lower times would be due to shorter received packets. This
> machine is running 2.1.90.
>
> I've done similar tests on a dual PPro with a PCI NE2000 (also an el
> cheapo), and I get similar times for ne_block_input(). However the
> whole 8390 interrupt routine has gone down to around 2 ms. This
> machine is 2.1.91.
>
> On a P90 system with an ISA SMC-ULTRA I recall getting up to 2 ms per
> interrupt. That machine was running 2.0.33.
>

I think you are measuring the time, not only for your interrupt, but
also for all the interrupts that happened during your ISR because the
interrupts were enabled.

A ISR needs so many CPU cycles to complete. If the ISR gives away its
CPU cycles by enabling interrupts, it will take much longer to complete
than expected. The idea of enabling interrupts during an ISR is, in
principle, not a sound engineering technique and, if absolutely necessary,
should be justified on the basis of some special circumstances.

For instance, a ISR that needs a timer during its execution, and therefore
enables interrupts so that the timer-tick will happen, is broken by
design.

Interrupts happen because hardware events have occurred. The ISR must
service those events only. An ISR that polls or waits for something
additional to happen is broken.

Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.92 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.058 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site