Lousy Network Performance

[Kurt Wall]

On Wednesday 29 June 2005 01:05, James McDonald wrote:
> On Wed, Jun 29, 2005 at 12:03:57AM -0400, Kurt Wall wrote:
> > On Tue, Jun 28, 2005 at 02:29:43PM +1000, James McDonald took 0 lines to 
write:
> > > On Mon, Jun 27, 2005 at 10:56:34PM -0400, Kurt Wall wrote:
> > > > Hi, list,
> > > >
> > > > How do I go about solving a significant latency problem on my
> > > > internal network. I have two computers connected via a crossover
> > > > cable, eth1 on the "server" (luther) to eth0 on the "desktop"
> > > > (easter). Both cards are 10/100. Ping time is atrocious:
> > > >
> > > > I can't see any reason why the latency should be so extreme.
> > >
> > > If you are using a crossover cable check your duplex settings. I have
> > > found performance gains by either enabling/disabling duplex.
> > >
> > > Use a tool like ttcp to push raw packets back and forwards... You
> > > should be getting around 100Mbps.
> >
> > Using ttcp, I didn't even get 10Mbit/sec:
> > On the sending machine, I ran
> > # ./ttcp -t -s -f m easter
> > ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> easter
> > ttcp-t: socket
> > ttcp-t: connect
> > ttcp-t: 16777216 bytes in 18.00 real seconds = 7.11 Mbit/sec +++
> > ttcp-t: 2048 I/O calls, msec/call = 9.00, calls/sec = 113.78
> > ttcp-t: 0.0user 0.0sys 0:18real 0%
> >
> > On the receiving machine, similarly:
> > # ./ttcp -r -s -f m
> > ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
> > ttcp-r: socket
> > ttcp-r: accept from 192.168.0.1
> > ttcp-r: 16777216 bytes in 18.00 real seconds = 7.11 Mbit/sec +++
> > ttcp-r: 2921 I/O calls, msec/call = 6.31, calls/sec = 162.28
> > ttcp-r: 0.0user 0.0sys 0:18real 0%
> >
> > Kurt
>
> Try setting the duplex to half using the miitool or ethtool or whatever and
> then rerun your tests. Unfortunately I have found that some of the linux
> drivers perform nowhere near the same as their Windows counterparts.
> However the 'hi end' cards. 3Com, Intel, IBM etc or anything they put in a
> Server system provided by the factory with Linux on it will probably work
> really well.

Changing to half-duplex didn't help. However, I have narrowed the
problem down to the NIC on the client system, which is the new budget
eMachines T6212 I bought. The NIC is an on-board RTL8139, which 
uses the 8139too driver:

eth0: RealTek RTL8139 at 0xee00, 00:11:09:15:29:f7, IRQ 11
eth0:  Identified 8139 chip type 'RTL-8100B/8139D'

So, I'm going to drop in a different card and see if that fixes the
throughput problems.

Kurt