[Cake] basic cake

[Cake] basic cake

[Dave Taht]

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.

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.

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"... fixed one bug, maybe spotted another...

Toke has been busy with flent, which has gained a really abusive 1000
tcp flows test, 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

Re: [Cake] basic cake

[Sebastian Moeller]

Hi Dave,

On Nov 25, 2015, at 17:02 , Dave Taht <dave.taht@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.

> 
> 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?)

> 
> 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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] basic cake

[Dave Taht]

On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> On Nov 25, 2015, at 17:02 , Dave Taht <dave.taht@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

>
>>
>> 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.

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

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.

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

>
>>
>> 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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] basic cake

[Sebastian Moeller]

Hi Dave,

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

> On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Dave,
>> 
>> On Nov 25, 2015, at 17:02 , Dave Taht <dave.taht@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>> 

Re: [Cake] basic cake

[Kevin Darbyshire-Bryant]

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

On 25/11/15 17:45, Sebastian Moeller wrote:
> Hi Dave,
>
> On Nov 25, 2015, at 18:30 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>> Hi Dave,
>>>
>>> On Nov 25, 2015, at 17:02 , Dave Taht <dave.taht@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,))
>
https://github.com/kdarbyshirebryant/sch_cake/tree/copyparms  - matching
tc with 'copytarget copyinterval' etc
https://github.com/kdarbyshirebryant/tc-adv/tree/copyparms

Works.  Never got as far as devising a test let alone running it.


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

Re: [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@gmx.de> wrote:
> Hi Dave,
>
> On Nov 25, 2015, at 18:30 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>> Hi Dave,
>>>
>>> On Nov 25, 2015, at 17:02 , Dave Taht <dave.taht@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@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cake
>>>
>

Re: [Cake] basic cake

[Kevin Darbyshire-Bryant]

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

On 25/11/15 18:23, Dave Taht wrote:
> What sort of dsl lines are out there? (does anyone still have 384k?
> 1mbit? on the uplink?)
Emphatic yes.  Not me personally, other family members on end of long
lines with 448kbit uplink. 1mbit-ish on down adsl.


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

Re: [Cake] basic cake

[Sebastian Moeller]

Hi Dave,

On Nov 25, 2015, at 19:23 , Dave Taht <dave.taht@gmail.com> wrote:

> 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.

Not sure about interleaving, if I can dig up something there I will report it here.

So on a modern VDSL2 line (rated 50/10Mbps) using G.INP retransmissions on the downstream and interleaving (of unknown depth) on the upstream I get:

user@computer:~> /usr/sbin/traceroute gstatic.com
traceroute to gstatic.com (173.194.112.55), 30 hops max, 60 byte packets
 1  172.30.42.1 (172.30.42.1)  0.289 ms  0.279 ms  0.313 ms
 2  87.186.224.243 (87.186.224.243)  8.715 ms  8.271 ms  8.254 ms
 3  87.186.194.202 (87.186.194.202)  9.307 ms  9.319 ms  9.309 ms
 4  217.239.48.202 (217.239.48.202)  11.146 ms  11.156 ms  11.157 ms
 5  72.14.217.76 (72.14.217.76)  10.363 ms  10.588 ms  10.598 ms
 6  209.85.254.108 (209.85.254.108)  12.143 ms  10.329 ms  17.548 ms
 7  72.14.235.247 (72.14.235.247)  10.407 ms  10.205 ms  10.397 ms
 8  fra07s28-in-f23.1e100.net (173.194.112.55)  10.359 ms  10.300 ms  10.446 ms
 
but from ; ping -c 1000 87.186.194.202 (the first ICMP responder) I get a summary:
--- 87.186.194.202 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 1000700ms
rtt min/avg/max/mdev = 6.896/9.313/23.189/1.292 ms

So your 9ms is not too far off of my ~7ms best case result. I note that supposedly BT uses G.INP on both down- and upstream (at least they were reported to test that configuration) potentially reducing the RTT to around < 7ms. I also note that XDSLs all seem to use a 4KHz symbol clock, so 1/4ms is the theoretical lower bound just based on that...


> 
> 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.


	I have some data for a number of lines, but currently lack the access to that data, I will try to compile it and send the data your way.

> 
> 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?)

	I believe even in many european countries and the rural US there are plenty of lines at the outer reaches of ADSL connectivity, so some lines only have 384k on the downlink and 64k on the uplink …

Best Regards

> 
> 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@gmx.de> wrote:
>> Hi Dave,
>> 
>> On Nov 25, 2015, at 18:30 , Dave Taht <dave.taht@gmail.com> wrote:
>> 
>>> On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>> Hi Dave,
>>>> 
>>>> On Nov 25, 2015, at 17:02 , Dave Taht <dave.taht@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@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/cake
>>>> 
>>