From: Ben Greear <greearb@candelatech.com>
To: Daniel Baluta <dbaluta@ixiacom.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: tcp wifi upload performance and lots of ACKs
Date: Mon, 04 Jun 2012 13:09:11 -0700 [thread overview]
Message-ID: <4FCD15E7.4080700@candelatech.com> (raw)
In-Reply-To: <CAEnQRZCNUYmP88Ocm_nG7gpA1Qcwy1tOc6kgCgZ7RqXcxQsHhg@mail.gmail.com>
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.)
>>
>> Kernel is 3.3.7+
>>
>> Anyone know of any tuning parameters that would let the receiving socket
>> wait a
>> bit longer and send more ACK data in fewer packets?
>
> An ACK is generated after every second full sized segment or a timeout
> expires.
>
> Currently, there is no way to tune these parameters. Here is an experimental
> patch [1]. If anyone, thinks that this patch has a chance to get accepted
> I will be happily try to further improve it.
It looks like it could be useful for my case, but I would also want
per-socket options to set the min/max ack delay so that the settings
are not just system-wide.
I can at least test this, and perhaps even hack on the code if
you are not interested in the per-socket settings...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2012-06-04 20:09 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 [this message]
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
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=4FCD15E7.4080700@candelatech.com \
--to=greearb@candelatech.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.