Probably known problem

Donald Becker becker@cesdis1.gsfc.nasa.gov
Wed Sep 22 06:25:19 1999


On Wed, 22 Sep 1999, Christian Corti wrote:

> I have one Linux server (Intel P60 / 16MB RAM) and another computer

That's a rather old machine, likely with an ancient PCI bus implementation
that cannot handle burst transfers.

> (K6/200 / 64MB) both with kernel 2.2.5 and 3COM 3c905B-NM-TX using driver 
> version 0.99L. They are connected at 100 Mbit through a Lantech dualspeed
> hub.
> Whereas performance reading from the server is not too bad (around 2.5
> MB/s), putting an 11MB file onto the server via ftp gave only 150KB/s.
> Here is what ifconfig said about the interface in the server right after
> starting the interface and ftp'ing (get and put):
> 
> eth0      Link encap:Ethernet  HWaddr 00:10:4B:32:2F:7C  
>           inet addr:192.168.0.254  Bcast:192.168.0.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:36039 errors:2 dropped:0 overruns:2004 frame:2
>           TX packets:54349 errors:0 dropped:0 overruns:0 carrier:636
>           collisions:259 txqueuelen:100 
>           Interrupt:9 Base address:0xfc80 

Hmmm, Rx overrun errors are normally very rare.  They nominally mean that the
card could not get enough PCI bandwidth, which is almost never a problem on
a PCI bus that can burst transfer.

Something that you can try is to lower the Rx threshold.  It's currently
set to receive a whole packet before transferring it from the card to main
memory.  (This setting is to work around a bug in older chips.)

Around line 966
-	       outw(SetRxThreshold + (1536>>2), ioaddr + EL3_CMD);
+	       outw(SetRxThreshold + (128 >> 2), ioaddr + EL3_CMD);

If this reduces or eliminates the Rx overruns, you have a PCI bus bandwidth
issue.  Please let us know the results.

> And that is what /proc/net/dev is saying right now (look for eth0, eth1 is
> a 10Mbit NE2000 from Novell):

Are you running an ISA card on this machine as well!?
They are OK for very light traffic, but suck down CPU time and bus bandwidth
if you are putting a lot of data through them!

> I also tried the program 'bing' to test network speed. I had to limit
> the size of big packets to around 2500 bytes with
> 'bing -S2500 pentium linuxserv'
> to get results. They were around 38 Mbit. With larger "big" packets I got
> no answer from my server, but an extra overrun for each tried packet.

This seems to confirm the bus saturation.  Note that packets larger than
1500 bytes (1476 bytes or so) are fragmented into multiple Ethernet frames.

> Next strange thing is when I read a file from Windows (95 or NT) from
> Samba. Reading speed is quite good (aroung 3 MB/s), but with LOTS of

Note that transmits will not usually be a problem, since the card can just
delay sending the packet until it has finished getting it from the PCI bus.

> I have to mention that I had to modify the net card in my server.
> It has an Intel Batman board (430LX chipset) with P60 and two PCI cards.
> One is the 3COM card, the other a Promise Ultra/33. Both are working fine
> when alone in the box. But the BIOS always assigns them the same real
> interrupt, I can't assign them separatly, not by swapping slots and not by
> changing BIOS setup. And sharing the same interrupt with this cards
> doesn't work with Linux. So I had to connect the INTA pin of the 3COM via
> a small interface (an inverter actually) to a free IRQ pin on the ISA bus
> (like very old PCI IDE cards) and modify the Linux driver to use a
> fixed interrupt.

Ackkk!!!
Wouldn't it be easier to just change the IDE driver to accept shared
interrupts?

Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html