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 <[email protected]> wrote: > Thanks! And sorry that I missed the sample code in the patch. > > On Mon, Sep 26, 2016 at 12:30 Neal Cardwell <[email protected]> wrote: >> >> On Mon, Sep 26, 2016 at 2:47 PM, Aaron Wood <[email protected]> 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 >> > <[email protected]> >> > 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 >> >> [email protected] >> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> > >> > >> > _______________________________________________ >> > Cerowrt-devel mailing list >> > [email protected] >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
