In the video, you can clearly see abnormal behavior โ it feels like hit registration and responsiveness are completely off, even though my connection appears stable. I've already tried many things: router configuration, port forwarding, traffic prioritization, and even testing with different ISPs and setups.
I'd really appreciate it if someone with more experience could take a look and give me advice or ideas on what might be going wrong. Any suggestions or insights are welcome.
Sometimes this can be out of your control (if the problem is related to upstream latencies), but we should review your configuration first.
What is your internet connection type (cable, dsl, fiber, cellular, satellite)? What is the speed tier you are promised from your isp (upload and download speeds).
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
I understand that my aim may not be pixel perfect, but please take a look at the measurements shown in the video. Despite that, the enemy still kills me, which makes me believe there is an issue with hit registration or latency.
Iโd appreciate if you could review this aspect carefully.
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
Posting videos of a video game doesn't communicate the 'feeling' because we're not able to experience the practical latency of your key press-to-action.
There's nothing in your config that looks unusual or out of sorts. You said that you've already got SQM enabled and that you're not seeing any bufferbloat... how did you tune and verify that?
Assuming that your computer isn't part of the problem, there isn't all that much else inside your network environment that can be done beyond using Ethernet and SQM, as the latency is often determined by factors outside your control. Two of the biggest considerations will be the performance of your ISP and the distance to + performance of the remote server (and its ISP). Assuming no major issues/congestion between your connection > ISP + internet > server, the distance will be the biggest factor... so a player who is very near to the server will often have an advantage over those who are more distant.
You didn't answer this -- pretty important question:
Beyond that, have you tried other servers (specifically, those that are very close to you)?