@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).
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.
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.
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".
Remind me, did I sign up here to entertain you or to help @Happi to get his sqm instance properly configured?
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.
@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.
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.
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).
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...).
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.