From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 16:24:08 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 868BE1065670 for ; Thu, 18 Feb 2010 16:24:08 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E4CEC8FC16 for ; Thu, 18 Feb 2010 16:24:07 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1IGO6C4039719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 17:24:06 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D69A5.4010506@omnilan.de> Date: Thu, 18 Feb 2010 17:24:05 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Stephen Hurd 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> <4B7D6635.20605@sasktel.net> In-Reply-To: <4B7D6635.20605@sasktel.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD29873D2A213BACAF2C862D3" 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:24:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD29873D2A213BACAF2C862D3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stephen Hurd schrieb am 18.02.2010 17:09 (localtime): =2E.. > A TCP SHOULD implement a delayed ACK, but an ACK should not be=20 > excessively delayed; in particular, the delay MUST be less than 0.5=20 > seconds, and in a stream of full-sized segments there SHOULD be an ACK = > for at least every second segment. That's why I asked for help understandig TCP. I'm surely wrong then. I=20 thought the ACK segment gets sent after the transfer of n segments=20 equals windows-size. I don't undesrtand that window size yet... I'm back = into my books > The idea of delayed ACKs is to allow an ACK to be sent with data if=20 > there will be data sent right away, not to combine ACKs... leaving out = > ACKs makes calculation of RTT problematical which causes performance=20 > problems all over the place... maybe the dearth of ACKs from the window= s=20 > system is causing the problem? The problem is not with the windows box, these transfer rates are=20 sensible. The problem is with two RELENG_8 machines. I'm doing this whole thing because I observed slowdowns under 20MB/s and = I try to reproduce and investigate this. But first I have to get the=20 idea right... If I don't understamd things going on when transfers make=20 sense, I won't be able to determine what happens when transfers are=20 slowed down... Thanks, -Harry --------------enigD29873D2A213BACAF2C862D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkt9aaYACgkQLDqVQ9VXb8gYpQCfeJSz+CmIPUe47T+IEdKL+Rtf SqoAn1DOzDMZ4aIRgIE+wSg3v9fv4Gcp =GF9X -----END PGP SIGNATURE----- --------------enigD29873D2A213BACAF2C862D3--