LEDE Luci QOS and SQM at same time

Anyways for whatever reason I got better latency with 44 on overhead instead of 18, especially in my COD game. Other question I have for you guys is that, is it ok to have some red spikes in dslreports.com during test even with A grade? Or we should not see any red spike at all to call it sucess?

Don't get too hung up on DLSReports results.

Intersting, for DOCSIS/cable this should not be, but specifying too large an overhead is roughly equivalent with setting a lower bandwidth, so you might want to try that instead?

Give me few numbers to try

Start at 95% of advertised, and work backwards in 5% increments.

Unfortunately even with 50% reduced speed for Up and download still resulted in bufferbloat

Did you set the preferred dslreports settings, that are out there? (Sorry, a bit busy to look up the post on the forum right now) Sets things like longer run time, turning on hi res bufferbloat test, other stuff, makes a standardized test to compare w the other SQM testers. Worth doing, especially the hi res bufferbloat test. Gives detailed graphs. I can't tell, since I'm on my phone, and they don't show on the mobile browser.

Follow the suggested SQM setup process from the LEDE website, using a ethernet connected computer, first.

And, you really do have a 135/5mbit service? Usually they are closer to 10/1 DL/UL ratio... but it could be that way, of course.

FWIW, I get the unfinished test now and then, too.. have yet to figure out why it happens. You won't see the extended bufferbloat graphs unless the test fully finishes, either. I think it's some issue on DSLr's side, since I get a run of it, then not, on my same LEDE fw.

Last note, when running wifi, you might see pretty bad bloat, even with SQM set up well and running... might be bad drivers. I've had bad luck w Win machines and certain wifi adapters, have fixed most, but not all by searching out and updating drivers. If you have a few, you might try them.

Last last note :slight_smile: on my cable, a few huge, short latency spikes are par for the course, but the SQM does seem to flatten a lot of them out. Don't worry too much about it. With the high res graphs, you can see this stuff better.

Could you repeat this test please and also post the output of "tc -s qdisc" from before and after the test. It would also be great if you could try again with the dslreports test as that is so much better/more informative than the seemingly most popular ookla speedtest*

*) I really really can not see why people seem to like ookla that much, sure it is not an incompetent speedtest but its terseness of report is basically only under-passed by fast.com. Now in fast.com's case that terseness truly is designed into the test, so it is by design (or by misdesign)...

An alternative to DSLReports I recommend is the Sourceforge Speed Test

Click on the View Details button at the conclusion of the test.

The sourceforge speed test seems to be pretty bogus and inaccurate, it claims an upload speed >25% faster than my actual line speed (18,2% above my contractual upload speed, 24.1% above my VDSL2 modem's sync rate, ~27% above my effective upload speed) - the download speed seems to be roughly correct (just slightly below the actual figures).

If you're overprovisioned, you can see speeds faster than advertised.

My speeds seem normal.


That would only be possible if sf's speed test would use too small and/ or compressable chunks of data for the upload test. Overprovisioning wouldn't explain values almost a quarter above the actual sync rate of my VDSL2 modem, which is just slightly below the physical maximum of the DSLAM line card and the attainable rate - and in every case more than a quarter above the values I get in real world tests with actual data (both small, medium and several GB in size).

can anyone help me with The FLExible Network Tester? i only have windows 10 on pc and laptop, how can i use this to test bufferbloat?

There are two options:

a) install a VM-system like the free virtualbox and create an ubuntu virtual machine (will work, but might not be as efficient as running on bare metal)

b) try to leverage windows 10's linux subsystem (see https://docs.microsoft.com/en-us/windows/wsl/install-win10), this might or might not work, there have been some recent changes to flent's git repository to work better with windoes, but I do not know whether "better" already means "at all".

After you get flent/netperf installed, please contact me again for actually running a test...

I probably would first try my luck with getting the dslreports speedtest and/or its CLI (commad line interface) up and running. As @JonP indicated, thee is a write-up of configuration recommendations for the dslreports speedtest at https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 (but these will only help after you got around the error; Question: which browsers did you test?).

i used 60 seconds for both up and down

i use chrome browser.

What to you get just using the DSLReports default settings?

Usually A but I get red spikes on download with default test, not with the above setting, seems to stay in green for entire 60 seconds.

Here's the test with wifi 2.4ghz

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