Configuring SQM for 6mbps?

I know it sounds crazy but I had SQM running great though recently started having some issues. I managed to mostly mitigate it by reducing egress / upload speed to 0 in basic settings. Previously was set to 540. As I was typing this I decided to bump it up to 600 whilst playing and found it to be much better but not the best. Experiencing what I believe is packet loss still.

Download speed is 6mbps / upload is 0.8mbps. Typically it is my PC hardwired via Ethernet, two phones and 1 TV on WiFi. Seems to only have issues when another device is connected (via WiFi at least) using any bit of down/upstream but I'm lead to thinking it's mostly upstream. Might be a case of I simply do not have enough bandwidth for the game itself but a solution could be prioritizing the traffic? The other devices are non-essential, I just do not want to shut off WiFi every single time I'd like to boot up a game to play.

config queue 'eth1'
        option qdisc 'cake'
        option script 'piece_of_cake.qos'
        option verbosity '5'
        option interface 'wan'
        option debug_logging '1'
        option download '4700'
        option qdisc_advanced '1'
        option squash_dscp '1'
        option squash_ingress '1'
        option ingress_ecn 'ECN'
        option egress_ecn 'NOECN'
        option linklayer 'atm'
        option overhead '44'
        option upload '600'
        option enabled '1'
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "uptime": 179463,
        "l3_device": "wan",
        "proto": "dhcp",
        "device": "wan",
        "metric": 0,
        "dns_metric": 0,
        "delegation": true,
        "ipv4-address": [
                {
                        "address": "192.168.10.200",
                        "mask": 24
                }
        ],
        "ipv6-address": [

        ],
        "ipv6-prefix": [

        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "0.0.0.0",
                        "mask": 0,
                        "nexthop": "192.168.10.199",
                        "source": "192.168.10.200/32"
                }
        ],
        "dns-server": [
                "66.38.2.240",
                "66.38.2.224"
        ],
        "dns-search": [
                "Home"
        ],
        "neighbors": [

        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [

                ],
                "dns-search": [

                ],
                "neighbors": [

                ]
        },
        "data": {
                "dhcpserver": "192.168.10.199",
                "leasetime": 86400
        }
}```


/usr/lib/sqm/run.sh: line 57: can't create : nonexistent directory
SQM: Stopping SQM on wan
/usr/lib/sqm/run.sh: line 57: can't create : nonexistent directory
SQM: Starting SQM script: piece_of_cake.qos on wan, in: 4700 Kbps, out: 600 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: ip: SUCCESS: /sbin/ip link add name SQM_IFB_3ab56 type ifb
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_3ab56 root cake
SQM: QDISC cake is useable.
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_3ab56 down
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_3ab56 type ifb
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_35554 type ifb
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_35554 root cake
SQM: QDISC cake is useable.
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_35554 down
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_35554 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: 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: 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: atm overhead 44 mpu 0
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev wan root cake bandwidth 600kbit atm overhead 44 mpu 0 besteffort
SQM: sqm_start_default: egress shaping activated
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_13d57 type ifb
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_13d57 ingress
SQM: QDISC ingress is useable.
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_13d57 down
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_13d57 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: tc: FAILURE (2): /sbin/tc qdisc del dev wan handle ffff: ingress
SQM: cmd_wrapper: tc: LAST ERROR: Error: Invalid handle.
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: 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: atm overhead 44 mpu 0
SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev ifb4wan root cake bandwidth 4700kbit atm overhead 44 mpu 0 besteffort wash
SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev ifb4wan up
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

Ran tc -s qdisc after generating some traffic whilst playing with said issues.

 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 25428487604 bytes 60176211 pkt (dropped 0, overlimits 0 requeues 106)
 backlog 0b 0p requeues 106
  maxpacket 17224 drop_overlimit 0 new_flow_count 1940857 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev lan4 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan3 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan2 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan1 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 806e: dev wan root refcnt 2 bandwidth 600Kbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms atm overhead 44
 Sent 12630599 bytes 84149 pkt (dropped 2193, overlimits 88538 requeues 0)
 backlog 66b 1p requeues 0
 memory used: 705184b of 4Mb
 capacity estimate: 600Kbit
 min/max network layer size:           28 /    1500
 min/max overhead-adjusted size:      106 /    1749
 average network hdr offset:           14

                  Tin 0
  thresh        600Kbit
  target         30.3ms
  interval        125ms
  pk_delay       25.8ms
  av_delay       6.59ms
  sp_delay        537us
  backlog           66b
  pkts            86359
  bytes        13507904
  way_inds          324
  way_miss          782
  way_cols            0
  drops            2193
  marks               0
  ack_drop            0
  sp_flows            7
  bk_flows            1
  un_flows            0
  max_len         12112
  quantum           300

qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
 Sent 178186268 bytes 143627 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev br-lan root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 806f: dev ifb4wan root refcnt 2 bandwidth 4700Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms atm overhead 44
 Sent 150080439 bytes 117555 pkt (dropped 26064, overlimits 153027 requeues 0)
 backlog 10598b 7p requeues 0
 memory used: 235872b of 4Mb
 capacity estimate: 4700Kbit
 min/max network layer size:           46 /    1500
 min/max overhead-adjusted size:      106 /    1749
 average network hdr offset:           14

                  Tin 0
  thresh       4700Kbit
  target            5ms
  interval        100ms
  pk_delay       33.6ms
  av_delay       10.5ms
  sp_delay        249us
  backlog        10598b
  pkts           143626
  bytes       180198440
  way_inds        13238
  way_miss          742
  way_cols            0
  drops           26064
  marks               0
  ack_drop            0
  sp_flows            5
  bk_flows            4
  un_flows            0
  max_len          3028
  quantum           300```

Any help would be greatly appreciated!

try

opkg install luci-app-statistics

It gives you a used bandwidth graph of different parts of the system.

First thing with your uplink all we really can do is manage the pain somewhat better, not remove it.

First step, disable sqm and run a few speedtests, also log into your modem to get the current DSL sync speeds (with 6/0.8 and ATM encapsulation I expect you to use a DSL link).

For the uplink we often can get really close to the link speed, so knowing the link/sync speed is quite helpful.

Next step is figuring out how much upload your game actually needs and how many other machines in your network exist. Knowing that will allow us to figure out how to get there...

The options are in sequence of involvement:
a) simply enable per-IP fairness that will give each active host an equal share of the available capacity. If you game requires say, 100 Kbps then this will likely work for up to 4 concurrently active machines in your network, if your game requires more it will allow fewer concurrently active machines
b) use one of cake's diffserv modes and only up prioritize your game by setting an appropriate DSCP (which will give your game traffic priority for up to 50% of capacity)
c) built your own dedicated upload qos sxcript to give your game priority access to watever capacity it needs.

6-6.3 down, 0.7-0.8 up. The modem/router is a Comtrend AR5230, unfortunately found no way to log into it. Every address I could think of was attempted to access it. x.199 was gateway via ipconfig in cmd, didn't work, so no way to figure out the DSL sync speeds. It's a phone line / copper pretty certain. Very old stuff.

Playing the game I am seeing 30KB/s - 40KB/s (0.24mbps - 0.32mbps) usage, via NetLimiter. I have removed the upload restrictions for now to make it usable whilst disabling WiFi while it's not needed / no other devices on the network. Is there a way to have another package/software that could impose an upload limit on a per device / IP basis while SQM is not touching the upload?

Have you tried the instructions in the following snapshot of
https://www.192-168-1-1-ip.co/comtrend/routers/410/

Maybe one of those will work (I would try 192.168.10.1 first).

That modem allows ADSL2+ with either traditional ATM or more modern PTM... if we do not get access to the modem ytp get more information we can still try to figure it out empirically, just follow the instructions here:

Sometimes matlab/octave cause issues in that case, just post a link to the results of the measurement run and I can have a look at it (but by all means try the octave code first and simply post the resulting images here). This is relevant as with such a low uplink, you really want to squeeze out the last Kbps and to do that robustly we need to know what the link actually delivers robustly and reliably....

