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
