SQM for WLAN, need seperate settings

it might be easiest to run irqbalance and hope it does an ok job

I've got this result with irqbalance, without offloading, no sqm applied.

Edit: But cat /proc/interrupts indicate 1e100000.ethernet still only use CPU0.

it's actually quite hard to test these high speeds, speed test sites can't necessarily keep up

The irqbalance is working, the following is the new results:

root@OpenWrt:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  8:     775118     775083     775092     775081  MIPS GIC Local   1  timer
  9:      53012          0          0          0  MIPS GIC  63  IPI call
 10:          0    1623144          0          0  MIPS GIC  64  IPI call
 11:          0          0    1768554          0  MIPS GIC  65  IPI call
 12:          0          0          0    1400583  MIPS GIC  66  IPI call
 13:     114178          0          0          0  MIPS GIC  67  IPI resched
 14:          0      78174          0          0  MIPS GIC  68  IPI resched
 15:          0          0     104412          0  MIPS GIC  69  IPI resched
 16:          0          0          0      90060  MIPS GIC  70  IPI resched
 18:         12          0          0          0  MIPS GIC  33  ttyS0
 19:          0          0          0          0  MIPS GIC  29  xhci-hcd:usb1
 20:    9831142          0          0          0  MIPS GIC  10  1e100000.ethernet
 21:          2          0          0          0  MIPS GIC  30  gsw
 22:        308          0          0    2474134  MIPS GIC  11  mt76x2e
 23:       1027     998889          0          0  MIPS GIC  31  mt76x2e
ERR:         73

in which clearly shows the mt76x2e work has been partially re-distributed to CPU1 & CPU3, instead of all load to CPU0 as before.

1 Like


The 'e' s in the rps ouput are somewhat odd......

Interesting idea, according to https://www.kernel.org/doc/Documentation/networking/scaling.txt OpenWrt does seem to do the recommended thing, but the results for a number of dual-core router seem to indicate that the official recommendations might aim at highe core counts. So irqbalance (if applicable) might be a nice fire-and-forget way to imprve on the openwrt defaults without having to dive into the intricacies of scaling.txt!

Yes, now the next thing would be to test sqm again (that is bidirectional sqm on wan, versus egress sqm on WAN plus your strict WLAN sqm limits)

With 700Mbps WAN the WLAN is the slowest link (usually). So SQM on the WAN alone is never going to fully mitigate the issue for wifi clients.

DSCP tags plus WMM will help, for a variable speed medium this is probably the best strategy

1 Like

Well, yes, but IMHO these are orthogonal issues. I had hoped the airtime fairness patches in 19.07 would solve the wlan issue without the need for a separate sqm instance on wifi (he is running 5 traffic shapers in the selected configuration which seems computationally quite expensive). Unlike the uolink, where cooperation from the ISP can simply not be expected, the FOSS drivers for the wlan should make it possible to reduce wifi bufferbloat without having to resort to apply static shapers to a variable bitrate link...

You know what I am going to say ;)... This is not going to significantly reduce his wifi bufferbloat, unless his issue is that his neighbors starve him of airtime, IMHO. It might also help if he has low bandwidth traffic of high importance that requires low-latency, but it will then merely move wifi bufferbloat around then to the other ACs (which might a perfectly acceptable solution for his use-case, but it feels like a work-around, no?).
It takes deep knowledge, restraint and taste to deal properly with the challenges of WMM (that is to say, I believe you are on top of this and do this to great success, but one needs to overcome the urge to simply put everything into AC_VO ;)* ).

I think the airtime fairness approach of including fq_codel into the 802.11 stack has the highest promise both for fairness/sharing as well as for latency (IIRC the target there is 20ms, which is not perfect, but a whole different game than the pre-ATF defaults). That said, this only helps if the wifi drivers for the OP's router support that reliably already (and it looks like that is not the case).

*) Which will just overload AC_VO and result in similar bufferbloat for the OP but in addition to airtime starvation for all other close-by APs on the same channel.

Well, bloated buffers are only a problem for latency sensitive traffic. for example a 10 hour torrent download doesn't "feel" slow because of an extra 500ms of bufferbloat.

Putting DNS in the VI queue, game and VoIP in VO, and all streams that have transferred more than ~1MB into Bulk goes a long way towards making the experience snappy. with that you can initiate new connections and get fast responses for new web pages.

1 Like

Assuming that "game traffic" is relatively sparse...

With this I disagree, not every transfer exceeding 1MB is bulk... (think video streaming which easily exceeds 1MB in volume and will be unhappy in AC_BK, AC_BE should be fine though). I do believe that the heuristic that fq_codel uses, give a small boost to new and/or sparse flows (sparse relative to the available bandwidth) is a pretty decent one with relative minor side-effects.
But really ath9K has airtime fairness for some time now, and I have had no real issues with wifi lag anymore*, short of doing test with flooding AC_VO from my macbook, which basically wipes out all other traffic, be it TX or RX (this is the test that routinely reminds me that using AC_VO needs the sort of restraint that you generally recommend, but that, I fear is lost on part of the audience :wink: )

