: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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
