netdev - Re: Re: Re: Re: Re: Re: Re: Re: limited network bandwidth with 3.2.x kernels

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]

Date:	Wed, 15 Feb 2012 15:56:20 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Neal Cardwell <ncardwell@...gle.com>
Cc:	alekcejk@...glemail.com, netdev@...r.kernel.org
Subject: Re: Re: Re: Re: Re: Re: Re: Re: limited network bandwidth with
 3.2.x kernels

Le mercredi 15 février 2012 à 09:49 -0500, Neal Cardwell a écrit :
> If there was an increase in the number of bytes charged to the socket
> for each skb, without a corresponding increase in TCP receive buffer
> size, that would explain a systematic decrease in receiver window that
> would cause some paths, like perhaps these, to become
> receiver-window-limited (which is consistent with the symptom of
> stable bandwidth for a given path).
> 
> Can you please try increasing the default TCP receiver window to see
> if this helps; try this as root on the 3.2 machine:
> 
> sysctl net.ipv4.tcp_rmem="4096 897664 897664"
> 
> Basically making the middle number as big as the third number should
> bump up the default receiver window size.
> 

Neal, this was taken into account, check how sk_rcvbuf is dynamically
handled in our stack.

tcp_rmem[1] is the initial sk_rcvbuf, but its updated as soon as receive
window changes

If you check tcpdumps, you dont notice signs of receiver-window-limited.



--
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