Tick rate and the main thread: why game servers want clock speed

Twelve players on a Minecraft server, and something is off. Mobs stutter, crops take forever, the day seems to drag, and yet the control panel says the processor is 18% busy and every player's ping is fine. Nobody is attacking the server, and nothing is wrong with the network.

The number that explains it is not on the control panel: 50 milliseconds. That is how long the server has to work out everything that happens in the world before the next step is due, and on most game servers that work happens on a single thread. That budget, and the single thread that spends it, explain most game server lag and why a faster core fixes it where more cores do not.

A world that moves in fixed steps

According to the Minecraft Wiki, almost every game runs as one large loop, and each pass round it is a tick.²A game server is that loop with nobody watching. It takes the players' input, advances the world by one step, tells the players what changed, and goes round again. It draws nothing; the simulation is the whole job.

The important word is fixed. A game could measure how long its last step took and advance the world by that much, but Glenn Fiedler's well-known article on game loops explains why that goes wrong: a physics simulation behaves differently depending on the step size it is fed, and with large or uneven steps springs explode, fast objects pass through walls and players fall through the floor.¹ His answer is to advance the simulation only in steps of one fixed size, so real time is consumed in whole steps. A fixed step is also what makes exact reproducibility possible, where the same inputs give the same result on every run.¹

On a server, a fixed step means a fixed rate. Minecraft runs at 20 ticks per second, one every 50 milliseconds, and an in-game day is exactly 24,000 ticks, which is 20 minutes of real time.² Valve's Source engine simulates in 15 millisecond steps by default, about 66.7 ticks a second. Each tick, the server works through the commands players sent, steps the physics forward, applies the game's rules and updates every object; only then does it work out which clients are due a new snapshot of the world.⁶

When a tick's work is done early, the server waits. The spark profiler's documentation gives the example of a Minecraft tick that takes 15 milliseconds, after which the loop sleeps for 35 before starting the next; without that sleep the game would run faster than intended.⁷ The illustration at the top of this page shows both cases: ticks that finish early and sleep, and ticks that never get to. The healthy durations in it are invented.

The budget: one second divided by the tick rate

The time a server has for each tick is 1,000 milliseconds divided by the tick rate. At 20 ticks a second that is 1,000 ÷ 20 = 50 milliseconds. At Source's default it is 15 milliseconds by definition. Counter-Strike 2 runs at 64 ticks a second (Valve's list adds "with Sub-tick"), a rate Valve later fixed so servers cannot change it, which leaves 1,000 ÷ 64 = 15.6 milliseconds. Community servers for its predecessor commonly ran at 64 or 128, and at 128 a tick gets 7.8.⁶

Everything that happens in the world has to fit inside that number, on every tick, on the server's hardware. Choosing a tick rate is therefore choosing how much work each step can afford. Valve states the trade directly: raise the tick rate and the simulation gets more precise, but server and client alike need more processor time and more bandwidth.⁶ Doubling the rate halves the time per tick and doubles the number of ticks, so a server that was comfortable at 64 has to do each step of the same world in half the time at 128.

Tick rate is not the update rate

Two other rates get mixed up with the tick rate. The update rate is how often the server sends a player a snapshot of the world. In Source the client asks for one with cl_updaterate, 20 a second by default, and the server never sends more snapshots than it simulates ticks. The command rate is how often a client sends its input, usually 30 packets a second, each carrying input sampled at the server's tick rate.⁶

None of these rates changes how long a tick may take. They change how often its result travels, and how long it takes to travel is a matter of distance and routing, which the guide to server location and latency covers.

What fills the 50 milliseconds

The Minecraft Wiki lists what the Java Edition server does in each pass of its loop, in order.²Condensed, a tick runs the scheduled block and fluid ticks (a redstone repeater changing state and water that needs to flow both ask for these), then ticks every chunk near a player, which is where mobs spawn and where random ticks make crops grow and leaves decay. Then come block events, every entity, the block entities such as hoppers, and finally the players' network traffic: queued packets sent and incoming ones handled. Every 6,000 ticks, which is five minutes at 20 ticks a second, the tick also autosaves the world. Then the loop waits for the next tick.²For a mob, being ticked means running its AI and working out a path.⁷

The durations in the drawing are made up. What drives the cost of a tick is less the number of players than what is loaded and running around them. The wiki's list of usual suspects is hoppers that keep checking for items above them, redstone that causes floods of block and light updates, large numbers of mobs and their AI, and a raised random tick speed.² Ten players standing at spawn keep one patch of the world busy. Ten players spread across the map, each beside an automatic farm, keep ten patches busy, and the server ticks all of them on every tick.

