From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3458B21F5A3 for ; Wed, 4 Nov 2015 06:28:27 -0800 (PST) Received: from u-089-d065.biologie.uni-tuebingen.de ([134.2.89.65]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MV6PJ-1ZxeNK2pyv-00YRkb; Wed, 04 Nov 2015 15:28:19 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <8737wm9g1y.fsf@toke.dk> Date: Wed, 4 Nov 2015 15:28:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B18AFFE-F259-42A1-B6B2-787AD23EB88E@gmx.de> References: <87oafbnsqn.fsf@toke.dk> <5638B29D.9020503@darbyshire-bryant.me.uk> <87k2pzns29.fsf@toke.dk> <6F28B0F0-8333-4753-802E-BDDAC42CBC7B@gmail.com> <87oafbat54.fsf@toke.dk> <877flzas49.fsf@toke.dk> <87pozqaomi.fsf@toke.dk> <8737wm9g1y.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:7JjM0pTYAno39g5Ye6bU8ce0+KJqxfyc/LODYnA4TgXZxcLPQlV 6rRCVczyOWeiNnNwUG3jPxog7e3VKjMJcGbTAgZIyuMr495yFOYaQqIiHt80a5lr4we+rDq 2UYEbDFn+wlN8ydhstpyzKDiDv4lUqUAyN4k3XzsdEyZg7w/oDe8ivU1OKuleYCJahQycZO 8CMHoiRPP9WqqYKHoLPwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:auRuP3QlAso=:19pQhQdssSXnhfqSP6pS3l JBvJ7YIbKJ0EzvBwlYpVOiKMIHWSpgVbDFyWeU6KKyuUUFo6LvIBbm+uup3lLI2nv5bV3AkJL 60cnsOQSfPv8JwpSzpt5NO9gWwWZT6YOqdu8nWR5irFgzwNSDI8ADNuRrqw6dB62GOpAvjyTH JCC5UTIGHxyHIf7yjFrIKhc4ulCgv0dDsmuDjTVCFEHViKadUjKhb1YhkkDGuxV4vzn9st6o8 WCxGhDK8UvG0/3VjV5oc8cGZQaTbmcpDQ6YNEPbTBRTrW9RDe+V8/YX93tNLzgIZ+N4DAXjQq 3lG3HOcxrgOKtJShPXNL02ZSFNaWGzlfioBiuP0XK6d6rtedLhl4sdMiM6AhyQ+PscuT/20o8 jKqHgR6INLqHHUinoG4Zqvp6zbwrdxQ5mwlukU6Ymj4bDLJHnyxS6S6KpWDIM+MhiMHX+kjFj amAiPjluoIBDdqIoYC3fAqu971DrSRRq3u+yz0tgayrl0LeijHyH+MNrCILAXjYtTTz3bL0Wx NZ6FmHVFg20p40LtvaIbksqxg8YHZ3Ue8kHljYIaI7IjAb21HAkl8n4ShtAauLkMh3DZ72Nbq Y4hPxaA6A4v+dNhPVpaUotcNwWMt1bor1h6SM6+5rquzEE8PEZhsmiEm67crby3F1aKvRv8ev W0sdsoLdFhBe63+vxekvmlXQ7Gz8vuRiITNELu6+IioxeXaXXY3+kHWkqWAn3gb1jwjWL31G0 af0zfVMmik3PFGuoRYZ0S5n+XMcc8FhThn75wtJe88guhGssiXkrCLxpMFEkxLj7w7B3gymMt eIb1UQn Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Correct 'change' behaviour X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 14:28:51 -0000 Hi Toke, me too ;) On Nov 4, 2015, at 12:09 , Toke H=F8iland-J=F8rgensen = wrote: > Dave Taht writes: >=20 >> in the general case, I recomend looking at the most current fq_codel >> code to see how to do it as right as possible. There were several = bugs >> found and fixed in it as well.... >=20 > Well, I did, and it doesn't seem to be doing anything different. So = much > so that I tried the same experiment on fq_codel: >=20 > $ sudo tc qdisc del dev eno1 root > $ sudo tc qdisc replace dev eno1 root fq_codel target 100ms interval = 200ms > $ sudo tc qdisc replace dev eno1 root fq_codel target 5ms = =20 > $ tc qdisc > qdisc fq_codel 8007: dev eno1 root refcnt 2 limit 10240p flows 1024 = quantum 1514 target 5.0ms interval 200.0ms ecn=20 > $ sudo tc qdisc del dev eno1 root = =20 > $ sudo tc qdisc replace dev eno1 root fq_codel target 5ms > $ tc qdisc =20 > qdisc fq_codel 8008: dev eno1 root refcnt 2 limit 10240p flows 1024 = quantum 1514 target 5.0ms interval 100.0ms ecn=20 $ sudo tc qdisc del dev eth0 root $ sudo tc qdisc replace dev eth0 root fq_codel target 100ms interval = 200ms $ sudo tc qdisc replace dev eth0 root fq_codel target 5ms $ sudo tc qdisc qdisc fq_codel 800a: dev eth0 root refcnt 6 limit 10240p flows 1024 = quantum 1514 target 5.0ms interval 200.0ms ecn=20 $ sudo tc qdisc del dev eth0 root $ sudo tc qdisc replace dev eth0 root fq_codel target 5ms $ sudo tc qdisc qdisc fq_codel 800b: dev eth0 root refcnt 6 limit 10240p flows 1024 = quantum 1514 target 5.0ms interval 100.0ms ecn=20 $ uname -a Linux happy-horse 3.16.7-24-desktop #1 SMP PREEMPT Mon Aug 3 14:37:06 = UTC 2015 (ec183cc) x86_64 x86_64 x86_64 GNU/Linux $ sudo tc qdisc del dev eth0 root $ sudo tc qdisc replace dev eth0 root fq_codel target 100ms interval = 200ms $ sudo tc qdisc replace dev eth0 root fq_codel target 5ms $ sudo tc qdisc qdisc fq_codel 8003: dev eth0 root refcnt 6 limit 10240p flows 1024 = quantum 1514 target 5.0ms interval 200.0ms ecn=20 $ sudo tc qdisc del dev eth0 root $ sudo tc qdisc replace dev eth0 root fq_codel target 5ms $ sudo tc qdisc qdisc fq_codel 8004: dev eth0 root refcnt 6 limit 10240p flows 1024 = quantum 1514 target 5.0ms interval 100.0ms ecn=20 $ uname -a Linux psychotb-01 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 = 10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux =20 So at least the opensuse 3.16.7 and the ubuntu 3.19.0 kernels both = suffer this issue. Maybe the kernel does this on purpose, or nobody ever = tests this functionality=85 Best Regards Sebastian >=20 >=20 > I.e. fq_codel suffers from exactly the same problem. >=20 > Is this a bug or is it expected behaviour? I'd say bug? >=20 > -Toke > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake