netdev - 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:	Tue, 21 Feb 2012 19:19:18 +0200
From:	alekcejk@...glemail.com
To:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: Re: Re: limited network bandwidth with 3.2.x kernels

В сообщении от Вторник 21 февраля 2012 17:45:51 вы написали:
> Le mardi 21 février 2012 à 06:21 +0200, alekcejk@...glemail.com a
> 
> > I tested last released 3.2.7 kernel (2.6.42.7-1.fc15.i686).
> > Speed problems in 3.2.7 the same as in 3.2.6.
> 
> I am not sure what you expected from 3.2.7, given we still are
> discussing of issues.
> 
> > I also have Fedora Rawhide installed in virtual machine (e1000 driver used there)
> > running on host with 3.1.10 kernel.
> > And I noticed that after one of 3.3 rc's (or even rc's of 3.2) kernel updates download speed of
> > updates from dl.fedoraproject.org in VM became extremely slow - about 160 kilobytes/sec
> > instead of 1,2 megabytes/sec as it was before.
> > But recently (somewhere between 3.3 rc3 and rc4) speed became again
> > as it should 1,2 MB/s.
> > 
> > Don't know is this problem related with speed in 3.2.x kernels
> > and it is hard to debug this now.
> 
> We have a pretty clear idea of what happens, we have to decide if we
> must change kernel defaults now or not.
> 
> On prior kernels, memory accounting was wrong, and a socket could
> consume far more memory than the limit given.
> 
> See the 3rd column in :
> 
> net.ipv4.tcp_wmem = 4096        16384   897664
> net.ipv4.tcp_rmem = 4096        87380   897664
> 
> We now have a more correct 'truesize' accounting, and this means a
> socket cannot lie anymore : Instead of consuming 1.200.000 bytes for receive
> buffers, it really cannot consume more than 897664 bytes.
> (unless yet another driver try to lie)
> 
> On your 32bit kernel, this means the tcp_rmem[2] (897664) really
> can be too small for your case with a 50 ms RTT, since memory/rtt is
> limiting the bandwidth.
> 
> On a 64bit kernel, we hit the memory/rtt limit less often because
> tcp_rmem[2] default value is 4127616, unless you have very small
> available memory.
> 
> Maybe we should default tcp_rmem[2] to 4Mbytes, even on 32bit kernel.
> 
> Could you try :
> 
> sysctl net.ipv4.tcp_rmem="4096 87380 4127616"
> or
> echo "4096 87380 4127616" >/proc/sys/net/ipv4/tcp_rmem

Download speed from ftp3.de.freebsd.org increases from 5 MB/s to 10 MB/s
after I set "sysctl net.ipv4.tcp_rmem="4096 87380 4127616""" in 3.2.7 kernel.

--2012-02-21 18:56:36--  ftp://ftp3.de.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/8.2/FreeBSD-8.2-RELEASE-i386-dvd1.iso.xz
100%[======================================>] 2 066 424 512 10,3M/s  in 3m 17s
2012-02-21 18:59:56 (9,99 MB/s) - «/dev/null» saved [2066424512]

But maximum speed in 3.1.10 kernel (without this sysctl settings) still
a bit more than in 3.2.7 - 11 MB/s instead of 10.3 MB/s.

--2012-02-21 18:56:36--  ftp://ftp3.de.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/8.2/FreeBSD-8.2-RELEASE-i386-dvd1.iso.xz
100%[======================================>] 2 066 424 512 11,0M/s   in 3m 30s   
2012-02-21 19:13:55 (9,39 MB/s) - «/dev/null» saved [2066424512]
--
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