[Bloat] [Cake] dslreports is no longer free
Sergey Fedorov
sfedorov at netflix.com
Fri May 1 17:37:10 EDT 2020
Thanks for the kind words, Sebastian!
+1; for normal users that is already bliss. For de-bloating a link however
> a bit more time resolution generally makes things a bit easier to reason
> about ;)
Apologies, I misunderstood your original statement. I interpreted it as a
vote to keep a single bufferbloat metric (vs loaded/unloaded latency).
Agreed on time resolution and its value. No question it's useful for
diagnostics. Open question is to what extent browser-based tools should be
used for detailed troubleshooting (due to sandboxing limitations), and when
is the time for the big guns (like flent) to enter the scene.
I like to talk about the latency-under-load-increase when helping people
> to debloat their links, but that also is a tad on the long side.
Fully agree on length, don't like the verboseness as well. Still looking
for a term that is shorter and yet generic enough that I can explain to my
mom.
Ah, I might have tried too hard at understatement, this was the only
> back-end worth mentioning in the "pros" section...
Got it. The breitbandmessung case is indeed interesting.
SERGEY FEDOROV
Director of Engineering
sfedorov at netflix.com
121 Albright Way | Los Gatos, CA 95032
On Fri, May 1, 2020 at 2:11 PM Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Sergey,
>
>
>
> > On May 1, 2020, at 22:09, Sergey Fedorov <sfedorov at netflix.com> wrote:
> >
> > Great review, Sebastian!
> >
> > NETFLIX: fast.com.
> > Pros: allows selection of upload testing, supposedly decent
> back-end, duration configurable
> > allows unloaded, loaded download and loaded upload RTT
> measurements (but reports sinlge numbers for loaded and unloaded RTT, that
> are not the max)
> > Cons: RTT report as two numbers one for the loaded and one for
> unloaded RTT, time-course of RTTs missing
> > BUFFERBLOAT verdict: incomplete, but oh, so close...
> > Just a note that I have a plan to separate the loaded latency into
> upload/download. It's not great UX now they way it's implemented.
>
> Great! I really appreciate the way fast.com evolves carefully to
> not confuse the intended users and to stay true to its core mission while
> it still gaining additional features that are not directly part of Netflix
> business case to operate that test in the first place. Don't get me wrong,
> I absolutely love that I can easily understand why you should be interested
> in getting reliable robust speedtests from all existing or potential
> customers to your back-end; and unlike an ISP's internal speedtest, you are
> not likely to sugar coat things ;) as your goal and the end-user's goal are
> fully aligned.
>
> > The timeline view is a bit more nuanced, in the spirit of the simplistic
> UX, but I've been thinking on a good way to show that for super users as
> well.
>
> Great again! I see the beauty of keeping things simple while maybe
> hiding optional information behind an additional "click".
>
> > Two latency numbers - that's more user friendly, we want the general
> user to understand the meaning.
>
> +1; for normal users that is already bliss. For de-bloating a link
> however a bit more time resolution generally makes things a bit easier to
> reason about ;)
>
> > And latency under load is much easier than bufferbloat.
>
> +1; as far as I can tell that term sort of was a decent
> description of the observed phenomenon that then got a life of its own; in
> retrospect it was not the most self explanatory term. I like to talk about
> the latency-under-load-increase when helping people to debloat their links,
> but that also is a tad on the long side.
>
> >
> > As a side note, if our backend is decent, I'm curious what are the
> backends for the speed tests that exist that are great :)
>
> Ah, I might have tried too hard at understatement, this was the
> only back-end worth mentioning in the "pros" section...
> (well, I also like how breitbandmessung.de deals with their purposefully
> limited backend (all located in a single" data center in Germany located in
> an AS that is not directly owned by any ISP, it's the german regulators
> official speedtest for germany against which we can effectively measure and
> get an early exit from contracts if the ISPs can not deliver the contracted
> rates (with a bit of slack)))
>
> Best Regards
> Sebastian
>
> >
> > SERGEY FEDOROV
> > Director of Engineering
> > sfedorov at netflix.com
> > 121 Albright Way | Los Gatos, CA 95032
> >
> >
> >
> > On Fri, May 1, 2020 at 12:48 PM Sebastian Moeller <moeller0 at gmx.de>
> wrote:
> > Hi Dave,
> >
> > well, it was a free service and it lasted a long time. I want to raise a
> toast to Justin and convey my sincere thanks for years of investing into
> the "good" of the internet.
> >
> > Now, the question is which test is going to be the rightful successor?
> >
> > Short of running netperf/irtt/iper2/iperf3 on a hosted server, I see
> lots of potential but none of the tests are really there yet (grievances in
> now particular order):
> >
> > OOKLA: speedtest.net.
> > Pros: ubiquitious, allows selection of single flow versus
> multi-flow test, allows server selection
> > Cons: only IPv4, only static unloaded RTT measurement, no
> control over measurement duration
> > BUFFERBLOAT verdict: incomplete, maybe usable as load generator
> >
> >
> > NETFLIX: fast.com.
> > Pros: allows selection of upload testing, supposedly decent
> back-end, duration configurable
> > allows unloaded, loaded download and loaded upload RTT
> measurements (but reports sinlge numbers for loaded and unloaded RTT, that
> are not the max)
> > Cons: RTT report as two numbers one for the loaded and one for
> unloaded RTT, time-course of RTTs missing
> > BUFFERBLOAT verdict: incomplete, but oh, so close...
> >
> >
> > NPERF: nperf.com
> > Pros: allows server selection, RTT measurement and report as
> time course, also reports average rates and static RTT/jitter for Up- and
> Download
> > Cons: RTT measurement for unloaded only, reported RTT static
> only , no control over measurement duration
> > BUFFERBLOAT verdict: incomplete,
> >
> >
> > THINKBROADBAND: www.thinkbroadband.com/speedtest
> > Pros: IPv6, reports coarse RTT time courses for all three
> measurement phases
> > Cons: only static unloaded RTT report in final results, time
> courses only visible immediately after testing, no control over measurement
> duration
> > BUFFERBLOAT verdict: a bit coarse, might work for users within a
> reasonable distance to the UK for acute de-bloating sessions (history
> reporting is bad though)
> >
> >
> > honorable mentioning:
> > BREITBANDMESSUNG: breitbandmessung.de
> > Pros: query of contracted internet access speed before
> measurement, with a scheduler that will only start a test when the backend
> has sufficient capacity to saturate the user-supplied contracted rates,
> IPv6 (happy-eyeballs)
> > Cons: only static unloaded RTT measurement, no control over
> measurement duration
> > BUFFERBLOAT verdict: unsuitable, exceot as load generator, but
> the bandwidth reservation feature is quite nice.
> >
> > Best Regards
> > Sebastian
> >
> >
> > > On May 1, 2020, at 18:44, Dave Taht <dave.taht at gmail.com> wrote:
> > >
> > >
> https://www.reddit.com/r/HomeNetworking/comments/gbd6g0/dsl_reports_speed_test_no_longer_free/
> > >
> > > They ran out of bandwidth.
> > >
> > > Message to users here:
> > >
> > > http://www.dslreports.com/speedtest
> > >
> > >
> > > --
> > > Make Music, Not War
> > >
> > > Dave Täht
> > > CTO, TekLibre, LLC
> > > http://www.teklibre.com
> > > Tel: 1-831-435-0729
> > > _______________________________________________
> > > Cake mailing list
> > > Cake at lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/cake
> >
> > _______________________________________________
> > 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/cake/attachments/20200501/f9969ce6/attachment-0001.html>
More information about the Cake
mailing list