RE: tcp wifi upload performance and lots of ACKs

["David Laight" <David.Laight@xxxxxxxxxx>]

> -----Original Message-----
> From: netdev-owner@xxxxxxxxxxxxxxx 
> [mailto:netdev-owner@xxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxx>
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.

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html