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>