From owner-freebsd-hackers Mon Dec 31 11:22:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 5AE6C37B430 for ; Mon, 31 Dec 2001 11:22:53 -0800 (PST) Received: from pool0439.cvx21-bradley.dialup.earthlink.net ([209.179.193.184] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16L81J-00006j-00; Mon, 31 Dec 2001 11:22:50 -0800 Message-ID: <3C30BB0C.7061DCCD@mindspring.com> Date: Mon, 31 Dec 2001 11:22:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Mike Silbersack , Josef Karthauser , Tomas Svensson , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? References: <200112310704.fBV74Wb18947@apollo.backplane.com> <3C30B31C.FFD2363B@mindspring.com> <200112311902.fBVJ2kk21403@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Matthew Dillon wrote: > :Cap the window size via the driver. This will probably require > :another attribute on all drivers, indicating "max allowable window > :size" ("0" could mean "any", and be used as the default so that we > :don't end up flaking out someone talking to Mars). > > It won't help. The problem is that the server is sending more > data then the client USB adapter can handle. If the client limits > its window size with the expectation that the server will send it > small packets, then any *other* transfer that uses larger packets > will have terrible performance. I'm talking about capping the maximum negotiable window size over the USB adapter... How can this cause problems, since (1) the only thing we are talking about is window size, not packet size (MTU), and (2) the only thing it will effect is the TCP stream post negotiation, so it should not result in a slowdown for any virtual circuit other than those that *NEED* a slowdown? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message