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 E63FC21F5DD for ; Tue, 27 Oct 2015 10:14:27 -0700 (PDT) Received: from u-089-d065.biologie.uni-tuebingen.de ([134.2.89.65]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M3NEK-1ahqu80IQi-00r1NC; Tue, 27 Oct 2015 18:14:24 +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: <8737wwmf1h.fsf@toke.dk> Date: Tue, 27 Oct 2015 18:14:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5FC9444D-C51A-4F81-BBE5-38A58E238E24@gmx.de> References: <87a8r4mji9.fsf@toke.dk> <6499FF74-D13B-4B2E-90E3-D1FDD3FD1468@gmx.de> <8737wwmf1h.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:FWGi/uxGnF6ZBps8bcYJoL+/QR6XpgM+S/jAlXdyYgR47b4z/TZ URdg9PysSS1qbNMbgAq2dAZq3D84Cg/un0GKYQe7LnmlPKhLH/GYPyP+e3nUF8biIKMJzQ/ L7WhFro6exE2/8KBXYQyVAQWUNh2tii8gGSmpE6x6oOyK2SXvH6iaq73OCFFkSwzFn70E1X mVgJMLE5y6SaiuzgUquBQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:2XmYHBjf0wE=:l6xYZOKz8PD3RgVKknIzh7 uXPLL12GmBzAfUAE5yTFg+dh/j78xBi6xBYs0xoVLfs7X7WxMp1NXarpON6IkFWLRElzUOVzN HpV8ar1kbq0rlvsA9rYWUVy1YPanGIIq+RrODT4XseMXKDRgHiHxAIVv91rTX1WRSTp+1evYn s2Trpna/ELvJPxndbM3lsjzCTUGrfgbDLBbZgOYkXKx/vqa7cAVXR3z4EtinkcEHzpnDzv27F N+f+pGLTmVPQHgVL+ZmQIUtCooKaYEUFHiRT/VmL0rUVz1eTeS6UnKz3zaYacHWzCUtPSExJb VTpg0L4C+ZnWZ/G3jqds37IlMcixmhGIBQFUK8bdTRwp/aqBxPmHkIL/avSY/9jSO+2ze8edn tQJW0k91xf6pTkk0vxX23GkJ/yukz2Zn/OfgEYldzOg7qt3Nn/oPK/0tvfdOXzKUL1FkSp8tz bd9YQpelP9MVpDPNiMZS02kskAV5CZmor6SvkFu/QKFLl/SUm9GLCHndT7TWZTJn42cZKo+yA 3Fxj16wltFbi1K+czhW4QUOjuqi4dmJV8lHWqaZKFd0iiEKMJTrbMMGp4mHbtqUgxuouY5Hed cN7YYkH2UrElD+P61SvGwYYTtMBlstsUur3pxK/Z2KIl6vbpUHOQjPdDiNNSTLTFmiORw1932 WRuhH8eVCwIfYjpKC3z5mTC0mXu1yaL80W1TcTDYrUgeKiQ+MPYPtY6sfF++7p2Fe4XTsQhSy ETEFI3BK0w785IoWwJI+YWDjr3JNiw7Zss0VxxiWZvwumhu+8aXQu4FbpZsc/VPBntUKEczlr 1W4/+az Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Running Cake at long RTTs 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, 27 Oct 2015 17:14:50 -0000 Hi Toke, On Oct 27, 2015, at 17:50 , Toke H=F8iland-J=F8rgensen = wrote: > Sebastian Moeller writes: >=20 >>> - Turn the hard packet queue size into a lower bound rather than an >>> upper bound. >>=20 >> This seems dangerous for low memory configurations? >=20 > Well, yeah, the max packet count allowed can be higher this way, but I > guess the only sane answer to that is "don't configure cake for = 100Mbit > and 1s+ of latency if you don't have the memory to spare=94. What about cake honoring it as a hard limit but complaining to = syslog, if cake deems the limit too low? If I recall correctly, having a = qdisc OOM a router basically functionally bricks the router (unit the = next reboot) or forces a reboot, both not ideal. >=20 > Having the (now lower) bound be a bit lower than it is currently may = be > a good idea, but not sure what it should be... The current 10240 = matches > fq_codel. Oh, I guess that is fine, it just means that for low memory = devices we need to teach sqm-scripts to reign in a bit... >=20 >>> - Scale the target to be 1/16th of the interval. >>=20 >> Codel theory claims 5-10%, so 1/20 to 1/10, so it seems you >> confirm the theory, not sure why cake did not do this as a >> default=85 rem, what actually was cake setting target to? Asked >> differently how sensitive to target being exactly 1/16th was the >> throughput? >=20 > Yup. 1/16th has the benefit of being implementable as a 4bit shift :) So is 1/8th ;) just curious, which values did you try? Codel RFC = argues for 5-10% with 10% giving ever so slightly more bandwidth, while = 5% keeps latency under load increase a bit smaller. But I really like = that reality fits theory here, chalk this one up for code;l=92s = designers ;) >=20 > Before, the target was hard-coded as 5 ms; so this was definitely an > oversight. Not sure, we had discussed this and Jonathan argued that it = requires empiric testing if I recall correctly, exactly what you have = done ;) I still believe that for any automatic choice cake does there should be = a manual override option for experimentation, most urgently a manual = target specification that will override all automatic optimizations. = Well, just as for the queue max size I believe cake should complain if = it thinks things are unreasonable but still do follow the users request = if non impossible=85 Best Regards Sebastian >=20 > -Toke