[Cake] ER-X now running cake, thanks for the help. :)

[Sebastian Moeller]

Hi Erik,


> On May 5, 2017, at 15:00, <erik.taraldsen at telenor.com> <erik.taraldsen at telenor.com> wrote:
> 
> 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.
> 
> 
> 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’s 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).

> 
> 
> 
> 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’ 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 = 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… (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 = 20 MB packets when UDP floods with randomised ports knocked out my puny 64mb router reliably in a few seconds). With ehe ERX’s 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’t the default tcp-friendly, and inelastic DOS traffic is essentially out-lawed?)


Best Regards
	Sebastian

> 
> 
> Default from "smart queue" fq_codel
> 
> 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
> 
> 
> -Erik
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake