From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6391E3B25E for ; Mon, 26 Sep 2016 18:09:55 -0400 (EDT) Received: by mail-ua0-x236.google.com with SMTP id i25so3129236uab.0 for ; Mon, 26 Sep 2016 15:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k3UPt3Jn869iHSkinW1bru2V/c2wkU63HIozhb838HU=; b=HcyKGuYlW9OGRRJtQ0CTSzomrOQAmv1KfZCBAGCqvJEDy6RtAepkj6zA6mKJPt+nK4 tEBAs9J2mdhYZ45BvApQ5q+DSrjNM5KoUiQEh+shyd0TEFUu97+w8Y9pSMHcKw6Qb6Db 3cFgSmRjcQdEs5bwYQI+JuUOmvZoJlK65L8hiu/+UYlFq1JAtnuMl+9fHTgcxNi8JxmH tJ7LukhjDujonDZocOuSt+i6WP8ygxKzfuho1e3o0vMEFSvkZPAvTL8eV718ImMfUgka H5cKjLeSjDtPd643JUZhiW8042LuOMbc8GP7q0WBTX2o+Fj7fSFeoPTc2M0OuYh1nwF8 8uWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k3UPt3Jn869iHSkinW1bru2V/c2wkU63HIozhb838HU=; b=R6pTnWSb5GQovDRmahxav8YFffv9FnmQxXYCB7zRcUQ3uglTgModtTMdk7uyqPiYga ES3VEhJJ5SVblOcw8Pw9nKYPIgnfB4byHlH4wFnr9wfJeuWaFsKWjKrpB4ykITnIickL 8MKOZbtRBBFyb872aeuNxBjQiTg2GYRePOkSqNsckGvnrQQbxbQBDuCgK1het2dfgKEI eN4YoOXi6uMZvWDzx3PrKtx37iJqrttHycyXSUAr42Ro1zDl3y1Ypqdno1PbpFYqet63 2JvJgZvR3QPKvKhErILQN3OUGOC4Y3yHrQmZQu24/Rapp/Pw4mXgK+Iz+ezgcJRptR8h JX1A== X-Gm-Message-State: AA6/9RlhtkHpcSYB8grSRyXsNuVXzZywXXiS/JVVZCQNXOViHcVDh/v57uSX+dihjXgHyFO9T7holarwj8j/mg== X-Received: by 10.176.5.169 with SMTP id e38mr519764uae.7.1474927794851; Mon, 26 Sep 2016 15:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.117.214 with HTTP; Mon, 26 Sep 2016 15:09:53 -0700 (PDT) In-Reply-To: References: From: Aaron Wood Date: Mon, 26 Sep 2016 15:09:53 -0700 Message-ID: To: Dave Taht Cc: "cerowrt-devel@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=94eb2c12315c481751053d7063ad Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 22:09:55 -0000 --94eb2c12315c481751053d7063ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll hit it from Comcast's ~150Mbps service on the peninsula when I get home today (with and without sqm) -Aaron On Mon, Sep 26, 2016 at 2:38 PM, Dave Taht wrote: > 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 wrote: > > Thanks! And sorry that I missed the sample code in the patch. > > > > On Mon, Sep 26, 2016 at 12:30 Neal Cardwell > wrote: > >> > >> On Mon, Sep 26, 2016 at 2:47 PM, Aaron Wood 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=3Dnet-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=3Dnet-next&id=3D2f0f9aef94129643133363b4503468 > cdccc481cc > >> > >> 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 > >> > > >> > 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=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > --94eb2c12315c481751053d7063ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll hit it from Comcast's ~150Mbps service on the= peninsula when I get home today (with and without sqm)

= -Aaron

On Mon, Sep 26, 2016 at 2:38 PM, Dave Taht <dave.taht@gmail.com&g= t; wrote:
I just put a netperf ser= ver 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 a= t
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:=C2=A0 The tcp_bbr_info struct for a so= cket 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 samp= le
>> code in the original kernel patch for TCP_CC_INFO:
>>=C2=A0 =C2=A0 https://patchwork.ozlabs.org/pa= tch/465806/
>>
>> (2) from ss: if you download and build the net-next branch of the<= br> >> iproute2 package:
>>
>> http:/= /git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/log= /?h=3Dnet-next
>>=C2=A0 =C2=A0then you will get support to print out the main parame= ters for a BBR
>> connection, eg:
>>
>>=C2=A0 =C2=A0The patch with BBR support for ss is here:
>>
>> http://git.kernel.org/cgit/<= wbr>linux/kernel/git/shemminger/iproute2.git/commit/?h=3Dnet-next= &id=3D2f0f9aef94129643133363b4503468cdccc481cc
>>
>>=C2=A0 =C2=A0As the commit notes, the BBR output looks like:
>>=C2=A0 =C2=A0 =C2=A0bbr:(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 cause= s the infamous
>> >> bufferbloat problem"
>> >>
>> >> So, instead of waiting for packet loss they probe and mea= sure, e.g.
>> >> when
>> >> doing slow start (here called STARTUP) they don't spe= ed up until packet
>> >> loss, but slow down before reaching estimated bandwidth l= evel.
>> >>
>> >> Cake and fq_codel work on all packets and aim to signal p= acket loss
>> >> early
>> >> to network stacks by dropping; BBR works on TCP and aims = to prevent
>> >> packet
>> >> loss.
>> >>
>> >>
>> >> Best regards,
>> >> Maciej
>> >>
>> >>
>> >> _______________________________________________
>> >> Cerowrt-devel mailing list
>> >> Ce= rowrt-devel@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/= listinfo/cerowrt-devel
>> >>
>> >
>> >
>> > _______________________________________________
>> > Cerowrt-devel mailing list
>> > Cerowr= t-devel@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@l= ists.bufferbloat.net
> https://lists.bufferbloat.net/listin= fo/cerowrt-devel
>



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

--94eb2c12315c481751053d7063ad--