From: Sebastian Moeller <moeller0@gmx.de>
To: Matthew Ford <ford@isoc.org>
Cc: "Dave Täht" <dave.taht@gmail.com>,
"Cake List" <cake@lists.bufferbloat.net>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cake] [Bloat] dslreports is no longer free
Date: Wed, 27 May 2020 11:32:10 +0200 [thread overview]
Message-ID: <26EE5DA8-8946-4E91-A9EE-2E807D9DB28C@gmx.de> (raw)
In-Reply-To: <289C7A4A-28B1-4692-AA2B-209347E65415@isoc.org>
Hi Mat,
> On May 27, 2020, at 11:08, Matthew Ford <ford@isoc.org> wrote:
>
> What's the bufferbloat verdict on https://speed.cloudflare.com/ ?
Not a verdict per se, but this has potential, but is not there yet.
Pros: Decent reporting of the Download rates including intermediate values
Decent reporting for the idle latency (I like the box whisker plots, ans the details revealed on mouse-over, as well as the individual samples)
Cons: Upload seems missing
Latency is only measured for a pre-download idle phase, that is important, but for bufferbloat testing we really need to see the latency-under-load numbers (separately for down- and upload).
Test duration not configurable. A number of ISP techniques, like power-boost can give higher throughput for a limited amount of time, which often accidentally coincides with typical durations of speedtests*, so being able to confirm bufferbloat remedies at longer test run times is really helpful (nothing crazy, but if a test can run 30-60 seconds instead of just 10-20 seconds that already helps a lot).
Best Regards
Sebastian
*) I believe this to be accidental, as the duration for "fair" power-boosting are naturally in the same few dozends of seconds range as typical speedtests take, nothing nefarious here.
>
> Mat
>
>> On 1 May 2020, at 20:48, Sebastian Moeller <moeller0@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@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
prev parent reply other threads:[~2020-05-27 9:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 16:44 [Cake] " Dave Taht
2020-05-01 19:34 ` [Cake] [Bloat] " Kenneth Porter
2020-05-01 19:54 ` Sebastian Moeller
2020-05-01 19:48 ` [Cake] " Sebastian Moeller
2020-05-01 20:09 ` [Bloat] " Sergey Fedorov
2020-05-01 21:11 ` [Cake] [Bloat] " Sebastian Moeller
2020-05-01 21:37 ` [Bloat] [Cake] " Sergey Fedorov
[not found] ` <mailman.191.1588369068.24343.bloat@lists.bufferbloat.net>
2020-05-01 23:59 ` [Cake] [Bloat] " Michael Richardson
[not found] ` <mailman.170.1588363787.24343.bloat@lists.bufferbloat.net>
2020-05-01 22:07 ` Michael Richardson
2020-05-01 23:35 ` [Bloat] [Cake] " Sergey Fedorov
2020-05-02 1:14 ` [Cake] [Make-wifi-fast] [Bloat] " Jannie Hanekom
2020-05-02 16:37 ` Benjamin Cronce
2020-05-02 16:52 ` Dave Taht
2020-05-02 17:38 ` David P. Reed
2020-05-02 19:00 ` Sergey Fedorov
2020-05-02 23:23 ` David P. Reed
2020-05-03 15:31 ` [Cake] fast.com quality David P. Reed
2020-05-03 15:37 ` Dave Taht
2020-05-02 20:19 ` [Cake] [Make-wifi-fast] [Bloat] dslreports is no longer free Sebastian Moeller
2020-05-27 9:08 ` [Cake] " Matthew Ford
2020-05-27 9:28 ` [Cake] [Make-wifi-fast] " Toke Høiland-Jørgensen
2020-05-27 9:32 ` Sebastian Moeller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26EE5DA8-8946-4E91-A9EE-2E807D9DB28C@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=ford@isoc.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox