Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Mar 2000 10:01:12 +0100
From:      Martin Cracauer <cracauer@cons.org>
To:        Mike Smith <msmith@FreeBSD.ORG>
Cc:        yramin <yramin@redshift.com>, "Howard Leadmon <howardl@account.abs.net>" <howardl@account.abs.net>, freebsd-current@FreeBSD.ORG
Subject:   Re: Best NIC for FBSD (was: Buffer Problems and hangs in 4.0-CURRENT..)
Message-ID:  <20000316100112.A41214@cons.org>
In-Reply-To: <200003152053.MAA01346@mass.cdrom.com>; from msmith@FreeBSD.ORG on Wed, Mar 15, 2000 at 12:53:43PM -0800
References:  <200003152017.MAA19573@www.redshift.com> <200003152053.MAA01346@mass.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii

In <200003152053.MAA01346@mass.cdrom.com>, Mike Smith wrote: 
> > fxp0:  The Intel driver is by far the highest preformance model,
> > beats the 3com (second best) hands down with much lower CPU 
> > overhead.
> 
> Do you actually have any numbers to quantify this?  There's nothing in 
> the driver architecture nor any of my testing that would suggest this is 
> actually the case at this point.

I appended an old posting of mine. No 3com cards, though.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany     http://www.bsdhh.org/

--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=nic-bench

Date: Mon, 8 Feb 1999 14:53:25 +0100
From: Martin Cracauer <cracauer@cons.org>
To: chat@freebsd.org
Subject: 100Mbit ethernet card comparision
Message-ID: <19990208145325.A8384@cons.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i

I just had three 100MBit/sec ethernet cards in reach and though I
could do a little experimenting:

Operating Systems:
FreeBSD: FreeBSD-current from Jan, 22, 1999 (before 4.0 branch)
Linux: 2.2.0-pre9, userland mostly Debian-1.3.1

Ethernet cards:
de - DEC 21140
fxp - Intel 82558
rl - Realtek 8139

Machine: 
Celeron 300A in Asus P2B (BX) at 4.5x83.5MHz

Benchmark: Send 1 GB of data over a rsh connection, using cstream (a
dd replacement with accurate timing, bandwidth limiting and /dev/null
built in), using 8 KB blocks. The CPU numbers are taken from top(1)
with a delay of 15 seconds.

OS      Card	MioByte/sec	%user	%sys	%interrupt
----------------------------------------------------------
Linux	de	10.93-10.96	3	26-28	-
FreeBSD	de	10.70-10.72	3	29-31	4-5
FreeBSD	fxp	10.66-10.67	3	25-28	5-6
FreeBSD rl	10.55-10.56	3	28-31	14-16
Linux	rl	10.85-11.14	3	28-30	-
Linux	fxp	doesn't work

The fxp module (eepro100) on Linux loads, but ifconfiging hangs the
machine (reset button mode). 

The de (tulip) driver on Linux needs manual selection of media type,
whereas none of the other test combinations did (rl on Linux worked
out of the box). Of course, Linux doesn't have section 4 manpages for
drivers, so I went through the linux-src/Documentation -> C-source ->
Web site mentioned in there cicle as well. And had to specify options
at module load time (as compared to anytime with ifconfig under
FreeBSD) and had to calculate hex number OR combinations (where
FreeBSD has cleartext options). 

The Intel chip got hot, the Realtek and DEC stayed cool.

Well, one intersting question is: Where's that interrupt handler CPU
time on Linux? In system CPU time? Hidden?

To get a clearer picture, I did a benchmark that approached the
question "If two processes compete, and one just consumes userland CPU
and the other just tries to TCP stream over a more or less interrupt
intensive device, how much CPU does the CPU-intensive process get?"

I run a number of dhrystones one after another so that the time for
all of them was about 1 min. Just before the first dhrystone starts,
the same TCP streaming benchmark as above is being started, and
immedeatly after the dhrystones end SIGHUP is sent to the cstream
tool, which ends its loop then and reports the throughput.

OS/card         seconds r/u/s on	throughput of
		on CPU process		network process
-----------------------------------------------------
FreeBSD/de:	10.36/10.26/0.02	2.10 MioB/sec
FreeBSD/de:	10.36/10.26/0.02	2.21 MioB/sec
FreeBSD/rl:	10.41/10.24/0.02	0.38 MioB/sec
FreeBSD/rl:	10.39/10.24/0.02	0.28 MioB/sec
FreeBSD/rl:	10.41/10.24/0.02	0.24 MioB/sec
Linux/rl:	27.8/14.7/0.6		8.44 MioB/sec
Linux/rl:	22.9/14.4/4.4		6.50 MioB/sec
Linux/rl:	26.4/14.7/5.8		7.81 MioB/sec
Linux/de:	20.7/14.6/0.9		9.21 MioB/sec
Linux/de:	20.5/13.8/1.0		9.14 MioB/sec
Linux/de:	21.0/14.2/1.2		9.64 MioB/sec

Example read: With rl Ethernet, Linux leaves half the CPU for the CPU
intensive process and gets ~8 MB/sec for the networking process, while
FreeBSD leaves 99% CPU for the CPU eater and gets 0.25-0.4 MB/sec out
of the networking connection.

Remark: Don't ask me why a dhrystone takes more CPU on Linux than on
FreeBSD. Identical source, gcc-2.7.2.x, timings verified with
stopwatch etc. Probably a symbol more in a shared library.

It is not a typo that time(1) reports significant system CPU for the
dhrystones on some (but not all) of the Linux/rl runs. Definitivly bad
accounting here.

Quick shot answer: this looks like the time spent in the interrupt
handle is being added to unrelated userland processes.

Glad I asked: The supposed ninja-macho networker's tool FreeBSD is
actually a little slower, while the supposed
we-have-more-drivers-and-every-idiot-can-configure-them OS runs on one
out of three cards without problems, one with enough digging to drive
unconviced people away and crashes on the last.

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
  Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany

--n8g4imXOkfNTN/H1--


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




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