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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 06 Jun 2012 21:15:55 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	Daniel Baluta <dbaluta@...acom.com>
CC:	netdev <netdev@...r.kernel.org>
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@...delatech.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.

I read through the original thread, and to summarize:

* Need to make the values per-socket.
* No multiplication in hot path.
* Would be nice to make it automatic.

The first seems fairly trivial..just add a new set of socket-opts (or
maybe just one that can take all 3 values?) and store the settings in
the socket structs.

As for getting rid of the multiply..I think you cannot just use shifts.
That does not give the needed granularity.  An alternative is
to update a cached computation every time the mss or socket-opt changes.

As for a magic heuristic to figure this out, I think that would be
quite tricky to do right.  So, maybe add that in the future, but
for the present, just allowing applications to set the value seems
enough.

We could support configurable system-wide defaults so that users of
programs that do not know this new sockopt can still take advantage
of the feature.

Does this sound like a reasonable solution?

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com
--
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