From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AFB0A3B29E for ; Fri, 5 May 2017 09:20:51 -0400 (EDT) Received: from [172.17.3.29] ([134.76.241.253]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LtaDM-1e59pW0wzs-010uJs; Fri, 05 May 2017 15:20:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <1493989225450.12354@telenor.com> Date: Fri, 5 May 2017 15:20:49 +0200 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <1493989225450.12354@telenor.com> To: erik.taraldsen@telenor.com X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:1Mgqsth/WgqDWglgvt5dy/psUt8Pny6by9B5n7vdynOZbtX9ST/ Q4XToNc/JY35JnBa+rIRWcHcNvNhNPihTAqgWtAhm8F4G/5eDQKE4NfWy6Up5Pdah6xSfvO t5kuzzC9bQBHl0q0DD3VPan34pTRdQ03b/or11sHnCQ0wGFuN5kskm/WlHAp/PnI0UbE84m rM2iNTnaLUoRREOT8ud1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:6LaTC6brmUA=:nVXw5I95fB6JnjjJyXwdvy ppf4zIXrYSQYZ0CCAXqZdHl5f3b7jrlqVp5Pd9AvgGkJ6sJjENv4qhhEF/dHNymYdgqzdi38d 23RynQ68AcfEEOn7s8YHq28XqB5YOhBULvc3LBs6bpTAhuISAtoEXRODgdPkUTALQB7NNZPaC vAv/kTs9fb29gzFNpNouZRI5Ao/1gHLxWP4uIFqJ3C/DlsPaW9LG7LITizb/ocq8UMcRNlB2Z fMNUSc3WpAnKZoffRQ7QoJ7rfuPfqJ61UnRDS5ncZPbmoUYtsPDuAlc669q00AsF8wz+J/VL7 yStYVxMpczjcRk4PPc9LjYSbFNeIP4V6wykdZKyc2rdfC7kj8TVfDL89EtohlKLoVADxf0Jjf tleNNtUrS7p2UA74JobC6wYLL9chiNfryMn8oI3l00D12vxsTsB82HMpSMtQ2+acz/b1RZoAt OC/3ZEjqY6+naHI7NQo2E8c2454XrTXdKAH6ZeSmHSgXWPeOZC4G32hE4uah+DIfgACf5IlKV pXZeZJi08vYlsX/8gV3nOxYoXt+3HApDp1Y1uIchPJQmh1rI6XovRfkQvzc1DYjB9hiV3yZ+X H+OmMcOZdeDE1kkHy1irB2pagmRXWaq4/U5lBReoyWSBIiKmsgZ7LpEXWMbnDkINeG7BKzFcG QqNYQ/7henPpmb6hu0UI2EK2qkeGTsoXo7gCM57T2d7LkDXnnU5y9L/6oV4rYgBz6NCwNRmbj l8kL35n0qqBDJO1+9B4jPnHjxPTMr1XV1BXK7Gx22Icv79+u8hAOHVG/Zobjdy1vtCZAMw31W 2ozDHS6 Subject: Re: [Cake] ER-X now running cake, thanks for the help. :) 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: Fri, 05 May 2017 13:20:52 -0000 Hi Erik, > On May 5, 2017, at 15:00, = wrote: >=20 > Just a follow-up from the great support I got here. I am now running = ER-X with cake with the precompiled binaries from Nils. I need to do = some tuning and get it properly into the lab. Currently I'm dogfooding = it at home. >=20 >=20 > Any other suggestions in order to make the topping of the cake so to = speek? I think https://lede-project.org/docs/howto/sqm pretty much sums up the = current best initial recommendations for sqm-scripts. > I notice for example that all interfaces pr default use pfifo_fast = and run a txqueuelen of 1000. Which is a bit deep for running a 20/1 = adsl line. If you specify a bandwidth parameter to cake that is below the = egress interface=E2=80=99s true bandwidth the txqueue is never going to = fill up, so you can leave it untouched. Also I believe that BQL will = effectively, if available and enabled on an interface, make the exact = value of txqueuelen irrelevant (I guess it needs to be large enough for = BQL to reach a decent maximum). >=20 >=20 >=20 > And a slight rant on the default fq_codel setup for ER-X, 10240 = packets? Before reducing that I got a one way delay of more than 600ms = when I congested the line with udp. Sane defaults Well, for sqm-scripts=E2=80=99 simplest/simple.qos we reduced = this to 1001; but the rationale pretty much is that this is really just = a belts and suspender thing, fq_codel should make sure under normal = conditions that the queue is never fully filled, so ideally this just = constrains the worst case memory requirement (roughly, as a non-giant = skb is I believe 2KiB in size, so 10240 packet will at worst require = 2*10240/1024 =3D 20 MB, for GRO/GSO giant packets this approximation = does not hold anymore, cake I believe has a memlimit keyword that allows = to explicit;y state how much memory one allows an instance to consume = worst case, cake also reports how much memory it actually consumed). Why = 10240, you ask (as did I): for the default of 1024 hashed queues this = allows 10 packets in each queue on average=E2=80=A6 (now if we had = another number of digits on our hands than 10 that might be different, = but I digress...) The only way to ever run into this is flooding with an unelastic load (I = first run into the 10240 packets =3D 20 MB packets when UDP floods with = randomised ports knocked out my puny 64mb router reliably in a few = seconds). With ehe ERX=E2=80=99s 256 MB I would guess the worst case = 20MiB is small change and I would not bother to change that. One problem = with the unelastic load is that as far as I can tell no flow on the open = internet is allows/assumed to behave like that (isn=E2=80=99t the = default tcp-friendly, and inelastic DOS traffic is essentially = out-lawed?) Best Regards Sebastian >=20 >=20 > Default from "smart queue" fq_codel >=20 > qdisc htb 1: dev eth4 root refcnt 2 r2q 10 default 10 = direct_packets_stat 0 direct_qlen 1000 > qdisc fq_codel 100: dev eth4 parent 1:10 limit 10240p flows 1024 = quantum 1514 target 5.0ms interval 100.0ms ecn >=20 >=20 > -Erik > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake