Dear All,
NOTE: As of late April/early May 2020 the dslreports speedtest seems to be disabled because of overload? Not clear how/if that situation is going to resolve, we might have just lost a powerful bufferbloat measurement tool. While I hope that this fine service is going to come back again, I anyway want to take the opportunity to thank dslreports for their great service for all those years for free!
As of mid 2020 tests seem to work again to some degree, so please use cautiously to avoid overloading the servers; that means by all means no automated repeated tests using the dslreports infrastructure, for simple bandwidth measurements, Ookla's speedtest.net (as of mid 2022 both the iOS and Android clients also report latency under load as detailed results) should be better suited for that use case, as would be fast.com (which can be configured to also report loaded latency, but it is unclear what the single number represents). Also a decent speedtest leveraging cloudflare's CDN as traffic source and sink is the waveform speedtest https://www.waveform.com/tools/bufferbloat; and this one actually measures latency as well and allows to download a .csv file containing the individual latency measurements. Cloudflare itself also added latency under load measurements to https://speed.cloudflare.com which also contains an un-loaded packet-loss test. BUT see Note 5, and always try the http test if https tests fail
Occasionally, while trying to understand bufferbloat issues, it is helpful to have finer control over a speedtest's variables than most speedtests seem to expose. Luckily the https://www.dslreports.com/speedtest offers a number of interesting knobs and toggles, if one completes the free registration. Here is the set of configuration changes I recommend to users wanting to better understand the bufferbloat behavior of their link (say, while trying to reduce bofferbloat with qos-scripts or sqm-scripts).
I recommend to configure the following speedtest parameters (you get to the configuration/preferences page by clicking the cog button):
-
set "No. download streams:" to 16 (if this causes errors during testing change both to 8 or even lower (see Note 1 below)
-
set "No. upload streams:" to 16 (if this causes errors during testing change both to 8 or even lower (see Note 1 below)
Rationale: To test the suitability of a link for concurrent usage one better tests with concurrent usage.
- check the "Hi-Res BufferBloat:" checkbox (on the detailed results page of a finished test click the Idle, Downloading, and Uploading labels underneath the bufferbloat bar graph to get results from all individual latency probes per test phase to better understand the bufferbloat issues)
Rationale: The higher temporal resolution helps in differentiating between different potential causes for high bufferbloat measurements.
-
set "Upload duration:" to 30, note not registered anonymous users are not allowed to change the duration
-
set "Download duration:" to 30, note not registered anonymous users are not allowed to change the duration
Rationale: A number of ISPs use transient bandwidth boosting approaches that are a decent help for sparse users, but that will also often make a short speedtest report overly optimistic bandwidth numbers. Since these transient boost typically seem to be only a few seconds measuring longer will help average their effect partially away.
- check the "dodge compression: " checkbox
Rationale: While compression can be a fair way to increase bandwidth, it is not a generally applicable technique and will not allow to compress all data equally well.
-
if you perform a test post a link to the detailed results page here in the forum (much nicer than just overview images), either copy and past the "link" from the results page "Sharing" section, or better select "Linked BBCode" which will give the summary graphic tat also acts as a link to the detailed results page (but make sure that those graphics actually display in the forum, otherwise post the link).
-
It seems a number of SSL cerificates used when HTTPS is enabled have expired and cause errors, so better not check the HTTPS checkbox (see note 5 below).
Examples (click on image to go to the detailed results):
Unmitigated Bufferbloat, especially on egress ([http://www.dslreports.com/speedtest/6796065])(http://www.dslreports.com/speedtest/6796065):
Mitigated Bufferbloat (https://www.dslreports.com/speedtest/9507819)
I would recommend to not simply judge a link by the one letter Bloat classifier in the summary graph but always look at the three individual detail plots (by clicking the "Idle", "Downloading", and "Uploading" links at the bottom of the three bars in the default bufferbloat plot).
Notes:
-
If your internet connection is very slow you might need to reduce the number of concurrent streams to account for the slowness. Depending on the asymmetry of the link you might need to use a lower number of streams in the upload direction. Typically a smaller number of streams will lead to less utilization of the link and lower reported bandwidth numbers. More streams emulate multiple concurrent bandwidth users, if you only ever use the link with one bandwidth heavy application at a time, setting the number of streams to 1 or 2 might lead to a better estimate of the useable bandwidth for that application, but for bufferbloat testing more streams typically create a stricter test, so go as high as your link will allow.
The ready-made profile types all use different numbers of streams (which seems a decent approach to account for the different capabilities of the different link technologies), which will make it somewhat tricky to compare the bandwidth results between the different profiles, so make sure to always use the same profile (potentially your own) when aiming for comparable tests...
If one selects too many streams in a direction the symptoms might be that not all of them start up and one gets an error message somewhere in the detailed results, in that case one should select a lower number until one finds a number that reliably works; also for asymmetrical links this number can be different for upload and download. It seems not important to always use the maximum number though, but something like 8-16 should allow to saturate a link even with TCP's typical bandwidth probing...
Also note that for some users setting the number of streams too high (say 16/16 for a 2/0.3 ADSL link) will not result in the described error message, but instead a badly bloated test result, in that case one should also try to manually set the test to use fewer streams (see https://forum.openwrt.org/t/sqm-makes-bufferbloat-significantly-worse/13456/33?u=moeller0) -
Once the test is running you can use the field at the bottom labeled "Note:" to add information about the test, this is a great place to document any relevant data, especially if you set out to test a number of different configurations.
-
For the lucky ones with really fast (500 Mbps and above?) links, have a look at the "official" dslreports recommendations of how to trim your browser/OS to be able to reliably hit such speeds: https://www.dslreports.com/forum/r29994522-speedtest-gigabit-testing-results-debugging
-
The dslreports speedtest results page renders different versions for mobile browsers, especially it does not show the bufferbloat detailed results; at least for mobile firefox this can be worked-around by checking the "Request desktop site" checkbox (this checkbox should be visible after clicking/tapping the three vertical dots "hamburger lite" menu in the upper right corner) and reloading the results.
-
Some/most/all? SSL certificates of the dslreports speedtest servers seem to cause issues with modern browsers, so make sure to run the test over http instead of https. There is a clickable link (use http) on the top right corner of the widget in which to select the test type, make sure to click this.
