Date: Mon, 7 Mar 2005 14:04:01 -0500 (EST) From: Charles Sprickman <spork@fasttrackmonkey.com> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance Message-ID: <Pine.OSX.4.61.0503071358310.5816@oof.local> In-Reply-To: <20050307090802.GR26999@insomnia.benzedrine.cx> References: <Pine.OSX.4.61.0503041726460.5816@oof.local> <20050305024850.GA96307@wjv.com> <20050307090802.GR26999@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Mar 2005, Daniel Hartmeier wrote: > 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. Correct. 192.168.0.40 is the OS-X box, home.manymonkeys.com (192.168.0.6) is the FreeBSD box. I sent a 1.6MB tar archive via ftp. > 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. Very interesting, thank you for that read of the tcpdump output. If you have the time, could you post back a few lines of the tcpdump with comments so that I might learn a little about what's going on? I don't have the best understanding of the intricacies of tcp... > 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? The tcpdump was run on the server (FBSD). Later today I will gladly do this again with a dump from each side. > Would be interesting to see a tcpdump of a connection from the same > client (same OS) to a different server OS, which works fine. I will do that as well from both ends. The other box will be OpenBSD 3.3 (anything beyond 3.3 panics on boot, so I'm stuck at 3.3). For giggles I'll do a dump of a transfer via udp (NFS) between the problem boxes to see if any packet loss is happening... Thanks very much, Charles > Daniel >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSX.4.61.0503071358310.5816>