From owner-freebsd-stable@FreeBSD.ORG Thu Feb 18 12:57:38 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 E0C1B106566C for ; Thu, 18 Feb 2010 12:57:38 +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 4DFF48FC15 for ; Thu, 18 Feb 2010 12:57:37 +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 o1ICvaWY036598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Feb 2010 13:57:36 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B7D3938.1000309@omnilan.de> Date: Thu, 18 Feb 2010 13:57:28 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Chuck Swiger References: <4B7C1365.9070806@omnilan.de> <70CD649D-7659-4CE2-A16C-49B8C891CB5B@mac.com> <4B7C4066.5040006@omnilan.de> In-Reply-To: <4B7C4066.5040006@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA4590C226364FBF460EE45E" Cc: freebsd-stable@freebsd.org Subject: 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 12:57:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA4590C226364FBF460EE45E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 17.02.2010 20:15 (localtime): =2E.. >>> Now my first idea is to compare MSS and windows sizes before and afte= r the performance drop. >>> How do I best capture them? tdpcump? It's GbE linkspeed... >> It seems more likely that ZFS is running into slowdowns from resource = contention, memory fragmentation, etc than your network would suddenly dr= op out, but tcpdump -w outfile.pcap is a good method of looking.... >=20 > Thanks, but fisrt tests showed that ZFS is not causing the slowdown. Hello, I got exactly the same limitations when using tmpfs. So for now I'll=20 concentrate on that, back to ZFS later. Please clarify my TCP understanding. If I have the window set to 65535 in the header and a MSS of 1460, how=20 often should the receiver send ACK segments? window/MSS, right? Now I see every two segments acknowledged in my dump (rsync between two=20 em0 interaces). I'd like to understand a) why disabling net.inet.tcp.rfc1323 gives slightly better rsync=20 throughput than enabled b) why I can't transfer more than 50MB/s over my direct linked GbE boxes.= But right now I even don't understand the dump I see. As far as I=20 understand I should only see every 45 data segments one ACK segment.=20 That would clearly explain to me why I can't saturate my GbE link. But I = can't imagine this is a uncovered faulty behaviour, so I guess I haven't = understood TCP. Please help. Thanks in advance, -Harry --------------enigDA4590C226364FBF460EE45E 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) iEYEARECAAYFAkt9OUAACgkQLDqVQ9VXb8hkMgCgj1MefInItFaZNUR0MYGKy0yh MesAoIFExZul/0EiKCDnIIf60SMC+xVW =yH9D -----END PGP SIGNATURE----- --------------enigDA4590C226364FBF460EE45E--