From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 290C63B29F for ; Sat, 22 Oct 2016 22:27:02 -0400 (EDT) Received: by mail-wm0-x230.google.com with SMTP id f193so53028023wmg.0 for ; Sat, 22 Oct 2016 19:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qz0ekxeo4JmqFbNSgFLTueyLeGMjZ0l2HDJMcm3/6yg=; b=yLJ7Dnh728DBf7kBxe2KCj/qxXdfC0mz0GDJS0Wxwbvz4p/vuGlKW0cNKOYlDRX+St H1WqeOYyZvLK+O6gZWmk15Qx+igk1TRYeAOGG3AsIgrjyDZ8es9nWBxYFdhf8HKBWM3z KrkJqI82FM/CRp6J+I9C/iR9lPvP0QFjleSi7HuGjgivxF4QduGmbKa+aE4MUtTn01up k8s5dSMUc2ezp7jvnKRVh8VXHsIzEqMmzRMHv+5GudE/3eKnfs2gstiSRejwd7IsrzYl HS6lOvtwCJm0qD71dOLkOgdfoPQohW1QIsCbN3L3ZVwPwIXB1G/Qm77LQ7nOc3oHpVwo aTjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qz0ekxeo4JmqFbNSgFLTueyLeGMjZ0l2HDJMcm3/6yg=; b=T+Ryc9bp49MjZD94tNllRQwyP03DmXP+x1xWA9/lwntfMF7UHG/U7g+aHUD0JyJLPF WE+Je2aHnF/4eMyzcd0BTXUzJyX5MOLYGJ85QuP3+srUqUXI0ZP5Ec8afjDUkYGYWDyv 5k57Ay+QHMDzclNhuo9kmpI408aCezhsEyK8OMjmoLeXzG2IlGUITtgXVP3KyZwq1yUK FSDYeqW+PFz2cH9O1ILoAArmSbaFGKY4k+L8txpr+CaWCMeLpx/i4ZEAJ4o9QoR3xJCR kihG9n1K31G0R3vlxmbjZRomHRA9siWqhu7z9QjzDiaPacMIQ0PqpueQre1wRZNm8c36 4jug== X-Gm-Message-State: AA6/9RmiYhDNIpDoCBKbu8TOx0oBPWP1QnYoAM7tXib046tQoiZzM2LiwJcCmMvM9x5xRv/FN2BuV043KodIkw== X-Received: by 10.28.127.215 with SMTP id a206mr16862203wmd.95.1477189621088; Sat, 22 Oct 2016 19:27:01 -0700 (PDT) MIME-Version: 1.0 Sender: justinbeech@gmail.com Received: by 10.28.207.134 with HTTP; Sat, 22 Oct 2016 19:27:00 -0700 (PDT) In-Reply-To: References: From: jb Date: Sun, 23 Oct 2016 13:27:00 +1100 X-Google-Sender-Auth: sym6KTPLlj8t5rnid3REme6Q0gk Message-ID: To: Dave Taht Cc: bloat Content-Type: multipart/alternative; boundary=001a11420cd6a18a69053f7f0260 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:27:02 -0000 --001a11420cd6a18a69053f7f0260 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bloat starts here half way through upload, but it isn't nearly as bad as the original example: https://www.dslreports.com/speedtest/5409732 I wonder if there is a browser or PC component to bad results on google fiber I imagine they all have the same equipment? On Sun, Oct 23, 2016 at 12: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 > --001a11420cd6a18a69053f7f0260 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bloat starts here half way through upload, but it isn'= t nearly as bad as the original example:

I wonder if there is a browser or PC c= omponent to bad results on google fiber I imagine they all have the same eq= uipment?


On Sun, Oct 23, 2016 at 12:47 PM, Dave Taht <dave.taht= @gmail.com> 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 <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

--001a11420cd6a18a69053f7f0260--