<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 4, 2017 at 6:22 AM, Andy Furniss <span dir="ltr"><<a href="mailto:adf.lists@gmail.com" target="_blank">adf.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Jim Gettys wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, May 3, 2017 at 5:50 AM, Andy Furniss <<a href="mailto:adf.lists@gmail.com" target="_blank">adf.lists@gmail.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Andy Furniss wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Andy Furniss wrote:<br>
<br>
b) it reacts to increase in RTT. An experiment with 10 Mbps<br>
bottleneck,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
40 ms RTT and a typical 1000 packet buffer, increase in RTT<br>
with BBR is ~3 ms while with cubic it is over 1000 ms.<br>
<br>
</blockquote>
<br>
That is a nice aspect (though at 60mbit hfsc + 80ms bfifo I<br>
tested with 5 tcps it was IIRC 20ms vs 80 for cubic). I<br>
deliberately test using ifb on my PC because I want to pretend<br>
to be a router - IME (OK it was a while ago) testing on eth<br>
directly gives different results - like the locally generated<br>
tcp is backing off and giving different results.<br>
<br>
</blockquote>
<br>
I retested this with 40ms latency (netem) with hfsc + 1000 pfifo<br>
on ifb.<br>
<br>
</blockquote>
<br>
So, as Jonathan pointed out to me in another thread bbr needs fq<br>
and it seems fq only wotks on root of a real eth, which means thay<br>
are invalid tests.<br>
<br>
</blockquote>
<br>
Specifically, BBR needs packet pacing to work properly: the<br>
algorithm depends on the packets being properly paced.<br>
<br>
Today, fq is the only qdisc supporting pacing.<br>
<br>
The right answer would be to add packet pacing to cake/fq_codel<br>
directly. Until that is done, we don't know how BBR will work in our<br>
world. - Jim<br>
</blockquote>
<br></div></div>
I guess you mean so cake could be used on egress of sender (in place of fq)?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Yes.</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That's not really the test that I intend to do, which is more like -<br>
<br>
[boxA bbr+fq] -> [boxB simulate ISP buffer] -> [boxC cake ingress shape]<br>
a bit lower than "line" rate and see how much "ISP" buffer gets filled.<br>
<br>
Also compare bbr, cubic and netem different rtts etc.</blockquote><div><br></div><div class="gmail_default" style="font-size:small">Ok. The usual warnings about netem being dangerous apply, though netem can be useful if run on a separate machine. Netem is an attractive nuisance, but has caused lots of results to be ultimately useless.... Be careful.</div><div class="gmail_default" style="font-size:small"> - Jim</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I will soon (need to find a crossover cable!) be able to see using<br>
a third sender how cake varies shaping bbr in simulated ingress.<br>
<br>
I can test now how bbr fills buffers - some slightly strange<br>
results, one netperf ends up being "good" = buffer only a few ms.<br>
<br>
5 netperfs started together are not so good but nothing like<br>
cubic.<br>
<br>
5 netperfs started with a gap of a second or two are initially<br>
terrible, filling the buffer for about 30 seconds, then eventually<br>
falling back to lower occupancy.<br>
<br>
TODO - maybe this is a netperf artifact like bbr/fq thinks it is<br>
app limited.<br>
<br>
The worse thing about bbr + longer RTT I see so far is that its<br>
design seems to be to deliberately bork latency by 2x rtt during<br>
initial bandwidth probe. It does drain afterwards, but for<br>
something like dash generating a regular spike is not very game<br>
friendly and the spec "boasts" that unlike cubic a loss in the<br>
exponential phase is ignored, making ingress shaping somewhat less<br>
effective.<br>
</blockquote></blockquote>
</div></div></blockquote></div><br></div></div>