Date: Fri, 30 Nov 2001 12:59:53 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: Leo Bicknell <bicknell@ufp.org>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: TCP Performance Graphs Message-ID: <200111302059.fAUKxrI19553@apollo.backplane.com> References: <Pine.BSF.4.30.0111301523400.3797-100000@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I don't think anyone's doubting the importance of larger windows; it's
:just that we can't do much increasing until they're dynamic.
:
:That being said, Matt did post a patch which implements socket buffer
:autoscaling a few months back. I've been meaning to review it, but
:haven't had the time. If you can give it some good testing and prove that
:it provides better performance in most cases (and hopefully no
:regressions), I suspect that might provide the momentum to get it
:looked at by more people and committed.
:
:Mike "Silby" Silbersack
One of the things that came out of that conversation, however, was
that it should be safe to increase the receive-side window, because
programs typically drain the receive buffers the moment data comes
in.
So I think we can safely increase the dfeault net.inet.tcp.recvspace
from 16384 to 32768 immediately.
The transmit side requires more thought. I did write that patch, and
it does work, but it's too messy for my tastes. I would personally
much rather rewrite it to (A) fix the RTT stored in the route tables
and (B) adjust the transmit window based on that, which is a much less
sophisticated patch (and less messy), but ought to work quite well
in regards to transmit buffer management.
After I figure out this 80K/sec problem I'll revisit the transmit-side
buffer limiting based on my new proposal above.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200111302059.fAUKxrI19553>