Date: Fri, 30 Nov 2001 10:05:15 -0800 From: jayanth <jayanth@yahoo-inc.com> To: "Bruce A. Mah" <bmah@FreeBSD.ORG> Cc: net@FreeBSD.ORG Subject: Re: FreeBSD performing worse than Linux? Message-ID: <20011130100515.C63426@yahoo-inc.com> In-Reply-To: <200111300527.fAU5R0s11199@c527597-a.cstvl1.sfba.home.com>; from bmah@FreeBSD.ORG on Thu, Nov 29, 2001 at 09:27:00PM -0800 References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011129004234.A16101@exuma.irbs.com> <200111300527.fAU5R0s11199@c527597-a.cstvl1.sfba.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm, this is what has broken fast retransmit.
I should probably replace
if (tp->t_dupacks < tcprexmtthresh)
tp->t_dupacks = 0;
with
if (tcp_do_newreno && (tp->t_dupacks < tcprexmtthresh))
tp->t_dupacks = 0;
jayanth
Bruce A. Mah (bmah@FreeBSD.ORG) wrote:
> If memory serves me right, John Capo wrote:
>
> [TCP weirdness]
>
> > I see exactly the same behavior on 3 -stable machines running kernels
> > from late October and early November. Another -stable machine with
> > a kernel from late September does pause but not as consistently as
> > the later kernel machines do. The client machine is running a
> > kernel from early November.
>
> How early in November? I'm staring at this commit message and
> wondering if it has any relevance to your situation:
>
> -----
> revision 1.107.2.18
> date: 2001/11/12 22:11:24; author: nate; state: Exp; lines: +3 -1
> MFH: V1.139
> when newreno is turned on, if dupacks = 1 or dupacks = 2 and
> new data is acknowledged, reset the dupacks to 0.
> The problem was spotted when a connection had its send buffer full
> because the congestion window was only 1 MSS and was not being incremented
> because dupacks was not reset to 0.
>
> Reviewed by: jlemon
> -----
>
> Bruce.
>
>
>
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?20011130100515.C63426>