Summary: turning on SQM decreases my 60Mbps down to a max of 40Mbps down. Is this a firmware/settings issue, or am I being limited by my device? (Archer C7 v5)
Details:
CenturyLink 60Mbps down, 5Mbps up DSL
Zyxel C300A DSL modem/router/AP combo in transparent bridging mode
Archer C7 v5 as the router and AP
OpenWRT 21.02.0
Installed the sqm-scripts and luci-app-sqm packages
Installed adblock and luci-app-adblock
WAN set up as PPPoE, no changes to WAN6
SQM settings/changes:
Interface name: pppoe-wan [have also tried on 'switch vlan: "eth0.2" (wan, wan6)' with similar results]
Down speed: 55000
Up speed: 4500
Link layer: ATM [not positive if I have ADSL(2) or VDSL]
Per packet overhead: 44
I have also started having issues where if one device is downloading at near the max bandwidth, no other devices will be able to load anything. This seems to be exactly opposite of the purpose of SQM, despite the DSLReports speed test showing vast improvements in bufferbloat.
What am I missing, or what do I need to check? I don't know where to even start troubleshooting this. It seemed like it worked wonderfully for a short time, even with the lower download speeds, but then started having other issues. I reset the firmware settings even and started from scratch with the same packages, with the same results. Should I completely reflash and see if I can get the good results again?
Nope, ADSL tops out at about 25/5 Mbps, in theory one can use ATM/AAL5 encapsulation also with VDSL2, but I have never seen this in the wild, so I would assume PTM (which means in SQM speak "Ethernet with overhead").
That is a bit on the high side for VDSL2, but typically it only costs little bandwidth and helps against bufferbloat to (slightly) overestime the per-packet-overhead.
But let's calculate the theoretical goodput (what you would measure in an on-line speedtest) for you SQM settings (for PPPoE/IPv4/TCP with MTU 1500, and per-packet-overhead 44):
Should I change my link layer settings first before other diagnostics? Results below are leaving as is for both.
Some of those devices are on WiFi, yes, but I've also had issues with attempting to browse the web from the computer that is on ethernet and doing the high bandwidth downloading. I can test this more if there are other issues that are apparent, since I know WiFi is prone to interference, etc.
For diagnostics of the status quo, keeping them unchanged seems decent, if however you see this as an exercise in optimizing the settings, I would repeat the tests with the changes settings.
I would always try to first test with wired machines, as WiFi has its own collection of challengen that can easily distract when optimizing/debugging SQM. But then I would always include WiFi tests, after getting the non-WiFi access into acceptable state.
This is missing out on a number of nifty tricks cake brings to the table, like per internal IP fairness (which often is not exactly what people want, but overall pretty decent and for a number of users simply "good enough", btw, the whole linked page is worth reading when optimising SQM is desired).
These look unsuspicious, so nothing for me to comment upon.
I updated the link layer settings and raised the shaping speed limits to what my actual speeds are supposed to be. That has gotten me to the calculated goodput values you provided for packet overhead set to 34.
Perhaps all I'm seeing is variation in the network outside of my control. Or perhaps I just need to tune SQM a bit more. I'll definitely read through the SQM details and see if anything there makes a difference.