[Cake] basic cake

Sebastian Moeller moeller0 at gmx.de
Wed Nov 25 15:08:28 EST 2015


Hi Dave,

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




More information about the Cake mailing list