What tick rate actually means, and why your server feels slow

When somebody says the server is lagging they mean one of four unrelated things, and three of them are not the server. Tick rate is how often the server advances the world. Ping is how long a packet takes to reach it. Frame rate is the player's own graphics card. A periodic hitch is usually the disk. Each has its own number, each has a different fix, and the whole job of a lag investigation is deciding which number to look at before you spend money. This post is how to read all four, with the actual commands per game.

What a tick is#

A game server runs a fixed-timestep loop. It wakes up, reads everything that arrived from clients since last time, advances the simulation by one step, sends each client what changed near them, then sleeps until the next step is due. One pass is a tick. The rate is how many it is supposed to do per second, and the budget is the wall clock time it is allowed to take.

budget per tick = 1000 ms / target tick rate20 ticks/s  -> 50.0 ms per tick   (Minecraft)50 ticks/s  -> 20.0 ms per tick   (many Unreal servers)64 ticks/s  -> 15.6 ms per tick   (Counter-Strike 2)128 ticks/s ->  7.8 ms per tick   (competitive Source servers)

If a tick finishes in less than its budget, the server sleeps and nobody notices. If it takes longer, the next tick starts late and every subsequent one inherits the debt. What players see depends on the engine. Minecraft slows the world down: the day gets longer, furnaces smelt more slowly, mobs move in slow motion, and everything stays internally consistent because the whole simulation is stretched. Shooters usually keep real time and drop information instead, so the world stays the right speed but updates arrive less often and hit registration gets vague.

Two consequences worth keeping in mind. First, the effect is global and even - when tick rate falls, it falls for everyone at the same moment by the same amount. A complaint from one player while nobody else notices anything is never a tick rate problem. Second, the budget is a wall clock number, so anything that blocks the main thread spends it: a garbage collection pause, a synchronous disk write, a plugin doing a database query inline. Those are not CPU shortages, and buying a faster CPU will not fix them.

Tick rates by game#

A few of these need the footnote. Counter-Strike 2 runs a 64 tick server but timestamps player input to the moment it actually happened between ticks, which is what "sub-tick" means - it removes most of the advantage 128 tick servers had in CS:GO, and it is why the old argument about tickrate matters less in CS2 than people arriving from the previous game expect. Source games set their rate at launch with -tickrate, and changing it changes movement physics, so a 100 tick server is not simply a smoother 66 tick server.

Valheim is the outlier and worth understanding because it explains a whole class of confusing reports. The server stores the world and relays state, but each zone is simulated by the first player who entered it. There is no single server tick to read, and one player on a bad connection makes the world wobble for everyone standing near them. That is covered in the Valheim dedicated server guide.

Reading the number#

Never diagnose from a player's description. Get the number.

Minecraft, Paper or Spigot. /tps prints the one, five and fifteen minute averages, capped at 20. It is a lagging indicator: a server that spiked to 300 ms for one tick still reads near 20. Paper's /mspt is the better number, because it shows the actual tick times over the last five seconds, ten seconds and one minute, with an average and a worst case.

> /msptServer tick times (avg/max) from last 5s, 10s, 1m:◴ 41.2/188.9, 38.7/188.9, 22.4/241.6

Read that as: normally fine, but something is occasionally costing nearly a quarter of a second. An average under 50 with a huge maximum is a spike problem - a chunk generating, a world save, a plugin on a timer - and it needs a profiler rather than a bigger plan. Vanilla 1.20.3 and later added /tick query, which prints the same idea, plus /tick freeze, /tick step and /tick sprint for debugging.

Minecraft, any version, when you need the cause. Install spark. /spark tps gives tick rate and CPU use per thread; /spark profiler start samples the server for a period and produces a web link showing which method is eating the tick. That link is the difference between guessing and knowing, and reading a spark profile goes through one line by line.

Source games. stats in the server console prints a row including the server's FPS, which is its tick rate, plus CPU use and bandwidth. status lists players with their ping. Both are console commands, so they work over RCON.

