Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
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


      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