[Cake] basic cake

[Sebastian Moeller]

Hi Dave,

On Nov 25, 2015, at 18:30 , Dave Taht <dave.taht at gmail.com> wrote:

> On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> Hi Dave,
>> 
>> On Nov 25, 2015, at 17:02 , Dave Taht <dave.taht at gmail.com> wrote:
>> 
>>> Last night I went about removing nearly every unproven "feature" that
>>> has been added to cake since july, in part to establish a baseline for
>>> a performance comparison directly against sqm-scripts with
>>> htb+fq_codel, on low end hardware, and in part, to be able to test
>>> each newer feature
>>> more fully on the testbed.
>> 
>>        Oh, shiny, want have ;) So the plan is to assess the performance cost of each of the individual features to allow a better rationale to justify keeping or rejecting specific ones? Sounds like a excellent idea.
> 
> pithy note here:
> 
> https://github.com/dtaht/bcake/commit/4b9e6035bfa0160fa3fdaddcf1722c1cf924afa9

	Oh, I am all for a) testing things properly before setting defaults, b) actually expose toggles for important parameters (toggles that better be followed, if I request "target 1 ms” I am fine with cake whining/complaining in the log, I am not fine with cake just (silently) doing what it thinks best; but we have been there before and I failed to convince enough people on that approach, so that boat has sailed and now instead of one cake with one toggle we have 2 cakes without toggles ;) (note I do like the implement and test one change at a time approach,))

> 
>> 
>>> 
>>> The very long list of commits is here, complete with pithy comments,
>>> in the separate repo.
>>> 
>>> https://github.com/dtaht/bcake/commits/master
>>> 
>>> I would like it if someone using a low end home router could benchmark
>>> this version of cake
>>> against the mainline version.
>> 
>>        Hrmmm, for that I would need to build my own firmwares, let’s see whether I am up for that… oh, will newcake still accept all of tc-adv’s command line arguments (and simply ignore them?)
> 
> I am keeping the api for now.

	Great that will make comparative testing easier...

> 
> I note that first up is cake besteffort flowblind 384k and cake
> besteffort flowblind 1mbit, with 5ms target.

	My hypothesis is that cake will stay longer in the drop state than required, effectively sacrificing more bandwidth (per flow) than necessary to reach the sojourn target. Cake’s approach to dequeue nicely time based should make sure packet sojourn time will actually be a good correlate at what happens at the real bottle-neck. Now I am curious what the results will be? So to risk a prediction, without the target adjustment or the 1 packet is always allowed shortcut original codel took, cake will sacrifice more bandwidth reducing effective throughput. I have no good idea for latency of un-related sparse flows, but would assume they will suffer a bit as well (entering drop state immediately?). Anyway looking forward to the results.

> 
> While we have established that "bad things happen", I really don't
> know what they look like. We have a lot of tools
> for generating traffic, but no pictures of what actually happens.

	Yes, +1 for better/more visualizations.

> 
> But you might want to skip this round of testing before we establish
> this baseline and move on.

	Given the sorry state of my home network, I probably should wait a bit ;).

Best Regards
	Sebastian

> 
>> 
>>> 
>>> My plan, such as it is, is to keep simplifying, and testing.  I still
>>> don't get the new hashing
>>> API....
>>> 
>>> This reduction effort was fruitful in that I found yet another way to
>>> reuse "now"…
>> 
>>        As long as there are few enough cycles between the uses that sounds wonderful, otherwise now degrades to once ;)
>> 
>>> fixed one bug, maybe spotted another...
>>> 
>>> Toke has been busy with flent, which has gained a really abusive 1000
>>> tcp flows test,
>> 
>>        bidirectional by any chance? Sort of the full internet simulator for home-routers?
>> 
>> 
>> Best Regards
>>        Sebastian
>> 
>>> and
>>> the ability to parse qdisc statistics, so long as you tell flent where
>>> to get them from:
>>> 
>>> 
>>> --test-parameter qdisc_stats_hosts=localhost\
>>> --test-parameter qdisc_stats_interfaces=$IFACE\
>>> 
>>> http://snapon.cs.kau.se/~d/newcake/t
>>> 
>>> 
>>> --
>>> Dave Täht
>>> Let's go make home routers and wifi faster! With better software!
>>> https://www.gofundme.com/savewifi
>>> _______________________________________________
>>> Cake mailing list
>>> Cake at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>>