Help on DSCP marking for gaming + SQM

Installing and Using OpenWrt Network and Wireless Configuration
21

awesome, I've done that with this:


iptables -t mangle -N dscp_mark
ip6tables -t mangle -N dscp_mark
iptables -t mangle -F dscp_mark
ip6tables -t mangle -F dscp_mark

iptables -t mangle -A FORWARD -j dscp_mark
ip6tables -t mangle -A FORWARD -j dscp_mark

## everything gets lower priority
iptables -t mangle -A dscp_mark --set-dscp-class CS0
ip6tables -t mangle -A dscp_mark --set-dscp-class CS0

##other UDP gets AF41
iptables -t mangle -A POSTROUTING -p udp --set-dscp-class AF41
ip6tables -t mangle -A POSTROUTING -p udp --set-dscp-class AF41

May I ask why i'm appending 'dscp_mark' sometimes, but 'POSTROUTING' other times, or did I do it wrong.

also, is there a way to give my Powershell 'ping' command EF/CS6 so I can see if it will have consistent low ping with no spike? I think that will also tell me if I did it wrong or if the spike problem is not from my side.

22

I think change the POSTROUTING to dscp_mark

23

The thing is, even though I've set to tag everything with CS0,
whenever I load webpages, that still goes into the 'Voice' bin which is the highest priority for diffserv4.


                   Bulk  Best Effort        Video        Voice
  thresh       1562Kbit       25Mbit    12500Kbit     6250Kbit
  target         11.7ms        5.0ms        5.0ms        5.0ms
  interval      106.7ms      100.0ms      100.0ms      100.0ms
  pk_delay          0us        954us        145us        316us
  av_delay          0us        176us          2us         27us
  sp_delay          0us         15us          2us         14us
  backlog            0b           0b           0b           0b
  pkts                0         3251            9          745
  bytes               0       506195         5244       128314
  way_inds            0            8            0            0
  way_miss            0          160            1           24
  way_cols            0            0            0            0
  drops               0            1            0            0
  marks               0            0            0            0
  ack_drop            0            0            0            0
  sp_flows            0            1            0            0
  bk_flows            0            0            0            1
  un_flows            0            0            0            0
  max_len             0         1514         1392         1392
  quantum           300          762          381          300

this is what it looks like after twitch and youtube webpage loads. the video data itself seems not to be in the highest priority bin though.

24

@dlakelan, @moeller0, do you mind me asking what the lines at beginning of custom rules do?
and Im assuming the "ping" command belongs to 'icmp' group? if that's the case Can I tag icmp with high priority just to see if the ping would be more stable?

iptables -t mangle -N dscp_mark
ip6tables -t mangle -N dscp_mark
iptables -t mangle -F dscp_mark
ip6tables -t mangle -F dscp_mark

iptables -t mangle -A FORWARD -j dscp_mark
ip6tables -t mangle -A FORWARD -j dscp_mark

and there's a warning like this:

# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.

i hope it doesn't mean I have to reload the config every time I connect

25

Packets hop over tens of machines on their way between you and the server... cake has control of only ONE of those hops.

1 Like
26

With a peak delay of 23 microseconds your router and its egress queue is really not the party to blame. I understand some people claim human sensitivity to be in the low milliseconds range (e.g. in VR where larger delays induce sea sickness in some) but double digit microseconds?

27

The problem @moeller0 is that SQM does such a miraculous job of improving the worst part of delay that people get the impression it's magic :wink:

There is delay all along the path. If you are really lucky it will have standard deviation something like 5ms. If you are unlucky some link in that path will have tens to hundreds of milliseconds of delay with weird distributions that just happen to give you a big lag right at the critical moment! Nothing Cake can do if that delay is happening somewhere deep in the internet.

1 Like
28

I hit the 10 reply limit for new user, had to wait a couple hours to reply again : (

OK I see, the queues aren't the problem then. The jitter caused by traffic is very noticeable though.
I also did the test I mentioned to @dlakelan
I tested with icmp packets tagged as CS6, and I ran ping command to google. I checked the qdisc, the ping packets are correctly queued into the highest priority bin.

normally they look like this

Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=11ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=7ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119

the interesting thing is, whenever I'm sending low priority data in the "Best Effort" bin, such is in the case of watching a stream from twitch, the ping still begin to fluctuate even though it's in the highest priority bin already. it starts to look like this:

ply from 172.217.13.99: bytes=32 time=7ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=15ms TTL=119
Reply from 172.217.13.99: bytes=32 time=14ms TTL=119
Reply from 172.217.13.99: bytes=32 time=15ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=7ms TTL=119
Reply from 172.217.13.99: bytes=32 time=13ms TTL=119
Reply from 172.217.13.99: bytes=32 time=15ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=15ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=15ms TTL=119
Reply from 172.217.13.99: bytes=32 time=13ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=16ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=14ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=16ms TTL=119
Reply from 172.217.13.99: bytes=32 time=17ms TTL=119
Reply from 172.217.13.99: bytes=32 time=17ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119

and this is more or less the same problem I run into with my games. These jitters (some times it gets to 30,40,50 ms) manifest themselves in the form of slow down, stutters, and jagged movement in Street Fighter V. So if the packet in the lower priority bin would stop affecting the ones in higher priority bins that would solve my problem.

And because the ping is so stable when there's no traffic I feel like it's a problem from my end instead of a problem along the hops, which I should be able to solve.

so it really comes down to:
is it normal for lower priority data to have such a noticeable effect on the higher priority data? or should the effect be attributed to the ingress queue (if ingress queue can have such effect on the egress queue).

29

What is your speed values?

30

you should be test the script of dlakelan @noobuser, if you are at the canada you speak french no ?

i'm a french user if you want i can try help with dlakelan :slight_smile:

31

i capped the speed at 90/25. and the queues have more than enough bandwidth when this happened.

32

oof my French is non-existent : (
But you must know Videotron then, I don't know if it's videotron screwing up or if it's me.

33

videotron no ? ^^ i'am at france telecom now the name is orange in vdsl2 type connexion

34

Please show the output of tc -s qdisc after such a test. If cake is the culprit its timing stats will show that.

35

Ok. At 25Mbps upload one large packet takes 2ms to send, so you are seeing variation in the range of 8ms or so, which is like 4 large packets, which is kind of typical variation.

Sorry, I had the math inverted. it takes 0.48ms to send a large packet, so no this doesn't make sense that it would have this much variation of 8ms.

The HFSC based script with a dedicated realtime queue might help a little. see the thread Help prioritizing games with alternative qdisc design

36

did a small test after restarting sqm:

Pinging google.ca [172.217.13.99] with 32 bytes of data:
Reply from 172.217.13.99: bytes=32 time=11ms TTL=119
Reply from 172.217.13.99: bytes=32 time=13ms TTL=119
Reply from 172.217.13.99: bytes=32 time=23ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=20ms TTL=119
Reply from 172.217.13.99: bytes=32 time=11ms TTL=119
Reply from 172.217.13.99: bytes=32 time=22ms TTL=119
Reply from 172.217.13.99: bytes=32 time=8ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=14ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=13ms TTL=119
Reply from 172.217.13.99: bytes=32 time=30ms TTL=119
Reply from 172.217.13.99: bytes=32 time=12ms TTL=119
Reply from 172.217.13.99: bytes=32 time=24ms TTL=119
Reply from 172.217.13.99: bytes=32 time=24ms TTL=119
Reply from 172.217.13.99: bytes=32 time=11ms TTL=119
Reply from 172.217.13.99: bytes=32 time=12ms TTL=119
Reply from 172.217.13.99: bytes=32 time=14ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=81ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119
Reply from 172.217.13.99: bytes=32 time=18ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=18ms TTL=119
Reply from 172.217.13.99: bytes=32 time=17ms TTL=119
Reply from 172.217.13.99: bytes=32 time=11ms TTL=119
Reply from 172.217.13.99: bytes=32 time=12ms TTL=119
Reply from 172.217.13.99: bytes=32 time=10ms TTL=119
Reply from 172.217.13.99: bytes=32 time=9ms TTL=119

and tc -s qdisc output

                   Bulk  Best Effort        Video        Voice
  thresh       1562Kbit       25Mbit    12500Kbit     6250Kbit
  target         11.7ms        5.0ms        5.0ms        5.0ms
  interval      106.7ms      100.0ms      100.0ms      100.0ms
  pk_delay          0us        340us          4us        135us
  av_delay          0us         16us          0us          7us
  sp_delay          0us         14us          0us          7us
  backlog            0b           0b           0b           0b
  pkts                0          172            1           78
  bytes               0        20923           75        13773
  way_inds            0            0            0            0
  way_miss            0           47            1            8
  way_cols            0            0            0            0
  drops               0            0            0            0
  marks               0            0            0            0
  ack_drop            0            0            0            0
  sp_flows            0            1            0            0
  bk_flows            0            0            0            0
  un_flows            0            0            0            0
  max_len             0         1514           75          590
  quantum           300          762          381          300

@dlakelan even in here, there's a 81ms of ping, so I guess i was correct to assume this is a problem of my ISP right? This is really not a normal thing to have, but they said they sent 3 different technicians to check the servers in my area and everything's fine...

37

What router are you running? There are a few which had strange latency spikes like this due to some driver issues etc. I thought that was mostly fixed these days but would be interesting to know which router.

38

I'm using the Archer c7 V2.
I've also tried the EMG 2926 provided by my ISP, the problem is still there -- but of course i didn't have OpenWRT on that one.

is the Archer known for this sort of problems?

and my Modem is Technicolor tc4400 which I specifically requested to avoid having a Intel Puma chipset in my modem.

39

the archer c7 was not one of the ones I was thinking of. I think you're pretty good device wise.

The ISP technicians who "check" things are almost certainly not sophisticated enough to debug random latency spikes. If you can load google they call it good.

Peak delay in the cake shaper was 0.3ms so a sudden 70ms extra latency for a ping was almost certainly caused by something in the path other than your machine.

1 Like
40

I see, this is very unfortunate for me since it seems like a problem that can't be helped.
Do you think local area congestion could cause something like this? I started notice this issue back in September when school (online classes) started.

but I really appreciate the help you and @moeller0 have given me.
I learned a lot just talking to you guys and now I know how to tag my packets in the future.