Lag: Difference between revisions
finishing the page
(CPU load issues part 1) |
(finishing the page) |
||
Line 50:
== 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:
<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 ==
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.
| |||