That points to a setting worth knowing in server.properties. simulation-distance, 10 chunks by default, is the radius around each player within which living entities are updated at all.³ Lowering it shrinks every player's patch, and with it the work in every tick.

Why it all runs on one thread

A Minecraft server does use more than one thread, but the tick is not one of the things it spreads out. PaperMC's troubleshooting guide names the tick loop as a major source of load and notes that it runs on one thread,¹¹ and spark's documentation says a slow tick delays the next one because ticks cannot run in parallel.⁷ The Minecraft Wiki's hardware page puts a number on the rest: the other work spreads onto extra cores, but rarely more than three of them.⁵

Everything in a tick reads and writes the same world. A mob's path depends on the blocks around it, a hopper's contents depend on what the hopper above it did a moment earlier, and a redstone circuit depends on the order its parts update. That order is part of the game's rules: the wiki documents that scheduled block ticks run by priority and then in the order they were scheduled, with particular priorities for repeaters and comparators.² Spread that work across threads and you either lock the shared data, which costs time, or let the result depend on which thread got there first, which breaks the machines players build.

Even work that looks independent can refuse to go faster. Factorio's developers once tried updating trains, the electric network and belts in parallel, three parts of their game that barely interact. The parallel version was slower than the original, because threads writing to memory that shared the same cache kept invalidating each other's copies.¹⁶

It can be done, at a price. Folia, a fork of the Paper server, splits the loaded world into independent regions of neighbouring chunks, each with its own tick loop, and runs them in parallel on a pool of threads, so no single main thread is left.¹⁴ Regions that touch must merge into one,¹⁵ so the design pays off on servers where players naturally spread out, such as survival and skyblock, with a sizeable crowd. The README's author expects every existing plugin to need changes and suggests at least 16 cores.¹⁴ When everyone gathers in one town, the regions around them merge, and that town is one thread's work again. The Minecraft Wiki warns that projects like this are complex and prone to bugs.⁵

The drawing shows a trap that catches many owners. PaperMC notes that on a machine with many cores, a server held back by its tick loop can show little CPU use compared with what the machine has.¹¹ One thread running flat out on an 8 vCPU server is 100 ÷ 8 = 12.5% of the machine. The control panel sees an idle box; the players see lag.

When a tick runs long

A tick that overruns is not cut short. It finishes, and the next one starts late. spark's documentation describes it as everything shifting to the right: fewer ticks fit into each second, and the game becomes less responsive.⁷ Because the game counts time in ticks rather than seconds, the world itself slows down. The Minecraft Wiki notes that nearly everything in the game is timed in ticks, so when TPS falls it all takes longer.² Crops, mob movement and the day cycle all run late together.

Fiedler's article names what happens when a loop tries too hard to catch up: the spiral of death. If simulating a stretch of game time takes longer than that stretch of real time, the loop falls behind, runs extra steps to catch up, and falls further behind.¹ He offers two ways out. Leave headroom, so the simulation normally needs much less time than it has and can catch up after a spike, or cap the number of steps and let the game run slower while the load lasts.¹ Minecraft does a version of the second: the first thing its loop does is reset the schedule if the server has fallen two seconds behind, rather than chase ticks it can never make up.²

If one tick runs long enough, the server assumes it has hung. The vanilla watchdog, set by max-tick-time, stops the server once a single tick has taken 60,000 milliseconds, with a log line that reads "A single server tick took 60.00 seconds (should be max 0.05)".³ Paper prints a thread dump after 10 seconds without a response, and its documentation says this is a warning of severe lag, not a bug or a crash. The top of that stack trace shows where the main thread was stuck.¹¹

Slow ticks and spikes are different problems

A server can lag in two ways. When every tick is a little too slow, TPS sinks and stays down. When most ticks are fine and a few take hundreds of milliseconds, TPS hardly moves and players still see freezes. spark's example is a server that spends 20 milliseconds on most ticks and occasionally 300 on one, which averages out to a healthy-looking number.⁷ Spikes are usually caused by something players did, and they need their own tools to catch.⁹

A worked example: the evening the tick hit 62 milliseconds

Take a survival server that runs at 20 TPS through the afternoon with an average tick of 28 milliseconds. It sleeps for the other 22, which is 44% of every tick, well above the 20% below which spark's documentation says a server is working hard.⁷ In the evening twice as many players are online, spread out across the map, and two new mob farms are running. The average tick rises to 62 milliseconds. The numbers are invented; the arithmetic is not.

