From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 167CE3B29F for ; Sat, 22 Oct 2016 22:30:48 -0400 (EDT) Received: by mail-qk0-x22a.google.com with SMTP id z190so197589552qkc.2 for ; Sat, 22 Oct 2016 19:30:48 -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=S+W1JuYmUa2AKNlZNwJKSiXIY88JnIZdta6X13kQ60U=; b=pcTQyFVJp+WEFvp1TUzxySEB6B+yYsXkkcNwc61LNyK81wAr6kdgZURlnB4HwVKalU VAxLDR8met2zNOiMfc5leEesEzuVXw6dq93Rj4Crit7qAkbV2+a+a5YlYz+NszOfdcOC Jx1VKnQmqPoawPycqGIUQqZ2Pf0HpW9flnbmrkq8pMRrRZwfQWwnDeSm1xfG2Yctd9mf pff3jZg3GungCC26wbescrxTZ9D3SHednHt+SjDMm2g7Jd9t9tse/2Inw29pmeoIQd80 iOoWFcYOaTF2TCCzEaMh1KaVmEFw+VGWV9wRPO/CZjEObQp5Y0M37PLUF5KSFtxCoI0x d3Tg== 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=S+W1JuYmUa2AKNlZNwJKSiXIY88JnIZdta6X13kQ60U=; b=Cvu03+xLBCA/xROnFgpEBNZxYDDRozdS8I5JhovV7gM2ag4KTGkeCDS3HZZCCrfOYQ Uhfyz5zFllH3SlA7G29yYQwO5/spiPF0j3FbRnqZpoJeaOxrxkqICGoZLxHDXBi8t/Ko 1LIxg15WXZ/ROD80CPaKoC9fwBTMUwtKUEP12axkam/SJwFO+I7jmefnpAFEnL1D3OyG twKG28q2n79Hv2WFfIQ9ZmNeLmF17J1GtC+BwkU+mDO5vyisZP4/g7QTDAdqJJA+2fVb bQjKcyHFRPsphyiGxucQUpjO3ufSOKA2veHj/GukBL1ve+baGg+R8AYV2p0Z0bruQM1/ TRdw== X-Gm-Message-State: ABUngvce+iS1hqUWPvCPEPwieWU6wmzJAFeSa8MQWl6ejbMyGsw6HUKSLUXVFMHvLTo+M/SQ+6ooRcyIo9de1g== X-Received: by 10.55.97.13 with SMTP id v13mr8438909qkb.158.1477189848618; Sat, 22 Oct 2016 19:30:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.161.194 with HTTP; Sat, 22 Oct 2016 19:30:47 -0700 (PDT) In-Reply-To: References: From: Benjamin Cronce Date: Sat, 22 Oct 2016 21:30:47 -0500 Message-ID: To: Dave Taht Cc: jb , bloat Content-Type: multipart/alternative; boundary=94eb2c057606315c9a053f7f10cf Subject: Re: [Bloat] 22 seconds til bloat on gfiber? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 02:30:49 -0000 --94eb2c057606315c9a053f7f10cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On the opposite side of things. I found these. I wish more people did high resolution samples. http://www.dslreports.com/speedtest/5414499 http://www.dslreports.com/speedtest/5414506 Why does Google Fiber have so much bloat? They're running line rate. This means their buffers are actually sized to have over 1 second of data at line rate. I understand the underlying protocol is encapsulating groups of Ethernet packets, which increases the burstiness in which the packets are dequeued, but that's insane. On Sat, Oct 22, 2016 at 8:47 PM, Dave Taht wrote: > randomly clicking around, 18 seconds to "start of bloat" on xfinity > http://www.dslreports.com/speedtest/5414347 > > On Sat, Oct 22, 2016 at 6:45 PM, Dave Taht wrote: > > On Sat, Oct 22, 2016 at 6:33 PM, jb wrote: > >> This example takes about 6 seconds to get all the uploads running as > >> they are staged, and then each upload takes a while to get to full spe= ed > >> because that is a function of the senders TCP stack. So the smoothed > >> total transfer rate lags as well, and the whole thing doesn't start to > bloat > >> out until we get to max speed. > >> > >> There is an upload duration preference that can increase the total tim= e > >> upload or download takes but people already have no patience and > >> close the tab when they start seeing decent upload numbers, > >> so increasing it just makes the quit rate higher still. For the quitte= rs > >> we get no results at all, other than they quit before the end of the > test. > > > > I agree that waiting that long is hard on users, and that since it > > takes so long to get to that point, it will take a lot of work for a > > gfiber user to stress out the connection, on a benchmark... but in the > > real world, with a few users on the link, not so much. > > > > 400-1000ms latency when loaded counts as an "F" grade, in my opinion. > > Perhaps doing the grade calculation only when the link is observed > > near max bandwidth achieved (say, half)? > > > > There are of course, other possible reasons for such bloat, like the > > browser falling over, I wish I had a gfiber network and routing device > > to test against. > > > > Is there any way to browse > > http://www.dslreports.com/speedtest/results/isp/r3910-google-fiber for > > like the last 20 results to see if this is a common behavior on gfiber > > for longer tests? > > > >> thanks > >> > >> On Sun, Oct 23, 2016 at 10:52 AM, Jonathan Morton < > chromatix99@gmail.com> > >> wrote: > >>> > >>> > >>> > On 23 Oct, 2016, at 00:56, Dave Taht wrote: > >>> > > >>> > http://www.dslreports.com/speedtest/5408767 > >>> > >>> Looks like that=E2=80=99s how long it takes for the throughput to ram= p up to > link > >>> capacity. That in turn is a function of the sender=E2=80=99s TCP. > >>> > >>> - Jonathan Morton > >>> > >>> _______________________________________________ > >>> Bloat mailing list > >>> Bloat@lists.bufferbloat.net > >>> https://lists.bufferbloat.net/listinfo/bloat > >> > >> > >> > >> _______________________________________________ > >> Bloat mailing list > >> Bloat@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/bloat > >> > > > > > > > > -- > > Dave T=C3=A4ht > > Let's go make home routers and wifi faster! With better software! > > http://blog.cerowrt.org > > > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --94eb2c057606315c9a053f7f10cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the opposite side of things. I found these. I wish more= people did high resolution samples.
http://www.dslreports.com/speedtest/5414499

