From owner-freebsd-stable@FreeBSD.ORG Tue Jun 14 15:07:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD4151065670; Tue, 14 Jun 2011 15:07:39 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id F184F8FC0A; Tue, 14 Jun 2011 15:07:38 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p5EF7SeG056848 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 18:07:34 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DF77930.3060203@digsys.bg> Date: Tue, 14 Jun 2011 18:07:28 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mikolaj Golub 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> In-Reply-To: <86ei2wmpg4.fsf@in138.ua3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HAST instability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:07:39 -0000 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