[Cake] basic cake

[Dave Taht]

I am under the impression that the best case RTT that can be obtained
from dsl to the next hop gateway  is in the 9ms range (no
interleaving) or about 18ms (with interleaving) - no matter the packet
size.

It would be good to know what a basic ping does on a real dsl line, as
that uses nearly the smallest possible packet size. Using a ping with
a larger packet size, to compare.

In setting up a proper emulation the rtt should be in there, in
addition to the other calculations.

What sort of dsl lines are out there? (does anyone still have 384k?
1mbit? on the uplink?)

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Wed, Nov 25, 2015 at 6:45 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 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
>>>
>