Lag: Difference between revisions
(CPU load issues part 1) |
(finishing the page) |
||
Line 50: | Line 50: | ||
== CPU load issues == |
== CPU load issues == |
||
The CPU load on the server can be responsible for some latency. To understand it, let's talk about the unit time used internally by minecraft: the tick. The game is designed in such way that 1 second corresponds to 20 ticks. So a tick is corresponding to 0.05s, or 50 ms. So each tick cycle, the game computes what needs to be computed within those 50ms. If it is faster than 50 ms, the game will idle until it reaches 50 ms. What's annoying is when the game needs to compute during more than 50ms to finish the tick. It causes the game to run less ticks per second (TPS). This is an handy metric to discuss the lag of the server, but practically the tick time is measured in ms, then a formula is used to convert it in TPS: |
The CPU load on the server can be responsible for some latency. To understand it, let's talk about the unit time used internally by minecraft: the tick. The game is designed in such way that 1 second corresponds to 20 ticks. So a tick is corresponding to 0.05s, or 50 ms. So each tick cycle, the game computes what needs to be computed within those 50ms. If it is faster than 50 ms, the game will idle until it reaches 50 ms. What's annoying is when the game needs to compute during more than 50ms to finish the tick. It causes the game to run less ticks per second (TPS). This is an handy metric to discuss the lag of the server, but practically the tick time is measured in ms, then a formula is used to convert it in term of TPS: |
||
<math>TPS(x) = \begin{cases} 20 & \text{if }x < 50\text{ ms} \\ 20\times \frac{50}{x}, & \text{if }x\geq50 \text{ ms} \end{cases}</math> |
|||
So even with the best connection in the world, if your server is slowing down, you'll feel the lag. For large packs such as GT:NH, lag is unavoidable, the more you progress, the more you need to learn about tricks to avoid lag. Devs do what they can to mitigate the issue, but it's not easy to just get ride of the unecessary CPU load. |
|||
== bug in mods == |
== bug in mods == |
||
Network handling in mods can sometimes cause desync or artificial latency. If you made sure it's none of the sources of lag above, feel free to open a ticket on the GT:NH bug tracker, we will gladly help you to hunt down the bug. |
|||
== Troubleshooting the lag sources == |
|||
=== Ping and Packet loss === |
|||
==== Command line tools ==== |
|||
* To monitor the ping, you can open terminal and use the following command `ping -t <your server ip or domain name>`. This will continuously check send ping requests to the server. |
|||
* To get the detailed route your packets are following to reach the server, run `tracert <your server ip or domain name>` on windows, or `traceroute <your server ip or domain name>` This will give you the nodes your traffic is going through, as well as your ping between you and them during the traceroute. Handy to find if there is a troublesome node ruining your traffic. If you see some nodes being named `*` it's normal, some nodes are configured to ignore ping requests (what does the traceroute behind the scenes) for security or performance reasons. |
|||
* on Linux, you can install MTR, for Matt's TraceRoute, it's a tool being a bit more precise than ping+traceroute combo, as it also gives the packet loss rate to each node. to use it, simply run `mtr <your server ip or domain name>` |
|||
==== Softwares ==== |
|||
[[File:WinMTR interface.png|alt=The interface of WinMTR|thumb|The interface of WinMTR]] |
|||
* On windows, you can use WinMTR, it's basically an interface for the MTR program. Nodes configured to ignore ping requests will always labeled with a packet loss rate of 100% and this is normal. |
|||
=== Server load === |
|||
For tracking down the server load, you can use tools such as [[Opis]] to profile stuff in game, such as what dimension is lagging, how many entities there are, what chunk is heavily loaded, what block generate lags, etc. You can also use profilers such as [[Warmroast]] or [[VisualVM]], which will display what part of the code is executed the most. |
Revision as of 19:51, 7 August 2023
Lag is something everyone has experienced in minecraft. This page will help you to understand it better and to diagnose it.
Here is a breakdown in possible sources of lag:
- bad ping
- packet loss
- CPU load (TPS)
- bugs in mods
Ping issues
Ping is a metric giving info about how long it takes for a network packet to go from your computer to the server, or vice versa. It is expressed in miliseconds (ms), and the lower it is, the faster it is to talk with the server. (or you are getting closer if the propagating medium didn't change).
Before digging more into networking stuff, let's talk about how is structured internet as a whole. It's mainly composed of:
- routers (or nodes)
- endpoints (servers or clients)
- connections between all those equipments (or links). The place where you plug a link to a router or an endpoint is called an interface.
A sub network of internet with the same policy for routing is called an Autonomous System (AS).
A ping measure follows these steps:
- measuring the time just before sending a "hello" packet
- sending a "hello" packet to the server
- waiting for a "hello" packet from the server
- measuring the time at the arrival of the packet
- computing the delta and dividing it by 2 (because of the round trip)
Inside a router, here are the following source of delays
- delay of arrival (time of propagation through the medium in the input link)
- delay of buffering in the input buffer (fixed by hardware)
- delay of processing (influenced by the global load of the router, such as other services or other interfaces being busy too)
- delay of buffering in the output buffer (fixed by hardware)
- delay of departure (time of propagation through the medium in the output link)
Also, a router is supposed to find the fastest path for routing your packets. For that, some routing algorithms are used, and usually, the route with the least amount of hops is prefered (a hop is a jump to one node to another). The issue is that between 2 AS, there can be what is called an administrative distance. It's simply a faked metric for routing algorithms, and it can impact greatly the routing. It is done by companies or governments for various reasons. Due to that, the fastest route will sometimes appear as the slowest route, causing your traffic to go through a longer route, increasing your ping.
There is also the fact that routers can sometimes become unavailiable (broken link, overloaded router, power failure, etc). When a router did not contacted its neighbors after some times, the neighboors will remove the faulty router from their routing table, which causes your route to be deviated.
To sum thing up, your route is evolving over time, and can be impacted, independantly from you, the server, or your ISP.
Packet loss issues
To convey your network packets over internet, there are two big protocols encapsulating your data: TCP and UDP. TCP is used when an application must transmit data with integrity (packet ordering, reemision of lost packets, etc), and UDP is used when an application must transmit data as fast as possible (streaming for instance). Minecraft uses TCP, because the game requires to process correct information and in the correct order to synchronise the client with the server.
A packet can be lost because of external reasons (router going down, etc), but also on purpose by the routers. In networking, equipments must be as fast as possible, so this translates into doing the least work possible. If the input buffer or the output buffer is full but a packet is incomming, instead of waiting, or asking for a resend of the packet to the previous router, the router will do the least work possible, which is trashing the packet. The integrity checks are delegated to client and server.
Packet loss does not impact your ping per se, but a too high rate of packet loss will cause you to feel a bigger latency than what the ping displays. And this is normal. Let's assume a ping to a server of 50 ms. The client initiate a TCP connection with the server, and start sending data to the server. After each block of data sent, the client will ask if the server got them, if not, the client reemit the packet, and ask again if the server got it. The client will keep emiting the packet until the server tells the client it got it. But each time, the data took 50 ms to be transmitted, so the higher is the amount of reemission, the bigger will be the difference between the latency displayed by the ping and the perceived latency in game.
In short, packet loss can increase your latency, no matter how good your ping is.
CPU load issues
The CPU load on the server can be responsible for some latency. To understand it, let's talk about the unit time used internally by minecraft: the tick. The game is designed in such way that 1 second corresponds to 20 ticks. So a tick is corresponding to 0.05s, or 50 ms. So each tick cycle, the game computes what needs to be computed within those 50ms. If it is faster than 50 ms, the game will idle until it reaches 50 ms. What's annoying is when the game needs to compute during more than 50ms to finish the tick. It causes the game to run less ticks per second (TPS). This is an handy metric to discuss the lag of the server, but practically the tick time is measured in ms, then a formula is used to convert it in term of TPS:
So even with the best connection in the world, if your server is slowing down, you'll feel the lag. For large packs such as GT:NH, lag is unavoidable, the more you progress, the more you need to learn about tricks to avoid lag. Devs do what they can to mitigate the issue, but it's not easy to just get ride of the unecessary CPU load.
bug in mods
Network handling in mods can sometimes cause desync or artificial latency. If you made sure it's none of the sources of lag above, feel free to open a ticket on the GT:NH bug tracker, we will gladly help you to hunt down the bug.
Troubleshooting the lag sources
Ping and Packet loss
Command line tools
- To monitor the ping, you can open terminal and use the following command `ping -t <your server ip or domain name>`. This will continuously check send ping requests to the server.
- To get the detailed route your packets are following to reach the server, run `tracert <your server ip or domain name>` on windows, or `traceroute <your server ip or domain name>` This will give you the nodes your traffic is going through, as well as your ping between you and them during the traceroute. Handy to find if there is a troublesome node ruining your traffic. If you see some nodes being named `*` it's normal, some nodes are configured to ignore ping requests (what does the traceroute behind the scenes) for security or performance reasons.
- on Linux, you can install MTR, for Matt's TraceRoute, it's a tool being a bit more precise than ping+traceroute combo, as it also gives the packet loss rate to each node. to use it, simply run `mtr <your server ip or domain name>`
Softwares
![The interface of WinMTR](http://static.miraheze.org/gtnhwiki/thumb/c/c7/WinMTR_interface.png/300px-WinMTR_interface.png)
- On windows, you can use WinMTR, it's basically an interface for the MTR program. Nodes configured to ignore ping requests will always labeled with a packet loss rate of 100% and this is normal.
Server load
For tracking down the server load, you can use tools such as Opis to profile stuff in game, such as what dimension is lagging, how many entities there are, what chunk is heavily loaded, what block generate lags, etc. You can also use profilers such as Warmroast or VisualVM, which will display what part of the code is executed the most.