lkml.org 
[lkml]   [2000]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 3c59x problems solved -- mostly
Arnaud Installe wrote:
>
> Hello,
>
> So I tried your suggestions. Unmasking the hd IRQs sure helps prevent a
> lot of buffer overruns. There still are some, but they're down by a
> factor of 100 or more...

Nice to have an explanation.

> Any suggestions to reduce those even further
> more than welcome, as I suppose this might cause some Multicast UDP
> packets to get dropped. :-/

Yes, you'll be dropping packets.

> Would using SCSI instead of IDE help, do you think ?

It depends upon the SCSI driver. I haven't measured kernel interrupt
latencies for a while. Back in March, IDE beat the pants off SCSI in
this regard.

The IDE system was UDMA-66 (using hdparm -u1 -d1). The SCSI sytem was
from Advansys (I don't know how good this driver is). The numbers are
at http://www.uow.edu.au/~andrewm/linux/intlat/intlat-disk.html. This
was for the 2.3.99 kernel.

IDE: 27 usecs
SCSI: 42 usecs

Still, these aren't large enough to explain this behaviour.

Are you sending much output to the console? You'll see from Doug
Gilbert's numbers that the console driver can block interrupts for a
millisecond. Try running X, or otherwise prevent things from writing to
the console.

The sensible alternative, of course, is to use a multicast filter. The
3c905B/C does have a 256 slot hash filter. Unfortunately (and
uncharacteristically), 3com forgot to document it. However it _is_
implemented in 3com's own GPL'ed driver. This driver is bundled in
RedHat 6.x and is available at
http://support.3com.com/infodeli/tools/nic/linux.htm . It's worth
visiting that site just for the amusement factor of having to click on
"I agree" for the license. It's the GPL!

Even better, port 3com's code to 3c59x.c and send me a patch :)


> The 2.2.17 driver still seems to have a few bugs though: we get messages
> like: "Too much work in interrupt, status e401". This seems to happen
> more on machines with RX buffer overruns.

hmm.. Yes, something is wrong. I see this could perhaps silently
happen if the driver is hopelessly out of memory. And this would
explain the failure you saw in the 2.2.16 driver. It had an
Rx-stops-working-on-OOM bug.

Could you please, before doing anything else, see if

echo '512 1024 1536' > /proc/sys/vm/freepages

makes a difference?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.053 / U:3.332 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site