Setting Up Sqm for Main Router Connected to Bridge Modem

I have my openwrt router connected to my cable modem. My cable modem is in bridge mode so my router is the main router. On the router I have my ps4 connected to. I was wondering what SQM settings I need to set up to get the best performance for gaming on my ps4 and just lower my bufferbloat in general.
Additional Info- Ethernet cable connecting the wan port of the router to the modem(obviously)
Ethernet cable connecting ps4 to lan port of the router.
cat /etc/config/sqm

config queue 'eth1'
        option debug_logging '0'
        option verbosity '5'
        option qdisc 'cake'
        option interface 'br-wan'
        option upload '10200'
        option script 'test_WAN_triple-isolate__piece_of_cake.qos'
        option qdisc_advanced '1'
        option squash_dscp '1'
        option squash_ingress '1'
        option ingress_ecn 'ECN'
        option egress_ecn 'NOECN'
        option qdisc_really_really_advanced '0'
        option download '85000'
        option enabled '1'
        option linklayer 'ethernet'
        option overhead '22'

tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2
 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 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
 Sent 2691054839 bytes 7792813 pkt (dropped 3688, overlimits 0 requeues 1512)
 backlog 0b 0p requeues 1512
  maxpacket 15140 drop_overlimit 64 new_flow_count 177823 ecn_mark 0 drop_overmemory 64
  new_flows_len 0 old_flows_len 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 eth0.1 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8036: dev br-wan root refcnt 2 bandwidth 10200Kbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms noatm overhead 22
 Sent 450533176 bytes 4349575 pkt (dropped 1568, overlimits 1321256 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 284702b of 4Mb
 capacity estimate: 10200Kbit
 min/max network layer size:           28 /    1500
 min/max overhead-adjusted size:       50 /    1522
 average network hdr offset:           14

                  Tin 0
  thresh      10200Kbit
  target          5.0ms
  interval      100.0ms
  pk_delay        2.9ms
  av_delay         78us
  sp_delay          8us
  backlog            0b
  pkts          4351143
  bytes       452778941
  way_inds        82328
  way_miss        22774
  way_cols            0
  drops            1568
  marks              13
  ack_drop            0
  sp_flows            1
  bk_flows            1
  un_flows            0
  max_len         24224
  quantum           311

qdisc ingress ffff: dev br-wan parent ffff:fff1 ----------------
 Sent 13983533507 bytes 14348458 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.2 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 noqueue 0: dev wlan1 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8037: dev ifb4br-wan root refcnt 2 bandwidth 85Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms noatm overhead 22
 Sent 14218777162 bytes 14343513 pkt (dropped 4945, overlimits 4964226 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 1488727b of 4250000b
 capacity estimate: 85Mbit
 min/max network layer size:           46 /    1500
 min/max overhead-adjusted size:       68 /    1522
 average network hdr offset:           14

                  Tin 0
  thresh         85Mbit
  target          5.0ms
  interval      100.0ms
  pk_delay        5.2ms
  av_delay        471us
  sp_delay         32us
  backlog            0b
  pkts         14348458
  bytes     14226190519
  way_inds        96062
  way_miss        23901
  way_cols            0
  drops            4945
  marks               4
  ack_drop            0
  sp_flows            2
  bk_flows            1
  un_flows            0
  max_len         48448
  quantum          1514

ifstatus wan
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "uptime": 50555,
        "l3_device": "br-wan",
        "proto": "dhcp",
        "device": "br-wan",
        "updated": [
                "data"
        ],
        "metric": 0,
        "dns_metric": 0,
        "delegation": true,
        "ipv4-address": [
                {
                        "address": "67.246.93.157",
                        "mask": 22
                }
        ],
        "ipv6-address": [

        ],
        "ipv6-prefix": [

        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "0.0.0.0",
                        "mask": 0,
                        "nexthop": "67.246.92.1",
                        "source": "67.246.93.157/32"
                }
        ],
        "dns-server": [
                "209.18.47.62",
                "209.18.47.61"
        ],
        "dns-search": [
                "twcny.rr.com"
        ],
        "neighbors": [

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

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [

                ],
                "dns-search": [

                ],
                "neighbors": [

                ]
        },
        "data": {
                "hostname": "OpenWrt",
                "leasetime": 69759
        }

Thanks for all the information, looks like a decent starting point.

I think it would be good to see the result of a speedtest with SQM disabled (as baseline) as well as one with your current SQM config. Maybe dslreport's speedtest? then see these instructions/recommendations...

Overall, I guess that you could/should try ack-filtering (due to docsis' bursty MAC) and potentially per internal IP fairness (to isolate your gaming rig from other users), but let's start with the speedtests.

1 Like

Unfortunately using my openwrt router as my main router wasn’t a good idea as it failed to deliver connection in some parts of the house so i have set my openwrt router as a bridge ap. Wifi and internet through lan ports of the openwrt router works fine but now I feel like i’ve screwed myself again because I’m not sure If I can use sqm on a bridge ap. Please let me know if it’s possible to do this.

SQM really needs to see all traffic/packet's to/from the bottleneck link to do its job. So if nobody connects directly (wifi or wired) to your primary router you can still debloat your wan link by using sqm on the AP. But if there is traffic from the primary router to any other devices than the AP and the wan side modem it is game over for SQM, sorry. Well, sqm can still be useful to shape your internal traffic, but for wan traffic it will lack the required information/control to do a proper job. Maybe relegate the other router to AP duty to expand wifi coverage and use the OpenWrt router as primary router instead?

1 Like

I think this works for me because on the openwrt router I don’t have wifi enabled I’m just using the lan ports on the router to connect to other devices like my PS4 in this case. You obviously have more knowledge on this than me so I’m not really sure what i’m saying but if i setup sqm on the lan interface would that work... like i said i might be mistaken can you please explain to me what you meant by it being useful to shape internal traffick.

Nope, sorry. To bebloat the WAN link, cake needs to see all traffic to/from that wan link. SQM works by avoiding filling the modem's/proprietary router's typically over-sized and under-managed queues with its own well managed queueing. The trick here is to set the Shaper rate such that they stay below the true bottleneck rates of the to-be-debloated link, admitting packet's to the modem at a speed at which each packet is immediately sent away and no packet's accumulate in the modem at all. But for this to work, sqm needs to see all packets, and in your case other users probably will be able to send/receive packets to/from the internet via direct connections to the primary non'OpenWrt router. I hope this clarifies this a bit....

1 Like

Alright I will have my ISP put my modem into bridge mode so I can use my openwrt router as the main router. In that case how would I set up sqm for the devices connected to the lan ports of the router will I use the wan interface still or just lan. I want to configure it mainly for my ps4 which will be connected to the lan port of the router.

Yes, for debloating your WAN link you typically need to instantiate sqm on the wan interface (if you do not use wifi in the router, you can also instantiate the download/ingress part of the wan Shaper on the egress side of the CPU's LAN interface, but that is an optimisation only).
The to thing to keep in mind is, sqm does not really work by only addressing latency sensitive machines like your PS4 it really needs to see/control all traffic over the critical link....

1 Like

Alright so I ran a couple speed test and my averages are 90 dl and 11.5-12 up. I’m going to start with doing 85% of those speeds... I’ve done a lot of reading and there’s different opinions with people saying layer_cake is better or WAN triple isolate etc. which one do you find to be the best.

Mmmh, yes 85% is a decent starting point, personally, with cake's ingress mode and my DSL Link's reliable rates, I have started to simply put in the net rates measured by on-line Speedtest as the gross Shaper rates, and then I perform a few tests to convince myself that this leads to reliable and robust bufferbloat mitigation, it mostly does. If not I start reducing the rates; the rationale, explore the rate space to find a reasonably robust setting that keeps latency under load in check still applies, I only changed the starting point. But if in doubt, I personally am prepared to sacrifice even large chunks of bandwidth for low latency under load, but I admit that this is a policy question each network admin needs to take for her/his network.

About the scripts, personally I like them all ;). But I would always start with either piece_of_cake.qos if no prioritization is required, or layer_cake.qos if DSCPs are planned to be used. And then I would add

option iqdisc_opts 'nat dual-dsthost ingress'
       option eqdisc_opts 'nat dual-srchost ack-filter'
        option linklayer_advanced '1'
        option tcMTU '2047'
        option tcTSIZE '128'
        option tcMPU '64'
        option linklayer_adaptation_mechanism 'default'

nat [src|dst]-host: to configure per-internal-IP-fairness, so that each machine only gets its equitable share of the available bandwidth. Note this sharing is dynamic, if a machine is only using little if it's share the reminder is distributed fairly among the actually active hosts.
ingress: to make the Shaper aim to control its own input rate and not as typically done it's output rate, this makes a ton of sense if the Shaper sits on the 'wrong' side of the true bottleneck as usual with shaping the download side of a home link.
ack-filter: this will try to merge compatible acks of flows which helps ack clicking on bursty MACs like docsis. (On my DSL link I typically from not use ACK-filtering, but on a docsis link like yours I would).
EDIT: corrected eqdisc_opts, thanks MPA!

Alright and for link layer adaptation should i put none or ethernet overhead and set packet to 22 because my router is connected to a cable modem?

use:

	option linklayer 'ethernet'
	option overhead '22'
	option linklayer_advanced '1'
	option tcMTU '2047'
	option tcTSIZE '128'
	option tcMPU '68'

the relevant parts are overhead 22 (for the standard 18 bytes of docsis plus 4 bytes for a possible VLAN tag) and tcMPU 68, to account for the (VLAN tagged) minimum ethernet frame size, tcMTU and tcTSIZE will be ignored by cake...
Your bottleneck link is the docsis link between modem and CMTS and you need to "model" the overhead for the shaper to account for the true bottleneck's properties, henve 22 (18) bytes overhead.

Egress should use dual-srchost:
option eqdisc_opts 'nat dual-srchost ack-filter'

1 Like