On Wed, Sep 27, 2000 at 11:26:09PM +1100, Andrew Morton wrote:
> > 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.
Hmm... Not good.
> > 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.
What we're seeing is we stress the hd's so much the whole system becomes
terribly slow whenever a disk access is needed. Simply logging in on the
console takes ages then. Perhaps this could explain those buffer
overruns ?
> 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.
Nope. Just X clients running on a remote X server.
> 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!
Thanks for the info. So the standard driver uses a software filter for
multicasts then ? What does that mean ? Not promiscuous mode, I suppose ?
> > 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?
I've been using '512 1024 2048' for the last series of tests. I suppose
that's ok as well, or isn't it ?
Arnaud
-- Arnaud Installe <ainstalle@filepool.com>Q: What do you call a blind pre-historic animal? A: Diyathinkhesaurus.
Q: What do you call a blind pre-historic animal with a dog? A: Diyathinkhesaurus Rex. - 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/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:19 EST