Re: [Cake] Stranger target behaviour

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

On 01/11/15 16:05, Sebastian Moeller wrote:
> Dear friends of cake,
>
> On Nov 1, 2015, at 14:21 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
>> On 01/11/15 09:47, Sebastian Moeller wrote:
>>> Hi there,
>>>
>>> On Oct 31, 2015, at 21:29 , Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>>> The second one is from the interval >> 4, which equates to 6.2ms. I
>>>> note I picked that because some early data (2012) we had showed that
>>>> target slightly greater than cable media acquision (6ms) time was a
>>>> slight win, and it did not hurt to use a number more evenly divisible
>>>> in binary than the arbitrary 5%.
>>> 	Well, but should it not be 6.2ms even if no rtt is explicitly requested? Currently cake has a lot of corner-cases that are not too well documented either.
>> Sebastian as ever picks up on the exact source of my confusion/point.
>>
>> If 'target=interval/16' is the new mantra then the defaults built in to
>> cake qdisc should be changed, otherwise we have the current situation
>> which is:  Default Interval=100ms, target=5ms.  If I specify rtt 100ms
>> via the joys of tc, then I have: Interval=100ms, target=6.2ms.  If I
>> specify a target keyword such as 'internet' which also has an interval=
>> 100ms, then target become 5ms again.  Somewhat inconsistent.
> 	I believe I just fixed this by initializing target in sch_cake to "interval >> 4”, I opted for the calculation instead of the simple number 6250 to sort of document the pattern and tried to put in a comment explaining why this is okay with codel's theory. Please note, I did not really test this, so for all I know it might break spectacularly...
Looks ok to me, though the optimising compiler likely will turn that
calculation into a constant 6250 anyway ;-)  Only comment would be
'watch your line length' - no lines over 78 chars ideally in the
kernel.  On that note I've just committed some checkpatch
style/formatting related changes.
> 	Slightly different question, I have a few cosmetic changes for tc, so which repository to commit this too, is tc-adv to be the gathering point for changes to be considered?
I've no idea!  Recently I tried to merge Toke's repo version into my
copy of Dave's tc-adv without success.  Well the merge works, but
openwrt complains loudly at this recent version of iproute2 utilities
and so far it's beyond my wit to tease out how to fix.  *if* it worked
then we could be down to 1 repo, 1 version that worked for linux & openwrt.

Speaking purely personally, committing to tc-adv would mean openwrt type
people would test/play with it (me!)  Committing to kau.toke.de would
mean non-openwrters would play....of course you could cherrypick/commit
to both :-)

Kevin



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]