same question is there such a rule ?
I hope this will answer your first question:
And since then, a few feature improvements have also been added. For example, there's now a new UI tab to view active connections and another one to easily create custom nftables rules.
Basically, there are a few settings in the advanced tab that allow traffic to be classified and prioritized or deprioritized in a more or less "automated" manner. However, these settings do not offer exactly the same functionality as dscpclassify. You could theoretically replicate dscpclassify features using custom rules.
However, I need to address one aspect of your default dscpclassify settings. The high throughput setting, as you have it configured, would likely only make a difference with WMM or when using diffserv8 (maybe on an AP) because AF13 in Cake DiffServ4 goes into the same tin as CS0, which is best effort. Additionally, the setting for threaded clients would only be truly beneficial if you have a significant amount of P2P traffic, such as frequently downloading many torrents or similar activities.
1 Like
hello everything is fine?
I'm waiting for your hfsc and cake settings, can you post them for us?
Unfortunately I am getting errors when trying to complete the auto setup, I am also getting the same issue of dscp showing cs0 even after disabling wash dscps when it is set to cs5
Awesome work, thank you Hundra!
I saw Netem is an option. Netduma has a feature called "steady ping."
Explanation in their words:
Steady Ping works by applying a ping buffer to your connection. This will slightly increase your ping, but it does this to account for the changes in ping or jitter you would normally experience. This results in an almost perfectly stable ping...
Could something similar be achieved with netem? If so could it be applied to specific traffic and/or game client ip?
Here is a picture to give a better explanation.
To add: I know with qos/sqm 'steady ping' theoretically should not be needed. It is a problem with my isp causing jitter. Idk if this would help but I thought it might.
Edit: Here is my bufferbloat result. My unloaded ping jumps up to 95ms when my avg is 16ms. It is noticeable in game when this happens. Since I have sqm setup ironically my ping gets better when loaded.
1 Like
My settings are pretty basic and I mainly play COD, but as requested, here is my config:
Summary
config global 'global'
option enabled '1'
config settings 'settings'
option WAN 'eth1'
option DOWNRATE '90000'
option UPRATE '45000'
option ROOT_QDISC 'hfsc'
config advanced 'advanced'
option PRESERVE_CONFIG_FILES '1'
option WASHDSCPUP '1'
option WASHDSCPDOWN '1'
option BWMAXRATIO '20'
option UDP_RATE_LIMIT_ENABLED '0'
option UDPBULKPORT '51413'
option TCPBULKPORT '51413,6881-6889'
option VIDCONFPORTS '10000,3478-3479,8801-8802,19302-19309,5938,53'
option TCP_UPGRADE_ENABLED '1'
config hfsc 'hfsc'
option netemdelayms '20'
option LINKTYPE 'ethernet'
option OH '44'
option gameqdisc 'bfifo'
option nongameqdisc 'fq_codel'
option nongameqdiscoptions 'besteffort ack-filter'
option MAXDEL '24'
option PFIFOMIN '5'
option PACKETSIZE '450'
option netemjitterms '7'
option netemdist 'normal'
option pktlossp 'none'
config cake 'cake'
option COMMON_LINK_PRESETS 'ethernet'
option PRIORITY_QUEUE_INGRESS 'diffserv4'
option PRIORITY_QUEUE_EGRESS 'diffserv4'
option HOST_ISOLATION '1'
option NAT_INGRESS '1'
option NAT_EGRESS '0'
option ACK_FILTER_EGRESS 'auto'
option RTT '25'
option AUTORATE_INGRESS '0'
config rule 'cod1'
option name 'cod1'
option proto 'udp'
option src_ip '192.168.1.208'
option src_port '3074'
option dest_port '30000-65535'
option class 'cs5'
option counter '1'
option enabled '1'
config rule 'cod2'
option name 'cod2'
option proto 'udp'
option dest_ip '192.168.1.208'
option dest_port '3074'
option class 'cs5'
option counter '1'
option enabled '1'
config rule
option name 'cod3'
option proto 'udp'
list src_ip '192.168.1.208'
list src_port '3074'
list dest_port '3074'
option class 'cs5'
option counter '1'
option enabled '1'
config custom_rules 'custom_rules'
@Ridz
What errors do you get when using the auto setup?
Another user had a similar issue, and we discovered that he had an incorrect setting that caused a syntax error in the nftables rules. Have you read through the thread and already taken any troubleshooting steps?
@bigbilly
Thanks!
Unfortunately, I don't own a Netduma R3 to test steady ping, but I believe this is more of a marketing tactic.
You can effectively manage jitter within your own network using QoSMate and by ensuring you have hardware robust enough to prevent latency spikes caused by overloading. However, addressing issues beyond your local network becomes challenging.
Theoretically, it might be possible to develop a buffer that processes incoming packets in a way that they are sent to the gaming device without jitter. However, the question remains whether this would provide significant benefits. Additionally, such an approach wouldn't work for outgoing packets, as once they leave your router, you can no longer control them. Perhaps one of our specialists has some thoughts on this topic? @dlakelan @moeller0
I would say your bufferbloat test looks quite good. It's difficult to determine whether that single ping spike occurred within your network or on the way to the server.
For the sake of completeness, I should mention: I’m not sure which root qdisc you’re using, but with how HFSC is implemented here, speed tests aren’t necessarily prioritized when HFSC is active so it may only "look" worse.
1 Like
Thank you for the explanation. My thoughts exactly that some type of packet buffer would improve consistency.
To clarify, I am currently running standard SQM with cake on n97 mini pc but your work stood out as being a fix it all solution. Specifically the inclusion of netem to add latency (potential packet buffer smoothing) and your statement in post 4 that "This ensures that the QoS rules remain effective even during periods of lower bandwidth."
This made me wonder if my latency/jitter was worse when not hitting ingress/egress limits due to sqm not being active in contrast to your solution where it is always active. However it seems that if bandwidth is not maxed out and if hardware is powerful enough, then theoretically latency/jitter should remain unchanged. This makes sense but contradicts what I observe when I run various test which makes me think that your solution could fix this.
The limitation you described about how the packets are only in control within the local network makes sense.
I will have to find the source for where I found this but, in netcode analysis, I have heard about game servers implementing this same type of packet buffer. In the case of if the client and the server both have a packet buffer implemented, then it might not matter if the packets bounce around when traversing through the network as the packets are smoothed out on both receiving and sending sides. Although this is just a theory I had. It would be interesting if this could be implemented if your package with netem but I am not sure if this is possible or if there would be any benefit.
I apologies if this is outside the scope of the project but I saw a lot of interesting things so I had to ask haha.
Edit: My bufferbloat test is odd although it is consistent in the way it behaves.
1 Like
This is the error message that I am getting, I have tried to see if people have had a similar issue to my own and tried to follow the troubleshooting steps.
I don't think it would be useful to have your router jitter-buffer your game packets, the best place for jitter buffering is in the game server. Every packet should have some kind of sequence number in it, and the server can buffer packets and process actions in sequence provided your jitter isn't TOO big. The main thing is to keep the jitter below some level where the server's jitter buffer can handle it.
6 Likes
De-jitter buffers are definitely a thing, but to built one, one needs access to some reliable per-packet timing and sequence information and that is something that the generic networking layers typically do not have... Within applications that information can be made available and e.g. VoIP clients and game servers (unsure about clients) do exactly that.
The way a de-jitter buffer works is that it will add a variable delay (within in some configured bound) such that the egressing packet stream is overall delayed, but the inter-packet spacing is again as intended. Note that this works best with constant packet rate flows, like VoIP or gaming control traffic and with some more slack video traffic.
4 Likes
Thanks for the reply. I thought it was something like this. Although it might not be a direct competitive or latency advantage, wouldn't a buffer on the client side "smooth out" the perception of the game? Would game consistency on the client side improve if both the client and server had packet buffers, due to the packets arriving at the client and server at the rate they were intended? Versus packets arriving at the game server as intended but not to the client due to the server having a packet buffer but not the client. In other words, the game server perceives the client inputs as consistent and smooth, as intended, but the server response perceived by the client is variable depending on the connection, resulting in a loss of consistency on the client side. Maybe the benefit would be similar to how 1% lows affect the perceived smoothness and consistency of the game, even if you have high average FPS, though I'm not certain.
Thank you for the reply, VoIP is a good example because it is real time just like gaming. Since packet buffers are used in real time applications where timing matters this makes me think a game client would benefit too. If I wanted to explore this further on how to make a packet buffer where would be a good place to start? DumaOS has this feature which they named steady ping. I realize this is mostly marketing but if they can implement it without the game application providing the timing information, would this mean it's possible? It could be they implemented it sub-optimally due to not having access to the specific application information as you stated in your post. I am no means an expert like @moeller0 or @dlakelan so I appreciate both of your insights.
1 Like
So I really do not know what/how dumaos does what it does nor what it promises to do. That said typicaly ICMP echo requests (commonly called pings) always carry a readable sequence number and almost always also a readable timestamp that could be used for a ping specific de-jitter buffer, but de-jittering ICMP pings will do exactly nothing for VoIP or gaming traffic, so seems to be an exercise in pure benchmarking
3 Likes
Netduma use openwrt heavly customized , dont know the kernel vers. and its just marketing.
My xr500 is in beta about 2 years.
1 Like
I did not know that! Thats pretty cool, gives me hope there is a way to implement it.
The only cool app the netduma have is geo-filter, the qos from netduma its bad very bad.
1 Like
I am not sure. From what I understand the terminology Duma uses is just for the average gamer. While the name steady ping implies ping, I think they really mean steady latency. When most people play games the game will display their "ping" but it is really round trip time or latency to the server. This is why Duma opted to call it steady ping I believe. I put a picture in this post to try to better explain.
Edit: Your explanation makes sense and I appreciate the explanation. Based on what you said if it is literal ping then you would be right and there would be no benefit.
I wish it was open source so you could get benefits of QoSmate and also get the geo-filter feature all in native Openwrt. Someone I saw someone built something similar and they were posting on another thread trying to rebuild their own version of geo-filtering.
Edit: Here is Dopam's version of geo-filter. Hopefully he is able to rebuild it.
Dejittering can only be done well by the apps themselves. A jitter buffer in the middle could potentially make the app have an easier time, but also is guaranteed to add lag to the entire circuit. In general the app should be doing the buffering. The router can best handle the traffic by forwarding it as fast as possible without inducing intermediate buffering in modem's or ISP equipment etc. basically what cake and HFSC etc do.
1 Like
Thanks for the insight. It is too bad there is no way to man in the middle buffer it. Your right that qos/sqm should resolve it but it is a problem with downstream jitter. I figured if there were buffers on either end of the up and down stream it would be able to smooth it out. I know this would cost overall latency, however that is a tradeoff I would take any day to get consistent gameplay and "fix" downstream jitter.