Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Dec 1998 13:22:28 -0500 (EST)
From:      Bill Paul <wpaul@skynet.ctr.columbia.edu>
To:        mestery@winternet.com (Kyle Mestery)
Cc:        dg@root.com, hardware@FreeBSD.ORG
Subject:   Re: Call for testers for RealTek 8139 driver
Message-ID:  <199812051822.NAA16071@skynet.ctr.columbia.edu>
In-Reply-To: <Pine.GSO.4.05.9812050047230.17859-100000@tundra.winternet.com> from "Kyle Mestery" at Dec 5, 98 00:57:14 am

next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Kyle Mestery 
had to walk into mine and say:

> Hi,

[chop]
 
> On Mon, 30 Nov 1998, David Greenman wrote:
> I have had some more time to look into this.  I still see collisions when I
> am displaying Quake back across the wire.  Lots of collisions.  But the other
> thing that bothers me is the performance of these cards.  I know they are
> incredibly low-end (for $20, I didn't expect an Intel Etherexpress Pro100/B!),
> and I have read the driver if_rl.c to see Bill Paul's comments about the
> chip, but I am seeing pretty terrible performance from my cards.  Both cards
> are id'd as follows:
> 
> rl0: <RealTek 8139 10/100BaseTX> rev 0x10 int a irq 19 on pci0.15.0
> rl0: Ethernet address: 00:e0:7d:01:a5:05
> rl0: autoneg complete, link status good (half-duplex, 100Mbps)
> 
> rl0: <RealTek 8139 10/100BaseTX> rev 0x10 int a irq 19 on pci0.17.0
> rl0: Ethernet address: 00:e0:7d:01:a5:07
> rl0: autoneg complete, link status good (half-duplex, 100Mbps)
> 
> The first card is on my dual PPro200 with 128MB RAM, aic7880, all SCSI.
> The second on is on my dual Pentium 133, 2GB EIDE, 1 GB SCSI on a BT-946c.
> Both are on a Hawking 10/100 dual speed hub with 10ft cat5 cable connecting
> them tothe hub.  There is also a HP/Apollo running NetBSD on the hub operating
> at 10Mb/s.  The Realtek cards are running at 100Mb/s half-duplex.
> 
> When I use ftp to transfer a file of size 9.5MB, if I am on the PPro machine,
> and type `put file`, I get about 1.5MB/s-2.5MB/s, and no collisions on either
> machine.  But, if I type `get file` from the PPro, I get between 4.5-5.5MB/s,
> and see about 340 collisions on each machine.  Is this to be expected because
> the Pentium is that much slower than the PPro machine with this driver?
> Is anyone else seeing this type of performance?  I remember Bill Paul saying
> he was seeing 11MB/s with a PII400.  How does it scale to what I have is
> what I am wondering, and if the performance I am seeing is to be expected.

Well, bear in mind that when I test, I typically just use ttcp to
source and receive data; this is not the same as using FTP, because
FTP also reads/writes files, which produes extra activity on the system
due to the disk controller. So you end up measuring the performance of
the NIC and the disks, which is not what you want.

The exception to this is if you have enough RAM in the system that
your test file fits entirely within the buffer cache: in this case,
after you've read or written the file the first time, it will stay
in RAM and there will be less disk activity (unless you overwrite it).
One test that I sometimes try is to 'get' a file to /dev/null a
couple of times. The first time causes the remote host to cache the
file so that subsequent retrieval attempts will be able to pull the
file right out of the buffer cache so that there will be no disk
activity. Getting the file to /dev/null means there will be no
activity on the receiving host either. (On Windoze, you can use
NUL: instead of /dev/null for the same effect. Unfortunately, you
can't 'put' a file to /dev/null: ftpd complains.)

Try this: go to ftp.sgi.com:/src/sgi/ttcp and get the file called
ttcp.c. Compile it with cc -O -o ttcp ttcp.c (you'll probably get a
few compilation warnings, but that's okay). Place a copy on both
machines.

On one host, do:

% ttcp -r > /dev/null

On the other, do:

% ttcp -s -n1000 -t <IP address of other host>

The -s flag means 'source data' and the -t means 'transmit.' This
will cause the one machine to send about 8MB of data back to the
first one. When it's done, you should see statistics printed on
both sides, including the transfer speed. This will let you generate
traffic without also generating disk activity, which will affect
the measurements. You can also swap the commands so that the second
host becomes the receiver and the first becomes the transmitter.
You can also do both at once. You can also increase the number of
blocks from 1000 to 10000 or more to increase the duration of the
test.

I have a single-CPU Pentium 200 machine with 64MB of RAM that I've
also been using for testing recently; on this machine, using a
driver that does buffer copies, transmit performance is usually
somewhere around 8MB/sec. The PII400 is usually much faster than
this, possibly because it can simply do bcopy()s much faster.

By contrast, when I tested the Macronix driver (which does not
require buffer copies) on the same P200 machine, I was able to
get around 10.5MB/sec transmit speed.

There are a couple of things you might try:

1) The PII 400Mhz machine I have is a Dell PowerEdge 2300/400 with
   two CPUs. I have noticed that a UP kernel has better transmit
   speed than an SMP kernel on the same hardware (using the same
   driver source). I'm not suggesting that you abandon SMP, but
   it would be interesting to see what happens if you use a UP
   kernel on these machines, just to see if it makes a difference.

2) The Dell machine has something like 6 PCI slots. If you look at
   the diagram plastered to the inside of the cover panel, it says
   that the first four are 'primary' slots, and the last two, which
   are mixed in among the ISA slots, are 'secondary.' I discovered
   one day that if I plug a card into one of these secondary slots,
   it works, but performance is terrible: a card that could transmit
   at 10MB/sec would suddenly only produce 3MB/sec tops. Moving the
   card back to one of the first four slots cured the problem.

   I don't know where you have your cards plugged in, but you might
   want to try shuffling them to different slots.

-Bill

-- 
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
Work:         wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812051822.NAA16071>