Is there point in running SQM on dumb AP?

Hi,

I have x86 router and three AX3600 dumb AP's connected via 1GbE. Everything works fine and x86 runs SQM Cake which takes care of buffer-bloat for Internet.

Buffer bloat goes up when running the test via WiFi, which is understandable as WiFi is shared medium with its own stack of buffers.

Is there any point in installing SQM on AP's themselves and letting it take care of WLAN? Max WiFi throughput via iperf3 is around 700Mbit/sec, so GbE is not really saturated so I assume WLAN would be the only part to run SQM on.

Is it better to let WLAN drivers take care of this themselves?

searching the forum for "SQM AP" provides some good answers ....

Hi,

I did the search but majority of content was about how to set up SQM on an AP.
I am able to set it up. My question is more about whether there is any improvement in doing so?
I know that there is some kind of fq_codel built into ath10 and I assume similar pattern exists in ath11 drivers.

So is SQM theretically able to improve packet jitter on a typical 5GHz AP that is not constrained by backhaul or does everything happen already in WiFi part of the path?

I don't think the answer is all that straightforward - see e.g.:

I think with newer WiFi chipsets, it is not necessary.

As a practical matter, it could be that the rates you see through your AP are sufficiently high that you couldn't run cake on them anyway without running out of CPU cycles.

2 Likes

Yes, that is a trade-off. CPU in AP must be fast enough to run SQM without dropping packets and SQM needs to be set lower than theoretical bandwidth in order to have margins for fair-queuing.

But speed in WiFi is always changing depending on reception and QAM used, so SQM would need to dynamically scale the buffer in accordance with WiFi phy.

So I suspect that if any shaping is to take place, it needs to happen in driver itself and not in generic CPU line.

1 Like

Makes sense. cake-autorate could also help dynamically adjust the bandwidth (I remember one user using it for this purpose for a while), but the defaults would probably need tweaking. Still, might help for some edge cases.

Sorry, If I may use the same topic as I have similar question.
I have x86 router with SQM cake/piece of cake connected with LAN to one of dumb AP ( RT3200) and then this AP is connected via WDS to another dumb AP again RT3200 -Let's call it APWDS.
When I test my bufferboat via waveforum with my phone ( S23) connected to the wired dumb AP - all is fine - I get the results I expect A+ Grade.
If I test it connected to APWDS the results are worst - I get B grade, which I find normal.
What puzzels me is that if I test the bufferboat from a laptop connected via Lan to APWDS - I get A+ result.
Does it mean that if I connect another dumb AP via Lan to APWDS, I will get better results or is it just interference as APWDS is client and master using same channel?

yes, acts as repeater, which results in less than half of bandwidth, probably below your SQM peak definition.
So via your Wifi repeater you likely do not reach the throughput max of your WAN/SQM definition.

Well that's my point I am reaching the expected speed. I am connected at 1200 Mbit via Wds ( ax, 80 mhz) and I have 420/ 260 Mbit SQM in any of the 3 scenrios. If WDS halves the bandwith ( let it be) and icreases the buffeebload, then why it is applicable only for the bufferbloat via Wifi and not via Lan.
In summary:
Phone connected to wired AP: no bufferbloat
Phone connected to APWDS: bufferbload
Laptop connected via Lan to the APwds: no bufferbload.

sqm/cake can be used on the LAN side, but with variable link speed interfaces it's hard to tune well enough and would be a rather high strain on the CPU (802.11ac ~350 MBit/s, 802.11ax ~800 MBit/s, that is a lot to do for most chipsets) - and most of the time, your WLAN isn't the real bottleneck here.

So theoretically possible, but generally not advisable (unless you really know what you're doing and add active orchestration around it).

1 Like

I have benchmarked Phone 8 (ac) and iPhone 13 (ax) side to side running iperf3 towards my AX3600 AP. 80MHz channel, 5Ghz, WPA3. ac peaks at 620Mbit, ax peaks at 730Mbit.

Basically, there is 15% bandwidth increase with ax. Far from double. Shaping 730Mbits in router via SQM will take substantial CPU horsepower.

Is there any tool to benchmark packet jitter internally (within my own LAN) between mobile device and router? iperf3 is good at measuring total bandwidth but for jitter I am forced to use web-based tool which muddies the result with everything in-between.

So the idea is to move the relevant parts from fq_codel into the wifi stack, avoiding the need for a shaper, alas that only really works for traffic from the AP to the stations (and only for select WiFi chips). For the other direction, we need to push the same technology into the client side drivers (for all relevant OS), which seems pretty hard. So for the station to AP direction an additional traffic shaper might still have utility, yet there we have essentially the same issue as with internet download/ingress shaping, our shaper sits at the wrong side of the true (variable-rate) bottleneck.... Everything is terrible..

1 Like

Possibly on a laptop install https://flent.org/

1 Like

if you are willing to script a bit:

  • try ping -c 1
  • put that in a shell endless loop
  • add a sleep of like 10ms (or lower if you like)
  • redirect the ping response time output to a log file
  • add a timestamp (date…) for each line
  • You can optionally add an „if“, to skip logging irrelevant ping response times that are below a certain delay threshold.
  • use „time“ for more exact measuring of the execution time of each ping (gets you more precise output than what ping outputs)

I do not have an example script at hand right now.

That will log ping times but unloaded packet jitter is seldom a problem. It is mostly noticeable after loading the connection to maximum. So I would basically need to run iperf3 and ping at the same time and log it.

You could also just log the organic wifi load and look at delay and load in conjunction