[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0712041031110.18529@kivilampi-30.cs.helsinki.fi>
Date: Tue, 4 Dec 2007 10:37:52 +0200 (EET)
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To: Lachlan Andrew <lachlan.andrew@...il.com>
cc: Stephen Hemminger <shemminger@...ux-foundation.org>,
shaoliu@...nceton.edu, "David S. Miller" <davem@...emloft.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
Douglas Leith <doug.leith@...m.ie>,
Robert Shorten <robert.shorten@...m.ie>,
Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] TCP illinois max rtt aging
On Mon, 3 Dec 2007, Lachlan Andrew wrote:
> On 03/12/2007, Stephen Hemminger <shemminger@...ux-foundation.org> wrote:
> > On Mon, 3 Dec 2007 15:59:23 -0800
> > "Shao Liu" <shaoliu@...nceton.EDU> wrote:
> > > And also a question, why the samples when SACK is active are outliers?
> >
> > Any sample with SACK is going to mean a loss or reordering has occurred.
> > So shouldn't the SACK values be useful, but RTT values from retransmits
> > are not useful.
>
> When SACK is active, the per-packet processing becomes more involved,
> tracking the list of lost/SACKed packets. This causes a CPU spike
> just after a loss, which increases the RTTs, at least in my
> experience.
I suspect that as long as old code was able to use hint, it wasn't doing
that bad. But it was seriously lacking ability to take advantage of sack
processing hint when e.g., a new hole appeared, or cumulative ACK arrived.
...Code available in net-2.6.25 might cure those.
--
i.
--
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