[Bloat] 22 seconds til bloat on gfiber?

[Benjamin Cronce]

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 <dave.taht at 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 at gmail.com> wrote:
> > On Sat, Oct 22, 2016 at 6:33 PM, jb <justin at 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  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 quitters
> >> 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 at gmail.com>
> >> wrote:
> >>>
> >>>
> >>> > On 23 Oct, 2016, at 00:56, Dave Taht <dave.taht at gmail.com> wrote:
> >>> >
> >>> > http://www.dslreports.com/speedtest/5408767
> >>>
> >>> Looks like that’s how long it takes for the throughput to ramp up to
> link
> >>> capacity.  That in turn is a function of the sender’s TCP.
> >>>
> >>>  - Jonathan Morton
> >>>
> >>> _______________________________________________
> >>> Bloat mailing list
> >>> Bloat at lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/bloat
> >>
> >>
> >>
> >> _______________________________________________
> >> Bloat mailing list
> >> Bloat at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bloat
> >>
> >
> >
> >
> > --
> > Dave Täht
> > Let's go make home routers and wifi faster! With better software!
> > http://blog.cerowrt.org
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20161022/e768b2a4/attachment-0002.html>