Date: Sun, 1 Apr 2001 16:10:39 -0400 From: "Jason T. Luttgens" <lucky@lansters.com> To: "'Bert Driehuis'" <driehuis@playbeing.org> Cc: <freebsd-stable@freebsd.org> Subject: RE: Network performance question Message-ID: <000001c0bae7$d315d910$0200010a@lucky> In-Reply-To: <Pine.BSI.4.21.0104012144270.4361-100000@c1111.nl.compuware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c0bae7$d315d910$0200010a>