SQM on RPI4 drops considerable amount of speed

Let's start by making the EU-300 the wan, then re-visit the CPU load issue and then re-evaluate whether the pi under OpenWrt works well enough, or not...

Regarding the CPU:
install htop and configure it to show the detailed CPU time (IIRC htop will not show soft interrupt processing otherwise, but that is where qdiscs like cake are accounted fir), then run htop on the OpenWrt router parallel to capacity tests and look whether any CPU is clogged by too much SIRQ (in the per CPU bar graphs this is shown as pink or purple) if the CPU load approaches 90% you likely have an issue. Then enabling packet steering might help or manually assigning and pinning interrupts... but first figure out whether we actually see CPU overload...

Tried this, The CPU barely touches 20%. Do note after switching the ports, i did touch 290 for a few tries before falling back to 230

Please remind me, if you disable sqm what rate do you measure?

Around 230, which is already far lower than what I should be getting which is around 290

Update, restarted openwrt and I am getting 290 without sqm

Mmh and with sqm?

About 170-190

It was probably a one off bad result in regards to latency,

      Server: RADINET Info. Solutions Pvt Ltd - Kota (id: 35153)
         ISP: Radinet Info Solutions Private
Idle Latency:     3.36 ms   (jitter: 0.11ms, low: 3.20ms, high: 3.48ms)
    Download:   190.57 Mbps (data used: 236.9 MB)
                  9.55 ms   (jitter: 4.19ms, low: 3.17ms, high: 24.25ms)
      Upload:   265.20 Mbps (data used: 256.6 MB)
                 10.12 ms   (jitter: 3.04ms, low: 4.51ms, high: 24.81ms)
 Packet Loss:     0.0%

My bufferbloat test on wired moved from a C to a A+

As you're using snapshot, be aware that there are 2 modes for packet steering - '1' is the newer method introduced in snapshot, and '2' is the method used in 23.05 and earlier. Test both, as the old method ('2') can have better performance.

where is this mode option?


Any core on my cpu barely crosses 5%, not even sure if sqm is actually functioning or not..

Uploads are better, about 20% usage and under load ping increases by 2ms compared to 30 of download

Using wifi the above results are found.

Using ethernet though, the cpu load touches 20%, bufferbloat doesn't occur.

Both ethernet and wifi are connected to the dumb AP.

With or without SQM?

With SQM enabled

The amount of cpu required depends on the amount of traffic.... to test whether sqm works try setting the shaper rates for both directions to 100 Mbps and run a online test....

If wired sqm seems to help but not over WiFi I would guess that likely your WiFi is the bottleneck... and bufferbloat is mostly dependent on the bufferibg/queueing at the bottleneck link. The whole idea behind sqm's traffic shaping is to make sure the effective bottleneck is on the sqm node so sqm's AQM (active queue management) and traffic scheduler are in control...

1 Like

SQM seems to be working over wifi..

Well thats very unfortunate as i excluisively use WIFI.

Also my AP is a Archer AX23 which uses the MT7621 chip which can't do sqm at 300.

Also i am getting rather inconsistent results, I reran the test over wifi and now the ping is +3ms on download and +0 on upload and a A+ grade.

EDIT - Ran it again, back to +30

I belive i should open another thread to chase this down?

My main concern is my AP is underpowered to do SQM, Since the RPI will handle WAN side and the AP only needs to do SQM on wlan, would that make it's life easier?

Please post the output of:

### check airtime fairness / AQL support on OpenWrt:
ubus call system board | grep 'model\|description'
iw list | grep 'Wiphy\|TXQS\|AIRTIME_FAIRNESS\|AQL'
iwinfo | grep 'Hardware:\|PHY name'

on your AP... that will give us the capabilities (these should handle download traffic reasonably well, but upload is under control of the stations...)

The point is that for WiFi fq_codel really should be part of the WiFi stack and made to operate well with the variable rate nature of WiFi...

Well, I would recommend to use ethernet for truly latency sensitive stuff like remote desktop or on-line gaming...

So here is the rub, under saturating loads fq_codel and cake will actually allow the standing queue to rise of to target and that will show in the average RTT increase, so with the default target of 5ms the average RTT should also increase by ~5ms, and hence if a bufferbloat test returns the average RTT increase you need to expect around +5ms in each direction... with WiFi adding more variability.

Your choice, after it is your thread, however you are likely to attract more eyes/help if you post a new thread with a title fitting your actual question.

It isn't on openwrt right now, as I am worried about unnecessarily fiddling with it and finding out the device doesn't support SQM. It's a Archer AX23 with dual core 880MHZ MT7621DAT soc and present in the openwrt wiki

That pretty much means that none of the OpenWrt WiFi goodies are implemented...

As I said for WiFi you really want to move fq_codel into the AP where it does not need a traffic shaper and hence is considerably cheaper...

So installing OpenWrt seems at least an option... but the dual core MIPS CPU is not going to be fast...
But given:
Warning 05/2024 There is no confirmed way to revert to OEM firmware at the moment. Do not proceed with installation, if not sure. Check the forum discussion.

you really need to be certain you are willing to risk switching to OpenWrt, assuming you have the V1 version to begin with...