Re: [Cake] cake flenter results round 2

[Dave Taht <dave@taht.net>]

I just want to verify that you increased the netem limit by a lot in the scripts?

tc qdisc add dev whatever root netem delay 10ms limit 100000


Georgios Amanakis <gamanakis@gmail.com> writes:

> I did some more testing. Same setup as before, I varied the amount of delay:
>
> server -- delay -- mbox -- client
> netserver Xms/Xms 45/900mbit
>
> Cake config:
> qdisc cake 801b: dev mbox.l root refcnt 2 bandwidth 45Mbit diffserv3
> triple-isolate ack-filter-aggressive rtt 100.0ms noatm overhead 38 via-ethernet
> mpu 84
> qdisc cake 801c: dev mbox.r root refcnt 2 bandwidth 900Mbit diffserv3
> triple-isolate rtt 100.0ms noatm overhead 38 via-ethernet mpu 84
>
> Results:
> delay 10ms (rtt) flent:
> https://drive.google.com/open?id=1hq_MRtocoDglTqxvAHoZvo932ThLBQaC
> delay 10ms (rtt) stat:
> https://drive.google.com/open?id=1kTnpreQzpRn-7iO6i85eXVf8GjJYg19e
>
> delay 20ms (rtt) flent:
> https://drive.google.com/open?id=1Ollbqg7BzM4RiPuSH-tiIuaE8vnKu5tg
> delay 20ms (rtt) stats:
> https://drive.google.com/open?id=1nwS80SJmnVtubIXyYgBCIQdom_QfSSKB
>
> delay 40ms (rtt) flent:
> https://drive.google.com/open?id=1nWUo82_L8_GobR1xbKms-jGhkNwT5msx
> delay 40ms (rtt) stats:
> https://drive.google.com/open?id=1oYfERh57fKHomVHb4z0dHQtFtP2U2aWs
>
> delay 80ms (rtt) flent:
> https://drive.google.com/open?id=17j2T12Xmbi10i-0drHOgdc1x1NL8zAto
> delay 80ms (rtt) stats:
> https://drive.google.com/open?id=1e8cf5z4xDXYMbY8Q1rMvJd8J8F5OOcth
>
> delay 100ms (rtt) flent:
> https://drive.google.com/open?id=1vg-A92eFc7AMSOuBgj-sRnANBMJda9og
> delay 100ms (rtt) stats:
> https://drive.google.com/open?id=1_WojJPa8h9JmNvmWjW9Gos8ShtvM-zt0
>
> I will repeat these with ack-filter instead of ack-filter-aggressive.
>
> George
>
> On Wed, Nov 29, 2017 at 10:44 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>     > (That was also informative for me about how netperf decides when to
>     > emit a data point…)
>     
>     In that case I can add that the stated reason for this way of doing
>     things is performance (i.e., emitting data points should not interfere
>     with transfer performance). This is mostly an issue on systems where
>     getting time is expensive; which is not the case on modern Linux
>     systems. But I'm not entirely sure that the optimisation only has
>     historical reasons; it may be that some systems supported by Netperf
>     still has this issue...
>     
>     -Toke
>     
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake