Best setting for FLINT 2 - gaming

Hello everyone, thank you in advance for your support and advice.
I need help optimizing my Flint 2 router for console gaming.
I have a 2.5 GIGABIT connection and I’ve already configured SQM, achieving an A+ rating.
Could you give me some tips on how to further optimize the connection? I’m still experiencing some issues with smoothness during online gameplay.

Are you sure the issue is on your side and not the side of the game host/servers? What kind of things are you seeing that need correcting? Latency spikes? Something else?

1 Like

Geomate - Geographic Game Server Filter for OpenWrt might be worth checking out.

With 2.5 GHz ISP connection there is not much tweaking need from your side. Your firsthop to ISP will likely never be the bottleneck. The trouble is further away in the internet data flow.

You might use LuCI statistics (or some other tool) to monitor latency "ping" to both the ISP next routers (can be found via traceroute) and to some popular local site just to see if the ISP connection is stable. Just to verify that there are no frequently repeating problems in the next few connection from you.

E.g. latency from my own MT6000 to my old ISP's switch (so going from my current ISP to the next one), the latency with 600 Mbit/s connection is steadily just ~1 ms. (most 0.8-1.1 ms, sometimes a spike of 1.5 ms, but never 20-30 or 100 ms)

And you might also read this story, which mostly talks about game-specific latency...

Once you are in the mercy of global routing, there is not that much you can do that would concretely help you in optimising routing.

In online console games, I notice increased latency and micro-lag. Also, the gameplay feels noticeably less smooth

This is my buferbloat test, with SQM

You see the 1/10th 1/20th outliers, while you worked areound nearby bufferbloat there is something shared in between with bloated buffers shared by many that only your provider can fix.

1 Like

Brada4 is highlighting a common but often misunderstood issue: your packets do reach their destination, and tests may show a decent final latency, but they’re getting delayed along the way, in ways that are not immediately visible.

Think of it like driving through several roundabouts on your way to work. You still get to the office (no packet loss), but on some days, you’re briefly held up at every roundabout. You’re technically on time, but the trip was less smooth and less predictable.

In online gaming, this kind of variable delay (jitter)—even without any packet loss—is enough to desynchronize your actions. You shoot, you block, but your real position is no longer in sync with what the server sees.

Brada4 suspects this is a case of bufferbloat upstream, possibly at the DSLAM level (in the case of a G.fast line), and outside the user’s control.
He points out that even with an A+ bufferbloat score, the reported latency values are too clean to be fully trusted, which is itself suspicious.

Bottom line: this isn’t a problem inside your home network.
it’s a delay upstream, caused by how your ISP handles shared traffic.
And that’s something only your provider can fix.

1 Like

Thank you very much robert for your clear explanation. Could you tell me what to tell my operator so that he can make the correct corrections regarding this problem?

If I were in your shoes, here's what I would do.

Until you say otherwise, I am going to assume your "operator" is a friend who is running a respectable ISP from which you subscribe to receive your service.

If I'm the operator of the ISP, I'm going to need to know some things:

  • What kinds of troubleshooting have you done, customer?
  • Have you confirmed the latency is not on your LAN side of the connection?
  • What times of day does this occur? Specific times or all times of the day?
  • Do you have data and/or charts you can show to visualize the issue you're claiming?
  • Does it happen when connected to a single host/service or is it multiple hosts/services?
  • Have you confirmed if those hosts/services have any known issues or degradations?

I think you probably get the picture there. So how can you provide such data? Well, a couple tools can help.

  • Traceroute: Run some traceroutes to IPs or FQDNs (which will translate to IPs) of the gaming service(s) you utilize. That can help show both the path your traffic is traversing from point A to point B. It can also show which hops incur the most latency, or abnormal amounts of latency, from your packets' perspective.
  • Ping: "ping" is a pretty simple tool on the surface and is quite ubiquitous these days. By itself, it is not going to show where along the way your packets are encountering issues from point A to point B, but it can be helpful to show that it's happening along with when it happens. Both can be valuable data points.
  • SmokePing: This is more of a tool than a concept, as it uses the same principle as "ping" under the covers. But basically this is a free tool you can set up to have a service which checks connection quality to a remote host on a recurring schedule. This allows for you to better visualize the latency you think you're feeling so that you can truly know it's occurring and could be something you share with your ISP.

There are other tools that can do more and in much greater detail--even the tools listed so far have a lot of additional options most people won't use much of the time. But they would be my starting point to confirm what you perceive is occurring and give you some data to start backing up any claims you make to your ISP. Most ISPs are going to have a pretty hard-nosed stance that it is not their issue, it must be on your side. So be ready to defend your position and go on the offensive with data in hand.

If you can convince the ISP of the issue and back it with proof, the burden will be on them to pursue troubleshooting on their side, should they choose to comply. It could be there is some bad BGP peering going on along the packets' path. It could be there are some intercontinental traversals the packet is subject to. Hard to say without data. So there is your mission, IMHO, get hard data. :wink: