Date: Mon, 01 Jul 2002 12:23:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Silbersack <silby@silby.com> Cc: Doug Barton <DougB@FreeBSD.org>, hawkeyd@visi.com, freebsd-hackers@FreeBSD.org Subject: Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi Message-ID: <3D20AC1C.72B60BC2@mindspring.com> References: <20020701135548.Y86208-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack wrote: > On Mon, 1 Jul 2002, Doug Barton wrote: > > The problem is that Terry has described the theory, whereas many of us > > who have observed the situation in the real world have noticed that even > > on a homogenous network (all with newreno enabled) performance is still > > worse than with newreno disabled. I guess you missed the part where I said that FreeBSD had bugs, and Matt Dillon posted patches? You guys are acting like this is something new that was recently discovered, like the recent SlashDot story on initial sequence numbers, which was first published a year and a quarter ago, but is somehow now magically, once again, "news". > > I don't have enough network stack fu to debug or improve this, but I > > have enough experience with it to know that off is better. For you, I'd > > say turning it off is the first thing you should test, and see what > > happens. > > I've been meaning to investigate, but I keep getting sidetracked... > > But yeah, I agree with you. Going back to plain reno isn't the end of the > world; it's still behaves decently and won't cause problems. "Off" has higher performance in the absence of congestion. If you can guarantee no congestion, I'd like to purchase network connectivity from you. I guess I will have to repeat Matt Dillon's postings verbatim to make the points that Matt, Poul, and others made with regard to NewReno and the FreeBSD failure case, as well as the workaround? "Off" is not the answer; "fix it" is the answer. If you can't do that, then "use Matt's workaround" is the answer. FWIW, Matt's workaround turns off NewReno for specific instances where it's known to fail because of trigerring on an incorrect one packet boundary, but it doesn't turn it off completely. This whole problem comes up every month or two, and has been known since NewReno was integrated, and has been characterized since Matt first looked at it in depth and provided patches. If you are running an old FreeBSD, then manually apply Matt's patches from the previous threads where this issue was discussed to death. -- Terry 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?3D20AC1C.72B60BC2>