LEDE Luci QOS and SQM at same time

Upload speed is improved.

Keep in mind these numbers and "grades" can change minute to minute.

I use servers that are close to me geographically, and use the default settings, which I feel is a more "real-world" test than rigging the test settings to get a desired result.

Are you now using SQM only? QOS only? Both?

Okay, this looks pretty decent. The spikes especially in downloading at around 66ms are still not nice, but they seem to be intermittent so I would ignore them for now.

@Happi, @jwoods might be interested in those results, I certainly am not. By default dslreports, like most other speedtests, will measure for a much shorter duration and that often hides bufferbloat (or rather does make its consequences less obvious).

Compared to the wired test above this indicates that on wifi you have other issues (the observed bandwidth indicates that sqm's shaper is not even exercised that much as wifi seems to be the bottleneck). Also the android browser you used is not able to sustain the requested 16/16 streams and falls back to 3/3 ("00.01s restrict to 3 streams due to slow browser"), the RTT to the servers is also significantly worse than during the wired test.
Could you repeat the wifi test while logging into the router and monitor the output of "top -d 1" (look whether the idle % gets close to zero).

That's fine.

I'm interested in seeing tests that are not rigged to get a desired result.

@jwoods, what in the recommendations under https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 appears to "rig" the test, and why do you believe the default settings to be more "real-world"?

And I am interested in data supporting your insinuation about rigging.

How? These scripts are shell scripts that will not run on windows (at least not out of the box) and they require a gn/bsdu ping and netperf to be installed and in the path, that is going to be tough for non-unix users. (Sure it is possible to run this on macosx but that will not help a considerable number of users that are windows only). And running netperf on the router itself (which will make the user a linux-user) is certainly not recommended if one intends to test the routers routing performance.

I guess your talking about @richb-hanover's betterspeedtest.sh

We ask users all the time to SSH in to the router and run commands...not difficult.

opkg update

opkg install netperf

Cut and paste the contents of betterspeedtest.sh into an .sh file on the router, or copy it over in its entirety.

Run the shell (example is in /tmp)

root@LEDE:/tmp# sh betterspeedtest.sh -4 -H netperf.bufferbloat.net -t 60

I changed the ping location in the script from gstatic.com to google.com.

To cite myself why I consider the idea to run netperf on the router less than ideal:

The point is that running netperf has a considerable CPU cost and will exercise different parts of the network stack and the firewall than routing. This is still a fine test, but it does not test the typical use-case so I would not recommend that to get an sqm configuration in decent shape.

1 Like

Your opinion.

We mitigate bufferbloat at the router, not endpoints.

Sure, I just happen to have spend considerable amounts of time helping users with that specific topic (bufferbloat and sqm configuration) and with some success I might add. What are your credentials in that matter?
And where is your substantiation of your claims that the dslreports "defaults" are more real-world relevant than the recommendations given in https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803?
Yes I am mildly annoyed by your obnoxiousness and insinuations, but I am also willing to act on your insight, assuming you can actually point out which of the recommendations are deficient. I am not willing that to act on your gut feeling alone though, so if you have data to back up your point, please, also present that.

That is not generally correct; but in the context of this thread, sure, we talk about configuring ingress and egress shaping on the WAN link to avoid suffering from the DOCSIS equipment's to generous latency allowances.
Note though that you used the word "router" and running netperf on the "router" does not test routing performance but rather the capabilities of the device as a "server", as I have already argued above. If you disagree with my assessment, please offer some data instead of terse "haikus".

No one cares (I know I don't) about your credentials, or whether you are mildly annoyed.

Your replies are becoming boring.

It's mildly interesting that DSLReports suggests not changing the defaults. Their results are somewhat inconsistent, so I don't use them anymore.

These results are consistent...first is with SQM, second without.

root@LEDE:/tmp# sh betterspeedtestnew.sh -4 -H netperf.bufferbloat.net -t 60
2018-04-04 01:32:00 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging google.com (60 seconds in each direction)
.............................................................
 Download:  5.72 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 24.397
    10pct: 26.989
   Median: 34.427
      Avg: 34.998
    90pct: 40.122
      Max: 86.542
..............................................................
   Upload:  0.95 Mbps
  Latency: (in msec, 62 pings, 0.00% packet loss)
      Min: 24.189
    10pct: 24.815
   Median: 29.377
      Avg: 29.923
    90pct: 34.220
      Max: 40.506
root@LEDE:/tmp# sh betterspeedtestnew.sh -4 -H netperf.bufferbloat.net -t 60
2018-04-04 01:37:23 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging google.com (60 seconds in each direction)
.............................................................
 Download:  5.92 Mbps
  Latency: (in msec, 59 pings, 0.00% packet loss)
      Min: 23.415
    10pct: 45.317
   Median: 80.596
      Avg: 78.029
    90pct: 98.806
      Max: 101.222
.....................................................................
   Upload:  0.9 Mbps
  Latency: (in msec, 63 pings, 0.00% packet loss)
      Min: 24.028
    10pct: 1714.662
   Median: 5286.372
      Avg: 4676.073
    90pct: 5891.121
      Max: 5901.980

People can decide for themselves.

Remind me, did I sign up here to entertain you or to help @Happi to get his sqm instance properly configured? :wink:

But to your argument, credentials do matter to some degree, especially if there are conflicting lines of advice as in this case @Happi might want to know the track record of the two sources, no?

Look, I asked for detailed information about deficits in the recommendations and all you deliver is this? In other words you seemingly did not base your assessment on real data but on gut feeling. You claim that dslreports "suggests not changing the defaults", do you have a link to that claim, please?

Please define "consistency"...

Sidenote: with your bandwidth ~6/1 Mbps your router probably has plenty of CPU cycles left to run the netperf binaries, but at @Happi's ~150/5 DOCSIS link shaping alone will eat up a lot CPU cycles so it is not clear that he will have enough left for the netperf instances. And as explained above you are not exercising the same software paths as when routing packets though the router.
There even was a bug fixed recently when locally generated/terminated traffic over ADSL was super-slow while routed traffic was not affected; see https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=17eb826a703d996d12004b68df12003a12d71421: "The speed through the DSL router was always as high as it should be, only traffic generated on the router itself were affected."
While this bug needed fixing, it indicates that it really is important to understand what exactly one tests and to select the test that is appropriate for the question one wants to answer.

Plus, using flent as a machinery to drive netperf and friends does allow to capture and store and image/visualize much more interesting data.
Tip: try https://github.com/richb-hanover/OpenWrtScripts instead of https://github.com/richb-hanover/CeroWrtScripts as the latter is less maintained than the former.

@jwoods, you might reconsider about not caring whether you annoy people in this forum as one of lede's principles was/is "be nice to each other". I certainly need to remind my self of that principle every now and then.

Years of experience using DSLReports and noting the results.

The betterspeedtest script is the same in both, so a non-issue.

I was referring to you specifically, rather than "people".

When you started throwing shade with this comment...

...expect it in return.

The moderators can feel free to delete any of my posts that don't comply with site policy.

Back on topic.

Please don't do that, and for several reasons. First, routing is different than output. And second, for my high speed connection running speedtests on the router produced vastly inferior results than running it on a separate PC, since the router was running out of CPU cycles. Use a dedicated PC connected through Ethernet for speedtesting, especially when SQM is in the mix, as that also requires a lot of processing power. Never use WiFi. Dslreports has been fine and very consistent in my testing, although that script can also be used.

Not knowing what speed test you were running and how it was configured, there isn't really anything to compare.

@richb-hanover can weigh in on his script, but I did not run out of CPU cycles on an Archer C7 v2 using it.

My results testing on the router varied ~2-3% from other web-based tests, with DSLReports as the outlier, so YMMV.

Flash-based web tests will produce different results than HTML5-based tests.

Browser add-ons can affect the results.

People can use whatever test tool they want.

I know what I won't be using.

I'm out.

As I said gut-feeling or can you share the links to the measurement results showing the inconsistencies?
That fits with your unwillingness/inability to show how the recommendations for configuring the dslreports speedtest lead to a "rigging" of the test to yield less real-world relevant results than the default. Now you can claim that the recommendations "rig" the test to yield more relevant bufferbloat measurements, but that, in my book, is a reason to follow those recommendations over the defaults (but that "rigging" is specifically noted as a rationale for the recommendations in the linked post).

Have a look at https://github.com/richb-hanover/OpenWrtScripts/commit/52f0c9e2c52352b6ed899af3738270f040fe69c1 you will notice that the scripts are not exactly the same. But my point still stands that we should direct new users to the openwrt scripts repository as this is the successor to the cerowrt repository, even if the actual differences are not that substantial right now.

I fail to see how even just annoying me rhymes with the "be nice to each other" directive? Plus I am not throwing shade, at least I did not want to do that; I really just wanted to un-confuse the OP about what tests I want to see. Because from my perspective the tangent about which speedtest to use is not helping getting the OP's problems fixed...

Well, my problem is that I want to help the OP and you are decidedly not helping in that*; I tried to politely ignore this obviously for too long. This whole tangent about your preferred speedtests did at best confuse the OP without getting me closer to get data to figure out what is going on on his link.
*) I do not want to imply that all of your points have been wrong (even though I believe some were) but mostly that they are not helping solving the OP's issues.

This would be an extreme remedy that should be reserved for totally unacceptable behavior (and I do not claim unacceptable behaviour just annoying rudeness). In this forum the moderators are just very hands-off, which is nice.
But just because the moderators do not admonish about a behavior does not mean that any behavior is okay. (This is the same flawed reasoning that makes some publicly traded companies only take penal law as the measure of what is acceptable...).

Thou doth protest too much...

Your keyboard warrior approach and condescending attitude have done nothing to help the OP.

If you have an issue with my posts, report it to a moderator.

Some call it protest, others call it "showing that the emperor has no clothes" (in that you still have a number of claims that await substantiation by data/evidence).
My point is not so much that you are "wrong" in your opinions but that to convince others you should be willing to present supporting information instead of purely subjective gut-feeling. But by now you have used up my good-will towards assuming your assertions are "true" until backed-up by data. You might note how I deflated your canards by posting links supporting my claims (like the adsl bug that affected router-initiated/-terminated traffic but not routed traffic; like the commit showing that betterspeedtest.sh is not identical in the two repositories). I also repeat that I am willing to change my opinions based on data and facts.

Not sure, I have a hunch that it would drive you to leave this thread it would increase the signal to noise ration and that in turn would also help the OP.
If you find my tone condescending then "welcome to the club", or put differently we are even then...

Yes, I have an issue with your unfriendly attitude and I fail to see how the moderators could help there. It is your decision how you conduct yourself in this forum, but I am just as free to point out that I would appreciate if you would generally act nicer. By now, I am pretty rude, this is just my attempt at modifiyng my communication so that you get my drift.

@Happi to increase the signal to noise ration in this thread I will try to refrain from going in tangents with jwoods. I will still counter argue if he keeps injecting irrelevant tangents without substantiating facts, but I will let the rest go.
I am still happy to try helping you get to the bottom of your issue. Whether sqm can be configured to solve the problem I do not know, but let's try.