From owner-freebsd-stable Sun Apr 1 13:11:15 2001 Delivered-To: freebsd-stable@freebsd.org Received: from snapper.lansters.com (21-155-124-64.dsl.lan2wan.com [64.124.155.21]) by hub.freebsd.org (Postfix) with ESMTP id 9EE4537B718 for ; Sun, 1 Apr 2001 13:11:10 -0700 (PDT) (envelope-from lucky@lansters.com) Received: from lucky (lucky.lansters.com [10.1.0.2]) by snapper.lansters.com (8.11.2/8.9.3) with SMTP id f31KB7h01146; Sun, 1 Apr 2001 16:11:07 -0400 (EDT) (envelope-from lucky@lansters.com) From: "Jason T. Luttgens" To: "'Bert Driehuis'" Cc: Subject: RE: Network performance question Date: Sun, 1 Apr 2001 16:10:39 -0400 Message-ID: <000001c0bae7$d315d910$0200010a@lucky> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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). Well, I thought that I was doing this by using a known set of data from the tcpdump I captured earlier and was replaying. Each time it replays, it is the same number of packets and payload content. The network I am testing on is isolated (not connected to anything else but these two computers). I'm not sure I see the difference between what you describe and what I did. What do I need to do to create the environment you mention? >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