> statsCPU    NetIn   NetOut  Uptime  Maps   FPS      Players12.40  0.9     4.7     412     3      66.14    18

Unreal servers. Squad prints its tick rate in the server browser. Other Unreal-based games expose a server FPS value in their console or admin tools. In all of them, the number falling as the server fills is the normal, expected shape, and what you are judging is where it lands at peak.

Everything else. If the game does not expose a tick counter, the substitute is the CPU graph. A game thread pinned at its limit while memory stays flat is a server that is out of tick budget, whatever the game calls it. Reading a server load graph covers the shapes.

Ping is a different number entirely#

Ping is the round trip between one player and the server. It is a property of the path between two machines - distance, the route, the quality of each hop - and the server has almost no influence over it. No amount of memory, CPU or NVMe changes a player's ping.

The diagnostic is trivial: look at everybody's ping at once. If one player is at 180 ms and the rest are at 30, that player has a network problem and the server is fine. If everybody jumped by the same amount at the same moment, something changed on the server's side of the network, which is a different and much rarer thing.

Three numbers hide inside "ping" and they are not interchangeable:

• Latency is the average round trip. High but steady latency is playable; games are built to hide a constant delay.
• Jitter is the variation. 60 ms of latency that swings between 40 and 200 feels far worse than a flat 120, because the client's prediction is wrong by a different amount every frame.
• Packet loss is updates that never arrive. Even 1% is visible as rubber-banding, because the client has to guess and then correct.

Latency, jitter and packet loss explains how to tell them apart, and reading traceroute and mtr is how you find which hop is responsible. The short version: run an MTR from the complaining player to the server for a few minutes, and look for the first hop where loss starts and stays.

Interpolation, prediction and lag compensation#

Understanding these three explains most of the arguments about tick rate, and explains why a higher number buys less than it sounds like it should.

Interpolation. Your client does not draw other players where the last snapshot put them. It draws them slightly in the past, between the last two snapshots it received, so that movement is smooth instead of teleporting on each update. The cost is a fixed delay, typically two ticks' worth. At 64 tick with two ticks of interpolation that is about 31 ms of built-in delay; at 128 tick it is about 16 ms. That 15 ms difference is the real prize in the 64-versus-128 argument, and it is a good deal smaller than the marketing suggests.

Prediction. Your own movement is simulated locally the instant you press a key, and corrected if the server disagrees. This is why your character feels responsive at 120 ms ping while everyone else looks delayed.

Lag compensation. When your shot arrives, the server rewinds other players to where they were at the moment you fired, based on your latency, and judges the hit against that. This is why you get hit behind cover: on the shooter's screen you were not behind cover yet. It is not a bug and it is not tick rate; it is the deliberate trade that makes shooters playable across a continent.

Older Source games let you tune your side of this with rate, cl_updaterate, cl_cmdrate, cl_interp and cl_interp_ratio, bounded by the server's sv_minrate, sv_maxrate, sv_minupdaterate and sv_maxupdaterate. Counter-Strike 2 removed most of that in favour of automatic rates and sub-tick timing, so advice copied from a 2016 CS:GO guide will not apply. Check what your specific game still accepts before pasting a config from the internet.

Frame rate is the client, and it is not your problem#

Frame rate is the player's own machine drawing the world. It has nothing to do with the server, which is worth establishing before somebody upgrades a plan to fix it. A player reporting stutter while the server console is quiet, the tick time is under budget and everyone else is happy is describing their graphics card.

Two things muddy this. First, players genuinely cannot tell the difference between a 25 fps client and a 15 TPS server from the inside; both look like the world lurching. Second, a low frame rate does slightly affect the server, because a client rendering at 20 fps sends its input less often and its own actions arrive late. That is a small effect and it harms only that player.

