Help prioritizing games with alternative qdisc design

The big question is... how is the response? How well does your game feel? hitreg, lag, etc?

how does it feel if another machine does speed tests during game?

1 Like

i will test now and i you keep informed

thanks a lot of dlakelan i just reboot now and classify appair

big thanks

i test play the night with dsl reports in game on my pc ps4 etc :stuck_out_tongue: :wink:

Honestly, at this point we should change this to an SQM script, we already have the hot-plug and the select your leaf qdisc machinery in place (which would need additions for qfq and drr)...

1 Like

hello everybody so this his my bufferbloat in my pc in full game

my game seems good with the scripts hitmarker song goods

I'm glad my original post is evolving into something good for gamers...lets see if will have the option to install additional qdiscs via package....

1 Like

i suggest setting you the test like this and see how it goes.

https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803

@dlakelan @Knomax I felt like I was getting ignored and not being helped any longer, could be that I didn't succeeded with these scripts or it could be that you guys got annoyed by my questions.

for now i went back to Dave build and turned on the SQM, if you guys decide to help again please do share if anything i could try. it seems like many things has changed in the Scripts in the last few posts.

as mentioned earlier the bufferbloat especially for the Upload was terrible with these Scripts, am sure that has caused the issues with the gaming as well, so far it seems the scripts were working based on the results I have posted. from these scripts bufferbloat was insane for the upload speed, it doesn't matter if i ran it low as 1mbps, still had the issue. it works fine with SQM enabled running Cake even at 5 mbps upload

Test the script in a game that have a network graffic like bf4 or bf5 seems more acurate..

Just a sugestion :sweat_smile:

1 Like

I'm not ignoring you, we are just debugging. @Dopam-IT_1987 has got it working so I suggest you scroll up and grab the most recent version and test it

1 Like

@dlakelan

i assume this should work as nothing else has changed

#!/bin/sh

## "atm" for old-school DSL or change to "DOCSIS" for cable modem, or "other" for everything else

LINKTYPE="DOCSIS"

WAN=eth1.2 # change this to your WAN device name
UPRATE=5000 #change this to your kbps upload speed
LAN=eth0.1
DOWNRATE=80000 #change this to about 80% of your download speed (in kbps)

## how many kbps of UDP upload and download do you need for your games
## across all gaming machines? 

GAMEUP=450
GAMEDOWN=1200

## set this to "pfifo" or if you want to differentiate between game
## packets into 3 different classes you can use either "drr" or "qfq"
## be aware not all machines will have drr or qfq available

gameqdisc="pfifo"

GAMINGIP="192.168.1.197" ## change this



cat <<EOF

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 = $GAMEUP kbps
Game download guarantee = $GAMEDOWN 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 = $(((1500*8)*3/UPRATE)) ms

DOWN = $(((1500*8)*3/DOWNRATE)) 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:

$((1500*8*3/5)) 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.

EOF




setqdisc () {
DEV=$1
RATE=$2
OH=37
MTU=1500
highrate=$((RATE*90/100))
lowrate=$((RATE*10/100))
gamerate=$3
useqdisc=$4


tc qdisc del dev "$DEV" root

case $LINKTOP in
    "atm")
	tc qdisc replace dev "$DEV" handle 1: root stab mtu 2047 tsize 512 mpu 68 overhead ${OH} linklayer atm hfsc default 3
	;;
    "DOCSIS")
	tc qdisc replace dev $DEV stab overhead 25 linklayer ethernet handle 1: root hfsc default 3
	;;
    *)
	tc qdisc replace dev $DEV stab overhead 40 linklayer ethernet handle 1: root hfsc default 3
	;;
esac
     



#limit the link overall:
tc class add dev "$DEV" parent 1: classid 1:1 hfsc ls m2 "${RATE}kbit" ul m2 "${RATE}kbit"

# high prio class
tc class add dev "$DEV" parent 1:1 classid 1:2 hfsc rt m1 "${highrate}kbit" d 80ms m2 "${gamerate}kbit"

# other prio class
tc class add dev "$DEV" parent 1:1 classid 1:3 hfsc ls m1 "${lowrate}kbit" d 80ms m2 "${highrate}kbit"


## set this to "drr" or "qfq" to differentiate between different game
## packets, or use "pfifo" to treat all game packets equally

REDMIN=$((gamerate*30/8)) #30 ms of data
REDMAX=$((gamerate*200/8)) #200ms of data

