Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next

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

I just put a netperf server up in linode's freemont, ca, cloud (kvm
paravirtualized hardware), with sch_fq enabled, ecn disabled, and bbr
as the default cc. (reno and cubic are also allowed)

I am curious if y'all hit it with your rrul, tcp_ndown,
rtt_fair_var_down (vs flent-freemont in the same dc) etc, that you get
sane results - with and without sqm-scripts moderating your
connection.

I've always kind of worried that sch_fq would misbehave in a
virtualized environment, and they seem to do some odd things with
policing/shaping in their world that I've not sorted out (speeds >
200Mbit)

DNS for flent-bbr-west.bufferbloat.net is propagating (both IPv4 and IPv6)

Til then:
the ipv4 for the thing is: 173 dot 230 dot 156 dot 252

I've put a broad sweep of results up in my github, haven't looked at
them to a huge extent yet.


On Mon, Sep 26, 2016 at 12:45 PM, Aaron Wood <woody77@gmail.com> wrote:
> Thanks! And sorry that I missed the sample code in the patch.
>
> On Mon, Sep 26, 2016 at 12:30 Neal Cardwell <ncardwell@google.com> wrote:
>>
>> On Mon, Sep 26, 2016 at 2:47 PM, Aaron Wood <woody77@gmail.com> wrote:
>> > Dumb question on this:  The tcp_bbr_info struct for a socket can be
>> > inspected at runtime through the ss utility or through a get socket opts
>> > call, right?
>>
>> Yes, you can use either approach:
>>
>> (1) from code you can use TCP_CC_INFO socket option; there is sample
>> code in the original kernel patch for TCP_CC_INFO:
>>    https://patchwork.ozlabs.org/patch/465806/
>>
>> (2) from ss: if you download and build the net-next branch of the
>> iproute2 package:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/log/?h=net-next
>>   then you will get support to print out the main parameters for a BBR
>> connection, eg:
>>
>>   The patch with BBR support for ss is here:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?h=net-next&id=2f0f9aef94129643133363b4503468cdccc481cc
>>
>>   As the commit notes, the BBR output looks like:
>>     bbr:(bw:1.2Mbps,mrtt:18.965,pacing_gain:2.88672,cwnd_gain:2.88672)
>>
>> Hope that helps,
>> neal
>>
>> >
>> > -Aaron
>> >
>> > On Sat, Sep 17, 2016 at 11:34 AM, Maciej Soltysiak
>> > <maciej@soltysiak.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Just saw this: https://patchwork.ozlabs.org/patch/671069/
>> >>
>> >> Interested to see how BBR would play out with things like fq_codel or
>> >> cake.
>> >>
>> >> "loss-based congestion control is unfortunately out-dated in today's
>> >> networks. On
>> >> today's Internet, loss-based congestion control causes the infamous
>> >> bufferbloat problem"
>> >>
>> >> So, instead of waiting for packet loss they probe and measure, e.g.
>> >> when
>> >> doing slow start (here called STARTUP) they don't speed up until packet
>> >> loss, but slow down before reaching estimated bandwidth level.
>> >>
>> >> Cake and fq_codel work on all packets and aim to signal packet loss
>> >> early
>> >> to network stacks by dropping; BBR works on TCP and aims to prevent
>> >> packet
>> >> loss.
>> >>
>> >>
>> >> Best regards,
>> >> Maciej
>> >>
>> >>
>> >> _______________________________________________
>> >> Cerowrt-devel mailing list
>> >> Cerowrt-devel@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >>
>> >
>> >
>> > _______________________________________________
>> > Cerowrt-devel mailing list
>> > Cerowrt-devel@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org