From owner-freebsd-net@FreeBSD.ORG  Tue Mar  8 21:02:26 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BD93C16A4CE
	for <freebsd-net@freebsd.org>; Tue,  8 Mar 2005 21:02:26 +0000 (GMT)
Received: from casselton.net (casselton.net [63.165.140.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5C4FB43D53
	for <freebsd-net@freebsd.org>; Tue,  8 Mar 2005 21:02:26 +0000 (GMT)
	(envelope-from tinguely@casselton.net)
Received: from casselton.net (localhost [127.0.0.1])
	by casselton.net (8.12.11/8.12.11) with ESMTP id j28L2BcJ036186;
	Tue, 8 Mar 2005 15:02:11 -0600 (CST)
	(envelope-from tinguely@casselton.net)
Received: (from tinguely@localhost)
	by casselton.net (8.12.11/8.12.11/Submit) id j28L26HR036180;
	Tue, 8 Mar 2005 15:02:06 -0600 (CST)
	(envelope-from tinguely)
Date: Tue, 8 Mar 2005 15:02:06 -0600 (CST)
From: Mark Tinguely <tinguely@casselton.net>
Message-Id: <200503082102.j28L26HR036180@casselton.net>
To: daniel@benzedrine.cx, tinguely@casselton.net
In-Reply-To: <20050308173907.GG26999@insomnia.benzedrine.cx>
X-Spam-Status: No, score=1.4 required=5.0 tests=REPLY_TO_EMPTY autolearn=no 
	version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ccn.casselton.net
cc: freebsd-net@freebsd.org
cc: spork@fasttrackmonkey.com
Subject: Re: FreeBSD 4.x and OS-X tcp performance
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2005 21:02:26 -0000


>  In this particular case, the server is increasing the window size with
>  subsequent ACKs. What does this mean? The receive buffer became less
>  full so quickly? The receive buffer was enlarged?

The last ACKs that you mention are window update notifications that the client
application removed data from the recieve buffer. The recieving application
on the FreeBSD machine fell way behind the sender. When the recieving host
lost a packet, the new data will go into the fragment reassembly area and
not the socket. The recieving application starts to catch up.

Strange this does not happen a lot.

--Mark Tinguely