[any gamer here] i experience a lot of lag and low outgoing pps in games?

Installing and Using OpenWrt
1

i am on ps4 i tried everything i fixed bufferbloat and i open up nat using port forwarding i get nat type 1 nothing seem to work i notice that i gets small outgoing packets compared to others here are the packets:

0:57:10.237419 IP (tos 0x0, ttl 64, id 9699, offset 0, flags [none], proto UDP (17), length 169)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 141
10:57:10.254611 IP (tos 0x0, ttl 64, id 13030, offset 0, flags [none], proto UDP (17), length 171)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 143
10:57:10.272491 IP (tos 0x0, ttl 64, id 13573, offset 0, flags [none], proto UDP (17), length 174)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 146
10:57:10.289884 IP (tos 0x0, ttl 64, id 58931, offset 0, flags [none], proto UDP (17), length 159)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 131
10:57:10.320986 IP (tos 0x0, ttl 64, id 64655, offset 0, flags [none], proto UDP (17), length 170)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 142
10:57:10.353689 IP (tos 0x0, ttl 64, id 13360, offset 0, flags [none], proto UDP (17), length 181)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 153
10:57:10.377028 IP (tos 0x0, ttl 64, id 44241, offset 0, flags [none], proto UDP (17), length 184)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 156
10:57:10.393483 IP (tos 0x0, ttl 64, id 27799, offset 0, flags [none], proto UDP (17), length 186)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 158
10:57:10.408756 IP (tos 0x0, ttl 64, id 45177, offset 0, flags [none], proto UDP (17), length 189)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 161
10:57:10.425792 IP (tos 0x0, ttl 64, id 17899, offset 0, flags [none], proto UDP (17), length 180)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 152
10:57:10.440455 IP (tos 0x0, ttl 64, id 35778, offset 0, flags [none], proto UDP (17), length 171)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 143
10:57:10.456877 IP (tos 0x0, ttl 64, id 2522, offset 0, flags [none], proto UDP (17), length 166)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 138
10:57:10.487969 IP (tos 0x0, ttl 64, id 27963, offset 0, flags [none], proto UDP (17), length 170)
    192.168.1.129.3074 > 108.61.237.130.44890: [udp sum ok] UDP, length 142
10:57:10.529425 IP (tos 0x0, ttl 64, id 60991, offset 0, flags [none], proto UDP (17), length 174)

and these are incoming packets

    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 399
10:53:58.869973 IP (tos 0x48, ttl 118, id 8341, offset 0, flags [none], proto UDP (17), length                                                                437)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 409
10:53:58.889819 IP (tos 0x48, ttl 118, id 8342, offset 0, flags [none], proto UDP (17), length                                                                481)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 453
10:53:58.900299 IP (tos 0x48, ttl 118, id 8343, offset 0, flags [none], proto UDP (17), length                                                                487)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 459
10:53:58.919176 IP (tos 0x48, ttl 118, id 8344, offset 0, flags [none], proto UDP (17), length                                                                467)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 439
10:53:58.938450 IP (tos 0x48, ttl 118, id 8345, offset 0, flags [none], proto UDP (17), length                                                                389)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 361
10:53:58.950545 IP (tos 0x48, ttl 118, id 8346, offset 0, flags [none], proto UDP (17), length                                                                391)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 363
10:53:58.972511 IP (tos 0x48, ttl 118, id 8347, offset 0, flags [none], proto UDP (17), length                                                                385)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 357
10:53:58.978774 IP (tos 0x48, ttl 118, id 8348, offset 0, flags [none], proto UDP (17), length                                                                329)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 301
10:53:58.999337 IP (tos 0x48, ttl 118, id 8349, offset 0, flags [none], proto UDP (17), length                                                                340)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 312
10:53:59.019358 IP (tos 0x48, ttl 118, id 8350, offset 0, flags [none], proto UDP (17), length                                                                326)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 298
10:53:59.029745 IP (tos 0x48, ttl 118, id 8351, offset 0, flags [none], proto UDP (17), length                                                                314)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 286
10:53:59.050504 IP (tos 0x48, ttl 118, id 8352, offset 0, flags [none], proto UDP (17), length                                                                321)
    108.61.237.130.44890 > 192.168.1.129.3074: [udp sum ok] UDP, length 293
