You can't reduce ping in Minecraft

Having optimum ping to your Minecraft server is a goal that many server administrators strive for. But believe it or not, it's very difficult. In this post I will discuss why you can't reduce ping in Minecraft.

Why can't it be done?

I'll explain each of these, but the reasons boil down to state and networking (network latency and the Minecraft protocol).


Minecraft's design inherently forces each server to have an extensive amount of state. That includes players, entities, and chunks. This is just vanilla; modified servers keep even more state! Due to conflicting ways of saving state, synchronizing it all is extremely difficult to the point that you'd probably need to design all of your infrastructure to support it from day one. Most server administrators don't have that kind of money or capabilities to do that.

However, you can create a Minecraft server with ephemeral Minecraft state. This is how the large minigame networks can have geographically-distributed servers.


There's two main causes to look at here, but it ties in with the Minecraft protocol.

First off, let's get something out of the way. The Minecraft protocol is poorly designed. While Mojang has corrected some of the egregious mistakes, they have overall expressed little interest in improving the protocol and network handling code, which were both last revamped in 1.7 (with a new protocol and networking based on Netty, which for the record is an excellent non-blocking I/O library for Java). However, this post is not intended to bash about how poorly designed it is overall, only to look at how some design decisions affect lag.

Minecraft uses TCP in order to communicate with servers. TCP is meant to be a reliable protocol, at the sacrifice of performance. Most games, on the other hand, use UDP, intended for high performance at the sacrifice of reliability. This has important consequences for latency, in that Minecraft only processes packets when it knows that it has received them correctly. This can cause lag, especially if that network is spotty and high-latency (think satellite and cellular networks).

Low latency is very important on the network side, but what about the network handling code? As it turns out, Minecraft's network handling code is also quite problematic. Minecraft will tend to process and tick player actions as they are received. There is also no lag compensation included in the protocol. This means that strategic "relogging" and (paradoxically enough) lag can help a player gain an edge over others in PvP, for instance.

Now we turn our attention to what is perceived by some as being able to reduce lag: tunnelling, BungeeCord behind BungeeCord, or two geographically distant BungeeCords connected through RedisBungee. This only works when players do not have good routes to your server. I will quote a post I made on the Spigot forums to this effect. It concerns OVH specifically, but it's not specific to them.

Reread my post: it only works if the user's route is bad. For instance, assume a hypothetical user on a typical cable connection in metro Atlanta (that's me!) who wants to connect to your OVH server. I get ~108ms to OVH RBX, so we'll roll with that.

Now let's say you choose a VPS for tunnelling. Let's say it's in New York. My ping to a New York VPS is 37ms. I'll take @RSNET-Radic's 70ms NYC->RBX measure, as I'm now travelling across something that's not my cable connection. Not including other stuff that might happen on that VPS, my effective latency is ~107ms - virtually the same as connecting to your server in France. It also turns out that my traffic stops in New York before heading across the ocean to Europe when I connect to your OVH server directly, so this step is redundant!

You also need to take into account other things, like connectivity. OVH has excellent connectivity due to their presence in public exchanges (they can peer with many ISPs "for free") and a wide network that aims to accept users at the nearest PoP. Also, bad peering is not very common in North America and Europe, making this even more redundant.

Basically, it works when the majority of players do not have a good route to your server, but this is rare if you are hosting in North America or Europe.

So, what are my choices?

  • Stateless hosting. This is only practical for stateless servers, like minigames servers. In this case, you'd create a separate network with its own servers. This is the approach the big minigame networks take.
  • Locate servers closer to your main player base. You can't possibly achieve minimal lag to every player on your server, so you will have to improvise by making sure that the majority of your player base has good latency. If your player base is primarily in New York, for instance, hosting in New York would be the logical choice.