MSPT vs TPS: what the numbers mean and what is normal

What is the difference between MSPT and TPS?

TPS is an average rate and MSPT is an average duration of the same thing. The spark docs say TPS "reports how many ticks on average are being processed by the game each second", with 20 as the target, and MSPT "reports how many milliseconds on average is taken by the game to process each tick", with 50 or fewer as the target. spark's tick loop guide explains the link: a tick that finishes early sleeps for the remainder, and a tick that runs long delays the next one, because "ticks cannot execute in parallel".

The relationship is arithmetic. One second holds 1,000 ms, so 1,000 divided by 50 gives 20 ticks. If ticks averaged 60 ms, the server could finish at most about 16.7 per second (1,000 / 60).

Paper's commands reference says /tps covers the past 1, 5 and 15 minutes and /mspt shows average, minimum and maximum over the last 5, 10 and 60 seconds, both "superseded by the /spark command". Paper has bundled spark since 1.21 and calls it "the preferred way to profile Paper" (profiling docs). On NeoForge, /neoforge tps prints the mean tick time and TPS for each loaded dimension (source code).

Is low TPS the problem, or is it the client or network?

Rule out the other two kinds of lag first, because only server lag shows up in MSPT. GameServerKings, a hosting seller, draws the split this way in its diagnosis guide (updated 12 Sep 2026), and XGamingServer, another seller, gives the same three types. The ping command is in spark's command docs.

Why watch MSPT instead of TPS?

TPS stays at 20 until the average tick passes 50 ms, so it hides how close you are to the edge. A server averaging 45 ms per tick shows 20 TPS with little room left. Space-Node and MamboServer both make that point, and neither gives a measurement. spark's lag-spike guide calls 50 ms "the point at which the server has to start catching up, or lagging".

How do you read the spark numbers?

Read the distribution, because an average can look healthy while a few slow ticks ruin play. /spark tps gives the minimum, median, 95th percentile and maximum MSPT. spark's lag-spike guide says spikes happen "when a small number of ticks (or sometimes just one tick) takes a long time to execute", and that in ordinary profiling "all the other samples will 'cancel out' the spike".

The median is the typical tick, the 95th percentile is the tick time that 19 of every 20 ticks stay under, and the max is the single worst tick in the window. Space-Node, a hosting seller, calls the 95th percentile "the useful column"; that is its opinion, not a spark rule.

Inside a profile, the server thread's sleep share is a second gauge. spark's tick loop guide calls about 80% sleep "healthy", says below 20% the server "might be lagging on some ticks" and below 5% it "is probably lagging, and has no spare capacity". It warns "these values are averages", so a spiky server can look fine.

What is a normal MSPT for a modded server?

There is no official normal beyond 50 ms. Paper's reference says MSPT "should be below 50 for 20 TPS", and neither Paper's nor spark's documents give a figure for modded servers, a given modpack or a player count.

spark's colours are the closest thing to a scale. Its formatter source, read on 8 Nov 2026, paints a tick time red at the game's ideal duration and yellow from 80% of it, which is 50 ms and 40 ms at 20 TPS. TPS is green above 90% of target and yellow above 80%, so above 18 and above 16. That is a display choice in the code, and spark's docs do not present it as a standard.

Publishers give other bands. None is a standard, and each row carries its own caveat.

Your pack, loader, world and players decide where your limit sits, so the useful number is your own baseline. Record the median, 95th percentile and max with your usual group online, then change one thing at a time. How to benchmark your own game server lays out the method.

GameServerBench plans to publish annotated spark exports from its own runs. No test server exists yet and nothing has been measured, so this page has no example numbers of its own.

What should you do with a bad reading?

Capture it while the problem is happening, because Paper says "the issue you are diagnosing must be actively occurring" for profiling to work. Decide whether it is a spike or steady load using the table above, follow the biggest percentage in the profile, fix that one thing and measure again. ATM10 server lag and high MSPT applies this to one pack. If long ticks line up with collections in /spark gc, see Java flags for modded servers.

Three readings send people the wrong way:

• High memory use. Paper's troubleshooting page says that without out-of-memory crashes or bad collection times, "high memory usage is expected".
• Low CPU on a lagging server. GameServerKings says the tick loop is one thread, so a panel can show low total CPU while that thread is full.
• /tick rate. GameServerKings warns that lowering it slows the game itself and is no performance fix.

Do other games use TPS and MSPT?

Not under those names. Palworld's REST API reports serverfps ("The server FPS") and serverframetime ("Server frame time (ms)"), and Pocketpair's metrics page lists no tick-rate field or official threshold. The idea is the same, a rate and a time per update, and target values differ by game. For Palworld specifics, see Palworld server lag and memory leak.

Next step: pick one repeatable activity, capture a ten-minute spark profile and keep the median, 95th percentile and max. Then return to the guides hub for the pack or game you run.