Stutter movemment in game with SQM

Installing and Using OpenWrt
1

I have issue with SQM on PI4, was getting very stuttery movement in game. Now SQM is off and movement is fine in game without any issue.
One more thing Pingplotter to game server was smooth without any packet loss.

uci show sqm
sqm.eth1=queue
sqm.eth1.ingress_ecn='ECN'
sqm.eth1.egress_ecn='NOECN'
sqm.eth1.itarget='auto'
sqm.eth1.etarget='auto'
sqm.eth1.verbosity='5'
sqm.eth1.qdisc='cake'
sqm.eth1.qdisc_advanced='1'
sqm.eth1.squash_dscp='1'
sqm.eth1.squash_ingress='1'
sqm.eth1.qdisc_really_really_advanced='1'
sqm.eth1.eqdisc_opts='nat dual-srchost ack-filter'
sqm.eth1.linklayer='ethernet'
sqm.eth1.linklayer_advanced='1'
sqm.eth1.tcMTU='2047'
sqm.eth1.tcTSIZE='128'
sqm.eth1.linklayer_adaptation_mechanism='default'
sqm.eth1.debug_logging='1'
sqm.eth1.enabled='1'
sqm.eth1.iqdisc_opts='nat dual-dsthost ingress'
sqm.eth1.interface='eth1'
sqm.eth1.download='20100'
sqm.eth1.upload='10050'
sqm.eth1.overhead='34'
sqm.eth1.tcMPU='64'
sqm.eth1.script='piece_of_cake.qos'

I coppied these settings from this post

Speedtest by Ookla

     Server: *****
        ISP: *******
    Latency:    14.73 ms   (0.55 ms jitter)
   Download:    21.77 Mbps (data used: 19.0 MB)
     Upload:     9.73 Mbps (data used: 4.4 MB)
Packet Loss: Not available.

internet speed package is 20mb download and 10mb upload. VDSL2 with max 1492 MTU available in modem settings and same MTU size is selected in openwrt settings.
Modem is in bridge mode with PI4.

Firmware Version
OpenWrt SNAPSHOT r14475-4a3230683b / LuCI Master git-20.259.37209-95c4082

1 Like
2

ACK-filtering really is only advantageous for high asymmetric links and/or bursty physical layers, like docsis, for a VDSL2 link at ~1:2 asymmetry you could easily do without this option. But that is a drive-by observation and very unlikely t be the root cause of your issues...

I assume that this was with SQM on and while playing the game in question?

Since I assume you use PPPoE (which would fit with the 1492 MTU) I would recommend to instantiate SQM on pppoe-wan. But to figure this out, could you post the output of ifstatus wan please?

3

yes it was with SQM on and also same time i was playing the game when pingplotter was running

1 Like
4

I removed the ip addresses

 ifstatus wan
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "uptime": 10950,
        "l3_device": "pppoe-wan",
        "proto": "pppoe",
        "device": "eth1",
        "updated": [
                "addresses",
                "routes"
        ],
        "metric": 0,
        "dns_metric": 0,
        "delegation": true,
        "ipv4-address": [
                {
                        "address": "*******",
                        "mask": 32,
                        "ptpaddress": "********"
                }
        ],
        "ipv6-address": [

        ],
        "ipv6-prefix": [

        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "0.0.0.0",
                        "mask": 0,
                        "nexthop": "*********",
                        "source": "0.0.0.0/0"
                }
        ],
        "dns-server": [
                "127.0.0.1"
        ],
        "dns-search": [

        ],
        "neighbors": [

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

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [
                        "*******",
                        "*********"
                ],
                "dns-search": [

                ],
                "neighbors": [

                ]
        },
        "data": {

        }
}
1 Like
5

Thanks! As I inferred pppoe-wan would be a better place for instantiating SQM on. But that again is unlikely to fix your issue.