*) But I have a pretty forgiving set-up at home, where the dect IP-phone's base station is connected via cat5 cable, so there are basically 8-9 wifi clients with both a 5GHz and a 2.4GHz radio in a relative small apartment, so it is quite easy to get that sort of set-up be-bloated (only having a sqm'd 49/36 Mbps link atm also helps to keep wifi loads transient).

But that is also dealt with by having fq_codel in the wifi driver, here it is the sparse flow boost that helps with DNS and connection start-up...

BUT in reality, no matter my dislike, a judicious use of AC_VO, _VO, and _BK in addition to the default _BE can help out a lot, so your advice is probably more helpful than my bickering :wink:

Thanks for irqbalance, now with software and HW offloading on, I got this quite decent throughput.

Edit: No sqm applied of course.

Edit2: Although SQM is claimed not fully compatible with offloading, but applying my SQM rules to wlan interfaces seems enough to control bufferbloat on WiFi.

1 Like

I also suggest to set basic rates and supported rates both starting at 12Mbps. this avoids any super hogging of airtime at the expense of reduced range.

fairness is great but only if it's supported which I thought you said wasn't on this device.

Re video streaming, yes that should stay in BE or even VI. Requires a bit of fanciness to identify.

1 Like

It is not compatible, back with an older hardware flow offloading, SQM only saw a handfull of packets of each flow until the hardware offload was triggered, I am unsure about the software offloading, since I never tried that.

Yes, but still 12 versus > 400 is still unfortunate...

According to @Mushoz it should be supported in 19.07 or master, not sure why it does not seem to work...

+1; I guess my point is fiddling with WMM requires a steady hand and a great deal of competence, not necessarily that helpful to people just starting out ;),
Anyway, a few selective up-prioritizations to AC_VO and a few selective down-prioritizations to AC_BK probably can ameliorate a lot (well, scrap can and replace with do, as I believe you actually run it that way)

I have SQM runing on my 200/100 fiber...and I'm not sure how the CPU usage works...but my fiber connection natively has very little/no bufferbloat. It's an ethernet connection to which I can see the Cisco switch on the other end. There is no intermediate modem in the way which seems to be the main source of bloat on DSL style links.

It seems that when SQM has 'nothing to do' the CPU usage is very low.....at least from what I observe.

The amount of CPU required for SQM should be directly proportional to the number of packets per second going through the router (at least, to first order). It has nothing to do with how big the upstream buffers are though. If you have a connection where the bufferbloat is well controlled upstream, it's perfectly reasonable to think about disabling SQM though, depending on how latency sensitive you are. For example if you don't do VOIP or games, you probably can live with even 100ms of bloat. If you do VOIP or games you probably want to keep your bloat below 15ms if at all possible, and most people will be happiest with those high priority streams at below 5ms stddev of jitter.

line 3 in 20-smp-tune # the variable doesn't work

NPROCS="$(grep -c "^processor.*:" /proc/cpuinfo)"
[ "$NPROCS" -gt 1 ] || exit

Change to this does, as it actually counts at least one cpu
NPROCS="$(grep -c processor /proc/cpuinfo)"
[ "$NPROCS" -gt 1 ] || exit

mmh, on my dual core router, both invocations do work and result in the expected result (2) (OpenWrt 19.7.X based turris omnia with turros OS 5):

root@turris:~# cat /proc/cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 1 (v7l)
BogoMIPS	: 1600.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x4
CPU part	: 0xc09
CPU revision	: 1

processor	: 1
model name	: ARMv7 Processor rev 1 (v7l)
BogoMIPS	: 1600.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x4
CPU part	: 0xc09
CPU revision	: 1

Hardware	: Marvell Armada 380/385 (Device Tree)
Revision	: 0000
Serial		: 0000000000000000
root@turris:~# grep -c processor /proc/cpuinfo
root@turris:~# grep -c "^processor.*:" /proc/cpuinfo
root@turris:~# grep -c "^Serial.*:" /proc/cpuinfo

So this also works for items with just a single line... what error do you see on your router?

disregard...screwy copy and paste. i missed a character :smile:

This may call for a seperate thread, but since fq_codel is the default qdisc, can it be changed to cake and the ifb is not necessary? Something like cake rate 50mbit bandwidth besteffort if a user so chooses?


sysctl net.core.default_qdisc

to see which qdisc is set as default. in OpenWrt there exists /etc/sysctl.conf which you can use to change the compiled in default of fq_codel. That said, fq_codel tends to be a better all around qdisc than cake, so I would recommend to think hard, before making cake your default. (But it is a policy decision for you to make, so if you decide for your network cake to be the better default, I won't disagree, not that you should care :wink: )

hello everybody

I just came across this topic which interests me for the wlan I have read from top to bottom but I cannot understand how I could apply sqm on my wlan and also on my lan at the same time