From owner-freebsd-stable Sun Apr 1 12:54:37 2001 Delivered-To: freebsd-stable@freebsd.org Received: from stargate.compuware.com (stargate.compuware.com [166.90.248.158]) by hub.freebsd.org (Postfix) with SMTP id A780A37B71B for ; Sun, 1 Apr 2001 12:54:28 -0700 (PDT) (envelope-from driehuis@playbeing.org) Received: from [199.186.16.12] by stargate.compuware.com via smtpd (for hub.freebsd.org [216.136.204.18]) with SMTP; 1 Apr 2001 19:54:28 UT Received: from bh1.compuware.com (compuware.com [172.22.1.239]) by cwus-dtw-mr02.compuware.com (Postfix) with ESMTP id E28A574C21; Sun, 1 Apr 2001 15:54:17 -0400 (EDT) Received: from trashcan.nl.compuware.com ([172.16.16.52]) by bh1.compuware.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HWM0ZBF5; Sun, 1 Apr 2001 15:54:17 -0400 Received: from c1111.nl.compuware.com (c1111.nl.compuware.com [172.16.16.36]) by trashcan.nl.compuware.com (Postfix) with ESMTP id 48300145A4; Sun, 1 Apr 2001 21:54:16 +0200 (CEST) Date: Sun, 1 Apr 2001 21:54:16 +0200 (CEST) From: Bert Driehuis X-Sender: bertd@c1111.nl.compuware.com To: "Jason T. Luttgens" Cc: freebsd-stable@freebsd.org Subject: RE: Network performance question In-Reply-To: <000001c0bae2$c8c7dad0$0200010a@lucky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 1 Apr 2001, Jason T. Luttgens wrote: > One of the things I was using to judge performance was how big of a file the > tcpdump on the listening machine recorded under each OS (and the number of > packets reported). But maybe this is not the right way to do this.... Definitely not :-) > So, what would be a good way to test the performace differences between > Linux 2.2, 2.4 and FreeBSD as a device to capture 100% packets off the wire > and not miss any? Send a predictable load to the device under test (say, include a sequence number) and use that to determine packet loss (and, also interesting, packet loss patterns). You will also have to repeat the test with different cards on each OS. It is more than conceivable that one OS has better workarounds for specific ethernet hardware bugs than another, or even that different trade-offs were made for performance vs reliability. A case in point is the 3Com 3C905TX, which has a hardware bug that causes the device to lock up if the receive buffer fills beyond a certain limit. Limiting the buffer size has an obvious impact on throughput, but can make the card continue to work where it fails if left unchecked. Since vendors keep such hardware bugs under wraps, not all implementors may even be aware of the bugs, and that can hardly be blamed on them. As a sideline, I think this policy by the hardware vendors is counterproductive for them. If they just published the bugs and workarounds for it (and avoid overhyping their device, so that it still complies to the minimum specs specs after the workarounds are applied), I think they'd be better protected against ravenous lawyers than if they hide the problems until the truth is forced out in court (as in the floppy controller disaster that cost some vendors huge amounts of money). Oh well... Cheers, -- Bert -- Bert Driehuis -- driehuis@playbeing.org -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message