Next thing, try to use the luci GUI to give you gaming PC a fixed internal IP address (easiest via GUI Network -> DHCP and DNS -> Static leases. That will help in the next steps trying to give priority to your gaming traffic, so you might as well start researching it now :wink:

0.8 upload. Ouch! I remember my DSL days none too fondly.

One thing I do recall is that upload latency was so bad that while using CAKE SQM I could slowly increase the upload speed in SQM, checking latency at each step with a buffer bloat test (e.g., waveform) until latency began to increase again, then back off to the last "good" upload speed setting. What I found is that I could set upload speed in SQM at or even higher than upload speed without SQM. Upload buffer bloat was that bad.

Haven't had too much time on my hands the last couple days to get anywhere on this, but I did set gaming PC a static address. Is there not a way to utilize SQM only for ingress but then rate limit egress of device by IP/MAC another way?

Sure, if you set one of the rates to 0, sqm-scripts will interpret that not as shape to 0 Kbps (as that would result in a non-functioning internet access link) but as "do not instantiate a shaper/qdisc" for that direction.

Sure, but that quickly becomes a whack-a-mole game, e.g. with modern devices that randomize their MAC addresses to get less traceable...

I would guess that a potential solution will be simply in enabling diffserv4* for egress and only make traffic from the gaming device with an appropriate DSCP (something easily done in the firewall GUI)... that will solve the egress/upload issue, but by itself will not solve the ingress download issue, but you do not seem to have issues there anyway....

*) diffserv4 will use up to 50% of the capacity for higher priority traffic in the second highest class named "Video", if you only put game traffic in there and nothing into the even higher priority (but smaller guaranteed capacity) "Voice" tin your game should play reasonably well, with a bit of luck.

Forgive the ignorant question but would setting SQM on wlan0 an upload (well, download since it's on the wlan0 interface) of say "5" not severely limit the upload of wlan0 like I need?

I don't have much hope in a fix besides "get better upload" here truthfully. Attempted things such as setting traffic to CS0 with traffic from PC to CS6 (iirc), tried using diffserv4, etc. All a no go.

Also: It seems like a sudden increase in downstream of another device will incur noticeable packet loss on my end, with a simple SQM ingress setting. Regardless if I play around with the value it still incurs a packet loss. I am seeing around 20-40KB/s download for this particular game (Counter-Strike 2) but even a 100KB/s download on another device will cause a packet loss "spike".

At these very low bitrates my gamer script may be more effective since it targets unfairness that prioritizes the game at a realtime priority over all other traffic. It also tries to force Tcp block size down to reduce lumpiness in transmission.

Sure for LAN directed interfaces like WLAN the "internet" direction and the "interface" direction are inverted in regard to each other, so WLAN egress + internet ingress.
Putting a shaper on WLAN will work, assuming all your traffic flows over the WLAN, as sqm will not be able to account for traffic from LAN and /or the router itself to/from the internet (for sqm to be able to robustly and reliably control bufferbloat it needs to built an artificial bottleneck).
Also sqm on WLAN will also throttle traffic from LAN to WLAN (depending on your home network usage that might be anywhere from not noticeable to annoying).

There are quickly dragons, so maybe we go though the options one by one, only to rule out anything easily fixed?
First thing would be to get packet captures from the game without sqm, so that we can assess how much capacity it might need (this number will be too low for the shaper though, and I guess the shaper for the gaming class should be set to ~2 the average gaming rate, to have some reserves).
But sure at one point, all we can do is manage the pain, not remove it completely...

Arghh, in another thread we had a go at CS2, and I am sad to report that it appears to be quite a "hog" needing (probably depending on a few things) north of 512 Kbps shaper setting to work well...
I think there the solution was to use @dlakelan's "gamer script". I still think that one should be able to achieve similar with in sqm, but none such qos script for sqm exists, so using the gamer script mihgt be the most convenient way.

The thing here is that at 800 Kbps a single full MTU packet takes some time for transmission:
1000*(15428)/(8001000) = 15.42 milliseconds
that means if you have upload traffic with large packets that by chance might just have started transmission before a gaming packet entered the queue that gaming packet, even with highest priority will be delayed for at least that transmission time, if one forces packets to be smaller then the maximal transmission time gets smaller, IPv4's smallest MSS setting (according to the standards, real OS might allow even lower settings) is around 500 Bytes, reducing the transmission time to around 5-6ms, much less noticeable than 15ms... (However since everything has consequences, reducing the LSS will also reduce the efficiency, as for the same anpunt of data you will need to send more packets and hence a higher proportion of the gross rate will be spend on the packet-size-independent packet headers; but that is hardly your biggest problem). The same observation also applies to your downlink, but there transmission time is in the 2-3 ms range already which often seems acceptable.