I recently asked for router recommendations focused on SQM to play GeForce NOW (cloud video gaming) with my 75/8 Mb/s VDSL2 connection. And on the advice of @eginnc, I bought Xiaomi 4A Giga and installed OpenWRT. (Luckily I was sent the product manufactured in March 2021, otherwise I wouldn't have been able to flash OpenWRT. See here.)
My setup: I have Zyxel DX3200-B0 VDSL modem in Bridge mode and Xiaomi Router 4A Giga is connected to it's LAN1 (RFC 1483) as PPoE-WAN. Everything is disabled on the modem-side (wifi, dhcp, nat, firewalls, qos stuff. It's acting as a dumb modem.)
I have installed and configured SQM as shown here. And set to %88 of my actual line speed of both download and upload. But my gaming experience is awful. Only I am connected to the router. No downloads in the background. Any tips on how to improve SQM?
Please test this. WiFi can be qquite weird so excluding WiFi at least as a test seems helpful. In case it is an WiFi issue you will not be able to fix it in SQM.
Can you please post the following output from your routers command line:
tc -s qdisc # without GeForce NOW active and ideally shortly after a fresh restart of SQM (/etc/init.d/sqm stop ; /etc/init.d/sqm start to clear the statistics counters)
EDIT: fixed a typo it is /etc not /eyc
play a while on GeForce NOW (and just report how well it plays and the in-game values)
I understand. I will hook up my laptop to router and test it tomorrow. Wish my room had eth wiring...
WiFi signal is strong though. I am getting the maximum WiFi rate of my router: 866/866 (Mbps)
Yes, that is odd. Can you post the output of: SQM_DEBUG=1 SQM_VERBOSITY_MAX=11 /etc/init.d/sqm stop ; SQM_DEBUG=1 SQM_VERBOSITY_MAX=11 /etc/init.d/sqm start
That might help figuring out what blocks sqm here.
root@OpenWrt:~# SQM_DEBUG=1 SQM_VERBOSITY_MAX=11 /etc/init.d/sqm stop ; SQM_DEB
UG=1
SQM: Acquired run lock
/usr/lib/sqm/run.sh: line 57: can't create : nonexistent directory
SQM: Stopping SQM on wan
root@OpenWrt:~# SQM_VERBOSITY_MAX=11 /etc/init.d/sqm start
SQM: Acquired run lock
SQM:
SQM: Sun Mar 20 00:18:11 +03 2022: Starting.
SQM: Starting SQM script: piece_of_cake.qos on wan, in: 69696 Kbps, out: 6969 Kbps
SQM: fn_exists: function candidate name: sqm_start
SQM: fn_exists: TYPE_OUTPUT: sqm_start: not found
SQM: fn_exists: return value: 1
SQM: Using generic sqm_start_default function.
SQM: fn_exists: function candidate name: sqm_prepare_script
SQM: fn_exists: TYPE_OUTPUT: sqm_prepare_script is a function
SQM: fn_exists: return value: 0
SQM: sqm_start_default: starting sqm_prepare_script
SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_230be type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_230be type ifb
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_230be root cake
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_230be root cake
SQM: QDISC cake is useable.
SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_230be down
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_230be down
SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_230be type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_230be type ifb
SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_78470 type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_78470 type ifb
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_78470 root cake
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_78470 root cake
SQM: QDISC cake is useable.
SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_78470 down
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_78470 down
SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_78470 type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_78470 type ifb
SQM: sqm_start_default: Starting piece_of_cake.qos
SQM: ifb associated with interface wan:
SQM: Currently no ifb is associated with wan, this is normal during starting of the sqm system.
SQM: cmd_wrapper: COMMAND: /sbin/ip link add name ifb4wan type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name ifb4wan type ifb
SQM: fn_exists: function candidate name: egress
SQM: fn_exists: TYPE_OUTPUT: egress is a function
SQM: fn_exists: return value: 0
SQM: egress
SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev wan root
SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev wan root
SQM: cmd_wrapper: tc: LAST ERROR: Error: Cannot delete qdisc with handle of zero.
SQM: LLA: default link layer adjustment method for cake is cake
SQM: cake link layer adjustments: overhead 34 mpu 0
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev wan root cake bandwidth 6969kbit overhead 34 mpu 0 besteffort
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev wan root cake bandwidth 6969kbit overhead 34 mpu 0 besteffort
SQM: sqm_start_default: egress shaping activated
SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_eb79c type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_eb79c type ifb
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_eb79c ingress
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_eb79c ingress
SQM: QDISC ingress is useable.
SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_eb79c down
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_eb79c down
SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_eb79c type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_eb79c type ifb
SQM: fn_exists: function candidate name: ingress
SQM: fn_exists: TYPE_OUTPUT: ingress is a function
SQM: fn_exists: return value: 0
SQM: ingress
SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev wan handle ffff: ingress
SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev wan handle ffff: ingress
SQM: cmd_wrapper: tc: LAST ERROR: Error: Invalid handle.
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev wan handle ffff: ingress
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev wan handle ffff: ingress
SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev ifb4wan root
SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev ifb4wan root
SQM: cmd_wrapper: tc: LAST ERROR: Error: Cannot delete qdisc with handle of zero.
SQM: LLA: default link layer adjustment method for cake is cake
SQM: cake link layer adjustments: overhead 34 mpu 0
SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev ifb4wan root cake bandwidth 69696kbit overhead 34 mpu 0 besteffort wash
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev ifb4wan root cake bandwidth 69696kbit overhead 34 mpu 0 besteffort wash
SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev ifb4wan up
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev ifb4wan up
SQM: cmd_wrapper: COMMAND: /sbin/tc filter add dev wan parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4wan
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc filter add dev wan parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4wan
SQM: sqm_start_default: ingress shaping activated
SQM: piece_of_cake.qos was started on wan successfully
It looks like you have set your SQM down/up speed to 69696/6969
But in your reply to bill888 to post your speed test without SQM, your DSL reports speed test without SQM shows your actual line speed is 48.9/7.53. There might be a clue there.
It is possible your VDSL2 speed is not as fast as advertised by your ISP and that your actual line speed is only around 48.9/7.53. Try setting your down/up speed to 43000/6600 and see if that helps your latency.
You might also try layer cake instead of piece of cake - I found that worked better for me when I had a bonded VDSL2 line.
Finally, if this improves things, try slowly increasing the speeds set in SQM until things start getting worse, and then back your speeds down a bit from there to find the sweet spot. Setting your SQM speeds does take a bit of trial and error. Also, I would not try to tune things to more than 2 of 3 significant figures. There's too much variability in line speed and server speed and WiFi and .... you get the idea...it's false precision.
Hope this helps.
Edit: Three other thoughts:
Are you using at least 40MHz channel width on your 5GHz WiFi? If not, try 40 MHz or 80 MHz channel width to improve your WiFi throughput and latency.
Some of your upload speeds are coming back as low as 4.7 or 6.8 on the Fast.com tests. Try lowering your upload SQM speed all the way down to 4000, then slowly raise it from there until latency starts getting worse and back down from there to find the sweet spot.
Software flow offloading works in snapshot (but not 21.02) - you could try installing snapshot and ticking the "software flow offloading" box under the Network>Firewall menu. Do not do this if you are not comfortable with installing luci from the command line though - snapshot does not come with Luci by default. This doesn't help a huge amount since all your SQM traffic can't be offloaded, but it can free up a few more CPU cycles. I've noticed ~5% to 10% improvement with CAKE.
Good point, also a reason to get a speedtest with the laptop connected via an ethernet cable, the bottleneck might actually be the WLAN (or might not, IMHO worth figuring out).
As a rule of thumb, I tend to recommend to run a few speedtests to reliable servers then pick "consensus" values for up- and downstream (comparing a few speedtests, ignoring outliers and trying to "eyeball" a central value) and plug these goodput numbers into SQM which will interpret these as gross rates resulting in an acceptable rate reduction so traffic shaping can actually work.
For example on my link the following is the relationship between shaper rate and speedtest goodput: 100 * ((1500-8-20-20-12)/(1500+26)) = 94.36%
so taking the goodput already gives 5% slack for the shaper (which might not be ideal, but should be a decent starting point).
Also regarding your Link, could you post what your modem reports as sync values, please?
piece_of_cake and layer_cake will only differ if your network differentially uses DSCP to mark packets, other than that layer_cake simply is a tiny bit more CPU-hungry...
so the theoretical upper limit for speedtest goodput from that sync, assuming VDSL2/PTM, PPPoE, IPv4, TCP and MTU 1500 is:
77.92 * (64/65) * ((1500-8-20-20)/(1500+22)) = 73.19 Mbps
8.224 * (64/65) * ((1500-8-20-20)/(1500+22)) = 7.73 Mbps
But your ISP might still employ a traffic shaper on his side restricting your link below the sync, most ISPs actually do, because DSLAMs/MSANs are not great placed to encounter congestion at....
Speedtest all tend to be "accurate" but not all of the test the speed across the link you are most interested in, for an internet access link it seems obvious to just trust the one reporting the highest rates, but that has the issues that quite a number of Speedtests report goodput well above the theoretical maximum as calculated above.... (speedof.me is notorious for that).
Regarding WiFI I still would like ot see a wired test.... it could be that WiFI puts an additional load on your router's CPUs so that there is not enough left for SQM, but that is not very likely from what you posted so far.
In the unlikely event this is what is going on, you could try installing irqbalance and change SQM to fq_codel/simple.qos. CAKE loads up one CPU thread; whereas fq_codel can make better use of all the CPU cores/threads. fq_codel also requires less CPU in general. If it has the CPU it needs CAKE can shave a few more ms of latency off your statistics, but fq_codel is pretty good too.
After you install irqbalance, you need to edit the file /etc/config/irqbalance to turn it on and reboot (or start it from the command line).
Also, installing and running htop in a command prompt window while you test SQM can give you some insights on CPU utilization.
