From owner-freebsd-hackers Fri Nov 30 15: 8:16 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 4269037B405; Fri, 30 Nov 2001 15:08:12 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C5CB581D04; Fri, 30 Nov 2001 17:08:11 -0600 (CST) Date: Fri, 30 Nov 2001 17:08:11 -0600 From: Alfred Perlstein To: Jonathan Lemon Cc: Matthew Dillon , 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: <20011130170811.S46769@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> <20011130162832.N46769@elvis.mu.org> <20011130165747.I75389@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011130165747.I75389@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Fri, Nov 30, 2001 at 04:57:47PM -0600 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 * Jonathan Lemon [011130 17:00] wrote: > On Fri, Nov 30, 2001 at 04:28:32PM -0600, Alfred Perlstein wrote: > > > > 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. > > There isn't anything in the receiver side that does this; ACKs are sent > in response to incoming packets. However, state is maintained on the > sender side as to whether we are performing fast retransmit or not. Either you don't follow or my concept of what happens is off. What i'm saying is this, consider each pair to be in some form of time: h1 send: p1 p2 p3 h2 recv: p1 p3 h1 recv: (nothing acks lost) h2 send: ack1 ack1 ack1 (dude, i missed a packet) h1 send: (nothing, waiting for ack) h2 send: (nothing, waiting for retransmit) h1 send: p1 p2 p3 (ack timed out) h2 send: (nothing, waiting for retransmit) what should happen is this: h1 send: p1 p2 p3 h2 recv: p1 p3 h1 recv: (nothing acks lost) h2 send: ack1 ack1 ack1 (dude, i missed a packet) h2 send: ack1 ack1 ack1 (dude, i missed a packet) h1 recv: ack1 ack1 ack1 h1 send: p2 p3 Basically, will the reciever keep acking not if 'it detects packet loss', but rather 'as long as packets are lost'. -- -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