At 62 milliseconds a tick the server completes 1,000 ÷ 62 = 16.1 ticks a second instead of 20, which is the bottom row of the illustration at the top of the page. An in-game day of 24,000 ticks now takes 24,000 ÷ 16.1, about 1,490 seconds, or just under 25 minutes instead of 20. The autosave every 6,000 ticks comes round every 6 minutes 12 seconds instead of every 5.² Everything in the world runs at about 81% speed.

The budget for one tick at 20 TPS

50ms

The evening tick in this example

62ms

What the server manages: 1,000 ÷ 62

16.1TPS

The length of an in-game day

24.8min

Now compare what each fix does to that 62 millisecond tick.

Only the last row gets back to Fiedler's headroom.¹ A server that just fits its budget on an ordinary evening has nothing left for the moment twenty players fight a raid in the same place. Aim for an average tick that leaves a clear margin, and treat the speed of one core and the amount of work in the world as the two levers you actually have.

The spike that TPS hides

Now a different second on the same server. Nineteen ticks take 30 milliseconds each and one takes 400. The server needs 19 × 30 + 400 = 970 milliseconds for all 20, so it still completes 20 ticks in the second and reports 20 TPS. The average tick is 970 ÷ 20 = 48.5 milliseconds, under the budget. Yet for 400 milliseconds, eight ticks' worth of time, nothing in the world moved. Only the maximum tick time, or a high percentile, gives it away.

Measuring tick health

Ticks per second (TPS) says whether the server kept up. Milliseconds per tick (MSPT) says how close it came, which makes it the more useful number: a server can only hold 20 TPS while each tick takes 50 milliseconds or less on average.²⁸ spark reports MSPT as a minimum, a median, a 95th percentile and a maximum, and the last two are where spikes show up.⁸

For spikes, the order matters. Run the tick monitor first: with --threshold-tick 50 it reports every tick over 50 milliseconds, the point at which the server starts catching up or lagging. Once you know how long the bad ticks are, start the profiler with --only-ticks-over set a little below that, so it records only the slow ticks and the normal ones cannot average the spike away.⁹

$ spark tps$ spark tickmonitor --threshold-tick 50$ spark profiler start --only-ticks-over 150 --timeout 600

In a profile, the time the server thread spends waiting for the next tick is its sleep. spark's rule of thumb: under 20% sleep, the server is working hard; under 5%, it is probably lagging already and has nothing in reserve.⁷

Seeing the main thread from Linux

Outside the game, top shows the same picture if you ask it for threads. The -H option lists every thread on its own line instead of adding them up per process, and -p limits the view to the server's process.¹⁷ On a server that is out of tick time, one line sits near 100% while the others idle, just as in the thread drawing above.

$ pgrep -f 'paper.*\.jar'48211$ top -H -p 48211

If MSPT is healthy and players still complain, the tick is not the problem. Look at the path between them and the server instead, and keep in mind that a flood aimed at a game server feels like lag from the player's side too; the guide to why game servers get DDoS attacks explains why they are a favourite target.

What it means for choosing a server

The people who maintain the server software give the same advice. PaperMC says that past a certain point more cores bring no benefit, so look for strong single-thread performance, with no fewer than four threads for the server.¹¹ The Minecraft Wiki also asks for strong single-core performance, and notes that the server rarely keeps more than three cores busy.⁵

Single-thread performance is the clock speed multiplied by how much work a core gets done per clock, helped by how often it finds its data already in cache. How those fit together, and why a boost clock describes one core rather than all of them, is covered in vCPU vs CPU core. The consequence for a game server is simple: of two processors, the one that runs a single thread faster runs your tick faster, whatever their core counts.

The other thing a tick needs is not to wait. On a VPS your vCPUs are scheduled onto physical cores shared with other guests, and a vCPU that is ready to run can wait for a core while someone else's work finishes, which Linux reports as steal time (the guide to what a VPS is shows how). Every one of those waits lands inside some tick and comes out of its budget. Cores allocated to you remove the wait, which matters most on a server whose tick is already close to its limit.

Put together, sizing a game server goes in this order:

• The main thread first. Pick for the fastest single core you can get, not the largest core count.
• Then enough cores for the helpers. Networking, loading and saving chunks, plugins and the operating system need their own. For Minecraft that is the three or four the documentation above describes, and a second server on the same machine needs its own set.
• Cores that do not wait. If the tick is near its budget at busy times, allocated cores protect it from other people's peaks.
• Headroom for the busiest evening. Size for the raid, not the average, and keep MSPT well under the budget.

The Minecraft calculator suggests a plan for your player count, and the server calculator covers other games. FiveM and RedM are sized differently, so there is no rule of thumb for them here: use the FiveM calculator.

Mistakes that cost ticks

Whatever dashboard you check, put MSPT and its maximum on it, not total CPU use.