case $useqdisc in
    "drr")
	tc qdisc add dev "$DEV" parent 1:2 handle 2:0 drr
	tc class add dev "$DEV" parent 2:0 classid 2:1 drr quantum 8000
	tc qdisc add dev "$DEV" parent 2:1 handle 10: red limit 150000 min $REDMIN max $REDMAX probability 1.0
	tc class add dev "$DEV" parent 2:0 classid 2:2 drr quantum 4000
	tc qdisc add dev "$DEV" parent 2:2 handle 20: red limit 150000 min $REDMIN max $REDMAX probability 1.0
	tc class add dev "$DEV" parent 2:0 classid 2:3 drr quantum 1000
	tc qdisc add dev "$DEV" parent 2:3 handle 30: red limit 150000 min $REDMIN max $REDMAX probability 1.0
	## with this send high priority game packets to 10:, medium to 20:, normal to 30:
	## games will not starve but be given relative importance based on the quantum parameter
    ;;

    "qfq")
	tc qdisc add dev "$DEV" parent 1:2 handle 2:0 qfq
	tc class add dev "$DEV" parent 2:0 classid 2:1 qfq weight 8000
	tc qdisc add dev "$DEV" parent 2:1 handle 10: red limit 150000 min $REDMIN max $REDMAX probability 1.0
	tc class add dev "$DEV" parent 2:0 classid 2:2 qfq weight 4000
	tc qdisc add dev "$DEV" parent 2:2 handle 20: red limit 150000 min $REDMIN max $REDMAX probability 1.0
	tc class add dev "$DEV" parent 2:0 classid 2:3 qfq weight 1000
	tc qdisc add dev "$DEV" parent 2:3 handle 30: red limit 150000 min $REDMIN max $REDMAX probability 1.0
	## with this send high priority game packets to 10:, medium to 20:, normal to 30:
	## games will not starve but be given relative importance based on the weight parameter

    ;;

    *)
	PFIFOLEN=$((1 + 40*RATE/(MTU*8))) # at least 1 packet, plus 40ms worth of additional packets
	tc qdisc add dev "$DEV" parent 1:2 handle 10: pfifo limit $PFIFOLEN
	## send game packets to 10:, they're all treated the same
	
    ;;
esac

if [ $((MTU * 8 * 10 / RATE > 50)) -eq 1 ]; then ## if one MTU packet takes more than 5ms
    echo "adding PIE qdisc for non-game traffic due to slow link"
    tc qdisc add dev "$DEV" parent 1:3 handle 3: pie limit  $((RATE * 200 / (MTU * 8))) target 80ms ecn tupdate 40ms bytemode
else ## we can have queues with multiple packets without major delays, fair queuing is more meaningful
    echo "adding fq_codel qdisc for non-game traffic due to fast link"
    tc qdisc add dev "$DEV" parent 1:3 handle 3: fq_codel limit $((RATE * 200 / (MTU * 8))) quantum $((MTU * 2))
fi

}


setqdisc $WAN $UPRATE $GAMEUP $gameqdisc

## uncomment this to do the download direction via output of LAN
setqdisc $LAN $DOWNRATE $GAMEDOWN $gameqdisc

## we want to classify packets, so use these rules

cat <<EOF

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)
EOF

read -r cont

if [ "$cont" = "y" ]; then

    iptables -t mangle -F POSTROUTING
    iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 1:3 # default everything to 1:3,  the "non-game" qdisc
    if [ "$gameqdisc" = "pfifo" ]; then
	iptables -t mangle -A POSTROUTING -p udp -s ${GAMINGIP} -j CLASSIFY --set-class 1:2
	iptables -t mangle -A POSTROUTING -p udp -d ${GAMINGIP} -j CLASSIFY --set-class 1:2
    else
	echo "YOU MUST PLACE CLASSIFIERS FOR YOUR GAME TRAFFIC HERE"
	echo "SEND TRAFFIC TO 2:1 (high) or 2:2 (medium) or 3:3 (normal)"
    fi
else
    cat <<EOF
Check the rules and come back when you're ready.
EOF
fi

echo "DONE!"

tc -s qdisc

Do i need to do these as well? like JuJu did?

echo "y" | /root/qosgaming.sh

in putty or local startup? or both?

yes, that's what starts the script when you reboot, you put it in the local script /etc/rc.local

It plays well in gaming...nice @dlakelan.

alight cool, i could try this again later on tonight

quick question, can i copy and paste the exact Chain POSTROUTING as mentioned above and repalce my IP with 192.168.2.167 to 192.168.1.197 ?

i assume those three are the only things that i need to setup based on the picture, unless there are more.

also i run UPNP, should i do the port forwarding manually and disable UPNP?

not sure what that question means, you can add additional matches to match whatever you want and send it to the real-time qdisc:

	iptables -t mangle -A POSTROUTING -p udp -d ${GAMINGIP} -j CLASSIFY --set-class 1:2
	iptables -t mangle -A POSTROUTING -p udp -d ${GAMINGIP} -j CLASSIFY --set-class 1:2

if you define a second variable GAMINGIP2 you can use it by just copying these lines and changing to GAMINGIP2 or also 3 or 4. Two lines for each machine you game on.

am more confuse about this part, like what exactly am i setting up here?

That is just reporting, to see that it is working... see how it has 9 and 5 packets... so it's classifying correctly.

allright that make sense, lets assume if everything works accordingly and i still get the bufferbloat issue with upload speed regardless of whatever i set it on. what other option should we be looking at at that point?

set your speeds correctly, and then play your game. don't worry about dslreports it doesn't measure the game performance.

Latest 5 matches...
Kill-Deaths
25-4
28-3
35-15
38-6
19-6
It works very well...and i dont have big bandwidth...so for you guys will work much much better than me. :wink:

2 Likes

It can be useful though if you give us some dslreports performance numbers, there could be stuff we can still tune, but it doesn't indicate how your game works, it indicates how other people will experience internet while surfing etc