@brada4, after I turned off packet stuttering, I no longer experienced delays with your firewall zone tips. These are the best I've had! I'm currently testing playing COD with Qosmate enabled and packet stuttering off, and I've configured the firewall zone just like you taught me. This is the best setup I've had so far. My game used to have screen shakes, but that's stopped now, and my response time has improved a lot. In the past, I often dropped bullets during gameplay, but now I'm connected to American servers from Brazil and it's much better. I'm still looking to fine-tune Qosmate. Thanks a lot for the tips!
1 Like
Well you did all on the spot. I was thinking of gradual approach taming the latency and jitter, you's probably get double throughput carefully walking same path again with same good latency you have now.
That is a decade old 32bit MIPS design that by now is majorly long in the tooth
And that is quite some hefty modern access bandwidth and unfortunate encapsulation
Especially if you add WiFi, firewalling and traffic shaping to the mix my gutfeeling is, your router is under-powered, so you either massively reduce the shaper rate to fall within the router's capabilities (I would guess around 100 Mbps combined up and down, maybe up to 150 if you really tweak it hard).
This is independent of the COU frequency, for CPU costly traffic shaping I believe you really want to enable packet steering, so the download and upload shaper can reside on different CPUs giving you a bit more shapable capacity.
Different VLANs will mostly only affect the LAN part so not sure this will noticeably help with on-line gaming. But why do you not simply try this out yourself?
That typically is done automatically be the game. However if you want to run your own game servers you should open the used ports in the firewall, otherwise ither's can not easily reach your server.
That is not a well-posed question. Your router can likely handle X packets/second, if 50% of these are IPv6 it can only handle 50% of capacity with IPv4 (and vice versa) but the same is true when comparing different IPv4 flows, capacity used by one can not be used by another.
I have no numbers on the relative cost in kernel for IPv4 and IPv6, but I personally believe that ship has sailed and modern home networks need both IPv5 and IPv6.
It depends... you really want to spread the router's load as evenly as possible over the CPUs but you can do this either by hand, or one-shot or automatically with irqbalance... the advantage of irqbalance likely is that it can adapt to changing loads.
No, typically tghis is handled automatically via MSS clamping in the firewall already... If you must set the MTU of PPPoe-wan to 1452, but not the one of the real uplink ethernet interface (e.g. eth0). The reason is that PPPoE overhead lives within the ethernet payload so if the MTU between your router and the ISP's PPPoe-terminating servers is 1500 (as it should) the largest possible IP payload to/from the internet ist 1500-8 = 1492 bytes, but the real MTU on your wan ethernet interface needs to be 1500... as this needs to keep room for the PPPoE header on top of the IP payload size. To/from the rest of the internet the consequence of the PPPoE tunnel is that it looks as if the MTU would be smaller.
2 Likes
@moeller0 This mtu change in pppoe-wan is right
Well, that should not hurt*. Was this done automatically, or did you configure this manually? I ask because for me the defaults seem to work well on my pppoe link.
*) Setting a smaller than possible MTU/MSS costs a bit of potential throughput but is unlikely to result in really negative consequences like loss of reachability.
1 Like
I did it manually, the previous one was 1492
Then undo it, 1452 is the IPv4 MSS value appropriate for a MTU of 1492, and with PPPoE the apparent internet MTU is 1492.
NOW, if any of these changes result in noticeable and quantifiable improvements keep them, but if they do not change anything I would heavily recommend not to play with these before researching and understanding the concepts behind MTU, MSS and how they intersect.
2 Likes
Remove all custom mtu settings unles you have certain indication they are wrong.
1 Like
One doubt, the MSS clamping, in the lan zone must be activated, because I saw that it is active in the wan zone. I read something MSS clamping, it should be active in a VPN or something, but I wonder if it should be activated in a normal firewall zone
It should be active in zones with reduced MTU only.
The patch to adapt correct mtu for pppoe or vpn is in snapshot but not in 23.05 yet, you can manually use its duplicate:
Save in /etc/nftables.d/mssfic.nft
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
ct packets < 14 oifname $wan_devices tcp flags syn / fin,syn,rst tcp option maxseg size set rt mtu comment "!fw4: Zone wan IPv4/IPv6 egress MTU fixing"
}
1 Like
Not really, you only want to affect packets that traverse the WAN link, no need to reduce the MSS for traffic within your home network.
1 Like
Just run SQM Cake, once you've achieved A+ bufferbloat/A+ quality ratings with no packet loss there is nothing else to be done for online gaming. You might need a device with a faster CPU (the CPU is very slow on your device) to get your full throughput with SQM.
If you are gaming on WiFi (hopefully not) use a target like mt76 devices with AQL limits and throttle down those settings to minimize latency.
12ms for online gaming is about as good as phyiscs/distance to server allows. All multiplayer games have a "tick rate" that is slower than that anyway, even the best tend to be around 64 tick. CS2 has variable/ subtick, but even then I doubt it updates more often then 12ms.
In terms of "feeling" latency it's unlikely because of push latency (tech has existed ever since QuakeWorld in 1996) you won't see or feel a smaller difference. Other things to make games more responsve is tied to framerate. The higher the framerate the lower the input latency. Fast enough CPU+GPU to handle higher framerates, high refresh rate monitors (144Hz and up) help tremendously, using 1KHz mouse/kb, enabling Nvidia Low Latency in NVCP or Reflex in games, using G-sync if your monitor VRR max is as high as your average fps, etc.
2 Likes
I'm not closing this post yet because throughout the week I will be testing my router and sharing my findings here. Following @brada4's suggestion to modify some settings in the firewall zone, I understand that when we set the WAN zone to "REJECT," the packet goes back to the sender, which adds extra load on our low-power routers. In contrast, when we "DROP" the packet, it is simply eliminated and discarded, which doesn't overload the CPU. By this weekend, I'll be testing the tips from @brada4 and @moeller0, and once the tests are complete, I will share my experiences with my router.
4o mini
I would certainly try to confirm that hypothesis though, dropping packets makes things harder to debug if debugging in needed, and in spite of common believe otherwise, dropping packets dies not make you invisible from the internet. ISPs tend to give differential responses depending on whether an IP is assigned to a customer of whether it is not in use... so "stealth mode" is not really stealthy... all default drop does is making it harder to fingerprint the router OS...
Wan forward reject generates spoofed reset/unreach.
Yes? My point is that such responses can help in debugging connectivity issues and are generally not a real security risk. Whether the generation of these responses is too costly (or costly enough to matter) is not clear a priori. That is why I would always test whether setting this to drop has a noticeable effect on 'performance'.
Just diagnostically - where would you forward them....
Where would I forward what? Any probe from the outside is likely to receive an explicit response (be it RST flag or a ICMP unreachable message) which makes it easier to debug things, compared to a drop, where it is hard to discern between the system is operational and drops the packet as requested versus the system is borked (misconfigures firewall) and does never even process the packet in question. And in fact it is this explicit pretty unambiguous response that some argue is a downside of REJECT as this e.g. speeds up port scanning as no/fewer retries are needed.
1 Like
See https://github.com/openwrt/openwrt/issues/13340
i.e if your provider is city-block-wide ethernet it causes problems (not yielding any benefit whatsoever.
1 Like