some quick comments on configuring cake

[dtaht]

To avoid further flooding of the 7.30beta thread with Cake topics, here some results taken from my home network:

RB5009, ROS 7.2.2, Fiber uplink at SFP1 using PPPoE with NAT capped at nominal 500/100 by the ISP equipment at the other end of the fiber.
The ISP UL shaper does a not so bad job, but the DL shaper is awful as visible in the plot without queue.

ROS simple queue setup targeting the PPPoE uplink interface

/queue type
add name=cake-WAN-tx kind=cake cake-diffserv=diffserv3  cake-flowmode=dual-srchost cake-nat=yes 
add name=cake-WAN-rx kind=cake cake-diffserv=besteffort cake-flowmode=dual-dsthost cake-nat=yes

/queue simple
add max-limit=500M/100M name=queue1 queue=cake-WAN-rx/cake-WAN-tx target=wan-pppoe1

This gives very good results in the flent rrul test. Almost no latency increase and both DL/UL are running at nominal speed, saturated by the 4 parallel connections.
flentres_cake.png


The same test with the simple queue on wan-pppoe1 disabled shows high buffer bloat >100ms. The latency under load increases by a factor of 10.
The total DL is about 1/2 of the line rate, because the 4 parallel connections are fighting each other.
flentres_noqueue.png


Regarding how good it works, it would really be interesting to hear what exact reasons MT has to disallow use cases such as above with the latest 7.3 beta.

I really hope they understand this now.

In other random work on trying to help mikrotik and the userbase out today, I posted these. I note that a big point for me, was always, that getting these algorithms running natively, at line rate, has a lot of benefits (really low cpu cost that way, for starters) , and that at least some of the shaping y’all have been forced to do was due to the lack of backpressure in the ethernet and wifi drivers.

http://forum.mikrotik.com/t/bql-and-default-queue-lengths/158510/1 - BQL and fq_codel cut many ms without shaping out of line rate.

And on fq_codel running native on the wifi:

http://forum.mikrotik.com/t/fq-codel-on-mikrotik-wifi/158515/1

I fear that mikrotik is also running way behind on these fronts.

I regret that I have to scale back my commitment (my grant ran out, nobody is paying me) to helping y’all out here for a while. Please summon me when there is progress on mikrotiks’ front? Also, my natural metier is email - the cake mailing list over on lists.bufferbloat.net is pretty active, in particular. Thx for all the wonderful work on documenting what works, and the flent plots, and everything. I will try to somehow compress this mutually educational exercise into some more compressed form over the coming months.