Date: Fri, 30 Nov 2001 15:08:16 -0700 From: Nate Williams <nate@yogotech.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Nate Williams <nate@yogotech.com>, Alexander Haderer <alexander.haderer@charite.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: Found the problem, w/patch (was Re: FreeBSD performing worse than Linux?) Message-ID: <15368.848.656239.615432@caddis.yogotech.com> In-Reply-To: <200111302200.fAUM0hD27448@apollo.backplane.com> 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
> :Note, my experiences (and John Capos) are showing degraded performance > :when *NOT* on a LAN segment. In other words, when packet loss enters > :the mix, performance tends to fall off rather quickly. > : > :This is with or without newreno (which should theoretically help with > :packet loss). John claims that disabling delayed_ack doesn't seem to > :affect his performance, and I've not been able to verify if delayed_ack > :helps/hurts in my situation, since the testers have been pressed for > :time so I can't get them to iterate through the different settings. > : > :I do however have some packet dumps, although I'm not sure they will > :tell anything. :( > : > :Nate > > Packet loss will screw up TCP performance no matter what you do. I know, dealing with that issue is my day job. :) My point is that older FreeBSD releases (and newer Linux releases) seem to be dealing with it in a more sane manner. At least, it didn't effect performance nearly as much as it does in newer releases. > 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. See above. > The question here is... is it actually packet loss that is creating > this issue for you and John, or is it something else? In my opinion, it's how the TCP stack recovers from packet loss that is the problem. > 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. Unfortunately, I'm unable to run tcpdump on the client, since it's running NT and we're not allowed to install any 3rd party apps on it (such as the WinDump package). I'm not saying that I expect the same results as I get on the LAN segment, but I *am* expecting results that are equivalent to what we were seeing with FreeBSD 3.x, and those that are in the same ballpark (or better) than the Linux systems sitting next to it. Given that I get great LAN resuls, I no longer suspect I have a ethernet autonegotiation problem, since I can get almost wire-speeds with local nodes, and close to maximum performance with our wireless products when the network segment the FreeBSD server is relatively idle. > 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'm not sure I agree. I wouldn't expect it would help/hinder the performance assuming a correctly performing stack, *UNLESS* the packet loss was completely due to congestion. In that case, delayed-acks *may* improve things, but I doubt it would help much with TCP backoff and such. Nate 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?15368.848.656239.615432>