[Cake] Fwd: cake flenter results round 2

Georgios Amanakis gamanakis at gmail.com
Wed Nov 29 13:19:57 EST 2017

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)
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)??


On Wed, Nov 29, 2017 at 1:00 PM, Dave Taht <dave at taht.net> wrote:

> Georgios Amanakis <gamanakis at gmail.com> writes:
> > ---------- Forwarded message ----------
> > From: Georgios Amanakis <gamanakis at gmail.com>
> > Date: Wed, Nov 29, 2017 at 12:50 PM
> > Subject: Re: [Cake] cake flenter results round 2
> > To: Dave Taht <dave at taht.net>
> >
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171129/e32e60f9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ackaggr_netem.tgz
Type: application/x-gzip
Size: 195804 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171129/e32e60f9/attachment-0001.bin>

More information about the Cake mailing list