From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:09:28 2010 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 E06DF106566C for ; Thu, 18 Feb 2010 16:09:28 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from neutron.sasknet.sk.ca (neutron.sasknet.sk.ca [142.165.20.180]) by mx1.freebsd.org (Postfix) with ESMTP id A5C458FC2B for ; Thu, 18 Feb 2010 16:09:28 +0000 (UTC) Received: from pps.filterd (neutron [127.0.0.1]) by neutron.sasknet.sk.ca (8.14.3/8.14.3) with SMTP id o1IG8PYw029933 for ; Thu, 18 Feb 2010 10:09:28 -0600 Received: from bgmpomr2.sasknet.sk.ca (bgmpOMR2.sasknet.sk.ca [142.165.72.23]) by neutron.sasknet.sk.ca with ESMTP id m18ac25qv-1 for ; Thu, 18 Feb 2010 10:09:27 -0600 Received: from ace.hurd.local (outgoing.bbsdev.net [76.202.204.46]) by bgmpomr2.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTPA id <0KY100MUIOVQMJ00@bgmpomr2.sasknet.sk.ca> for freebsd-stable@freebsd.org; Thu, 18 Feb 2010 10:09:27 -0600 (CST) Date: Thu, 18 Feb 2010 08:09:25 -0800 From: Stephen Hurd In-reply-to: <4B7D61DE.2020906@omnilan.de> To: Harald Schmalzbauer Message-id: <4B7D6635.20605@sasktel.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> <4B7D3938.1000309@omnilan.de> <4B7D5AC4.9020509@mahan.org> <4B7D61DE.2020906@omnilan.de> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20091205 SeaMonkey/1.1.18 Mnenhy/0.7.6.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-18_10:2010-02-06, 2010-02-18, 2010-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002180110 Cc: freebsd-stable@freebsd.org, Patrick Mahan Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] 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: Thu, 18 Feb 2010 16:09:29 -0000 Harald Schmalzbauer wrote: > Some experimental results: > When rsyncing with windows, and FreeBSD is receiver, I see the same > ACK ever two segemnts, but speed is at 72MB/s. > When FreeBSD is sender and Windows is receiver, it looks more I > expected. There are about 20 data segments before a ACK is returned. > And there are TCP Window Update Segments, reflecting smaller receiver > buffers on the windows side. But this happens at a throughput of > 82MB/s!!! So the windows machine is behaving like I understand the TCP > flow control. > Any explanation why the FreeBSD machine seems to ignore window size? Yes, here we are in RFC1122: 4.2.3.2 When to Send an ACK Segment A host that is receiving a stream of TCP data segments can increase efficiency in both the Internet and the hosts by sending fewer than one ACK (acknowledgment) segment per data segment received; this is known as a "delayed ACK" [TCP:5]. A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. The idea of delayed ACKs is to allow an ACK to be sent with data if there will be data sent right away, not to combine ACKs... leaving out ACKs makes calculation of RTT problematical which causes performance problems all over the place... maybe the dearth of ACKs from the windows system is causing the problem?