[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201001191309.03927.denys@visp.net.lb>
Date: Tue, 19 Jan 2010 13:09:03 +0200
From: Denys Fedoryshchenko <denys@...p.net.lb>
To: Damian Lukowski <damian@....rwth-aachen.de>,
Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
netdev@...r.kernel.org
Subject: Re: Crazy TCP bug (keepalive flood?) in 2.6.32?
On Tuesday 19 January 2010 11:10:12 you wrote:
> Hi,
> thank you for testing. So srtt and rttvar is zero in any of those cases.
> Ilpo, it is a bug in tcp_rtt_estimator then, I suppose?
>
> There is also a code comment in tcp_input.c, saying:
> > * NOTE: clamping at TCP_RTO_MIN is not required, current algo
> > * guarantees that rto is higher.
>
> So we either fix tcp_rtt_estimator or simply clamp at TCP_RTO_MIN?
>
> Damian
>
> > On Monday 11 January 2010 15:02:34 you wrote:
> >> On Sat, 26 Dec 2009, Denys Fedoryshchenko wrote:
> >>> Few more dumps. I notice:
> >>> 1)Ack always equal 1
> >>> 2)It is usually first segment of data sent (?)
> >>>
> >>> Maybe some value not initialised properly?
> >>
> >> Can you see if the RTO lower bound is violated (I added some printing of
> >> vars there too already now if it turns out to be something):
> >>
> >> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> >> index 65b8ebf..d84469f 100644
> >> --- a/net/ipv4/tcp_ipv4.c
> >> +++ b/net/ipv4/tcp_ipv4.c
As i see in code it is rounding RTO to minimum value.
It fixes my problem seems.
Btw just a bit about my environment - wireless networks (sometimes lossy!)
with low speed (128-512Kbps) customers working over pppoe. Maybe it will give
a tip why rtt value is too low.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists