[SQM/QOS] Recommended settings for the dslreports speedtest (bufferbloat testing)

Dear All,

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):

  1. set "No. download streams:" to 16 (if this causes errors during testing change both to 8 or even lower (see Note 1 below)

  2. 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.

  1. 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.

  1. set "Upload duration:" to 30, note not registered anonymous users are not allowed to change the duration

  2. 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.

  1. 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.

  1. 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).

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)

Notes:

  1. 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)

  2. 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.

  3. 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

  4. 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.

12 Likes

Great to have a well standardized method for the community, to gauge what is a difficult to visualize issue and when it's improved.

One thing to be aware of, if you look at the results on a mobile phone vs the full site (some of us, like me, do most of their browsing on phones?) you don't see the most useful part, the high res bufferbloat graphs. At least on my Android with the browsers I use. Not sure if there's a way around this, didn't see a link to switch sites, etc.

I wanted to mention it, since it caught me out back when I first started to look at this, and those hi-res latency graphs are the main piece of information.

1 Like

Hi Jon,

good point! As a work around firefox offers a "Request desktop site" checkbox in the menu that appears if one clicks the 3 stacked dots symbol in the upper right corner; once this box is checked, firefox shows the bufferbloat plots again. The same trick also seems to work for chrome. It is a bit counter intuitive that dslreports hide this information for mobile users though...

Best Regards

I get best results by setting ingress to 0 and egress to 1.5 times the upload bandwidth, along with layer_cake.

That sounds interesting, could you post a link to the detailed result of your speedtest, please (instructions in post #1 above). In theory that setting should give maximum bandwidth but should also show high latency-under-load numbers (bufferbloat); if it does not show bad bufferbloat, either your ISP runs a tight ship with little bufferbloat, or something is wrong. In any case I would recommend we discuss this in a different thread, as it seems only remotely related to settings for the dsreports speedtest, okay?

Best Regards

Hi,

After read topic and re-configure my test.

I run the tests with the default settings and get an "A" 99% of the time.

I believe that the fault of the low note, be it from my ISP, because although I use fiber I noticed that my line has a lot of packet loss, I would very much like to find a solution to stabilize the IPTV application quality in Smartv, I have not got it right yet.

continue to test the QOS settings until you find the best one

I am not quite sure what your exact problem is. In any way I believe that it is not directly related how to configure the dslreports speedtest and hence might be better placed in its own new thread.

Imho there should be a thread about the best SQM and overhead settings for diffrent types of access. (DSL/VDSL,CABLE/DOCSIS, Fiber aso)
It's quite hard to figure it out on your own if your not an expert about SQM QoS and i think that would help a lot of people not to wrongly configure SQM and get bad or even worse results that without SQM... :wink:

What you describe is exactly why CAKE was developed!

There isn't any "generic" settings possible as every line is different, even within the same technology and provider. It even varies by time of day, weather, and how long your modem has "trained" (sometimes over days).

Other challenges come with type of equipment. If you've got a DOCSIS 3.1 modem and a properly configured DOCSIS 3.1 head end, there's already PIE at the head end. Your settings may well be completely different than someone that has a DOCSIS 3.0 modem that gets routed to head-end equipment that doesn't supply PIE.

There might be some rules of thumb, but it really comes down to "try it and see", as well as your own tolerance for lag and how you balance that out against bandwidth.

Using flent-gui I can get a line "tuned" with CAKE or fq_codel to something reasonable in under an hour, without knowing what is happening in the algorithms.

1 Like

This is my current SQM settings, from another post on the forum:

sqm.eth1=queue
sqm.eth1.interface='pppoe-wan’
sqm.eth1.download='14400’
sqm.eth1.upload='10800’
sqm.eth1.debug_logging='0’
sqm.eth1.verbosity='5’
sqm.eth1.qdisc='cake’
sqm.eth1.script='piece_of_cake.qos’
sqm.eth1.qdisc_advanced='1’
sqm.eth1.squash_dscp='1’
sqm.eth1.squash_ingress='1’
sqm.eth1.ingress_ecn='ECN’
sqm.eth1.egress_ecn='ECN’
sqm.eth1.enabled='1’
sqm.eth1.qdisc_really_really_advanced='1’
sqm.eth1.itarget=‘7.5ms’ 
sqm.eth1.etarget=‘7.5ms’ 
sqm.eth1.iqdisc_opts='rtt 150ms nat dual-dsthost mpu 64’
sqm.eth1.eqdisc_opts=‘rtt 150ms nat dual-srchost mpu 64’
sqm.eth1.linklayer='ethernet’
sqm.eth1.overhead='8’
sqm.eth1.linklayer_advanced='1’
sqm.eth1.tcMTU='2047’
sqm.eth1.tcTSIZE='128’
sqm.eth1.tcMPU='128’
sqm.eth1.linklayer_adaptation_mechanism='cake’

So, I agree with your observation that this would be nice. But I also agree with @jeff that there typically is no generic setting that is easy to recommend.

Now two more procedural points:
a) Why don't you just start that thread? I believe you should have the permission to just start a new thread (and you could just start by moving your initial post into the new thread)

b) I would like to point out politely (and I know that this will partly fail) that this thread is not the right place to discuss per packet overhead or typical encapsulation schemes.

c) this is also not the best place to discuss individual /etc/config/sqm instances.

2 Likes

Yes you are right about this thread, but i'm realy no expert about QoS.
But anyway i'm thinking about to start a new and clean thread about SQM QoS Settings.
Imho it's way better to have a general settings thread than searching through all the other question ones here in the forum !
Especially overhead calculation would be interesting... If you could offer some input out of your experience it could be a useful thread ! :slight_smile:

For example i never heared of "rtt 150ms and sqm.eth1.itarget=‘7.5ms’
sqm.eth1.etarget=‘7.5ms’ " settings before...
We can discuss this within the new thread, as you said it's not the right thread here and i completely understand this.

Thanks for your time.

2 Likes

For a start, use the LEDE luci-sqm interface to get a basic configuration without having to learn much... then learn more and experiment more. Start a thread if you need to.

And yes, this isn't the place, just the place holder of the "standardized" settings for Dslreports, so we can have more consistent results using it as a testing tool.

Could you - perhaps on another thread - perhaps outline your procedure for tuning with flent in another thread?

1 Like