All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Daniel Baluta <dbaluta@ixiacom.com>, netdev <netdev@vger.kernel.org>
Subject: Re: tcp wifi upload performance and lots of ACKs
Date: Thu, 07 Jun 2012 07:41:50 -0700	[thread overview]
Message-ID: <4FD0BDAE.7030809@candelatech.com> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6F3C@saturn3.aculab.com>

On 06/07/2012 05:20 AM, David Laight wrote:
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org
>> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Ben Greear
>> Sent: 07 June 2012 05:16
>> To: Daniel Baluta
>> Cc: netdev
>> Subject: Re: tcp wifi upload performance and lots of ACKs
>>
>> On 06/04/2012 12:22 PM, Daniel Baluta wrote:
>>> On Mon, Jun 4, 2012 at 9:29 PM, Ben Greear<greearb@candelatech.com>
> wrote:
>>>> I'm going some TCP performance testing on wifi ->   LAN interface
> connections.
>>>>    With
>>>> UDP, we can get around 250Mbps of payload throughput.  With TCP,
> max is
>>>> about 80Mbps.
>>>>
>>>> I think the problem is that there are way too many ACK packets, and
>>>> bi-directional
>>>> traffic on wifi interfaces really slows things down.  (About 7000
> pkts per
>>>> second in
>>>> upload direction, 2000 pps download.  And the vast majority of the
> download
>>>> pkts
>>>> are 66 byte ACK pkts from what I can tell.)
>>
>>> [1] http://marc.info/?l=linux-netdev&m=131983649130350&w=2
>>
>> After a bit more playing, I did notice a reliable 5% increase in
>> traffic (200Mbps ->  210Mbps) from changing the delack segments
>> to 20 from the default of 1.  That is enough to be useful to me,
>> and there may be more significant gains to be found...
>> I haven't done a full matrix of testing yet.
>
> Does this delaying of acks have a detrimental effect on the
> sending end?
> I've seen very bad interactions between delayed acks and
> (I believe) the 'slow start' code on connections with
> one-directional data, Nagle disabled and very low RTT.
>
> What I saw was the sender sending 4 data packets, then
> sitting waiting for an ack - in spite of accumulating
> several kB of data to send.
>
> Delaying acks further will only make this worse.

I'm sure it's not for everyone in all cases.  In my case, I'm
sending long-term bulk transfer, at high speeds, over wifi network
which has some latency.  Tested one-way traffic so far.

With the patch and delayed acks, I get more sender throughput than
without (200Mbps -> 210Mbps).

Thanks,
Ben

>
> 	David
>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

  reply	other threads:[~2012-06-07 14:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-04 18:29 tcp wifi upload performance and lots of ACKs Ben Greear
2012-06-04 19:22 ` Daniel Baluta
2012-06-04 20:09   ` Ben Greear
2012-06-04 20:15     ` Daniel Baluta
2012-06-07  0:26   ` Ben Greear
2012-06-07  0:40     ` Ben Greear
2012-06-07  4:15   ` Ben Greear
2012-06-07 12:20     ` David Laight
2012-06-07 14:41       ` Ben Greear [this message]
2012-06-07 17:51       ` Rick Jones
2012-06-07 18:10         ` David Miller
2012-06-04 19:32 ` Eric Dumazet
2012-06-04 20:12   ` Ben Greear
2012-06-04 20:18     ` Eric Dumazet
2012-06-05 14:28 ` Glen Turner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD0BDAE.7030809@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=dbaluta@ixiacom.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.