Date: Fri, 30 Nov 2001 16:28:32 -0600 From: Alfred Perlstein <bright@mu.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: 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: <20011130162832.N46769@elvis.mu.org> In-Reply-To: <200111302200.fAUM0hD27448@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Nov 30, 2001 at 02:00:43PM -0800 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>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011130162832.N46769>