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).
Mitigated Bufferbloat (https://www.dslreports.com/speedtest/9507819)
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.