Hi, how are you? I wanted to ask for help to see if they guide me in this, I want to know if in the "Match mark" box go the DSCP & TOS
Firewall marks and the DSCP field are different things. See the manpage iptables-extensions and look for the following sections:
mark
This module matches the netfilter mark field associated with a packet
(which can be set using the MARK target below).
[...]
MARK
This target is used to set the Netfilter mark value associated with
the packet. It can, for example, be used in conjunction with routing
based on fwmark (needs iproute2). If you plan on doing so, note that
the mark needs to be set in the PREROUTING chain of the mangle table
to affect routing. The mark field is 32 bits wide.
[...]
dscp
This module matches the 6 bit DSCP field within the TOS field in the
IP header. DSCP has superseded TOS within the IETF.
[...]
DSCP
This target alters the value of the DSCP bits within the TOS header
of the IPv4 packet. As this manipulates a packet, it can only be
used in the mangle table.
[...]
If you told us more about your goal, we could help you better.
No, these are firewall marks.
There is "Match DSCP" option available, but not under Port forwarding.
My idea is to give priority to port 37000-40000, and I wanted to know what command I can put there
You have already installed luci-app-qos so go to QoS under Network menu and configure it there.
1 Like
Can you say more about your network, especially the uplink type, modem, router?
Which application are you trying to improve - maybe a game?
What is your goal - for example low latency (ping)?
You might want to try SQM with cake.
For many applications, it works well with a simple configuration, without explicit priorities.
1 Like
Hello, the idea is to have a low latency network with a good impact register, I play fps games like Apex, bf, and cod. My specifications are
Linksys WRT x32 router
Modem F @ st 38901
300 up and 16 down coaxial fiber internet
I use sqm with cake and layer_cake.qos
You need to add an interface as well there, it should be the wan (or whatever wan you have).
Are you sure about the number of bytes?
May I see your /etc/config/sqm please?
Do not install multiple QoS packages simultaneously.
I suggest to remove luci-app-qos and qos-scripts.
1 Like
Ok, I'm going to uninstall what you suggest, but why do you say it?
SQM with cake works well and does not require qos-scripts anymore. However, I am not sure that your SQM configuration is complete yet. Why did you not set the Link layer adaptation?
You could also show the result of your speed test here if you want.
From the SQM article:
- Set the Download and Upload speeds to 80-95% of the speed you measured above in the Preparation.
- For Cable - Choose Ethernet , and set per packet overhead to 22
The DSLReports download speed is lower and the idle ping latency is much higher than the values measured with Telecentro. The DSLReports ping latency hardly differs between idle and loaded.
I guess there is a congested link elsewhere (not directly on your uplink). If the path to the game server is also affected, you cannot fix this problem yourself with technical measures. SQM might still be useful, but only for close destinations where your own uplink is the bottleneck.
I suggest to put SQM and QoS aside for now. Instead, run mtr or traceroute against the game server or some other remote server to find the bottleneck link. Post the results here if you want an opinion.
Then talk to your ISP, because they might be able to fix the congestion problem.
I will change the subject of this thread since the focus of the discussion has changed.
I'm currently trying to optimise my connection for gaming too.
I have FTTP (fiber to the premises) and get 300/50 Mbps. My ISP told me to set the MTU on the WAN interface of my router so in this case it's 1492 after determining the MTU for line.
Why does SQM Link Layer Adaption need to be set? It says Ethernet with overhead: select for e.g. VDSL2. VDSL2 is fiber to the cabinet (FTTC) with copper cable the rest of the way the premise. VDSL2 typically supports up to 80Mbps here in the UK. With this in mind and the fact I have FTTP not FTTC, I have had Link Layer Adaption set to none (default). Can anyone explain this need for the overhead on the Link Layer Adaption for connections 80Mbps and above?
That typically is an indication for something like an 8 byte PPPoE header...
Easy, SQM's core idea is to deal with bufferbloat. That is over-sized and under-managed buffers in typical end-user network equipment that under saturating loads can create queues worth multiple 100s of milliseconds (sometimes into the thousands) all packets entering such a queue will have to wait for all packets ahead in the queue to be sent first, resulting in massive latency-under-load increases that ruin most/all interactive internet uses (video conferencing, on-line gaming, ...).
So, SQM properly manages its own buffers (making the buffer-size itself mostly irrelevant) resulting in latency under load increases in the low 10s of milliseconds (easily 1-2 orders of magnitude better than standard queues); the trick now is to rate limit SQM in a way, that the bad buffers in the network simply never fill up, and to do that SQM needs to make sure it never admits more data into its upstream than the upstream can reasonably transmit without excessive buffering. Now, just when you send a package by mail, the box itself has weight and volume (and needs to be transported), similarly data packets carry payload and some overhead bytes (for e.g. addressing, so that your payload reaches the intended computers at the other side of a "connection"). With data packets this addition per-packet-overhead typically is fixed in size, while the payload is not, so the overhead to payload ratio of packets can easily range from ~1:1 to ~1:25, but the size the kernel sees for each packet is just the payload (I am simplifying here) while the transport needs to transport payload+overhead. To make up for this difference traffi-shapers like sqm can be told what amount of overhead to add to each packet's payload to get a realistic estimate of how much transport-rate that packet will consume. So SQM needs the per-packet-overhead information to make sure that it will not admit too much data into its upstream and thereby cause undesired filling of the under-managed buffers.
Does that help?
None is mostly wrong, but getting a reliable estimate of the true per-packet-overhead of an arbitrary link is hard. Luckily, over estimating the overhead (slightly) only causes a slight reduction in peak throughput while preserving low latency-under-load increases, so if in doubt just err a bit on the larger side for the per packet overhead.