Date: Thu, 4 Aug 2011 15:19:54 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Lawrence Stewart" <lstewart@freebsd.org> Cc: freebsd-net@freebsd.org, Andre Oppermann <andre@freebsd.org>, slw@zxy.spb.ru Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? Message-ID: <20229216858044E4881642284F245750@multiplay.co.uk> References: <E18D678F05BB4F3B93ADEB304CCA8504@multiplay.co.uk><1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk><4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <C706DEE346684B8DB06CFC090F556E72@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Lawrence Stewart" <lstewart@freebsd.org>
> Thanks for bringing me in directly, I haven't been keeping up with the
> mailing lists at all recently.
No problem
>> So I suppose the question is should maxsegments be larger by
>> default due to the recent changes e.g.
>> - V_tcp_reass_maxseg = nmbclusters / 16;
>> + V_tcp_reass_maxseg = nmbclusters / 8;
>>
>> or is the correct fix something more involved?
>
> I'm not sure if bumping the value is appropriate - we have always
> expected users to tune their network stack to perform well when used in
> "unusual" scenarios - a large BDP fibre path still being in the
> "unusual" category.
TBH I wouldn't classify a latency of 7ms @ 100Mbps unusal in the slightest
in this day and age.
> The real fix which is somewhere down on my todo list is to make all
> these memory constraints elastic and respond to VM pressure, thus
> negating the need for a hard limit at all. This would solve many if not
> most of the TCP tuning problems we currently have with one foul swoop
> and would greatly reduce the need for tuning in many situations that
> currently are in the "needs manual tuning" basket.
This would indeed be a great improvement.
> Andre and Steven, I'm a bit too sleepy to properly review your combined
> proposed changes right now and will follow up in the next few days instead.
No problem, we've increased nmbclusters on all our machines and there now
performing fine in the problem scenario so no rush, look forward to your
feedback when you've had some sleep :)
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20229216858044E4881642284F245750>