Help prioritizing games with alternative qdisc design

I’m using the ER-X which has no WIFI and I’m also not using a bridge:


… so everything should go through the Ethernet port.

My girlfriend is also using the internet but wasn’t streaming or surfing in one of my captures.

Yes I’m capturing on the same machine as I game.

Internet -> ISP Router/modem in bridge mode -> ERX with OpenWRT -> unmanaged switch ->

  • Wired: Gaming PC, Work Notebook, Xbox SX etc…

  • Wireless Router: TV, Smartphone etc…

I think the issue is not only on my end because I just played a normal Modern Warfare multiplayer game and this is my outcome:


Which looks normal to me.. What do you say?

yes that looks relatively good. How do the packets per second look?

Packets per second is in the first pic?

1 Like

When activision finds out...

:rofl: :rofl: :sweat_smile: :sweat_smile: :joy: :joy: :joy:

@Hudra At first thank you.
@dlakelan Do you have my captures from PS4?Maybe if @Hudra sends you the files from multiplayer and warzone (different) mode find something interesting...etc if send rates are the same...12-15 packets/100ms like ps4....or something else....i say this because he plays the same game like me...and has the same router..edgerouter x.

@Dopam-IT_1987 I wish to have your connection!!

2 Likes

Yea i could send @dlakelan all captures if he would like to dig through them

Send me a capture where things were going wrong... I'll PM you a link to drop it...

In the script i have put the ipv4 of my ps4 i can put ipv6 like in this image

Yes, that should work. And I can ping your ipv6 only 165ms round trip :wink: (fortunately it immediately refuses ssh)

im running latest script i think but i aint sure if ts working
does this look correct

root@OpenWrt:~# ./qos.sh
ipset v7.3: Set cannot be created: set with the same name already exists
ERROR: could not create realtimeset4 do you have ipsets working?
ipset v7.3: Set cannot be created: set with the same name already exists
ERROR: could not create realtimeset6 do you have ipsets working?
ipset v7.3: Element cannot be added to the set: it's already added
ipset v7.3: Element cannot be added to the set: it's already added
ipset v7.3: Element cannot be added to the set: it's already added
ipset v7.3: Element cannot be added to the set: it's already added

This script prioritizes the UDP packets from / to a set of gaming
machines into a real-time HFSC queue with guaranteed total bandwidth

Based on your settings:

Game upload guarantee = 8000 kbps
Game download guarantee = 33000 kbps

Download direction only works if you install this on a *wired* router
and there is a separate AP wired into your network, because otherwise
there are multiple parallel queues for traffic to leave your router
heading to the LAN.

Based on your link total bandwidth, the **minimum** amount of jitter
you should expect in your network is about:

UP = 3 ms

DOWN = 0 ms

In order to get lower minimum jitter you must upgrade the speed of
your link, no queuing system can help.

Please note for your display rate that:

at 30Hz, one on screen frame lasts:   33.3 ms
at 60Hz, one on screen frame lasts:   16.6 ms
at 144Hz, one on screen frame lasts:   6.9 ms

This means the typical gamer is sensitive to as little as on the order
of 5ms of jitter. To get 5ms minimum jitter you should have bandwidth
in each direction of at least:

7200 kbps

The queue system can ONLY control bandwidth and jitter in the link
between your router and the VERY FIRST device in the ISP
network. Typically you will have 5 to 10 devices between your router
and your gaming server, any of those can have variable delay and ruin
your gaming, and there is NOTHING that your router can do about it.

adding fq_codel qdisc for non-game traffic due to fast link
adding fq_codel qdisc for non-game traffic due to fast link

We are going to add classification rules via iptables to the
POSTROUTING chain. You should actually read and ensure that these
rules make sense in your firewall before running this script.