Why does= Google Fiber have so much bloat? They're running line rate. This means= their buffers are actually sized to have over 1 second of data at line rat= e. I understand the underlying protocol is encapsulating groups of Ethernet= packets, which increases the burstiness in which the packets are dequeued,= but that's insane.

On Sat, Oct 22, 2016 at 8:47 PM, Dave Taht <dave.= taht@gmail.com> wrote:
rand= omly clicking around, 18 seconds to "start of bloat" on xfinity http://www.dslreports.com/speedtest/5414347

On Sat, Oct 22, 2016 at 6:45 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Oct 22, 2016 at 6:33 PM, jb <justin@dslr.net> wrote:
>> This example takes about 6 seconds to get all the uploads running = as
>> they are staged, and then each upload takes a while to get to full= speed
>> because that is a function of=C2=A0 the senders TCP stack. So the = smoothed
>> total transfer rate lags as well, and the whole thing doesn't = start to bloat
>> out until we get to max speed.
>>
>> There is an upload duration preference that can increase the total= time
>> upload or download takes but people already have no patience and >> close the tab when they start seeing decent upload numbers,
>> so increasing it just makes the quit rate higher still. For the qu= itters
>> we get no results at all, other than they quit before the end of t= he test.
>
> I agree that waiting that long is hard on users, and that since it
> takes so long to get to that point, it will take a lot of work for a > gfiber user to stress out the connection, on a benchmark... but in the=
> real world, with a few users on the link, not so much.
>
> 400-1000ms latency when loaded counts as an "F" grade, in my= opinion.
> Perhaps doing the grade calculation only when the link is observed
> near max bandwidth achieved (say, half)?
>
> There are of course, other possible reasons for such bloat, like the > browser falling over, I wish I had a gfiber network and routing device=
> to test against.
>
> Is there any way to browse
> http://www.dslreports.com/speedtest/results/isp/r3910-google-fiber for
> like the last 20 results to see if this is a common behavior on gfiber=
> for longer tests?
>
>> thanks
>>
>> On Sun, Oct 23, 2016 at 10:52 AM, Jonathan Morton <chromatix99@gmail.com>
>> wrote:
>>>
>>>
>>> > On 23 Oct, 2016, at 00:56, Dave Taht <dave.taht@gmail.com> wrote:
>>> >
>>> > http://www.dslreports.com/speedtes= t/5408767
>>>
>>> Looks like that=E2=80=99s how long it takes for the throughput= to ramp up to link
>>> capacity.=C2=A0 That in turn is a function of the sender=E2=80= =99s TCP.
>>>
>>>=C2=A0 - Jonathan Morton
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat@lists.buf= ferbloat.net
>>> https://lists.bufferbloat.net/listin= fo/bloat
>>
>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferb= loat.net
>> https://lists.bufferbloat.net/listinfo/blo= at
>>
>
>
>
> --
> Dave T=C3=A4ht
> Let's go make home routers and wifi faster! With better software!<= br> > http://blog.cerowrt.org



--
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
ht= tp://blog.cerowrt.org
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--94eb2c057606315c9a053f7f10cf--