Date: Thu, 29 Nov 2001 21:18:33 -0800 From: "Bruce A. Mah" <bmah@FreeBSD.ORG> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Greg Lehey <grog@FreeBSD.ORG>, net@FreeBSD.ORG Subject: TCP anomalies (was Re: FreeBSD performing worse than Linux?) Message-ID: <200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com> In-Reply-To: <200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu> References: <20011128102241.6887B380A@overcee.netplex.com.au> <20011128112006.195983808@overcee.netplex.com.au> <20011129105321.C74413@monorchid.lemis.com> <200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1808650111P Content-Type: text/plain; charset=us-ascii If memory serves me right, Garrett Wollman wrote: > Each trace shows a single large file transfer from a 4.4-stable > machine to my -current desktop over a local-area network. I'm pretty rusty at debugging TCP implementations, but I'll try to contribute something... Your 4.4-STABLE machine, is it from before or after rev 1.107.2.18 of sys/netinet/tcp_input.c? (Mon Nov 12 22:11:24 2001 UTC) I'm not sure how relevant this point is, but some of the anomalies I noticed seem related to fast retransmit (see below). Also...where did you do the trace (i.e. sender, receiver, or a third machine)? > test4 was > aborted about 10% into the transfer so that you have a chance at > looking at the whole thing in xplot. There are multiple pathologies > visible in the results, but a good place to start would be around > :56.44 in test4. test4 was the only trace I looked at. One thing that caught my eye is that the receiver seems to be sending a bunch of dupacks (in some cases, many more than needed to trigger fast retransmit) but no retransmit happens. In *most* cases, the receiver somehow gets the missing data because you can later see it acking later sequence numbers. The first place I saw this was at :41.504152. This looks a little odd, but it *could* be explained by data segments getting misordered somewhere and the dupacks getting lost. Another place to look is the large number of consecutive dupacks starting around :41.978767. I don't know what's happening here, but after a long time (about a second?!?) the sender finally gives up and sends the receiver what it wants. Cheers, Bruce. --==_Exmh_1808650111P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Exmh version 2.3.1+ 05/14/2001 iD8DBQE8Bxap2MoxcVugUsMRApAMAKDvOa1CwUxLt/XYWS+/eatsEX1N/QCfUwbt ce2ewwfnFV79kzsG6xRYgQA= =ha30 -----END PGP SIGNATURE----- --==_Exmh_1808650111P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111300518.fAU5IXx11078>