Continue? (type y or n and then RETURN/ENTER)
y
ip6tables v1.8.3 (legacy): --match-set requires two args.
Try `ip6tables -h' or 'ip6tables --help' for more information.
Everything is taken care of for RED qdisc
DONE!
Can not output tc -s qdisc because it crashes on OpenWrt when using RED qdisc, but things are working!
root@OpenWrt:~#

This is the only thing I'd worry about, perhaps you have a customized rule that isn't correct? Or you need to re-download the dscptag.sh script maybe I had a typo in an older version or something?

Thank you dlakelan i will try your idea

i think it might be working now but still i aint sure
can you tell me if this is ok

root@OpenWrt:~# ./qos.sh
ipset v7.3: Set cannot be created: set with the same name already exists
ERROR: could not create realtimeset4 do you have ipsets working?
ipset v7.3: Set cannot be created: set with the same name already exists
ERROR: could not create realtimeset6 do you have ipsets working?
ipset v7.3: Element cannot be added to the set: it's already added
ipset v7.3: Element cannot be added to the set: it's already added
ipset v7.3: Element cannot be added to the set: it's already added
ipset v7.3: Element cannot be added to the set: it's already added

This script prioritizes the UDP packets from / to a set of gaming
machines into a real-time HFSC queue with guaranteed total bandwidth

Based on your settings:

Game upload guarantee = 8000 kbps
Game download guarantee = 33000 kbps

Download direction only works if you install this on a *wired* router
and there is a separate AP wired into your network, because otherwise
there are multiple parallel queues for traffic to leave your router
heading to the LAN.

Based on your link total bandwidth, the **minimum** amount of jitter
you should expect in your network is about:

UP = 3 ms

DOWN = 0 ms

In order to get lower minimum jitter you must upgrade the speed of
your link, no queuing system can help.

Please note for your display rate that:

at 30Hz, one on screen frame lasts:   33.3 ms
at 60Hz, one on screen frame lasts:   16.6 ms
at 144Hz, one on screen frame lasts:   6.9 ms

This means the typical gamer is sensitive to as little as on the order
of 5ms of jitter. To get 5ms minimum jitter you should have bandwidth
in each direction of at least:

7200 kbps

The queue system can ONLY control bandwidth and jitter in the link
between your router and the VERY FIRST device in the ISP
network. Typically you will have 5 to 10 devices between your router
and your gaming server, any of those can have variable delay and ruin
your gaming, and there is NOTHING that your router can do about it.

adding fq_codel qdisc for non-game traffic due to fast link
adding fq_codel qdisc for non-game traffic due to fast link

We are going to add classification rules via iptables to the
POSTROUTING chain. You should actually read and ensure that these
rules make sense in your firewall before running this script.

Continue? (type y or n and then RETURN/ENTER)
y
iptables: Chain already exists.
ip6tables: Chain already exists.
Everything is taken care of for RED qdisc
DONE!
Can not output tc -s qdisc because it crashes on OpenWrt when using RED qdisc, but things are working!
root@OpenWrt:~#

@Kinel Restart firewall first..from Overview.
Then run script and post output.

Only 3 ms for upload!!!

In mine i have this:

Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: This script prioritizes the UDP packets from / to a set of gaming
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: machines into a real-time HFSC queue with guaranteed total bandwidth
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Based on your settings:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Game upload guarantee = 3000 kbps
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Game download guarantee = 8000 kbps
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Download direction only works if you install this on a *wired* router
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: and there is a separate AP wired into your network, because otherwise
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: there are multiple parallel queues for traffic to leave your router
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: heading to the LAN.
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Based on your link total bandwidth, the **minimum** amount of jitter
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: you should expect in your network is about:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: UP = 0 ms
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: DOWN = 0 ms
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: In order to get lower minimum jitter you must upgrade the speed of
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: your link, no queuing system can help.
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Please note for your display rate that:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: at 30Hz, one on screen frame lasts:   33.3 ms
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: at 60Hz, one on screen frame lasts:   16.6 ms
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: at 144Hz, one on screen frame lasts:   6.9 ms
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: This means the typical gamer is sensitive to as little as on the order
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: of 5ms of jitter. To get 5ms minimum jitter you should have bandwidth
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: in each direction of at least:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: 7200 kbps
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: The queue system can ONLY control bandwidth and jitter in the link
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: between your router and the VERY FIRST device in the ISP
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: network. Typically you will have 5 to 10 devices between your router
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: and your gaming server, any of those can have variable delay and ruin
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: your gaming, and there is NOTHING that your router can do about it.
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Error: Cannot delete qdisc with handle of zero.
Sat Dec 12 10:32:50 2020 daemon.err dnscrypt-proxy[1915]: [2020-12-12 10:32:50] [NOTICE] [dnscrypt.eu-nl] OK (DNSCrypt) - rtt: 45ms
Sat Dec 12 10:32:50 2020 daemon.info avahi-daemon[2781]: Server startup complete. Host name is OpenWrt.local. Local service cookie is 2974567644.
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: adding fq_codel qdisc for non-game traffic due to fast link
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Error: Cannot delete qdisc with handle of zero.
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: adding fq_codel qdisc for non-game traffic due to fast link
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: We are going to add classification rules via iptables to the
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: POSTROUTING chain. You should actually read and ensure that these
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: rules make sense in your firewall before running this script.
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done:
Sat Dec 12 10:32:50 2020 daemon.notice procd: /etc/rc.d/S95done: Continue? (type y or n and then RETURN/ENTER)
Sat Dec 12 10:32:51 2020 daemon.notice procd: /etc/rc.d/S95done: Everything is taken care of for RED qdisc
Sat Dec 12 10:32:51 2020 daemon.notice procd: /etc/rc.d/S95done: DONE!
Sat Dec 12 10:32:51 2020 daemon.notice procd: /etc/rc.d/S95done: Can not output tc -s qdisc because it crashes on OpenWrt when using RED qdisc, but things are working!

0ms on down and up
Now im testing the manual GAMEDOWN\GAMEUP

I have some wireshark capture of DSCP tag:

playing cod cold war (core teamdeathnatch)

0ms pretty good i think.
Also successfully tag packets as CS7.

root@OpenWrt:~# /etc/qos.sh
ipset v7.3: Set cannot be created: set with the same name already
ERROR: could not create realtimeset4 do you have ipsets working?
ipset v7.3: Set cannot be created: set with the same name already
ERROR: could not create realtimeset6 do you have ipsets working?
ipset v7.3: Element cannot be added to the set: it's already adde
ipset v7.3: Element cannot be added to the set: it's already adde
ipset v7.3: Element cannot be added to the set: it's already adde
This script prioritizes the UDP packets from / to a set of gaming
machines into a real-time HFSC queue with guaranteed total bandwi
Based on your settings:
Game upload guarantee = 2050 kbps
Game download guarantee = 7000 kbps
Download direction only works if you install this on a *wired* ro
and there is a separate AP wired into your network, because other
there are multiple parallel queues for traffic to leave your rout
heading to the LAN.
Based on your link total bandwidth, the **minimum** amount of jit
you should expect in your network is about:
UP = 3 ms
DOWN = 0 ms
In order to get lower minimum jitter you must upgrade the speed o
your link, no queuing system can help.
Please note for your display rate that:
at 30Hz, one on screen frame lasts:   33.3 ms
at 60Hz, one on screen frame lasts:   16.6 ms
at 144Hz, one on screen frame lasts:   6.9 ms
This means the typical gamer is sensitive to as little as on the
of 5ms of jitter. To get 5ms minimum jitter you should have bandw
in each direction of at least:
7200 kbps
The queue system can ONLY control bandwidth and jitter in the lin
between your router and the VERY FIRST device in the ISP
network. Typically you will have 5 to 10 devices between your rou
and your gaming server, any of those can have variable delay and
your gaming, and there is NOTHING that your router can do about i
adding fq_codel qdisc for non-game traffic due to fast link
adding fq_codel qdisc for non-game traffic due to fast link
We are going to add classification rules via iptables to the
POSTROUTING chain. You should actually read and ensure that these
rules make sense in your firewall before running this script.
Continue? (type y or n and then RETURN/ENTER)
y
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Another app is currently holding the xtables lock. Perhaps you waw option?
Everything is taken care of for RED qdisc
DONE!
Can not output tc -s qdisc because it crashes on OpenWrt when usiut things are working!
root@OpenWrt:~#

what is your GAMEUP\GAMEDOWN, using auto or manual
Mine is:

GAMEUP:3000
GAMEDOWN: 8000

I have it in auto for testing.

Ok 1 question GAMEUP\GAMEDOWN its minim speed granted to console game or the maxim.
If i do a speed test on ps4 console menu i have more than i set on GAMEDOWNGAMEUP