[Cake] Configuring cake for VDSL2 bridged connection

Sebastian Moeller moeller0 at gmx.de
Wed Sep 14 16:48:22 EDT 2016



On September 14, 2016 10:41:22 PM GMT+02:00, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>
>
>On 14/09/16 21:06, techicist at gmail.com wrote:
>> I'm back again, been quite busy so lost track of this. I'm using LEDE
>> now too.
>>
>> Is there an easy way to see cake is actually working? A command or
>> something I can type in just to get clarification?
>
>You can prove that cake is being used as the queue discipline (qdisc)
>by 
>doing something like 'tc qdisc'
>
>On my LEDE box it returns:
>
>qdisc noqueue 0: dev lo root refcnt 2
>qdisc cake 800d: dev eth0 root refcnt 2 bandwidth 9840Kbit diffserv4 
>dual-srchost rtt 100.0ms noatm overhead 12
>qdisc ingress ffff: dev eth0 parent ffff:fff1 ----------------
>qdisc fq_codel 0: dev eth1 root refcnt 2 limit 10240p flows 1024
>quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc noqueue 0: dev br-lan root refcnt 2
>qdisc mq 0: dev wlan0 root
>qdisc fq_codel 0: dev wlan0 parent :1 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc fq_codel 0: dev wlan0 parent :2 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc fq_codel 0: dev wlan0 parent :3 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc fq_codel 0: dev wlan0 parent :4 limit 10240p flows 1024 quantum 
>1514 target 5.0ms interval 100.0ms ecn
>qdisc noqueue 0: dev wlan1 root refcnt 2
>qdisc cake 800e: dev ifb4eth0 root refcnt 2 bandwidth 39300Kbit 
>diffserv4 dual-dsthost rtt 100.0ms noatm overhead 12
>
>eth0 is my WAN facing interface, which is why it's the only interface 
>with 'cake' as the qdisc.  You'll also note the overhead parameter.
>
>'tc -s qdisc' will show some more interesting stats for all the qdiscs.
>
>Narrowing to a particular interface is often more helpful e.g. 'tc -s 
>qdisc show dev ifb4eth0' would show those same stats for the 'incoming'
>
>side of my wan interface.
>
>The outgoing interface is probably where most of the cake action is 
>taking place.  Look at 'drops & marks' for cases where cake has 
>signalled flows to back off.  Also the more dynamic stats of sparse 
>(sp), bulk (bk) and unresponsive (un) flows give a snapshot of how many
>
>flows cake is dealing with right now.
>
>>
>> Also, I've set the overhead to 12 as recommended before, due to the
>VLAN
>> BT Openreach use in the UK, which I believe OpenWRT cannot account
>for.
>> Whilst in this section of the LuCi GUI, I noticed "Which linklayer
>> adaptation mechanism to use; for testing only", has a "cake" option?
>> Should this be enabled?
>
>Yes it should be enabled.

This really depends... Tc's stab (size table) method really is not so bad as long as you do not need to account for ATM cells; cake' s in build overhead accounting is not necessarily better for non-atm links. That said it is still on my to-do list to switch sqm-scripts to use cake' native method as the default if cake is used. But since the default to stab seems to work just as well and is rather universal (and cake' s whole overhead handling is massively under-documented) I never really got around to implement this...

Best Regards
        Sebastian


>
>
>Kevin
>_______________________________________________
>Cake mailing list
>Cake at lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cake

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


More information about the Cake mailing list