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: <AE90C24D6B3A694183C094C60CF0A2F6026B6F3C@saturn3.aculab.com>
Date:	Thu, 7 Jun 2012 13:20:19 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Ben Greear" <greearb@...delatech.com>,
	"Daniel Baluta" <dbaluta@...acom.com>
Cc:	"netdev" <netdev@...r.kernel.org>
Subject: RE: tcp wifi upload performance and lots of ACKs

 

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

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html