From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 6AECF21F5A3 for ; Tue, 3 Nov 2015 09:52:55 -0800 (PST) Received: from hms-beagle.home.lan ([217.237.68.126]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lxgnf-1aVeJj0IB9-017EaW; Tue, 03 Nov 2015 18:52:52 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <878u6fas88.fsf@toke.dk> Date: Tue, 3 Nov 2015 18:52:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64F71419-78F8-465F-B43E-D0F2CF08AB19@gmx.de> References: <87pozspckj.fsf@toke.dk> <6A2609D9-7747-487B-9484-ECC69C50DE96@gmx.de> <874mh3pai9.fsf@toke.dk> <50C2A7B7-1B81-41E1-B534-CA449296FE77@gmail.com> <87a8qvc8tz.fsf@toke.dk> <328DEF4F-F149-42C5-920E-53D16DCF544C@gmx.de> <87si4natbf.fsf@toke.dk> <87fv0nasy5.fsf@toke.dk> <878u6fas88.fsf@toke.dk> To: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:ztGVx5sa3yepWJCTz7U87/MJxkFloF5UZe3KVO57mlKw4eSet+2 5b+I5i5vaSjwxM0hXjzQbimgfi/BFeVrcQjTWnXTuS6Twui+8h/sAaYF/I2flqAEcKZnnNh P3wGP1SDIM9xw4H/fEcjFRS3LaD6DOj5SncjvwXZe66ciQTpZfW7nkfqPaYideXA9Ap+9By BnM8HID9h/ukeev1aYDQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:iJHUtipFc6g=:LncPLecDP7QYtv8Wc7WKPZ pXMdaTaGk6lCbCzS0kXr7sNn0nTnsoz6aWZhFmU3GU3W/iZ1cbU24jmVbSsUq0DzL/+a0vXAb G/dmfIjq5M38n2NysuYV3ysOXhP2e8+4KKXlgivahywZMX7mc/gQkqRGO366BNpWvXDOzrWes f01DrAYuWbC08XqFWL3fZ0NcHTd+DD8In2Pz14yWzZ0PL+A8qjjHzuDM/ZIAYn1v6dhBrERCZ vTNyf+u4kD7+SDTi3NCRj8LIAcEemSra9lhufEOvFR+O8TFSOyaGgY3S+uw1ib8q2BJr9B9mv EpRJw5WVABa80NoHoa12dAiFX3VP4OB+47lp2RlXGUJR+bZLDARfv5YoeTYGAiLO64AR9M3xQ D4fOSGIpTK9cpnkjuoIdwH6FbKBZXbZForha0vl0a2C9tujpPyWcDOwRO2giGrW/JcYNipRIy 9Vs2/0HhKtcVqEyJtEolgoysSmMhHAyx/7JmsoIFzKO+OxrOxMiO82w/4y+fdtHgX0ev1vXNd CVx4cpXMz+L6wXaMTJnlR+J2TELDnUjP0CXyWhju+LG87E/8UXpQxVJaoIGjYgkbk4T7GycNG UgMfzjowGgG4wT+1mcLEWgbCsEQ7UTHRbbNOLfTy0C5Ivn3RgucKfaclFhzzf9fFGTzylZEyc usqj9adcXioDsqPNyEWxkieGH8ipVpFORWX3lElYSyNur5/UhgQYoHs7BRLBiB/i7tKzLfuRV YrZPm3mwK9Rs9bomvw22v6URKHuabf4H1NrQ2CemllCSxzAtv5RW2Aw2pXjDW4Y0hCBb2xhpR fBmuJwM Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Long-RTT broken again 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: Tue, 03 Nov 2015 17:53:19 -0000 Hi Toke, On Nov 3, 2015, at 18:49 , Toke H=F8iland-J=F8rgensen = wrote: > Sebastian Moeller writes: >=20 >> I guess I have constantly been talking about a different limit than = you, >> sorry. I was and still am advocating for the hard memory limit. >=20 > Well, if we add a 'limit' parameter that limits memory consumption > rather than queue space measured in packet size, then it will function > different than the same parameter of all other qdiscs. Hardly a good > idea, I'd say? Except, both are strongly correlated in practise, by virtue of = each packet pinning a 2KB skb, I do not care too much if there is a = constant factor required to get from packet limit to memory or not. What = I really want is that halving the limit halves the memory demand ;).=20 Best Regards Sebastian >=20 > -Toke