Date: Mon, 31 Dec 2001 14:44:42 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Julian Elischer <julian@elischer.org>, Mike Silbersack <silby@silby.com>, Josef Karthauser <joe@tao.org.uk>, Tomas Svensson <tsn@gbdev.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? Message-ID: <200112312244.fBVMigK35786@apollo.backplane.com> References: <Pine.BSF.4.21.0112311139180.9721-100000@InterJet.elischer.org> <200112311941.fBVJfvc25822@apollo.backplane.com> <3C30C5F9.BCC1BAE8@mindspring.com> <200112312017.fBVKHTs26004@apollo.backplane.com> <3C30E7B9.96EFA40F@mindspring.com>
index | next in thread | previous in thread | raw e-mail
Terry, I give up. Maybe if you actually tried to go in and fix it
you would see what I'm talking about. For your information:
* Julian's work has nothing to do with this particular problem. It
has to do with constricted bandwidth. This issue has nothing to do
with USB's bandwidth limitations.
* The window size is not negotiated between client and server (other
then whether window scaling is used or not, which is non-applicable).
Each side's TCP protocol receiver controls the window size it
advertises.
* The window size has no bearing on the number of in-transit packets,
unless you make assumptions in regards to the packet size. That's
the crux of the problem faced by the receiver in this case.
* If you think reducing the receive window on the fly is easy, try it
and you will find out that it isn't as easy as you might have
thought.
* And if you think you can handle that, now try figuring out, in the
receiver, how to dynamically increase and reduce the window based on
the size of the packets being received and try to discern the difference
between packet loss and a driver problem, to then limit the number
of in-transit packets (through a massive window reduction). Good luck!
* I never said the server was the problem. To the contrary, I've
been saying that the client is the problem.. USB ethernet is
broken, period.
As I have said, it may be possible to make new-reno on the client
(receiver) side to cause the transmit side to close its congestion
window (and to keep it closed, or fairly closed). But I aint gonna
be the one to try to do it.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112312244.fBVMigK35786>