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.
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.
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?
« SpeedGuide.net TCP Analyzer Results » Tested on: 2020.06.06 10:34 IP address: 69.130.xx.xxx 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 SACKs: ON 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:
- install mtr on your router, if you have not done so already:
opkg update; opkg install mtr
- figure out an valorant related IP address (say by using wireshark on the gaming PC), let's use google's DNS IP-address 18.104.22.168 as a stand-in
- monitor that address while gaming
3.a) ssh into your router
mtr -ezb4 22.214.171.124
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?