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@netflix.com 121 Albright Way | Los Gatos, CA 95032 On Fri, May 1, 2020 at 2:11 PM Sebastian Moeller wrote: > Hi Sergey, > > > > > On May 1, 2020, at 22:09, Sergey Fedorov 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@netflix.com > > 121 Albright Way | Los Gatos, CA 95032 > > > > > > > > On Fri, May 1, 2020 at 12:48 PM Sebastian Moeller > 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 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@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/cake > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > >