Date: Mon, 7 Mar 2005 21:48:25 +0100 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Charles Sprickman <spork@fasttrackmonkey.com> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance Message-ID: <20050307204825.GY26999@insomnia.benzedrine.cx> In-Reply-To: <Pine.OSX.4.61.0503071358310.5816@oof.local> References: <Pine.OSX.4.61.0503041726460.5816@oof.local> <Pine.OSX.4.61.0503041841060.5816@oof.local> <20050305024850.GA96307@wjv.com> <Pine.OSX.4.61.0503061628260.5816@oof.local> <20050307090802.GR26999@insomnia.benzedrine.cx> <Pine.OSX.4.61.0503071358310.5816@oof.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 07, 2005 at 02:04:01PM -0500, Charles Sprickman wrote: > 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... Data is flowing only in one direction (from client to server), so we see the client sending payload and the server acknowledging it. As long as no packets are lost and the server keeps acknowledging, the client could send one continuous stream of maximum sized payload packets. However, if the server stops acknowledging, the client must stop sending more data once it has filled up the window advertised by the server and wait for the server to either acknowledge further data or increase its window. Nothing exciting happens until timestamp 16:41:29.008909 in your log. 16:41:29.008672 client 321457:322905(1448) 16:41:29.008751 server ack 322905 win 7240 16:41:29.008909 client 324353:325801(1448) Since the log represents the server's view, the lack of segment 324353:322905 in the log means that this packet from the client was lost in transit. Now the server keeps acknowledging 322905, and we expect the client to notice and retransmit the lost segment. 16:41:29.009064 server ack 322905 win 7400 16:41:29.009146 client 325801:327249(1448) 16:41:29.009233 server ack 322905 win 8424 16:41:29.009409 client 328697:330145(1448) 16:41:29.009521 server ack 322905 win 9448 The client hasn't noticed yet and is still sending further segments past the gap. The server is advertising increasing window sizes, probably because it's still draining the data up to the gap. Notice that there's a new gap created as 327249:328697(1448) was lost. 16:41:29.011250 client 335937:337385(1448) 16:41:29.011331 server ack 322905 win 14568 Now the client has filled up the window. If it doesn't retransmit now, it has to stall. It can't send anymore higher segments because the window is full. 16:41:29.011758 client 322905:324353(1448) Finally, the retransmit. 16:41:29.011919 server ack 327249 win 10224 Now the server acknowledges up the the second gap. 16:41:29.021620 server ack 327249 win 13296 ... 16:41:29.024911 server ack 327249 win 56304 And keeps acknowledging the same, while the window grows again. But nothing from the client. 16:41:29.146218 192.168.0.40.58347 > home.manymonkeys.com.ftp: . ack 376 win 65535 <nop,nop,timestamp 38 05665564 543875729> (DF) [tos 0x10] Odd, an acknowledgment on the FTP control connection just at this time. I don't know what that means, but it's not a coincidence, I'd bet. 16:41:30.462822 client 327249:328697(1448) Now the client finally retransmitted the segment from the second gap. But look at the timestamp, about 1.4 seconds have passed, which is much too long. After that, things go back to normal. The same thing repeats nine more times throughout the connection. You can spot the places by comparing subsequent timestamps. You'll find the spots where there are >1s delays in between two packets. > The tcpdump was run on the server (FBSD). Later today I will gladly do > this again with a dump from each side. Before we blame the client, let's look at the dump from the client. Maybe the client is trying to retransmit earlier, but those packets get lost. It's just odd that this would happen for more than a full second. Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050307204825.GY26999>