Vodafone Station Cable (Bridge Mode) into
NanoPi R4S with OpenWrt 22.03.0-rc1 + a switch
1000/50 Cable Connection, without sqm enabled i get 940/54.
I enabled packet steering and Irqbalance with SSH to get better speeds. (SQM: 650mbit -> 800mbit)
These are my current SQM settings according to the offical SQM Details site and posts i read from @moeller0
Are these settings correct im not sure about the Per Packet Overhead i dont use a VLAN so i took 18
(22 - the 4VLAN tag) for my Cable connection.
The next thing i want to adress is the prioritization of my gaming packets. I couldn´t find a tutorial to set it up and i dont know where to insert the settings. I have read about Layer cake and dscp marks with diffserv4. I just want a simple priorization for only the gaming packets (udp) which my pc sends.
Yes, the recommendation for 22B is based on the off-chance of a VLAN tag being present and the observation that slightly overestimating the per-packet-overhead is "safe".
If you want to use sqm with prioritisation, you need to switch to layer_cake.qos and then make sure to properly mark your packets before cake gets hold of them. If you use snapshot builds there is the new qosify tool that allows relative easy rule based DSCP marking and prioritization (it is an alternative to sqm in that it will itself manage its own cake instances, so do not run qosfy and sqm on the same interface).
But if all you want is to prioritize the outgoing UDP packets from one specific host you should be able to configure a simple traffic rule (action DSCP classification, for Source Address of your computer) add a static DHCP lease bound to the MAC address of your computer...
At the moment im using the "stable" firmware for my device. I tried a snapshot but the speeds with sqm were bad. I read about qosify but i only saw some code/configs so i was not sure. I am new to SSH and i like it more when i have a GUI so is there already an opkg package for qosify ?
so can my ISP set a vlan tag ? and therefore its better to set it to 22 ?
well the best would be to prioritize only the packets my game uses which i think i can find with wireshark or how do you do that ?
and how do i do that is there a guide or something you can recommend ?
Yes, your ISP could, but I have not yet seen a DOCSIS ISP that actually does that, as explained the rationale for recommending 22 over 18 is that if the overhead is truly just 18, setting 22 costs really only a very small amount of potential throughput, while setting 18 if the true overhead is 22 can result in noticeable bufferbloat.
Yes, I would get a packet capture and look inside that... you should look up your gaming computer's IP address though, makes it easier to select/filter the packets in wireshark/tcpdump
Click on the "Traffic Rules" tab in the firewal page (the third after "General Settings" and "Port Forwards") there you can add a new rule and select "DSCP classification" as action... no need to manually twiddle iptables commands.
Just add the text diffserv4 to the fields named "Advanced option string to pass to the [in|e]gress queueing disciplines; no error checking, use very carefully". But if you really only want to prioritize one application than even layer_cake.qos's default differserv3 policy would work...
I believe OpenWrt 22 will use firewall4 and unlike firewall3 that does not yet? have a custom rules section. But for your simple marking action you will not need that.
I am still on an older system with firewall3 so will not be able to answer from first hand experience...
internal IP address of you gaming PC, firewall based marking only works for egress/upload, for download the problem is that cake/sqm handle the incoming packets before the firewall code gets hold of them, if you need DSCP remarking for ingress qosify is your best bet right now (but qosify currently can not see the internal IP addresses as it runs outside of NAT).
Not going to work for ingress/download, so leave this empty and configure Source address instead.
You need to pick something which cake will put in the high priority tin, EF will work for both diffserv3 and diffserv4 (see here for details).
Some ISPs will actively drop CS7 marked packets entering their networks, so I would first test this out, orvuse cake's wash option, which will first use the dscp value to select the correct tin but then remark the packet to DSCP0.
@elan the goal here is to do minimal QoS by just expediting game traffic to one isolated host in the LAN. For egress iptables/nftables are just fine, and for ingress qosify does not allow marking by internal addresses yet. So respectfully this is not a problem where qosify will do much better than the method described above. Also not sure whether your config is as minimal as the OP aimed at?
Now if game traffic can be easily identified by port numbers with minimal false positives for ingress a qosify rule could be used, but in that case a tc filter could also be employed....
Yes, I would very much appreciate if we would not discuss your unconditional support for qosify in every QoS related thread.
Especially if qosify is not well suited for the problem at hand....
This is IMHO not a beauty contest which QoS framework/tool is 'better' overall, but the question should be every time which of the available tools is suited for the problem at hand...
For DSCP-marking by internal IP address in the egress direction qosify simply is not suited.
The available options are:
a) mark at source: (for windows10/11 see here) E.g. for setting EF for putty on windows use: New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46
To do that for a game one needs to replace putty.exe with the correct binary name, but it is not 100% clear if that will work (I neither play games nor use windows10/11 so can not really test that very well, that said, I did test and confirm the EF-marking for putty as shown above in a windows10 VM).
b) use iptables/nftables to create a DSCP-marking rule: this can be done either by "raw" [ip|nf]tables command or by using the LuCI GUI to create a traffic rule using "DSCP classification" as action
c) use a "raw" tc command (tc-filter and tc-pedit) to achieve the same
All of these will work equally well with sqm (simple.qos, layer_cake.qos) or qosify. None of these will solve the problem of treating incoming gaming packets to a higher priority. That can be ameliorated however by using a purely port based classification/marking rule for ingress, and that is actually something that qosify excels at.
So in the OP's shoes I would:
0) install and configure your choice of sqm or qosify to instantiate traffic shaping for ingress/download and egress/upload
assign a static lease to the gaming computer so it will reliably get the same internal IPv4 address (your.game.host.address)
create a packet-capture during a short game session to figure out which source and destination ports are used by the game's traffic (I would capture traffiv both in the internal network/LAN as well as on the WAN interface to see which addresses ports are stable and which get fudged by NAT/masquerading)
create a traffic rule (within LuCI's firewall->Traffic Rules page) to mark all packets from source your.game.host.address with the appropriate destination port (or port range) the game uses (I am guessing here that the destination port will be stable) to set the DSCP to EF
potentially use qosify to also EF-mark incoming packets with the appropriate ports (you can also try to hook into qosify's DNS integration to hook into the source IP addresses, but given how CDNs work that can have false positives)
report back what you tried and how it worked
And please keep in mind, that in prioritization for every packet that gets preferential treatment other packets will need to wait longer if there are no lower-priority packets available prioritization does not gain much anymore, hence it helps to only up-prioritize a few flows/packets (less restraint is required for down-prioritizing flows, but care needs to be taken to only do that to flows where completion time does not matter that much).
hi nik try like this for dscp classification in traffic rules
config rule
option name 'CS4 gaming'
list proto 'udp'
option src '*'
option dest 'lan'
list dest_ip 'ip of my device'
option target 'DSCP'
option set_dscp 'CS4'
option enabled '0'
your rules must be postrouting for see
postrouting = mark dscp exemple for see in wireshark ...
This is not going to do much... this will DSCP mark incoming packets, but only after cake is already done with them. As I said this method only works for egress traffic.
I just confirmed that on my OpenWrt19 based router with firewall3 the following rule:
config rule
option src '*'
list src_ip '192.168.42.201'
option target 'DSCP'
option dest '*'
option set_dscp 'EF'
list proto 'tcp'
list proto 'udp'
list proto 'icmp'
option enabled '1'
does work and result on marked packets on my WAN side. For testing I ran ping -c 5 8.8.8.8 on 192.168.42.201 while running tcpdump -i pppoe-wan -v -n 'host 8.8.8.8 and icmp'
on my router and when ever I sent packets on 201 tcpdump showed packets with (tos 0xb8 which according to https://linuxreviews.org/Type_of_Service_(ToS)_and_DSCP_Values is exactly the 8bit hexadecimal TOS value for EF...
Note however if I capture on br-lan the same packets are not yet marked EF but are still at CS0, but that is expected, also when capturing packets directly on the windows host CS0 will be visible unless method a) from my earlier post is used.
But where (on which interface) did you run wireshark? As I just wrote, I only see the changed DSCP on my WAN interface not on the 192.168.42.201 host or on br-lan. I also confirmed that the counters for the tin carrying EF in tc -s qdisc for the egress cake instance increase when 192.168.42.201 produces traffic, so I am 100% confident that on my machine with firewall3 it works as can be expected, but that might be different for firewall4.