I would like to see the output of tc -s qdisc first ideally after say 10-20 minutes after a reboot with no network load (sort of idle condition) and then the same while you are playing and encountering the stutters (both ideally recorded close in time and without an addition reboot, or sqm reset, I want to see how cake's counters change between idle and loaded).

6

Could you post the pingplotter results here, maybe as a screenshot. Or you could also install and run mtr on the router (opkg update ; opkg install mtr ; mtr -ezb4 GAME.SERVER.IP.ADDRESS, just replace GAME.SERVER.IP.ADDRESS with the correct server name or ipv4-address).

7

OK i didn't save the pingplotter when i was facing the stutter in game.
This is the latest ping plot

login-p3.worldoftanks.com(openwrt)
login-p3.worldoftanks.com(openwrt)2016×1240 354 KB

8

i selected pppoe-wan in sqm settings, default qdisc is fq_codel and game is working fine now even running speed test in the background

cat /etc/config/sqm

config queue 'eth1'
        option ingress_ecn 'ECN'
        option egress_ecn 'NOECN'
        option itarget 'auto'
        option etarget 'auto'
        option verbosity '5'
        option qdisc_advanced '1'
        option squash_dscp '1'
        option squash_ingress '1'
        option qdisc_really_really_advanced '1'
        option eqdisc_opts 'nat dual-srchost ack-filter'
        option linklayer 'ethernet'
        option linklayer_advanced '1'
        option tcMTU '2047'
        option tcTSIZE '128'
        option linklayer_adaptation_mechanism 'default'
        option debug_logging '1'
        option enabled '1'
        option iqdisc_opts 'nat dual-dsthost ingress'
        option download '20100'
        option upload '10050'
        option overhead '34'
        option tcMPU '64'
        option script 'piece_of_cake.qos'
        option interface 'pppoe-wan'
        option qdisc 'fq_codel'

at 9:27 you can see when i was running speedtest little dent in ping line

Screenshot 2020-09-18 213212
Screenshot 2020-09-18 2132121004×1084 58 KB

9

These look okayish, except that ~250 ms delay to the game servers should make any non round based gaming pretty much suck. But other than that the only other interesting result seems to be that the forward way seems to run over cogent...

10

piece_of_cake will force cake to be used independent of the value in "

       option qdisc 'fq_codel'

"

But please puost the output of tc -s qdisc to get a feel how the stats look for the okay case and later for the non working case.

11

image
image1084×56 7.94 KB

This sudden jump of 100ms with high variability happens at the exit of a private network inside your ISP I assume. So that's likely to be a choke point that you have no control over.

12

game is working fine now after reboot and flashing of new image from community build.
here is output

 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 mq 0: dev eth0 root
 Sent 10061586924 bytes 7501254 pkt (dropped 0, overlimits 0 requeues 65)
 backlog 0b 0p requeues 65
qdisc fq_codel 0: dev eth0 parent :5 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 2818416238 bytes 2122618 pkt (dropped 0, overlimits 0 requeues 18)
 backlog 0b 0p requeues 18
  maxpacket 1514 drop_overlimit 0 new_flow_count 50 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 1603858742 bytes 1177376 pkt (dropped 0, overlimits 0 requeues 4)
 backlog 0b 0p requeues 4
  maxpacket 1514 drop_overlimit 0 new_flow_count 53 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 1109240987 bytes 870440 pkt (dropped 0, overlimits 0 requeues 27)
 backlog 0b 0p requeues 27
  maxpacket 1514 drop_overlimit 0 new_flow_count 59 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 3646670895 bytes 2641918 pkt (dropped 0, overlimits 0 requeues 12)
 backlog 0b 0p requeues 12
  maxpacket 1514 drop_overlimit 0 new_flow_count 392 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 883400062 bytes 688902 pkt (dropped 0, overlimits 0 requeues 4)
 backlog 0b 0p requeues 4
  maxpacket 1514 drop_overlimit 0 new_flow_count 41 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
 Sent 458062345 bytes 3274026 pkt (dropped 0, overlimits 0 requeues 24)
 backlog 0b 0p requeues 24
  maxpacket 1514 drop_overlimit 0 new_flow_count 22 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 cake 8005: dev pppoe-wan root refcnt 2 bandwidth 10050Kbit besteffort dual-srchost nat nowash ack-filter split-gso rtt 100ms noatm overhead 34 mpu 64
 Sent 219698637 bytes 2184124 pkt (dropped 90140, overlimits 1002990 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 404544b of 4Mb
 capacity estimate: 10050Kbit
 min/max network layer size:           34 /    1492
 min/max overhead-adjusted size:       68 /    1526
 average network hdr offset:            0

                  Tin 0
  thresh      10050Kbit
  target            5ms
  interval        100ms
  pk_delay       1.99ms
  av_delay        132us
  sp_delay          5us
  backlog            0b
  pkts          2274264
  bytes       227991560
  way_inds        29553
  way_miss         8922
  way_cols            0
  drops            1781
  marks               0
  ack_drop        88359
  sp_flows            1
  bk_flows            1
  un_flows            0
  max_len         13320
  quantum           306

qdisc ingress ffff: dev pppoe-wan parent ffff:fff1 ----------------
 Sent 3934372975 bytes 2958645 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8006: dev ifb4pppoe-wan root refcnt 2 bandwidth 20100Kbit besteffort dual-dsthost nat wash ingress no-ack-filter split-gso rtt 100ms noatm overhead 34 mpu 64
 Sent 3882748954 bytes 2922049 pkt (dropped 36596, overlimits 4952905 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 347328b of 4Mb
 capacity estimate: 20100Kbit
 min/max network layer size:           28 /    1492
 min/max overhead-adjusted size:       64 /    1526
 average network hdr offset:            0

                  Tin 0
  thresh      20100Kbit
  target            5ms
  interval        100ms
  pk_delay        813us
  av_delay        718us
  sp_delay          6us
  backlog            0b
  pkts          2958645
  bytes      3934372975
  way_inds        38580
  way_miss        10343
  way_cols            0
  drops           36596
  marks               0
  ack_drop            0
  sp_flows            0
  bk_flows            1
  un_flows            0
  max_len          1492
  quantum           613
13

yes that's the ping to Europe and it is normal

14

that's the ping to US, game is playable and it is 15vs15 tank battle. They have servers in Europe too but account transfer is not possible

15

Good thingking! Looking at the DNS name, mrs01 might denote Marseille (since MRS is its airport's code), the next hop's par is probably Paris, followed by lon for London, so Europe for sure, but whois 39.35.0.1 points to Pakistan as origin, so that jump seems really caused by the speed of light in a sea cable connecting Karachi and Marsaille? Interestingly cogent's last hop seems to be in Chicago (ORD is a well known code for Chicago)...

That certainly is a path long enough to accumulate loads of unexpected delay variations. But thinking about this, it might be a good idea to add "rtt 200" to both iqdisc_opts and eqdisc_opts, to relax cake's interval a bit, otherwise it might be too harsh to those long range flows...

1 Like
16

routing is best optimized for Europe and we get constant ping to Europe compared to Asia like Singapore or some other location for servers. To Europe it is typically 140-160ms ping and to singapore we get like 110-130ms ping. But in Europe region at least you can understand the language. So i always prefer europe region but i dont know why game developers like to tie game to just a specific region and you cant change the location of server.
here you can see maps for fiber cable connecting our globe.


Thanks to internet we are now in global village :smiling_face_with_three_hearts: just milliseconds away
17

Mmmh, I would try hard to get into closer by servers, the longer the path the more likely intermittent latency variability is going to get. SQM is decent to fix your own access link, but not very suited to fix upstream path issues...

18

Try convincing them to switch your account to a new region then?

+1...

19

i am facing the issue again what tests should i run?
ping is fine to server

20

it's a pc game right? any chance some other application is updating or something dl heavy?

per ip fairness may hinder you if that's the case...

moeller asked for 'tc -s qdisc' while connection was idle for a while and a second when connection was used for a while...?

in this case... maybe one now would help too

tc -s qdisc

you can also go to luci > realtime graphs > connections

and see the top 2-5 in the list if something is chugging data... ( particularly on same pc... cake would likely handle better from elsewhere ) it moves alittle quickly...

the command line tool

iptraf-ng

iptraffic monitor > eth1(or ppp) ( will probably give a much more readable picture )