[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1432664721.4060.294.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Tue, 26 May 2015 11:25:21 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ido Yariv <ido@...ery.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>,
Nandita Dukkipati <nanditad@...gle.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Ido Yariv <idox.yariv@...el.com>
Subject: Re: [PATCH] net: tcp: Fix a PTO timing granularity issue
On Tue, 2015-05-26 at 13:55 -0400, Ido Yariv wrote:
>
> The platform this was tested on was an embedded platform with a wifi
> module (11n, 20MHZ). The other end was a computer running Windows, and
> the benchmarking software was IxChariot.
> The whole setup was running in a shielded box with minimal
> interferences.
>
> As it seems, the throughput was limited by the congestion window.
> Further analysis led to TLP - the fact that its timer was expiring
> prematurely impacted cwnd, which in turn prevented the wireless driver
> from having enough skbs to buffer and send.
>
> Increasing the size of the chunks being sent had a similar impact on
> throughput, presumably because the congestion window had enough time to
> increase.
>
> Changing the congestion window to Westwood from cubic/reno also had a
> similar impact on throughput.
>
Have you tested what results you had by completely disabling TLP ?
Maybe a timer of 10 to 20ms is too short anyway in your testbed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists