Benchmarks That Predict Game Server TPS: Single-Thread Share, Tick p99, NVMe QD1, and Jitter

Generic benchmark suites measure the wrong things for game servers. A Geekbench multi-core score of 40,000 tells you nothing about whether a Minecraft world with 9000 entities holds 20 TPS, and a CrystalDiskMark sequential figure of 7 GB/s tells you nothing about the 40-microsecond saves that occur between ticks. What predicts player experience is a narrow set of numbers: single-thread share, tick-time p99, NVMe queue-depth-1 latency, and jitter under fractional load.

This article defines each metric, gives the pass threshold, and builds a weighted rubric you can apply to any candidate machine. The thresholds assume you benchmark on the actual node rather than a spec sheet, so provision the box first and treat the dedicated game server hardware listed with measured clock and NVMe details as the pool of candidates to test.

Single-thread share is the first-order predictor

Take the Cinebench R23 single-core score and divide it by the multi-core score. The result, expressed as a percentage, is the single-thread share. On a 32-core EPYC 7543 with a 1380 single and 24,000 multi, the share is 5.8%. On an 8-core 4.7 GHz part with 1900 single and 15,000 multi, it is 12.7%. Higher is better for game servers because simulation runs on one or two threads.

Any machine below 7% share will struggle with a 48-slot survival world regardless of its total score. The underlying reason is that game logic is not parallelized, so the multi-core score adds nothing but heat and power draw. Rank candidates by single-core score first, then use the share to filter out parts that only look fast because they have 64 cores.

Tick-time p99, not average tick time

Average tick time hides the spikes players actually feel. Run a load test at 85% of target player count for 30 minutes and record the 99th percentile of tick duration. For a 20 TPS Minecraft server the budget is 50 ms, so p99 should stay under 35 ms with an average under 22 ms. Averages of 18 ms with a p99 of 70 ms mean a visible stutter roughly every 500 ticks.

Measure with the server’s own timing output where possible, and a pinned sampling loop otherwise. Tick p99 is the single metric that correlates most tightly with player complaints about “random lag,” because it captures the tail that averages erase.

NVMe queue-depth-1 latency decides save-freeze length

Game servers issue small, synchronous writes and reads during saves, map transitions, and database commits. That is a queue depth of 1, not 32. Use fio with a 4K block, iodepth 1, and single job to measure this directly. The pass threshold for a survival server is 120 microseconds at p99 and 250 microseconds at p99.9.

• fio --name=qd1 --rw=randread --bs=4k --iodepth=1 --numjobs=1 --size=4G --runtime=60 --percentile_list=99:99.9
• Enterprise TLC with power-loss protection typically lands at 75-110 µs p99.
• Consumer QLC drives often show 800 µs to 2 ms p99, a 10-20x gap.

A drive can score 6 GB/s sequential and still fail this test. Autosave freezes are a QD1 latency problem, not a bandwidth problem, which is why swapping a fast drive in for a slow one sometimes fixes stutter that earlier hardware changes did not.

Jitter under fractional load

Benchmarking an idle machine is easy and nearly meaningless. Run your real workload at 60% CPU and measure the standard deviation of tick completion times across 5000 ticks. Jitter, expressed as the coefficient of variation, should sit under 8% for competitive shooters and under 15% for survival games. Above those numbers the server feels inconsistent even if no single tick exceeds budget.

Jitter often comes from CPU frequency transitions and interrupt handling rather than raw throughput. Setting the scaling governor to performance and pinning the game thread away from the interrupt-handling core typically cuts jitter by 30 to 50% on the same hardware. That is free performance, and it is invisible to synthetic tests.

Memory bandwidth per active slot

World streaming and mod loading are memory-bandwidth heavy. Measure with STREAM triad on the populated node and require at least 45 GB/s per socket on DDR4-3200 eight-channel and 70 GB/s on DDR5-4800 twelve-channel. Below 35 GB/s, chunk loading on a Valheim or 7 Days world becomes the dominant cost during player travel.

Divide sustained bandwidth by active slots as a sanity check. A 20-slot modded world consuming 60 GB/s is 3 GB/s per slot, which is normal. If a candidate machine shows 1 GB/s per slot and rising tick times during travel, memory is the floor, not the CPU.

Network path quality under load

Run 200 concurrent synthetic sessions and measure round-trip jitter with a ping loop every 100 ms for 10 minutes. The p99 should not exceed the idle p50 by more than 3 ms. Also watch for retransmits at the NIC: more than 0.05% on a healthy path indicates a duplex mismatch or congested uplink rather than a game-side problem.

Test during the target region’s peak hour, not at 04:00. A path that shows 4 ms p50 and 9 ms p99 at noon can show 6 ms p50 and 40 ms p99 at 21:00 on an oversubscribed switch, and that is the number your players will report.

Scoring rubric and pass bands

Weight the metrics by how much they move player experience: single-thread share 30 points, tick p99 25 points, NVMe QD1 p99 20 points, jitter coefficient 15 points, network jitter 10 points. Full marks at the pass threshold, half marks at the warn line, zero below. A usable game node scores 70 or more.

Apply the rubric before you commit to an annual contract. It takes about 40 minutes of testing and it filters out the machines that will generate tickets for the next twelve months, regardless of what the invoice says about core count.

Interpreting a score before you buy

A score of 85 means the node clears every threshold with margin and will absorb one content patch. A score of 72 means it works today but has no room for a heavier modpack or a player surge. Anything under 65 will pass a smoke test and fail on a Friday night, and no amount of tuning recovers single-thread share or QD1 latency.

Run the same rubric against the dedicated servers built for sustained game workloads and keep the test scripts, because re-running them after every hardware change is how you catch a drive swap or a noisy neighbour before players do.