public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: John William <jw2357@hotmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Abysmal RECV network performance
Date: Thu, 31 May 2001 22:22:59 -0700	[thread overview]
Message-ID: <3B1726B3.6ED0872C@candelatech.com> (raw)
In-Reply-To: <F75GMVJ7AnvcesML51O000040fe@hotmail.com>

John William wrote:
> 
> >Depends on what is driving it...  An application I built can only push
> >about
> >80 Mbps bi-directional on PII 550Mhz machines.  It is not the most
> >efficient program in
> >the world, but it isn't too bad either...
> >
> >I missed the rest of this thread, so maybe you already mentioned it, but
> >what is the bottleneck?  Is your CPU running at 100%?
> >
> >Greatly increasing the buffers both in the drivers and in the sockets
> >does wonders for higher-speed connections, btw.
> >
> >Ben
> 
> I don't know what the bottleneck is. What I'm seeing is ~60Mbps transmit
> speed and anywhere from 1 to 12Mpbs receive speed on a couple 10/100 cards
> using the 2.2.16, 2.2.19 and 2.4.3 kernels.
> 
> I have tried increasing the size of the RX ring buffer and it did not seem
> to make any difference. It appears that there is some sort of overrun or
> other problem. There is a significant slowdown between the 2.2.x and 2.4.x
> kernels.
> 
> However, just tonight, while really hammering on the system, I started to
> get some messages like "eth1: Oversized Ethernet frame spanned multiple
> buffers, status 7fff8301!". Any ideas what could be causing that?

Nope, I'd take it up with the driver developers.  For what it's worth,
the Intel Ether-Express Pro cards are the only ones I've found yet that
really work right at high speeds.  Intel's e100 driver seems to work really
well for me, but the eepro driver also works well with most versions of
the eepro cards I've used...

I have had definate problems with the natsemi (locked up), tulip (won't
autonegotiate multi-port cards correctly, or something), rtl8139 (would
lock up, haven't tried recent drivers though)....

I used to assume that Linux had the best/fastest networking support around,
but the reality is that I've had a really hard time finding hardware/drivers
that works at high speeds (60Mbps+, bi-directional).

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

  reply	other threads:[~2001-06-01  5:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-01  4:57 Abysmal RECV network performance John William
2001-06-01  5:22 ` Ben Greear [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-06-01  3:50 John William
2001-06-01  4:56 ` Ben Greear
2001-05-30  2:55 John William
2001-05-31 16:40 ` Nivedita Singhvi
2001-05-29  6:45 Nivedita Singhvi
2001-05-28  3:47 John William
2001-06-01  6:13 ` Stephen Degler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B1726B3.6ED0872C@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=jw2357@hotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox