From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C537F3CB43 for ; Thu, 22 Nov 2018 16:30:20 -0500 (EST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 34FA721B3D; Thu, 22 Nov 2018 21:30:19 +0000 (UTC) From: Dave Taht To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: Fabian Ruffy , cake@lists.bufferbloat.net References: <477d23a4-724c-2601-2cb2-ce1f0c0910f2@cs.ubc.ca> <87r2fczuue.fsf@toke.dk> Date: Thu, 22 Nov 2018 13:30:07 -0800 In-Reply-To: <87r2fczuue.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Thu, 22 Nov 2018 22:05:29 +0100") Message-ID: <87pnuwby1s.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Emulating Bufferbloat X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 21:30:20 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Fabian Ruffy writes: > >> Hello, >> >> this is a somewhat esoteric question. I am trying to actually force buff= erbloat >> in an emulation setup I am using. I set up a dumbbell topology and push = traffic >> through it, causing congestion at the central link. I use this setup to = compare >> congestion avoidance algorithms such as DCTCP to other solutions. >> This has worked nicely with the 4.18 kernel. However, after upgrading to= 4.19 I >> cannot reproduce bufferbloat anymore. The traffic (even UDP packets) is >> perfectly rate limited and I never see any congestion happening. This is= great, >> but in practice it prevents me from prototyping algorithms. > > Ha, that's awesome! :D I have not upgraded to this branch. And in general I do recomend using a separate box. "Nuke it from orbit, it's the only way to be *sure*". However, recently I was able to get bufferbloat by using network namespaces for my test, and perhaps that "still works"? In this extremely long thread there's a test setup of network namespaces you can try: https://github.com/systemd/systemd/issues/9725 > >> My interface configuration for bottlenecked links is: >> >> qdisc tbf 5: dev OBcbnsw1-eth2 root refcnt 2 rate 10Mbit burst 15000= b lat >> 12.0ms >> =C2=A0Sent 6042 bytes 51 pkt (dropped 0, overlimits 0 requeues 0) >> =C2=A0backlog 0b 0p requeues 0 >> qdisc netem 10: dev OBcbnsw1-eth2 parent 5:1 limit 500 >> =C2=A0Sent 6042 bytes 51 pkt (dropped 0, overlimits 0 requeues 0) >> =C2=A0backlog 0b 0p requeues 0 >> >> >> I have the suspicion that it is related to the CAKE changes in the 4.19 = kernel, >> but I am not exactly sure. I am not using tc cake at all. Do you maybe k= now >> what could cause this behavior? Apologies if this is the wrong mailing >> list. > > My guess would be changes in the TCP stack; can't point you to anything > specific off the top of my head, though... > > -Toke > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake