[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201503271946.07464.wrosner@tirnet.de>
Date: Fri, 27 Mar 2015 19:46:07 +0100
From: Wolfgang Rosner <wrosner@...net.de>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: One way TCP bottleneck over 6 x Gbit tecl aggregated link // Kernel issue
Hello Eric,
I tried to discern the possibilities of Debian patches having solved the
problem vs, regression bug in recent Kernels.
So I tested:
- Vanilla 3.16.7
- recent Debian 3.19.1
============
results:
- Vanilla 3.16.7
from
https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.7.tar.xz
result: really bad,
~ 500 Mbit /s both inbound and outwards
inbound even with -P24 parallel threads not more than 800 Mbit
outobund with -P12 we are back over 5 Gbit/s again
>From that, to mee it looks like the problem was introduced before 3.16.7
but only partly solved since then.
I tried to map vailla versions with the davem fork,
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/tree/
but got lost in git / developer workflow .
- recent Debian 3.19.1
same results as with any other recent kernel
inbound > 5.5 GBit
outbound ~ 3.2 GBit
outbound -P 2 > 5 Gbit
So it looks like the debian people have _not_ found the solution, but were
just lucky enough with their
3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt4-3~bpo70+1
not to hit it yet...
Am Donnerstag, 26. März 2015 20:34:05 schrieb Wolfgang Rosner:
> Hello, Eric
>
> Am Montag, 23. März 2015 03:33:17 schrieben Sie:
> > On Mon, 2015-03-23 at 01:57 +0100, Wolfgang Rosner wrote:
> > > Are you ready to assist me on this track?
> >
> > First check if the problem is already solved, using this git tree ?
> >
> > http://git.kernel.org/cgit/linux/kernel/git/davem/net.git
>
> Does not look like that :-(
>
>
>
> I tried both 3.19.2 frome kernel.org and
> a git clone frome above adress from "master" this morning.
> $ uname -a
> Linux cruncher 4.0.0-rc5+ #1 SMP Thu Mar 26 08:48:08 CET 2015 x86_64
> GNU/Linux
>
>
> Sorry when it took some time.
>
> I've built a workaround for my aufs nfsroot to get rid of that, at least
> for testing.
> Both kernels were built w/o aufs patches, so we cannot blame this anymore
> (I've learned that people like to do so...)
>
>
> -----------
>
> I tried sequential run to check for jitter and to allow for adaptation
>
> for i in `seq 10` ; do iperf -c 192.168.130.225 -t 100 ; done
>
> 3.17 / 3.30 / 3.16 / 3.19 / 3.29 / 3.29 / 3.35 / 3.32 / 3.22 / 3.32
> Gbits/sec
>
> ...full bandwith at shared Link utilisation:
>
> [ 4] 0.0-10.0 sec 3.31 GBytes 2.84 Gbits/sec
> [ 3] 0.0-10.0 sec 3.32 GBytes 2.85 Gbits/sec
> [SUM] 0.0-10.0 sec 6.63 GBytes 5.69 Gbits/sec
>
> ...full bandwith (5.66 Gbits/sec) in the opposite direction
>
> (Test figures are from davem 4.0.0-rc5+, on 3.19.2 they were quite the
> same)
>
> ------------------------
>
> Tried a look at differences in kernel .config
> between the versions where the problem occured
>
> diff /boot/config-3.16.0-0.bpo.4-amd64 /boot/config-3.19.0 | less
>
> there is one occurence of TCP
> '> # CONFIG_TCP_CONG_DCTCP is not set
>
> but it should not hurt if it is not set, should it?
>
> All the other stuff does not ring any bell wiht my (very limited) range of
> experience.
>
>
> So what next?
>
>
>
> Wolfgang Rosner
>
> --
Wolfgang Rosner
--
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
Powered by blists - more mailing lists