From owner-freebsd-questions@FreeBSD.ORG Wed Dec 6 23:39:52 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB92816A47C for ; Wed, 6 Dec 2006 23:39:52 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 127EA43DC5 for ; Wed, 6 Dec 2006 23:37:24 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id kB6Nbonb017600; Wed, 6 Dec 2006 15:37:57 -0800 (PST) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id kB6Nbi52015164; Wed, 6 Dec 2006 15:37:47 -0800 (PST) In-Reply-To: <200612062246.WAA17265@sopwith.solgatos.com> References: <200612062246.WAA17265@sopwith.solgatos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 6 Dec 2006 15:37:43 -0800 To: freebsd@sopwith.solgatos.com X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-questions@freebsd.org Subject: Re: TCP parameters and interpreting tcpdump output X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 23:39:53 -0000 On Dec 6, 2006, at 6:46 AM, Dieter wrote: > I found a couple more things that don't look right. > > 000017 IP bsd.63743 > src.65001: . ack 52 win 65535 > 000107 IP bsd.63743 > src.65001: . ack 52 win 65535 > 000012 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535 > 000005 IP bsd.63743 > src.65001: F 52:52(0) ack 52 win 65535 > 000172 IP src.65001 > bsd.63743: . ack 53 win 4096 > 000004 IP src.65001 > bsd.63743: F 52:52(0) ack 53 win 4096 > 000003 IP src.65001 > bsd.63743: . ack 53 win 4096 > 000016 IP bsd.63743 > src.65001: . ack 52 win 65535 > 000011 IP bsd.63743 > src.65001: . ack 53 win 112 <------ why does > the window suddenly shrink? I'd guess because both sides have requested that the connection close...it's a bit hard to say because you're not including complete data over the life of a connection, or even the sequence numbers. ("tcpdump -nttt" or "tcpdump -ntttv" would be more informative.) > 002366 IP src.rfe > bsd.12340: P 1:1317(1316) ack 1 win 4096 > 099554 IP bsd.12340 > src.rfe: . ack 1317 win 65535 <------ why > does it take 99.5 millisec to ack? > > The ack time is normally 12 or 13 microseconds, which seems to be > okay. > But 99.5 milliseconds is *way* too slow, data will be lost. > > Is TCP sitting around waiting for a second packet, so that > it can be "efficient" and ack two packets at once? Yup. Coalescing data before sending it results in less overhead. > What can I do to fix this? Is there a knob I can turn to say > "ack every packet", or "only wait xxx microseconds for a 2nd packet" ? You can turn on TCP_NODELAY via setsockopt() to disable the Nagle algorithm. There are probably sysctl's you can tweak, also... -- -Chuck