From owner-freebsd-hackers Fri Nov 30 14:28:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 1A05437B405; Fri, 30 Nov 2001 14:28:38 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 8871381D04; Fri, 30 Nov 2001 16:28:32 -0600 (CST) Date: Fri, 30 Nov 2001 16:28:32 -0600 From: Alfred Perlstein To: Matthew Dillon Cc: Nate Williams , Alexander Haderer , jlemon@freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?) Message-ID: <20011130162832.N46769@elvis.mu.org> References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011128104629.A43642@walton.maths.tcd.ie> <5.1.0.14.1.20011130181236.00a80160@postamt1.charite.de> <200111302047.fAUKlT811090@apollo.backplane.com> <200111302130.fAULUU324648@apollo.backplane.com> <15367.64883.390696.863120@caddis.yogotech.com> <200111302200.fAUM0hD27448@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111302200.fAUM0hD27448@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Nov 30, 2001 at 02:00:43PM -0800 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 [011130 16:02] wrote: > > Packet loss will screw up TCP performance no matter what you do. > NewReno, assuming it is working properly, can improve performance > for that case but it will not completely solve the problem (nothing will). > Remember that our timers are only good to around 20ms by default, so > even the best retransmission case is going to create a serious hicup. > > The question here is... is it actually packet loss that is creating > this issue for you and John, or is it something else? The only way > to tell for sure is to run tcpdump on BOTH the client and server > and then observe whether packet loss is occuring by comparing the dumps. > > I would guess that turning off delayed-acks will improve performance > in the face of packet loss, since a lost ack packet in that case will > not be as big an issue. I have an odd theory that makes use of my waning remeberence of the stack behavior, this may be totally off base but I'd appreciate it if you guys would consider this scenerio if at all to put my mind at ease. I seem to remeber several places in the stack that detect what looks like a hiccup and immediately begin sending a sequence of ACKs in order to trigger the other side's fast retrasmit code. One of the things that I don't remember seeing is that state is persistant. This means that in the face of packet loss, we may burst some ACKs then back off prematurely instead of sending another blast a couple of ms later if nothing has come back at us. This could cause a major stall. It especially makes sense because in the face of packet loss it may be both ways, meaning just because we screamed once "I DIDN'T GET THAT" doesn't mean the other side has heard our complaint. Is this a possiblity? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message