The test that settles it in ten seconds: ask them whether the frame counter in their own game is high while things feel wrong. If frames are at 144 and the world is lurching, it is the server. If frames are at 22, it is not.

Telling the four apart#

The regular freeze deserves a mention because it gets misdiagnosed constantly. Most games write the world to disk on a timer, and on a large world that write can block the main thread for a second or more. It looks like a tick problem and it is a storage problem. What NVMe actually changes covers which operations that helps and which it does not.

What actually raises tick rate#

In order of how much they usually help, and how much they usually cost:

1. Do less work per tick. Fewer entities, a smaller view or simulation distance, fewer scripts on short timers, fewer loaded chunks or zones. This is free and it is nearly always the biggest win. For Minecraft that means Paper's optimisation settings; for other games it means the equivalent knobs in their configs.
2. Find the one expensive thing. Most lag has a single cause: one plugin, one mob farm, one chunk with ten thousand items in it. A profiler finds it in minutes. Replacing the server does not.
3. Faster single-core CPU. Almost every game server simulates on one thread, so clock speed sets the ceiling. More cores help everything around the simulation and do not raise that ceiling.
4. Remove the blocking work. Synchronous disk writes, a database query on the main thread, a garbage collection pause. These show as huge maximum tick times with a normal average, and they are fixed by configuration, not hardware.
5. Fewer players. Unpopular, effective, and honest. A 60-slot server that holds its rate is better than a 100-slot one that does not - see how many players fit on a server.

What does not help: more memory on a server whose memory graph is flat, NVMe on a CPU-bound server, and a different data centre for a problem that is not the network. CPU or RAM is the thirty-second version of that triage, and why TPS drops and what to do is the Minecraft-specific deep dive.

The bandwidth cost of a higher tick rate#

Tick rate is also a bandwidth setting, which is rarely mentioned. The server sends each player a snapshot per tick, so doubling the rate roughly doubles outbound traffic.

per-player downstream ~= snapshot size x tick rate200 bytes x 64 ticks/s  = 12.8 kB/s   per player200 bytes x 128 ticks/s = 25.6 kB/s   per player32 players at 128 tick  ~= 820 kB/s out, sustained

Those are illustrative figures - real snapshot size varies with the number of visible entities - but the shape is right, and it explains why a 128 tick server with a big player count needs an uplink it can rely on rather than one it shares. It also explains why raising tick rate on a server that is already near its CPU limit makes everything worse: you have doubled both the compute and the network cost of exactly the thing that was already late.

FAQ#

Is 20 TPS bad?

No. 20 is Minecraft's maximum and its normal state. TPS is capped at the target rate, so 20.0 means healthy and anything below means behind. The equivalent healthy reading in a 64 tick shooter is 64, not 20 - the numbers are not comparable between games.

Does a higher tick rate reduce my ping?

No. Tick rate changes how often the server updates you; ping is how long the update takes to travel. A 128 tick server on another continent will feel worse than a 64 tick server nearby. The only thing tick rate removes is a few milliseconds of interpolation delay.

Why do I die behind cover?

Lag compensation. The server rewound the shooter's view to the moment they fired, and at that moment you were visible on their screen. It is deliberate: the alternative is shooters having to lead every target by their own latency. Higher tick rates narrow the window slightly but never close it.

My server shows 20 TPS but players say it lags. What now?

Look at maximum tick time rather than the average. /mspt on Paper, or a profiler on anything else. An average of 20 ms with a peak of 400 ms is a server that freezes briefly and often, and TPS averaged over a minute hides that completely.

Will upgrading my plan fix low TPS?

Only if the plan's CPU share is what is limiting you, and only when the new plan has faster cores rather than more of them. Check the CPU graph against the limit first. If the graph is not at the limit, something on the main thread is blocking, and more CPU buys nothing.

Does tick rate affect how much RAM I need?

Barely. Memory is driven by how much world and how many entities are loaded, not by how often they are updated. Tick rate is a CPU and bandwidth setting.