Hi! Recently I got OpenWrt running on my Linksys E8450, but despite having a gigabit fiber internet connection (actual speeds are usually about 500 Mbps for either upload or download), I'm having issues with online gaming, and sometimes even watching livestreams. The issue was not present on my previous non-OpenWrt router, which was only slightly weaker in overall hardware performance than the E8450. With either gaming or livestreams, despite being on wired gigabit ethernet (not Wi-Fi!), every few minutes or so, there would be what appears to be (but I'm not sure if it actually is) MASSIVE ping spikes and/or packet loss.
For example, when playing Team Fortress 2, I would repeatedly teleport back to where I was a second ago, yet all the players around me seem to be moving along just fine. Something similar happens in Final Fantasy XIV, but since it only uses TCP instead of UDP, it's even worse (maybe it keeps on retrying?): everything just stops for a few seconds, then things move for just a second, then stops for a while, that cycle repeats for half a minute or so, then it's back to normal.
This is such a bizarre issue to me, I just have no clue what the cause is, especially after everything I've tried. I've tried SQM QoS (which AFAIK isn't supposed to be useful on such a fast connection), reducing firewall rules, enabling packet steering (which I would think isn't very useful on the E8450's dual-core CPU), and even replaced some Ethernet cables, and none of it has helped.
The WAN connection is IPv6-only, but with a DS-Lite connection over it to allow access to the IPv4 internet. I can't tell if the DS-Lite connection is part of the issue, though. The DS-Lite connection on the previous router was working just fine.
I suggest that you test with setting CAKE at 10Mbit/s upload and download. You can try running a ping test and saturating the upload and download and monitoring for RTT increases. The adaptive rate project, although not designed to be used for fixed bandwidth connections could be leveraged to help see what's going on with your connection since it monitors RTT with a very high frequency and plots it out to log file together with load etc.
Either with or without CAKE (I'm assuming you're talking about SQM QoS using the "cake" queue discipline), there aren't any significant changes in RTT, only changes in speed to around what I specified.
Also, because of the behavior I observed:
when playing Team Fortress 2, I would repeatedly teleport back to where I was a second ago, yet all the players around me seem to be moving along just fine.
I'm fairly certain that the router and therefore my PC is receiving packets from WAN just fine, while there's something wrong with sending from my own network to whatever it is on the internet. It's pretty inconsistent though. It seems like it could happen at random while those applications are running, and I can't reliably reproduce the issue with iperf3 to servers (which are at least as fast as my internet connection) on the internet.
Good news! I think I figured it out. The firewall configuration wasn't accepting IPv4 ICMP packets at all from WAN, save for echo requests I think. I changed the rules to accept any type of IPv4 ICMP packet from WAN, both forwarded and input, and we've had a fast and rock solid connection over the last 24 hours or so. Perhaps information needed to maintain the connection wasn't getting across from the other end...
I did also enable MSS clamping for both of the firewall zone configurations, but considering that UDP connections were also affected, I doubt it had much effect. Probably doesn't hurt to enable it anyways though, especially since the DS-Lite connection does some encapsulation.
I won't mark this as solved quite yet, as I want to make sure it's actually fixed over the next few days or so, then I'll reply again with an update.
Alright, we haven't had any issues at all since then, so I think it's safe to say the problem has been solved.
Also, it might be worth noting that shortly after adding the IPv4 ICMP filters, I changed them to only allow ICMP types 0, 3, 8, 11, and 12, as well as rate limiting those to 1000 packets per second, and it has been working fine as well.