10:53:59.060703 IP (tos 0x48, ttl 118, id 8353, offset 0, flags [none], proto UDP (17), length

i want to know where is the problem and how to fix and these packets are normal for gaming or i gets small outgoing compared to incoming ????

2

Yes, it makes sense (to me) that outgoing traffic for a game is less than incoming.
In a typical shooter, your game needs to tell the server about your position and your actions.
The server needs to tell you about the position and actions of all other players in the game.
So it needs to send you more information than you send it.

Context:

Summary

Historical nonsense about packets per second and gaming
How can i increase packets per second for ip?

1 Like
3

You're on WiFi? If you solve buffer bloat with SQM and have a great wired router you may find the WiFi driver buffers inconsistently and adds lags spikes.

1 Like
4

The simplest and most efficient setup I've found is this:

  1. Your ISP subscribed down/up rates for download and upload boxes
  2. SQM Scripts with cake/piece of cake at default settings and the proper packet overhead.
root@OpenWrt:~# cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.

# 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.

iptables -t mangle -A FORWARD -i br-lan -p udp -s 172.16.1.9 --sport 3074 -j DSCP --set-dscp 0x22

*Edit the protocol, source ip of the gaming pc/box, and ports for your game. the DSCP is set at AF41 (Interactive Video)

1 Like
5

And iptables with DSCP work with peace of cake.

6

I apologize but I don't understand your response...

7

So gaming packets range from 64-1280 bytes (udp) depending on what title you're playing. This is normal and it looks like you're playing a realtime feedback type.

8

DSCP isn't for layer of cake script

9

Neither piece of cake nor layer cake by default wash outbound DSCP markings. Normally inbound is squashed for PREROUTING into the WAN and even so it's washed on the way in by other providers along the routing to your CPE modem. Something like a private network such as an end to end VPN or MPLS would be some of the ways you could guarantee markings stay intact. DSCP is useful for the lan and partial of the way outbound onto the internet without a special service.

Most servers only care about throughput, not latency, and so there's not much you can do about that.

2 Likes
10

Well piece_of_cake only uses one priority tin, so it basically ignores all dscps, layer_cake defaults to 3 priority tins IIRC and will steer packets into these tins by DSCPs, but by default it will ignore DSCPs on ingress, as DSCPs coming from ones ISPs typically are untrust-worthy and iptables does not allow changing packets before ingress cake sees them (both nftables and tc can manipulate dscps before ingress qdiscs see them, but tc is pretty arcane and ignorant of interal IP-addresses, and nftables has not made it into OpenWrt for good). Hope that helps...

1 Like
11

How are you getting NAT Type 1? That would mean you're directly connected to your modem without a router? Do you have DOCSIS (cable internet) connection?

12

i leased public ip from ISP and i used in br-lan Interface

13

I wanted to share my best settings for gaming, having tried many limiters, qdiscs, and different mixups.
This seems to be the best setup:

root@OpenWrt:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
ethtool -G eth0 tx 8
echo '12000' > /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max
exit 0


root@OpenWrt:~# cat /etc/sysctl.conf
# Defaults are configured in /etc/sysctl.d/* and can be customized in this file
net.ipv4.tcp_low_latency=1

root@OpenWrt:~# tc -d qdisc show dev eth0.2
qdisc cake 805c: root refcnt 2 bandwidth 10Mbit diffserv3 flows nonat nowash no-ack-filter split-gso rtt 150ms noatm overhead 22 mpu 64
qdisc ingress ffff: parent ffff:fff1 ----------------

root@OpenWrt:~# tc -d qdisc show dev ifb4eth0.2
qdisc cake 805d: root refcnt 2 bandwidth 45Mbit besteffort flows nonat wash ingress no-ack-filter split-gso rtt 150ms noatm overhead 22 mpu 64

root@OpenWrt:~# cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.

# 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.

iptables -t mangle -A PREROUTING -p udp --dport 3074 -j DSCP --set-dscp 0x30
iptables -t mangle -A POSTROUTING -p udp --sport 3074 -j DSCP --set-dscp 0x30

All offloads on every interface are off except for wlan & loopback. This is the major cause of most of your lag if your connection is slower than 100mbps, even with AQM enabled.
(even with cake's ability to peel superpackets into smaller one)

4 Likes
14

could you explain me in pm this information with more details or even link me your steam id so it would be easier

15

Hey man sorry to bother you, but can you explain where you got this number from?

I'm always looking for ways to make my gaming experience better and came across your post. I just don't know if setting this exact number would make any sense for my connection...thanks!

16

It's a conservative number that stems from the Byte Queue Limit suggested figures:
https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/

10mbit 1514 (one mtu packet plus 14bytes ethernet type 2 header)
100mbit 3000
1gbit 6000
10gbit 12000

The high majority of folks wouldn't run 10Gbit, but 12000 is still conservative against the default max :wink:

2 Likes
17

Thanks for sharing your results and for taking the time to reply!

18

I am not sure that this is the best way to look at that. IMHO one should size the maximum of that buffer such that the service time is still acceptable, e.g. for gigabit:

(1000 * 1000 bit/se)/8 bit/Byte * 1ms = 125000 Bytes

Why, because SQM's shaper will all start to admitting small batches of packets to the driver once the shaper rate exceeds a few Mbps, by default 1ms worth of packets. This is done as at higher and higher speeds the chance of getting the CPU in time gets smaller and smaller and to avoid stalls we accept a small (configurable) additional delay from the queue in the driver. For that to work however the driver needs to accept that many bytes, and hence try to not set this limit too low, if you want to use an additional shaper on the SQM side of things...
If you are willing to accept a throughput hit, by all means set the max BQL limit low! I just want you to know the consequences of doing so.

1 Like
19

The suggested size could correlate to a new thesis of only buffering the minimal amount needed to keep it busy and prevent starvation.

B = (RTT × C) / √n

1000^3 * .001 / 8 / √1024 or 32 = 3906.25 or ~2.6 1514 sized packets.

1 Like
20

You lost me :wink:

The thing is, under load cake will not be guaranteed to be run often enough to guarantee that the driver buffer never runs dry (at which point a "bubble" is introduces in the output). For HTB SQM tries to make that buffer configurable (but that only works, as your example made me realize if BQL has not acted and reduced the buffer to too small sizes, which potentially explains why that batching parameter does not really work as expected)...

2 Likes