From owner-freebsd-net@FreeBSD.ORG Mon Mar 7 09:08:09 2005 Return-Path: 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 AE6D916A4CE for ; Mon, 7 Mar 2005 09:08:09 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BB543D39 for ; Mon, 7 Mar 2005 09:08:08 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j27983nF021361 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2005 10:08:03 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j27982I1025368; Mon, 7 Mar 2005 10:08:02 +0100 (MET) Date: Mon, 7 Mar 2005 10:08:02 +0100 From: Daniel Hartmeier To: Charles Sprickman Message-ID: <20050307090802.GR26999@insomnia.benzedrine.cx> References: <20050305024850.GA96307@wjv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 09:08:09 -0000 On Sun, Mar 06, 2005 at 04:45:30PM -0500, Charles Sprickman wrote: > For fun I'm going to post a full tcpdump of an ftp session from one box to > the other, maybe someone can spot something there? It's attached and > bzip'd. It's a tcpdump of both hosts transferring a 1MB tarfile. I can only find an FTP control connection and _one_ data connection in that dump. Client 192.168.0.40 is uploading one file of about 1.6MB to server home.manymonkeys.com. There's a pattern in the dump, looks like a TCP problem. The client pushes data to the server. Every now and then, packets are lost. Mostly, the client retransmits normally. But ten times, it seems to ignore the server ACKing below a lost segment. It quickly gets several ACKs but only retransmits the lost segment after a full 1.4 seconds. This accounts for a total of 14.5 seconds of stalling the upload. The entire transfer is 15.02 seconds, so the 1.6MB are actually uploaded in 0.5 seconds, and the stalling entirely accounts for the slow throughput. Looks like the client is at fault. There's window scaling, but with scale factors 0. No SACK. I think the client should retransmit earlier. Which OS is running on which of those hosts? Which host did you tcpdump on (or was it on a third machine, in between)? Could you get a tcpdump from both server and client simultanously for the same connection, so we can see where packets are lost, and get both peers' point of view? Would be interesting to see a tcpdump of a connection from the same client (same OS) to a different server OS, which works fine. Daniel