Date: Fri, 30 Nov 2001 16:57:47 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Alfred Perlstein <bright@mu.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Nate Williams <nate@yogotech.com>, Alexander Haderer <alexander.haderer@charite.de>, jlemon@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?) Message-ID: <20011130165747.I75389@prism.flugsvamp.com> In-Reply-To: <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> <20011130162832.N46769@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 30, 2001 at 04:28:32PM -0600, Alfred Perlstein wrote: > * Matthew Dillon <dillon@apollo.backplane.com> [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. 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. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011130165747.I75389>