Bad Speeds and Ping with SQM

So I've been fiddling with the settings in the luci and can't seem to get good results. SQM usually reduces my internet speeds by 25% sometimes 40% and I still get ping spikes in all games. SQM does make it slightly better, but if someone is using bandwidth I still get ping spikes. Valorant in particular is barely playable most of the time. I think maybe because it uses more upload bandwidth than other games. I have a DSL connection and I usually get 19.5 download and .6-.8 mbps upload, upload can be pretty variable even with no upload traffic. Any help is greatly appreciated.

1 Like

How do tou measure those ping spikes, and how large are they in relation to the base RTT?

First how did you measure these speeds? Could you link in or copy a screenshot of a speedtest showing that, please? (In the past we recommended the dslreports speedtest, but that has become unavailable do to over-use)
Mmmh, let's just look at the upload, 600-800 Kbps simply is going to be painful. Here is a coarse approximation how long a full MTU packet is going to take being transferred over that link:
If the 600/800 are goodput as measured via a speedtest
1000 [ms/sec] * (1500 [Byte/packet] * 8 [bit/Byte]) / (600 [Kbit/sec] * 1000 [bit/Kbit]) = 20 ms
1000 [ms/sec] * (1500 [Byte/packet] * 8 [bit/Byte]) / (800 [Kbit/sec] * 1000 [bit/Kbit]) = 15 ms
if these values are actual DSL sync rates it gets a bit worse (depending on the actual per packet overhead, roughly 10%, but we can ignore that for now).

That means that when ever there is another packet in line before your game packets or in the process of being trensferred over the link the game's packet will need to wait for an additional ~20ms, and if there are more than one packet it gets noticeably worse...

As far as I can tell there is not much you can do in that situation. But please try your game with all other traffic sources disabled and no other traffic on the uplink, if gaming works well then, there might be a fighting chance to improve the under-load situation somewhat, but if things are bad even then you are out of luck... BTW, do you use any additional traffic sources in addition to the game like a real-time voice/video chat?

when I have no other traffic and I'm the only one connected there seems to be no problems at all. The ping spikes in game just off of memory can be like 500+ ms or not that big but still causing stutters. I tried putting an 8 mbps download on while playing and my ping went from a stable 44-46 to 70-150 ms and packet loss. with SQM on it seemed like it actually got worse, higher ping spikes and more packet loss.
Screenshot (97)

Okay, so it is not impossible, then.
Could you please post the output of:

cat /etc/config/sqm
tc -s qdisc

to get a better understanding of the SQM configuration, and maybe also post the statistics page from your dsl modem to get a feel for your link quality?

cat /etc/config/sqm

