Re: [Cake] Fwd: cake flenter results round 2

[Dave Taht <dave.taht@gmail.com>]

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 <gamanakis@gmail.com> 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 <dave@taht.net> wrote:
>>
>> Georgios Amanakis <gamanakis@gmail.com> writes:
>>
>> > ---------- Forwarded message ----------
>> > From: Georgios Amanakis <gamanakis@gmail.com>
>> > Date: Wed, Nov 29, 2017 at 12:50 PM
>> > Subject: Re: [Cake] cake flenter results round 2
>> > To: Dave Taht <dave@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.
>>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619