From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 1B2D321F5C0 for ; Tue, 3 Nov 2015 11:24:53 -0800 (PST) Received: from hms-beagle.home.lan ([217.237.68.126]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MTTKZ-1a3ycw07ol-00SRkF; Tue, 03 Nov 2015 20:24:49 +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: Date: Tue, 3 Nov 2015 20:24:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <907246CB-2510-4217-B13C-DDFE0909D1BC@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> <64F71419-78F8-465F-B43E-D0F2CF08AB19@gmx.de> <8737wnarzp.fsf@toke.dk> <87twp39d61.fsf@toke.dk> <0E86DECF-C583-4414-95CF-8F145D7E82D7@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:6sJ3u8rbiJlu9s/36KIWtKS3MkjBBGaZ8ygzXOZCo4Fdt15AfvD S9XIM3jVofaIr/ERfcNQmmprhetlhNlhAdO7+Ifcc6HfRtJpo6i2G1K2FWgkCsfUj+JAisT bVfOTeFZZwQ6UpLdZ+xUeKyYqCjWzj2RTIGhG3KzgjG72zl/r/5+enJTKTVL/z93y0xViyL GuVEHLe0KZM4vdvoZBFeA== X-UI-Out-Filterresults: notjunk:1;V01:K0:c5uJXZ3/RuM=:9XgekbOkzK4w0tnFqLD7Wf lxDwrFNKf4u3nZ4A20Nzn0jzntlFgVGdomrBwgOKmrBwbH5LWCBZUBn5Le1az1iiA8VaI78wz d4F6fCngWnqZU9pGtnBdqXJltUErK8bRkzS1EmU5ueZr7pCuv2ruiCf5KJ8fZD62W2+npvlVL hZLSIV70FQKvA8h96jti8RTiTPelI9CuKDw2rB+bB1zZs2epPSg/mUmSDUGWRLSK2+4IZ2m4c kQf1NMkP8yVuGa+Zp3lduKRb/jpH+wyJXTya3VgpUTOdnj81od3XdUVerZI8VbJRpm67HJNhZ 0M3mhhGLIuJl3hAypzIQDzddgWNaS0r+e31RZmTWecCzo+k+dm/RusvKR7NpQaHlfTl9QnVVj GMbuOPoecjt1MQJrCkJtapxfsqDbZjG1NEZPXKhqo5RbtZ2TOdZ98oOe6Y/1nFR0WQAo/sspQ KCXUcoexxgWgrB528lSueQ9Ffna1Ta/mqytAdR0JIhHAwVhkpASIAQqhp2F3qMUI3t+3xA62A fDsM1ZM0fF56tJtrJXXP3vkUjmp00Fc/jP0cddwKQdDs3/QlMKU1e3WtCWqyM8O8SjG8um9KD yMYHwUDV4VVz9hs9Z5Lvy6HY65h+Gq0YTKbnI5WzKRpEvhT3vYTbK+PHOB4T6zD9HsIelANiO gwSmy02Da7TxgzYnTqkMti9xQ7q54MaViY/IRiDBAICwBHQuiDeYQ4l7hPrKheq/UV57O3Dkz 61YBfamD+nRnBvt7u9r5W9EedyAC/+oa7UUGwtKNiHCOwm+uGCGmLe8uWYRcrdgi4d6eCNN6j oFdT4F1 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 19:25:16 -0000 Hi Jonathan, On Nov 3, 2015, at 20:17 , Jonathan Morton = wrote: > Conceptually, I think limiting actual memory usage is the right thing = to do. =20 I agree ;) but I am coming at this from the avoid OOM direction = anyway; I believe Toke=92s point for people coming from the BDP angle is = equally valid (if less important to me personally). > Ideally, the allocations would turn out closer to the actual packet = sizes, but by watching the allocated size, we will automagically take = advantage of improvements in this area - which must happen elsewhere in = the kernel. But this is acknowledging there is a discrepancy and the = punting, turning it into someone else=92s problem, no? >=20 > Limiting total on-wire packet bytes is nice from a theoretical point = of view, but we don't live in a theoretical world. The performance = discrepancy shouldn't be as big as it is. But this is about honoring BDP calculations for worst case = buffering scenarios where the sender dumps all packets for a whole = transfer period in one instantaneous burst (well almost); this seems = well documented in the literature and hence might be something users = might actually want to do... >=20 > Limiting packet count is wrong and awful and we shouldn't do that, = even if everyone else does. The fact that counting allocated bytes = behaves the same way at the moment is unfortunate. Why? The fact that they are correlated also allows to limit by = allocated size, since the correlation is directionally insensitive, so = to speak, we can always argue that the packet fans just need a = proportionality constant and be done with ;). I guess this needs a clear = name than simply limit to avoid confusing people who already know other = qdiscs and their behavior. Best Regards Sebastian >=20 > - Jonathan Morton