Probably known problem

Christian Corti corticn@rupert.informatik.uni-stuttgart.de
Wed Sep 22 05:46:42 1999


I also have a problem concerning low speed and lots of errors.

I have one Linux server (Intel P60 / 16MB RAM) and another computer
(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 

I'm worried about the overruns and collisions, since there were no other
computers connected to the net. I don't think that there is a bad cable,
but I'm not sure, I only tested three in total. Could this be a card or
driver problem, too? On the other computer there were no errors indicated.

Trying the different settings of the driver doesn't change anything.

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

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:1641763907 26218507    0    0    0     0          0         0 1641763907 26218507    0    0    0     0       0          0
dummy0:       0       0    0    0    0     0          0         0  4032506   18954    0    0    0     0       0          0
 ippp0:135846349  178179    0    0    0     0          0         0 513411385  175487    4    0    0     0       0          0
  eth1:66908621  338949    0    0    0     0          0      1260 115059909  352358    1    0    0    32       2          0
  eth0:140012184 1454728    8    0 4519     8          0         0 407001905 1885345    0    0    0   632    7362          0

By the way, the transmit value for ippp0 can't be correct. I have never
transmitted 513 MB (!!) via ISDN since the last reboot August 18th,
only 15 MB. Receive value is correct.

Loading the 3COM driver with full debug on didn't print any error in the
/var/log/messages file, only normal debug output.

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.
But I know that directly after installing my server in spring this year
(with kernel 2.0.35 and driver 0.99E I think) I was able to say
'bing -S20000' from my computer to the server and I got full 100 Mbit.

Results from 'bing -S2500':
---------------------------

BING	pentium.zuhause (192.168.0.1) and linuxserv (192.168.0.254)
	44 and 2500 data bytes
39296 bits in 1.007ms: 39022840bps, 0.000026ms per bit
39296 bits in 1.075ms: 36554419bps, 0.000027ms per bit
...
39296 bits in 1.052ms: 37353612bps, 0.000027ms per bit

--- pentium.zuhause statistics ---
bytes   out    in   dup  loss	rtt (ms): min       avg       max
   44  1294  1294          0%	        0.085     0.089     0.182
 2500  1294  1293          0%	        0.191     0.196     0.257

--- linuxserv statistics ---
bytes   out    in   dup  loss	rtt (ms): min       avg       max
   44  1293  1293          0%	        0.373     0.388     0.575
 2500  1293  1293          0%	        1.531     1.569     1.686

--- estimated link characteristics ---
estimated throughput 37353612bps
minimum delay per packet 0.269ms (10054 bits)

average statistics (experimental) :
packet loss: small 0%, big 0%, total 0%
average throughput 36622554bps
average delay per packet 0.280ms (10475 bits)
weighted average throughput 36622554bps

Results from 'bing -S3000':
---------------------------

BING	pentium.zuhause (192.168.0.1) and linuxserv (192.168.0.254)
	44 and 3000 data bytes

--- pentium.zuhause statistics ---
bytes   out    in   dup  loss	rtt (ms): min       avg       max
   44     5     5          0%	        0.092     0.115     0.184
 3000     5     5          0%	        0.226     0.242     0.286

--- linuxserv statistics ---
bytes   out    in   dup  loss	rtt (ms): min       avg       max
   44     5     5          0%	        0.414     0.425     0.432
 3000     5     0        100%	

not enough received packets to estimate link characteristics.

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
collisions. Writing is as slow as described above. Why do I have
collisions in Windows, but not Linux?? I'm using the Windows drivers from
3COM, not from Microsoft. And I don't have fullduplex enabled, that's
sure.

And finally I had to set rsize and wsize both to 2048 for NFS and for
Samba. Higher values lead to no transmission at all (well, at most 10
bytes/s, imagine transferring 1MB at that speed!).

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. Intel wasn't able to tell me how to program the PCI
interrupt steering logic (the chipset has no interrupt routing table built
in).
This solution works fine since converting all to original state and
taking out the Promise card changes nothing in performance or errors.

The one and only question I have is:
What is wrong with my server?

Christian