netdev - Re: TCP funny-ness when over-driving a 1Gbps link (and wifi)

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] [day] [month] [year] [list]

Message-ID: <4DDE7190.3080503@genband.com>
Date:	Thu, 26 May 2011 09:28:16 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	Ben Greear <greearb@...delatech.com>
CC:	rick.jones2@...com, Stephen Hemminger <shemminger@...tta.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: TCP funny-ness when over-driving a 1Gbps link (and wifi)

On 05/20/2011 03:33 PM, Ben Greear wrote:

> I tried a different test today: 3 TCP connections between two
> wifi station interfaces (using ath9k). Each connection is
> endpoint configured to send 100Mbps of traffic to the peer.
>
> With a single connection, it does OK (maybe 250ms round-trip time max).
> With 3 of them running, round-trip user-space to user-space latency
> often goes above 3 seconds.

<snip>

> So, seems a general issue with over-driving links with multiple TCP
> connections. Doesn't seem like a regression, and probably not really
> a bug, but maybe the buffer-bloat project will help this sort of
> thing...

Given that one rule of thumb for the send buffer size is twice the 
bandwidth delay product, it seems clear that on a wifi connection 3 
seconds worth of buffering is excessive.  I think I'd classify that as a 
bug.

Chris


-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@...band.com
www.genband.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