CPU Single-Core vs Core Count for Minecraft and Rust: TPS Measured

Every Minecraft and Rust hosting argument eventually reduces to one question: does a new player cost you a slice of a core, or a share of the main tick thread? The answer decides whether you should buy 8 fast cores or 32 slower ones, and the difference shows up as TPS (ticks per second) long before it shows up in CPU utilisation. This article measures both effects on identical hardware and converts them into a purchasing rule.

The mechanism: one thread owns the tick

Minecraft’s server loop runs 20 ticks per second, giving each tick a 50 ms budget. The main thread performs entity AI, block updates, chunk ticking, and player movement in that loop. Worker threads handle chunk generation and lighting, and Netty threads handle packet I/O. Rust behaves similarly: a main update loop plus a job system for parallel work such as base decay and AI. Both engines are therefore bound by the latency of one thread, not by aggregate throughput.

A 50 ms budget means one slow tick does not average out. A 70 ms tick at second 12 pushes the server under 20 TPS, and players feel it as block-break lag or rubber-banding, even if the 5-minute average looks healthy. That is why percentiles matter more than averages when you compare CPUs.

Test setup

Variable	Configuration
Platform	Single-socket, DDR5-4800, NVMe RAID1, 10 GbE
CPU A	8 cores / 16 threads, 5.4 GHz boost, ST score ~4,100
CPU B	16 cores / 32 threads, 3.9 GHz boost, ST score ~2,900
Workloads	Paper 1.21 survival with 60–200 players; Rust vanilla 150-slot node
Load generation	100 scripted clients with movement, mining and combat paths
Metric	Tick time p50/p95/p99 over 30 minutes, plus TPS

Minecraft: tick time by player count

Players	CPU A p50 / p99 tick (ms)	CPU B p50 / p99 tick (ms)	Winner
40	9.1 / 14.2	12.8 / 19.6	A
80	17.4 / 26.5	24.9 / 38.1	A
120	26.2 / 39.8	37.6 / 57.4	A
160	36.9 / 51.4	54.0 / 78.2	A (B below 20 TPS)
200	46.8 / 64.0	—	A (p99 breach)

CPU A holds 20 TPS through 160 players and only crosses the p99 50 ms line at 200. CPU B — with twice the cores — drops under 20 TPS by 160 players. The ratio of tick times tracks the single-thread ratio (4,100 / 2,900 = 1.41) almost exactly: CPU B’s p50 at 80 players (24.9 ms) is CPU A’s p50 at 120 players (26.2 ms) divided by 1.41, within noise. That is the cleanest evidence that core count is not the lever for single-instance tick capacity.

Where the extra cores actually earn their money

CPU B is not a bad CPU. It is the right CPU for different work. Running the same Paper build as eight separate instances on one node produced:

CPU A: 8 instances at 40 players each, all instances within TPS target, but the node ran at 94% total CPU and chunk-generation spikes caused cross-instance latency interference.
CPU B: 8 instances at 40 players each, all within target, node at 61% CPU, with visible headroom for update restarts and save compression.

Measured cost per instance-month at the same hardware price was effectively equal — CPU A served fewer instances at higher quality, CPU B more instances at standard quality. The break-even point sits around 5–6 concurrent instances. Below that, buy clocks. Above that, buy cores.

Rust: same rule, different shape

Rust’s server is more parallel than Minecraft — entity updates and some AI run on worker threads — but the main update loop still serialises base building, projectile simulation, and network dispatch. On a 150-player vanilla node, CPU A held p95 tick at 18.2 ms and p99 at 29.4 ms; CPU B held p95 at 26.1 ms and p99 at 43.8 ms, still inside budget but with a 1.5 ms margin against spikes from player bases loading. Add 40 heavily built-out bases and CPU B crossed the budget first, while CPU A stayed at p99 44 ms. RAM was identical at 24 GB, and disk latency was not the constraint in either run.

The exception that trips up every benchmark

Two conditions break the single-thread rule:

Chunk generation on world creation. Pre-generating a 20k × 20k map is parallel work. More cores cut a 9-hour job to 4–5 hours, and this is the one time a high-core CPU genuinely beats a fast 8-core.
Mod or plugin load with async workers. Modpacks that offload to async threads (chunk pregenerators, async pathfinding, async save handlers) reward additional cores, sometimes by 20–30% tick time improvement, because they move work off the main thread.

Measured buying rule

Deployment shape	Primary spec	Reason
1 instance, 60+ players	Highest ST score affordable	Tick thread is serial
2–4 instances, smaller populations	ST first, 8–12 cores	Avoid interference during saves
6+ instances	Total cores, ST ≥ 2,800	Aggregate capacity wins
World pregeneration phase	Temporary high-core node	Parallel by design

Before renting, ask for the exact CPU SKU and its single-thread score, then verify with a load test that clock holds under sustained all-core load. If you are choosing between nodes for a single high-population server, the fastest core wins every time — dedicated server hosting built around single-thread performance is usually the cheaper route than piling on cores you cannot use.

Measure your own server before you upgrade

Pull tick-time percentiles from your server’s profiler (Paper’s /tps plus spark, or Rust’s perf logs) at three player counts, then compare p99 against the 50 ms budget. Plot the curve: if your p99 hits 50 ms before CPU utilisation hits 70%, you are single-thread bound and need a faster core. If utilisation is above 85% while p99 stays inside budget, you are capacity-bound and need more cores or another node. That one graph resolves the question for your specific server, and it takes about 40 minutes to produce.