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.
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?
but
Looks suspicious, like some sort of unexpected tunnel layer somewhere. Could you please visit:
https://www.speedguide.net/analyzer.php
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 8.8.8.8 as a stand-in
- monitor that address while gaming
3.a) ssh into your router
3.b)mtr -ezb4 8.8.8.8
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?