<div dir="ltr"><div>With netem's limit set at 100000, I repeated the tests for ack-aggressive, ack, noack.<br><span class="gmail-m_5385637683561042073gmail-im"><br>Setup:<br>server        --        delay        --        mbox        --        client<br></span>netserver             50ms/50ms             45/900mbit<br><br></div>George</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 29, 2017 at 1:51 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">there is no performance impact of using really high values for netem<br>
limit. Stick with 100000. :)<br>
<br>
(well, there is a cache impact, but that's the cost of correct simulation)<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Nov 29, 2017 at 10:19 AM, Georgios Amanakis <<a href="mailto:gamanakis@gmail.com">gamanakis@gmail.com</a>> wrote:<br>
> I completely neglected this. It turns out sometimes netem drops, sometimes<br>
> it doesn't.<br>
> This would also explain the different behaviour I am getting (rrul1)<br>
> sometimes.<br>
> I guess it is because netem doesn't drop in this case.<br>
><br>
> I am attaching a new file with both cases (I could replicate them again).<br>
> Delay's netem and mbox's cake stats are in the txt files.<br>
><br>
> Is a limit of 4000 a sane value?<br>
> Calculated as (0.05s * 900mbit/s / 8bit/byte / 1500bytes/packet)??<br>
><br>
> George<br>
><br>
> On Wed, Nov 29, 2017 at 1:00 PM, Dave Taht <<a href="mailto:dave@taht.net">dave@taht.net</a>> wrote:<br>
>><br>
>> Georgios Amanakis <<a href="mailto:gamanakis@gmail.com">gamanakis@gmail.com</a>> writes:<br>
>><br>
>> > ---------- Forwarded message ----------<br>
>> > From: Georgios Amanakis <<a href="mailto:gamanakis@gmail.com">gamanakis@gmail.com</a>><br>
>> > Date: Wed, Nov 29, 2017 at 12:50 PM<br>
>> > Subject: Re: [Cake] cake flenter results round 2<br>
>> > To: Dave Taht <<a href="mailto:dave@taht.net">dave@taht.net</a>><br>
>> ><br>
>> > To avoid a misunderstanding, the delay parameter in both:<br>
>> > "ip netns exec delay tc qdisc replace dev delay.r root netem delay 50ms"<br>
>> > "ip netns exec delay tc qdisc replace dev delay.l root netem delay 50ms"<br>
>><br>
>> I would strongly suspect you are seeing drops in these qdiscs also<br>
>> without the increased limit, at the increased delay, at 900mbit (go<br>
>> check with ip netns exec delay tc -s qdisc show)<br>
>><br>
>> My original scripts were targeted at 16Mbit/1mbit and thus I didn't<br>
>> change the limit.<br>
>><br>
><br>
</div></div><span class="im HOEnZb">> ______________________________<wbr>_________________<br>
> Cake mailing list<br>
> <a href="mailto:Cake@lists.bufferbloat.net">Cake@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
><br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: <a href="tel:1-669-226-2619" value="+16692262619">1-669-226-2619</a><br>
</div></div></blockquote></div><br></div>