Re: NE2000 slow interrupts safe?

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Sun, 19 Apr 1998 22:09:57 +1000

Richard B. Johnson writes:
> 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.

Sigh. I don't think this is a significant factor, however, I've just
run another series of tests where I disable interrupts in
ne_block_input() and I get times ranging from 0.5 to 1 millisecond
(for largish packets). This is with my PCI NE2000 card on a dual PPro.

> 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.

If I have an ISR taking 1 millisecond (NE2000) and another ISR that
comes every 1 millisecond, I think it's pretty obvious that enabling
other interrupts during the NE2000 ISR is a damn good idea.

Of course, I'd rather that the NE2000 didn't take that much time, and
that's why I've started this thread.

> 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.

Er, no argument from me. But what's this got to do with my problem?

> 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.

Once again, no argument, but I don't see what this has to do with my
problem either. The NE2000 isn't polling, it's sitting in a tight
loop, in particular:
insw(NE_BASE + NE_DATAPORT,buf,count>>1);

I don't call that polling! What bothers me is that my colleague is
reporting under 140 microseconds for his pSOS ISR, now that he's coded
some of it in assembler and increased the ISA clock to 12 or 16
MHz. And this is on a 486 DX2-66! I would expect that my PCI card with
a PPro would be able to match that, but apparently not.
This is something I'd like to track down.

Regards,

Richard....

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