From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: Sebastian Moeller <moeller0@gmx.de>, <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Configuring cake for VDSL2 bridged connection
Date: Thu, 15 Sep 2016 10:24:44 +0100 [thread overview]
Message-ID: <a0bea93a-1d90-f333-1d17-999f99bc6ed9@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <49D049BE-2130-4947-8D1D-23741D0B4C62@gmx.de>
On 14/09/16 21:48, Sebastian Moeller wrote:
>
>
>>> 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...
I prefer to keep all the manipulation in one module....I'd like to think
it more cpu and cache efficient. Whether cake's add/mul/div calculation
in the case of atm framing as faster than stab's memory table &
potential cache miss is one for the clever people.
>
> Best Regards
> Sebastian
>
>
>>
>>
>> Kevin
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
next prev parent reply other threads:[~2016-09-15 9:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-23 13:44 techicist
2016-08-23 14:27 ` moeller0
2016-08-23 15:13 ` techicist
2016-08-23 20:09 ` Sebastian Moeller
2016-08-24 17:01 ` techicist
2016-08-24 17:03 ` techicist
2016-08-24 17:03 ` techicist
2016-08-24 17:16 ` Alan Jenkins
2016-08-24 19:33 ` techicist
2016-08-24 19:47 ` Alan Jenkins
2016-08-24 19:49 ` Alan Jenkins
2016-08-25 14:53 ` techicist
2016-08-26 8:14 ` Alan Jenkins
2016-08-26 11:15 ` techicist
2016-08-26 11:29 ` moeller0
2016-08-26 11:32 ` techicist
2016-08-27 7:43 ` Alan Jenkins
2016-08-27 16:17 ` techicist
2016-08-27 17:48 ` Alan Jenkins
2016-09-14 20:06 ` techicist
2016-09-14 20:41 ` Kevin Darbyshire-Bryant
2016-09-14 20:48 ` Sebastian Moeller
2016-09-15 9:24 ` Kevin Darbyshire-Bryant [this message]
2016-09-15 9:43 ` techicist
2016-08-26 11:52 ` Alan Jenkins
2016-08-26 12:04 ` techicist
2016-08-27 7:31 ` Alan Jenkins
2016-08-24 8:52 ` Kevin Darbyshire-Bryant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a0bea93a-1d90-f333-1d17-999f99bc6ed9@darbyshire-bryant.me.uk \
--to=kevin@darbyshire-bryant.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox