Re: [Cake] Cake upstream Planning

[Dave Taht <dave@taht.net>]

Dave Taht <dave@taht.net> writes:

>>
>> TCP RTT ~= 8ms with default qdisc, throughput ~= 940 Mbit
>> TCP RTT ~= 4.5ms with ‘cake unlimited’, throughput ~= 920 Mbit
>> TCP RTT ~= 1ms with ‘cake unlimited lan’, throughput ~= 920 Mbit

This was with BQL in play? Monitoring BQL's behavior might help.

I'd also love to know an exact setting for the shaper as a close as
possible to the underlying bandwidth of ethernet. However, I tend to be
plagued with

>>
>> So yes, we can lower TCP RTT with these more aggressive settings. But just to
>> make sure, we’re confident that there are no other side effects from these lower
>> targets and intervals? Is there anything else I should test for to be sure? For
>> example, when I rate limit to 950 Mbit and try the same test above, ‘lan’ causes
>> a 20% drop in throughput vs the defaults. That may be from an overtaxed CPU, but
>> I don’t know. I also wonder how this affects routed vs local traffic. I’ll try
>> to test this at some point, as I want to understand it better anyway to know how
>> backhaul links should be configured...

One interesting thing that might make tcp behave better is the new
pacing code which lets us set pacing to a different log value. Presently
- at 10 - the TSQ algorithm recalculates things at 1ms. The pacing value
is intended to be changed to, say, 6 or 7 to make wifi work
better... and I suspect, that if it were upped to, say 12 (250us), on ethernet,
that might make pacing more effective there.

Just like breaking the sound barrier, breaking the 1ms barrier looks to
be hard within conventional kernel thread scheduling.

>>
>>     Non-Blockers:
>>     
>>     * I don't believe in cobalt, or rather, I won't believe in it until we
>>     have data at many RTTs. That said, what I'd propose would be a
>>     monolithic cobalt.h file rather than codel5.h.
>>     
>>     The netns stuff will make simulating RTTs and bandwidths much easier….
>>
>>     
>>     * I think the fq_codel batch drop facility is better than what cake uses
>>     in case of floods. Partially due to the need to handle backports the
>>     mechanism fq_codel uses is hard to use - but going mainline we could add
>>     this.
>>     
>>     * The autorate_ingress code should be marked experimental. I keep hoping
>>     it can be improved by better looking for "smoothness" inbound, but
>>     algorithms escape me. This doesn't bother me much, as tcp continues to
>>     be improved over the past 50 years, perhaps we can find ways to improve
>>     this with more users.
>>     
>>     * It is possible to tune the quantum and peeling functions to not peel
>>     to the extent they do. Particularly there is usually no need (aside from
>>     wanting accurate statistics) to peel below 1500 bytes (except perhaps
>>     with the new ack filter mode). We experimented a lot with this in the
>>     early days but could never come to a resolution.
>>     
>>     * I don't have any use for precidence mode and would like to remove it.
>>
>> Regarding non-blockers, for FreeNet’s purposes, I wanted to see if I could add
>> the option to use packet marks as one of the identifiers for host isolation, but
>> I’ve not had time to explore it yet. This would be helpful for ISPs that want to
>> ensure fairness when there isn’t a one-to-one mapping between IP address and
>> customer. I’ll see if I can at least try it.
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake