Qosify: new package for DSCP marking + cake

Has anyone tried to lower txqueuelen to 100? Or between 50-100 as some sites are referring to. https://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips/ but this is only for fq_codel?

And if you lower txqueuelen, should it be changed on my eth1, eth1.102 and eth0 (this is my switch for eth1/wan).

Hey guys, I wanted to share my experience and my settings with you, because my game only improved when I limited bandwidth on the internet via port 3074 in my game, which is Warzone. In many of my searches I see people reporting that they use qosify to improve their games, and mainly use dscp cs4 or cs6 in the rules on port 3074, but that never worked for me when it comes to games, and my game always had that I felt like I was always late. In many forums here in Brazil, people reported that they use their dscp in CS0 and said that the worse prioritization in their game "COD WARZONE", their game ran better. I did a test using SQM QOS, limiting my internet to 5mb Down and 5mb Up with all the Cake settings, and my internet is 700mb down and 350mb Up, and my experience in the game was wonderful without loss and feelings of delay, but the bad thing about all this is that you have a 700mb internet, limiting it to 5mb just for the game wouldn't make much sense and I started looking for a way to limit my internet via the game's port which is 3074. Firstly I want to say that I'm not one specialist in internet networks, I do everything by error and success and deduction and day-to-day experience. As I don't know how to write scripts, I started talking to chatgpt artificial intelligence so he could help me make a script that limits the internet per port, and kabummm, he made me a script that limits the internet bandwidth on the port 3074 of my game for 5mb of DOwn and 5mb of Up, as I don't know how to test this script to see if it was working I tested it while playing, as my experience with the bandwidth limitation script per port turned off in the game was horrible and when Enabled it was Wonderful with much more fluid gameplay and no feeling of delay. I'm going to share the Script here with you and also my qosfy settings that I use so that everyone can test it. I'll say right away that I'm no script or internet expert.

Follow all the steps without skipping anything. This is a tutorial for laypeople like me.
I made the commands using MS-DOS.

Bandwidth Limitation Script for Port 3074.

To limit bandwidth on a specific port in OpenWrt, you can use tc (Traffic Control), which is a tool for controlling network traffic. I will provide an example script that you can use to limit bandwidth on port 3074 to 5 Mbps upload and 5 Mbps download.

Make sure you access your OpenWrt router via SSH or console and run the following commands:

1-Open MS-Dos Prompt and Type:

ssh root@your-router-ip

2-Open the text editor to create a new script:

vi /etc/firewall.user

3-Add the following content to the file, use your I key to edit, copy and paste the script inside:

#!/bin/sh

# Bandwidth limit for port 3074
tc qdisc add dev br-lan root handle 1: htb default 10
tc class add dev br-lan parent 1: classid 1:1 htb rate 5mbit
tc class add dev br-lan parent 1:1 classid 1:10 htb rate 5mbit

# Filter packets on port 3074 and apply bandwidth rules
iptables -t mangle -A PREROUTING -p udp --dport 3074 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p udp --sport 3074 -j MARK --set-mark 1

# Apply markup rules to the created class
tc filter add dev br-lan parent 1: protocol ip prio 1 handle 1 fw classid 1:10

Once edited, click "Esc" and type ":wq" to exit.

4- Enter this command afterwards to make the script executable:

chmod +x /etc/firewall.user

5- Enter this command and restart the firewall to apply the changes:

/etc/init.d/firewall restart

My Qosify settings were based on this link:
[https://github.com/Last-times/CAKE-QoS-Script-OpenWrt]

Minhas configurações .cake.sh

My .cake.sh settings are too big and don't fit here, how can I share this file with you?

Qosify is pretty powerful but it has some limitations especially when it comes to Cod. Qosify only looks at the remote port and not the local port of a specific ip. Every single code game uses a random remote port range from 30000 – 65535 and the local port is always 3074 udp. So, if you want to prioritize Cod with qosify you would have to prioritize udp ports from 30000 – 65535 for your whole network, what really makes not sense. That’s because qosify can’t look behind your nat. At least not at this moment and therefore it is not very well suited for prioritizing warzone.

Something better suited for your use case and also easy to use would be DSCPCLASSIFY.

Gaming in general most of the time needs very little bandwidth. Warzone only needs approx. 100 – 300 kbps. So, you limiting game packets on port 3074 udp to 5 mbit will probably do not very much.

In the past there were several people here in the forum that tried limiting their bandwidth with mixed results. Even I tried it and for some time I felt good but this maybe was just placebo.

There were some really wild speculations in the past. Cod in general makes something like a network probe when you start the game (you could see the bandwidth value in cods network settings) and if you would limit your bandwidth to a certain point, it would change these numbers and people thought it could give you some sort of a benefit. Maybe their matchmaking would put you in a lower skilled lobby if it found out that you have a weak connection or it would put you on the “good side” of lag compensation. But these assumptions were all pretty wild.

If you really hard limit your game to 150 or 200 kbps it gets unplayable. You can try it for yourself.

Don’t know what version of OpenWrt you are using but newer versions of OpenWrt default use nftables not iptables like in your script but you could of course always install legacy iptables packages. Also, with fw4 and nftables. Chat gpt does not now this because it’s knowledgebase is limited to the end of 2021 at least for the free version gpt 3,5. So if you want other people to try your rules you should port them to nftables syntax.

3 Likes

exactly

juste you can make this rules fr example

if you want priorize your console

config rule
        option name 'PS5udp'
        list proto 'udp'
        list src_ip '192.168.2.160'
	list dest_port '!80'
	list dest_port '!443'
	option class 'cs4'
        option family 'ipv4'
	option counter '1'
1 Like

I wanted it to be more specific, because I leave qosify the way it is, and do Dscpclassify, or I delete qosify and just do dscpclassify, could you give me your COD rules too so I can analyze them.

you should be delete oqsify and use only dscpclassify

with sqm

2 Likes

Could you give me your sqm script and your dscpclassify so I can analyze it?

1 Like

I don’t want to spam the qosify thread with dscpclassify settings. I think it would be the best if you open a new topic or just ask for help in the dscpclassify main thread and I will provide you a config for warzone.

1 Like

Yes, I see the topic because I want to be helped a lot on this issue.

I tried sqm and qosify. I think qosify works better for me. I get normal pings and no packet loss even when other people are using the internet and streaming videos torrent etc. SQM was not that great.

Right now, I am downloading a torrent at full speed and tried playing an online game with a European server. 170-190ms ping with 0-1-2% packet loss.

If you use sqm with cake and diffserv4 the underlying qdisc is the same. So there shouldn’t be much of a difference between the two unless something wasn’t configured right.

The biggest difference between the two is how dscp marks are applied… qosify uses eBPF and with sqm you can use nftables or iptables (if on an older version) for the marks.

1 Like

Happy new year everyone. :fireworks:

When it comes to matching akamai.net that is used for streaming. I've logged 15 domains that is used for streaming from akamai.net.

a1160.v.akamai.net
a131.dscg1.akamai.net
a1356.dscg2.akamai.net
a1523.dscr.akamai.net
...

Is it recommended to use dns:<pattern> or dns_c:... ?

- dns:<pattern>
	fnmatch() pattern supporting * and ? as wildcard characters
- dns_c:...
	Like dns:... but only matches cname entries

And is this the correct way to match all domains for akamai.net?

dns:*.akamai.net video
or
dns_c:*.akamai.net video //(maybe dns_c does not support fnmatch()?).

Why I'm asking is that matching works better with IP rather than dns. Not sure why, but just wanna make sure I'm doing it right.

Thanks.

1 Like

Keep in mind that not everything on Akamai is streaming e.g steamuserimages-a.akamaihd.net comes from Steam Images.

If you stream Twitch, this may come useful .us-west-2.playback.live-video.net

max_len on my downstream seems to be lower than what it should be. My ppoe-wan mtu is 1492. I can push the max_len of Best Effort to 1448 when I "ping google.com -f -l 1464". Other than that it never exceeds 1440. @moeller0

/etc/config$ qosify-status
===== interface wan: active =====
egress status:
qdisc cake 803b: root refcnt 2 bandwidth 4900Kbit diffserv4 dual-srchost nat wash ack-filter split-gso rtt 100ms noatm overhead 34 mpu 68 
 Sent 2242058438 bytes 21258756 pkt (dropped 18899, overlimits 3422718 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 496Kb of 4Mb
 capacity estimate: 4900Kbit
 min/max network layer size:           28 /    1492
 min/max overhead-adjusted size:       68 /    1526
 average network hdr offset:            0

                   Bulk  Best Effort        Video        Voice
  thresh      306248bit     4900Kbit     2450Kbit     1225Kbit
  target         59.3ms          5ms       7.42ms       14.8ms
  interval        154ms        100ms        102ms        110ms
  pk_delay       5.21ms       4.58ms        507us        812us
  av_delay        797us        454us         34us         45us
  sp_delay         25us         17us         12us         18us
  backlog            0b           0b           0b           0b
  pkts          8037078      7326937      5856445        57195
  bytes       373745174   1475346550    371804375     25179896
  way_inds        49481       113640          762            7
  way_miss         3016       156780         1159          148
  way_cols            0            0            0            0
  drops               0         2208           63            0
  marks               0          205            0            0
  ack_drop         2437        12050         2137            4
  sp_flows            1            3            0            1
  bk_flows            0            0            1            0
  un_flows            0            0            0            0
  max_len         44640        37440        16893        10080
  quantum           300          300          300          300


ingress status:
qdisc cake 803c: root refcnt 2 bandwidth 16600Kbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 34 mpu 68 
 Sent 56713808979 bytes 43911277 pkt (dropped 342507, overlimits 80390328 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 694656b of 4Mb
 capacity estimate: 16600Kbit
 min/max network layer size:           46 /    1448
 min/max overhead-adjusted size:       80 /    1482
 average network hdr offset:            0

                   Bulk  Best Effort        Video        Voice
  thresh       1037Kbit    16600Kbit     8300Kbit     4150Kbit
  target         17.5ms          5ms          5ms          5ms
  interval        113ms        100ms        100ms        100ms
  pk_delay       12.7ms       1.91ms       19.2ms        505us
  av_delay       3.22ms        584us       12.3ms        131us
  sp_delay         68us         32us         29us         27us
  backlog            0b           0b           0b           0b
  pkts         13750799     13409607     16990928       102450
  bytes     19605062147  15122438684  22348686135     94649085
  way_inds        77770       243959         1330            7
  way_miss         3061       151543         1156          143
  way_cols            0          247            0            0
  drops           56390       147929       138184            4
  marks               0        27047           12            0
  ack_drop            0            0            0            0
  sp_flows            1            1            1            1
  bk_flows            0            0            1            0
  un_flows            0            0            0            0
  max_len          1440         1448         1440         1440
  quantum           300          506          300          300

The max_len of your incoming packets is typically only affected by up stream devices outside of your control, with the exception that your router will likely perform MSS clamping as well that might be responsible for that effect. That said as long as you do not get fragmentation due to this the "cost" of this is pretty negligible...

1 Like

It's the same even if I turn off MSS clamping from firewall. So I guess there is nothing to do / worry about. Thanks.

1 Like

One more question, do I need "split-gso" on ingress if I don't have packages larger than 1500? Does it make sense to turn it off to save few CPU cycles?

I do not know whether split-gso incurs a cost if no packet needs to be split... but the packet merging can happen in the linux NIC driver of your router. So unless the shaper rate is well above 1 Gbps I personally would keep split-gso as a back-stop. But by all means just try it out. An occasional glance at tc -s qdisc output should inform you whether you you might want to reenable it.

1 Like