netdev - Re: tcp wifi upload performance and lots of ACKs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1338838352.2760.1906.camel@edumazet-glaptop>
Date:	Mon, 04 Jun 2012 21:32:32 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: tcp wifi upload performance and lots of ACKs

On Mon, 2012-06-04 at 11:29 -0700, Ben Greear 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?

Well, thats half duplex days...

There is the ACK every 2 packets rule of thumb, so that tcp sender can
increase its cwnd.

Then, some folks tried submitting patches to make '2' more like 10 or
15, but this went nowhere.

Other idea is to arm a timer and defer ACK sending, in the hope we
receive another packet very soon.

That could be done with a special qdisc, sort of netem...



--
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