From owner-freebsd-hackers Mon Dec 31 14:44:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B67E837B416 for ; Mon, 31 Dec 2001 14:44:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBVMigK35786; Mon, 31 Dec 2001 14:44:42 -0800 (PST) (envelope-from dillon) Date: Mon, 31 Dec 2001 14:44:42 -0800 (PST) From: Matthew Dillon Message-Id: <200112312244.fBVMigK35786@apollo.backplane.com> To: Terry Lambert Cc: Julian Elischer , Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112311941.fBVJfvc25822@apollo.backplane.com> <3C30C5F9.BCC1BAE8@mindspring.com> <200112312017.fBVKHTs26004@apollo.backplane.com> <3C30E7B9.96EFA40F@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message