<div dir="ltr">I'll hit it from Comcast's ~150Mbps service on the peninsula when I get home today (with and without sqm)<div><br></div><div>-Aaron</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 2:38 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">I just put a netperf server up in linode's freemont, ca, cloud (kvm<br>
paravirtualized hardware), with sch_fq enabled, ecn disabled, and bbr<br>
as the default cc. (reno and cubic are also allowed)<br>
<br>
I am curious if y'all hit it with your rrul, tcp_ndown,<br>
rtt_fair_var_down (vs flent-freemont in the same dc) etc, that you get<br>
sane results - with and without sqm-scripts moderating your<br>
connection.<br>
<br>
I've always kind of worried that sch_fq would misbehave in a<br>
virtualized environment, and they seem to do some odd things with<br>
policing/shaping in their world that I've not sorted out (speeds ><br>
200Mbit)<br>
<br>
DNS for <a href="http://flent-bbr-west.bufferbloat.net" rel="noreferrer" target="_blank">flent-bbr-west.bufferbloat.net</a> is propagating (both IPv4 and IPv6)<br>
<br>
Til then:<br>
the ipv4 for the thing is: 173 dot 230 dot 156 dot 252<br>
<br>
I've put a broad sweep of results up in my github, haven't looked at<br>
them to a huge extent yet.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Sep 26, 2016 at 12:45 PM, Aaron Wood <<a href="mailto:woody77@gmail.com">woody77@gmail.com</a>> wrote:<br>
> Thanks! And sorry that I missed the sample code in the patch.<br>
><br>
> On Mon, Sep 26, 2016 at 12:30 Neal Cardwell <<a href="mailto:ncardwell@google.com">ncardwell@google.com</a>> wrote:<br>
>><br>
>> On Mon, Sep 26, 2016 at 2:47 PM, Aaron Wood <<a href="mailto:woody77@gmail.com">woody77@gmail.com</a>> wrote:<br>
>> > Dumb question on this: The tcp_bbr_info struct for a socket can be<br>
>> > inspected at runtime through the ss utility or through a get socket opts<br>
>> > call, right?<br>
>><br>
>> Yes, you can use either approach:<br>
>><br>
>> (1) from code you can use TCP_CC_INFO socket option; there is sample<br>
>> code in the original kernel patch for TCP_CC_INFO:<br>
>> <a href="https://patchwork.ozlabs.org/patch/465806/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.org/<wbr>patch/465806/</a><br>
>><br>
>> (2) from ss: if you download and build the net-next branch of the<br>
>> iproute2 package:<br>
>><br>
>> <a href="http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/log/?h=net-next" rel="noreferrer" target="_blank">http://git.kernel.org/cgit/<wbr>linux/kernel/git/shemminger/<wbr>iproute2.git/log/?h=net-next</a><br>
>> then you will get support to print out the main parameters for a BBR<br>
>> connection, eg:<br>
>><br>
>> The patch with BBR support for ss is here:<br>
>><br>
>> <a href="http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next&id=2f0f9aef94129643133363b4503468cdccc481cc" rel="noreferrer" target="_blank">http://git.kernel.org/cgit/<wbr>linux/kernel/git/shemminger/<wbr>iproute2.git/commit/?h=net-<wbr>next&id=<wbr>2f0f9aef94129643133363b4503468<wbr>cdccc481cc</a><br>
>><br>
>> As the commit notes, the BBR output looks like:<br>
>> bbr:(bw:1.2Mbps,mrtt:18.965,<wbr>pacing_gain:2.88672,cwnd_gain:<wbr>2.88672)<br>
>><br>
>> Hope that helps,<br>
>> neal<br>
>><br>
>> ><br>
>> > -Aaron<br>
>> ><br>
>> > On Sat, Sep 17, 2016 at 11:34 AM, Maciej Soltysiak<br>
>> > <<a href="mailto:maciej@soltysiak.com">maciej@soltysiak.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> Just saw this: <a href="https://patchwork.ozlabs.org/patch/671069/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.org/<wbr>patch/671069/</a><br>
>> >><br>
>> >> Interested to see how BBR would play out with things like fq_codel or<br>
>> >> cake.<br>
>> >><br>
>> >> "loss-based congestion control is unfortunately out-dated in today's<br>
>> >> networks. On<br>
>> >> today's Internet, loss-based congestion control causes the infamous<br>
>> >> bufferbloat problem"<br>
>> >><br>
>> >> So, instead of waiting for packet loss they probe and measure, e.g.<br>
>> >> when<br>
>> >> doing slow start (here called STARTUP) they don't speed up until packet<br>
>> >> loss, but slow down before reaching estimated bandwidth level.<br>
>> >><br>
>> >> Cake and fq_codel work on all packets and aim to signal packet loss<br>
>> >> early<br>
>> >> to network stacks by dropping; BBR works on TCP and aims to prevent<br>
>> >> packet<br>
>> >> loss.<br>
>> >><br>
>> >><br>
>> >> Best regards,<br>
>> >> Maciej<br>
>> >><br>
>> >><br>
>> >> ______________________________<wbr>_________________<br>
>> >> Cerowrt-devel mailing list<br>
>> >> <a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.<wbr>bufferbloat.net</a><br>
>> >> <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cerowrt-devel</a><br>
>> >><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Cerowrt-devel mailing list<br>
>> > <a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.<wbr>bufferbloat.net</a><br>
>> > <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cerowrt-devel</a><br>
>> ><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Cerowrt-devel mailing list<br>
> <a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.<wbr>bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cerowrt-devel</a><br>
><br>
<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">--<br>
Dave Täht<br>
Let's go make home routers and wifi faster! With better software!<br>
<a href="http://blog.cerowrt.org" rel="noreferrer" target="_blank">http://blog.cerowrt.org</a><br>
</div></div></blockquote></div><br></div>