Date: Tue, 14 Jun 2011 18:07:28 +0300 From: Daniel Kalchev <daniel@digsys.bg> To: Mikolaj Golub <trociny@freebsd.org> Cc: pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HAST instability Message-ID: <4DF77930.3060203@digsys.bg> In-Reply-To: <86ei2wmpg4.fsf@in138.ua3> References: <4DE21C64.8060107@digsys.bg> <4DE3ACF8.4070809@digsys.bg> <86d3j02fox.fsf@kopusha.home.net> <4DE4E43B.7030302@digsys.bg> <86zkm3t11g.fsf@in138.ua3> <4DE5048B.3080206@digsys.bg> <4DE5D535.20804@digsys.bg> <4DE8FE78.6070401@digsys.bg> <4DE90955.9020505@digsys.bg> <86zklp8vmg.fsf@kopusha.home.net> <86vcwd8vj8.fsf@kopusha.home.net> <4DF7647F.7020901@digsys.bg> <86ei2wmpg4.fsf@in138.ua3>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.06.11 17:56, Mikolaj Golub wrote: > It has turned out that automatic receive buffer sizing works only for > connections in ESTABLISHED state. And with small receive buffer the connection > might stuck sending data only via TCP window probes -- one byte every few > seconds (see "Scenario to make recv(MSG_WAITALL) stuck" in net@ for details). > I have tried some TCP/IP tuning to help utilize the faster network, but for the moment it is likely local disks limit the throughput to about 230 MB/sec peak. The peaks now are the same as before, but now the total performance is better. However, it may turn out that single TCP/IP session across 10Gbit network would not be able to achieve very high throughput. It may be beneficial to support multiple parallel TCP/IP connections between primary/slave in order to utilize faster networks. Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DF77930.3060203>