config queue 'eth1'
        option debug_logging '0'
        option verbosity '5'
        option qdisc 'cake'
        option linklayer 'atm'
        option overhead '44'
        option script 'piece_of_cake.qos'
        option interface 'eth0.2'
        option qdisc_advanced '0'
        option upload '700'
        option download '17000'
        option enabled '1'

 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 114840280241 bytes 124508584 pkt (dropped 0, overlimits 0 requeues 695)
 backlog 0b 0p requeues 695
  maxpacket 27252 drop_overlimit 0 new_flow_count 628821 ecn_mark 0
  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 812d: dev eth0.2 root refcnt 2 bandwidth 700Kbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100.0ms atm overhead 44
 Sent 230367 bytes 983 pkt (dropped 0, overlimits 437 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 18144b of 4Mb
 capacity estimate: 700Kbit
 min/max network layer size:           28 /    1378
 min/max overhead-adjusted size:      106 /    1590
 average network hdr offset:           14

                  Tin 0
  thresh        700Kbit
  target         26.0ms
  interval      121.0ms
  pk_delay       32.4ms
  av_delay        3.9ms
  sp_delay         13us
  backlog            0b
  pkts              983
  bytes          230367
  way_inds            0
  way_miss          155
  way_cols            0
  drops               0
  marks               0
  ack_drop            0
  sp_flows            1
  bk_flows            1
  un_flows            0
  max_len          1392
  quantum           300

qdisc ingress ffff: dev eth0.2 parent ffff:fff1 ----------------
 Sent 607309 bytes 1727 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 812e: dev ifb4eth0.2 root refcnt 2 bandwidth 17Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100.0ms atm overhead 44
 Sent 628376 bytes 1723 pkt (dropped 4, overlimits 334 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 16128b of 4Mb
 capacity estimate: 17Mbit
 min/max network layer size:           46 /    1500
 min/max overhead-adjusted size:      106 /    1749
 average network hdr offset:           14

                  Tin 0
  thresh         17Mbit
  target          5.0ms
  interval      100.0ms
  pk_delay        780us
  av_delay         96us
  sp_delay          5us
  backlog            0b
  pkts             1727
  bytes          631607
  way_inds            0
  way_miss          151
  way_cols            0
  drops               4
  marks               0
  ack_drop            0
  sp_flows            1
  bk_flows            1
  un_flows            0
  max_len          1957
  quantum           518

The interface Statistics page of the modem might be relevant here?


Looks suspicious, like some sort of unexpected tunnel layer somewhere. Could you please visit:
and copy and past the content of the text box below the " Share Your Results" header?

« TCP Analyzer Results » 
Tested on: 2020.06.06 10:34 
IP address: 
Client OS/browser: Windows 10 (Chrome 83.0.4103.61) 
TCP options string: 020405b40103030801010402 
MSS: 1460 
MTU: 1500 
TCP Window: 262656 (not multiple of MSS) 
RWIN Scaling: 8 bits (2^8=256) 
Unscaled RWIN : 1026 
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 
BDP limit (200ms): 10506kbps (1313KBytes/s)
BDP limit (500ms): 4202kbps (525KBytes/s) 
MTU Discovery: ON 
TTL: 117 
Timestamps: OFF 
IP ToS: 00000000 (0) 

my openwrt router wasn't getting internet when I turned bridge mode on my isp router so I just left it off, idk if that matters or has anything to do with this. I don't know what a tunnel layer is

Mmmh, that is odd it reports a MTU of 1500...

Mmh, that page is interesting, but not what I hoped for, I guess Line [1|2] Status might actually show DSL error counters?

idk I'm new to this networking stuff

What router are you running? It could be out of CPU cycles.

Mmmh, I wonder that ISP router, does that offer WiFi by chance? And are other devices connected to the ISP router, either via cables or WiFi when your problems occur?

it does, I usually have it disabled though and the same problems happen with it off. I have the isp router connected to an edge router x running openwrt and a unifi access point connected to that

do you think there's anything I can do

Mmmh, nothing quick, but if you are dedicated enough you could try to figure out wha/where goes wrong.
I would, for example try to figure out a the IP address of one of the servers you play on and then use mtr to monitor that network path for a while, ideally while playing:

  1. install mtr on your router, if you have not done so already:
    opkg update; opkg install mtr
  2. figure out an valorant related IP address (say by using wireshark on the gaming PC), let's use google's DNS IP-address as a stand-in
  3. monitor that address while gaming
    3.a) ssh into your router
    3.b) mtr -ezb4

then look at the best, worst and average RTT columns. Expect the RTT to gradually rise along the path (typically seen in the best column), but if there is one hop with a stepp RTT increase and all later hops also show a similar increase that would indicate congestion along your network path.
If that hop is your router or the ISPs end of your link, you have a decent chance of improving things with changing your SQM config, if such a congested hop appears later along the path, there is not much you can do from your end (except talk to your ISP, if you are lucky).

Now, since without competing traffic things seem to work, I would assume that maybe we can improve things a bit. First add the following to your /etc/config/sqm:

option qdisc_advanced '1'
option ingress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option iqdisc_opts 'nat dual-dsthost ingress'
option eqdisc_opts 'nat dual-srchost'
option debug_logging '1'

This will configure per-internal-IP-fairness for both up- and downstream. Given your small upstream you might need to disable this for the egress direction (but test first), by deleting the eqdisc_opts line.

How about you try this, with and without competing traffic and we than take it from there?