Date: Fri, 30 Nov 2001 12:58:28 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: net@FreeBSD.ORG Subject: Re: TCP anomalies (was Re: FreeBSD performing worse than Linux?) Message-ID: <200111301758.fAUHwSP28351@khavrinen.lcs.mit.edu> In-Reply-To: <200111300647.fAU6l9K60404@prism.flugsvamp.com> References: <local.mail.freebsd-net/20011128102241.6887B380A@overcee.netplex.com.au> <local.mail.freebsd-net/20011128112006.195983808@overcee.netplex.com.au> <local.mail.freebsd-net/20011129105321.C74413@monorchid.lemis.com> <local.mail.freebsd-net/200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu> <local.mail.freebsd-net/200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com> <200111300647.fAU6l9K60404@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 30 Nov 2001 00:47:09 -0600 (CST), Jonathan Lemon <jlemon@flugsvamp.com> said: [Quoting Bruce Mah:] >> 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. Those are not duplicate acks because the window is still getting updated. >> 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. > Yes, I think that area (I was looking at it too) provides a fairly > good illustration that fast retransmits are broken. The transmit > at 14:01:42.969338 appears to be the retransmit timer finally kicking in. Yes, that's the conclusion Tim Shepard and I came to as well. -GAWollman 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?200111301758.fAUHwSP28351>