[Cake] cake flenter results round 2

[Georgios Amanakis]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171129/6e0a150a/attachment-0001.html>