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[off-list ref]  wrote:

quoted

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 [off-list ref]
Candela Technologies Inc  http://www.candelatech.com