Also, it is easier (for me at least) to download a tarball of all your results for a given run, rather than each one individually.
I am thinking we can rename ack-filter-aggressive to ack-filter-too-damn-aggressive. Dave Taht <[email protected]> writes: > 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 <[email protected]> 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 <[email protected]> >> 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 >> [email protected] >> https://lists.bufferbloat.net/listinfo/cake > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
