there is no performance impact of using really high values for netem limit. Stick with 100000. :)
(well, there is a cache impact, but that's the cost of correct simulation) On Wed, Nov 29, 2017 at 10:19 AM, Georgios Amanakis <[email protected]> wrote: > I completely neglected this. It turns out sometimes netem drops, sometimes > it doesn't. > This would also explain the different behaviour I am getting (rrul1) > sometimes. > I guess it is because netem doesn't drop in this case. > > I am attaching a new file with both cases (I could replicate them again). > Delay's netem and mbox's cake stats are in the txt files. > > Is a limit of 4000 a sane value? > Calculated as (0.05s * 900mbit/s / 8bit/byte / 1500bytes/packet)?? > > George > > On Wed, Nov 29, 2017 at 1:00 PM, Dave Taht <[email protected]> wrote: >> >> Georgios Amanakis <[email protected]> writes: >> >> > ---------- Forwarded message ---------- >> > From: Georgios Amanakis <[email protected]> >> > Date: Wed, Nov 29, 2017 at 12:50 PM >> > Subject: Re: [Cake] cake flenter results round 2 >> > To: Dave Taht <[email protected]> >> > >> > To avoid a misunderstanding, the delay parameter in both: >> > "ip netns exec delay tc qdisc replace dev delay.r root netem delay 50ms" >> > "ip netns exec delay tc qdisc replace dev delay.l root netem delay 50ms" >> >> I would strongly suspect you are seeing drops in these qdiscs also >> without the increased limit, at the increased delay, at 900mbit (go >> check with ip netns exec delay tc -s qdisc show) >> >> My original scripts were targeted at 16Mbit/1mbit and thus I didn't >> change the limit. >> > > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake > -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
