Hello i play first person shooter games in console ps4. A friend uses fresh tomato firmware and this qos works perfect for this games.
It uses sfq with 2 classes only and only 2 rules...
One with udp protocol and transferred 256kb
And one more with tcp and udp transferred 256kb+...thats it.
Can we create a script to do the same thing in Openwrt?
4 Likes
Hi @knomax, you sent me some personal messages, thanks for posting this publicly.
I have some ideas how we can get a very similar result, maybe even with a better rule than this one, I will think about it a little and try to put something together. I'm thinking perhaps a TBF to get the rate right, and then a simple drr with two classes, one for games and one for everything else (DRR is similar to SFQ but offers a little more control).
2 Likes
Thanks @dlakelan i think and other call of duty gamers are interested in that... Waiting for testings.
1 Like
TBF for rates....256kb and 256+kb?DRR for classification?
You need to control the upstream total rate, so that would be TBF.... Then you want to have basically two classes of traffic, one priority class that can send lots of packets and one low-priority class that has to wait if the priority class has packets.
So something like 10:1 ratio of bytes between the two classes...
Then we need a classifier, it will use iptables to use a classification. The best would be to have a single gaming machine and then classify all the UDP from that gaming machine as high prio... that'd be probably most reliable... There is also some other options I will consider.
All udp traffic in gaming machine without transferred rates? Waiting and for other options you are thinking.
to set up the qdiscs I think:
#!/bin/sh
WAN=eth0.2 # change this to your WAN device name
UPRATE=650 #change this to your kbps upload speed
tc qdisc replace dev $WAN handle 1: root tbf limit 3000 burst 6000 rate ${UPRATE}kbit
tc qdisc add dev $WAN parent 1: handle 2: drr
tc class add dev $WAN parent 2: classid 2:1 drr quantum 1500
tc class add dev $WAN parent 2: classid 2:2 drr quantum 15000
tc qdisc add dev $WAN parent 2:1 bfifo limit 3000
tc qdisc add dev $WAN parent 2:2 bfifo limit 15000
Now we need to add two iptables rules to classify outbound packets
#!/bin/sh
GAMINGIP = "10.1.1.3" # change this
# start by putting everything into 2:1 as "default"
iptables -t mangle -A PREROUTING -j CLASSIFY --set-class 2:1
#reclassify all udp packets from your gaming machine as 2:2, high priority
iptables -t mangle -A PREROUTING -p udp -s ${GAMINGIP} -j CLASSIFY --set-class 2:2
To test this, try disabling SQM, and then running the two scripts by hand, you can put the scripts in something like /etc/customqos/ folder
If things bork, execute
tc qdisc delete dev $WAN root
and restart the firewall
The way this works is it ultimately allows only $UPRATE kbps to be sent out of the WAN device... avoiding an upstream queue building in your ISP routing equipment etc... But the way it schedules packets, for every byte you can send in the 2:1 queue (the normal queue) you can send 10 bytes in the high priority queue... so if there's nothing in the high priority queue, then the low priority queue gets all the bandwidth, but if there's contention, about 90% of the bandwidth will generally go to your gaming rig.
1 Like
It "boosts" routing udp packets? I understand It right? So decrease latency even more than packets waiting in a queue?
Sort of yes. It makes 10 bytes go from your game machine's UDP for every 1 byte for other traffic... I'm testing it now, needs a little work on syntax for setting up the tbf.
Ok I edited the script to make the tbf work. There may need some tuning of the various magic numbers here 
if you have more than one gaming machine you can add more than one iptables rule to add those UDP packets to the high prio queue.
For bfifo 3000 kbytes is big value? And for DRR my connection pppoe mtu is 1492.
3000 bytes in this case is around 2 packets, so not a very big value. Packets will get dropped which will throttle connections other than your UDP.
The idea here is that game control packets are UDP and I assume you want ultimate priority for them, that you want low probability of dropping, and that you're willing to give them 90% of your upstream bandwidth.
The 15000 bytes for the high priority queue means very low probability of drops for the gaming UDP.
3000 bytes for low priority queue means very quickly bulk TCP streams will start dropping if there are UDP packets to go through.
if you can test this to see if the basic idea works, we can tune it later with the fine-tuning, 1500 vs 1492 etc is not so important at this point.
Many users confirm that if they throtle connection like 3000kbps for download and etc 400kbps for upload they see some improvement in hit reg...
So can we do this with some iptables rules... In combination with the scripts already posted to test It?
The script posted will throttle the upload to UPRATE using the token bucket filter (TBF)... I'd suggest to throttle it to about 80% of what you get from a speed test. If you use something like an edgerouter and have wired connections for both WAN and LAN we can set up a similar thing in the output of the LAN device, will just require running the same thing and adding a couple iptables rules to classify based on destination.
start with just the upload. This is all theoretical at the moment, so really needs testing before we try other stuff.
I use edgerouter.. You say to do the same and in download direction after? In edgerouter i have console wired and a separate router with openwrt to act as access point for WiFi. You are right.. Upload is more important.
So i close all sqm.. Qos staff... Do speedtest at take 80%of upload to set the script.. And start testing in gaming. Unless you are not online in the forum... What values can i adjust increase/decrease for "sweet spot"?
Generally you'll want the upload speed to be as high as possible while maintaining high hitreg and low latency. It probably means somewhere between about 80 and 95% of your speed test rate.
If you're going to do up and down direction here's a script:
#!/bin/sh
WAN=eth0.2 # change this to your WAN device name
UPRATE=650 #change this to your kbps upload speed
LAN=eth0.1
DOWNRATE=3000 #change this to about 80% of your download speed (in kbps)
setqdisc () {
DEV=$1
RATE = $2
tc qdisc replace dev $DEV handle 1: root tbf limit 3000 burst 6000 rate ${RATE}kbit
tc qdisc add dev $DEV parent 1: handle 2: drr
tc class add dev $DEV parent 2: classid 2:1 drr quantum 1500
tc class add dev $DEV parent 2: classid 2:2 drr quantum 15000
tc qdisc add dev $DEV parent 2:1 bfifo limit 3000
tc qdisc add dev $DEV parent 2:2 bfifo limit 15000
}
setqdisc $WAN $UPRATE
setqdisc $LAN $DOWNRATE
#!/bin/sh
GAMINGIP = "10.1.1.3" # change this
# start by putting everything into 2:1 as "default"
iptables -t mangle -A PREROUTING -j CLASSIFY --set-class 2:1
#reclassify all udp packets from your gaming machine as 2:2, high priority
iptables -t mangle -A PREROUTING -p udp -s ${GAMINGIP} -j CLASSIFY --set-class 2:2
iptables -t mangle -A POSTROUTING -p udp -d ${GAMINGIP} -j CLASSIFY --set-class 2:2
1 Like
OK i Will test first the upload part.. If It wants some adjustments.. What values can i change.. Up or down?
if you start with just the upload direction you can adjust the UPRATE around a little, try 80% of upload speed, then try 95... maybe back off to 90... try to get it so it gives you good "feel".
also remember to adjust the GAMINGIP to be the internal IP of the machine you game on.
not much else should need fooling around with, but you might adjust the bfifo lengths, you could try doubling or cutting them in half to see what it does.
OK thank you very much.. I Will post the results.. Maybe and other gamers can test It to have better "view".
A good type of test would be to fire up your game, and then ask someone on another machine to run a speed test, see how the responsiveness behaves when idle vs when under load. See how much the speed fluctuates in the speed test when you do lots of gaming activities (like dslreport which provides a graph)
I Will start the game and making speed test via my Linux pc... Or saturate my connection downloading Ubuntu image etc. And look how It goes.