Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?000001c0bae7$d315d910$0200010a>