Server Tick Rate and Hardware: Choosing 20, 30, 64, or 128 Tick Without Overspending

Server tick rate is treated as a feature badge, but on real hardware it is a budget. Every tick, the simulation loop must read inbound packets, step physics and game logic, resolve collisions, run anti-cheat heuristics, and build an outbound snapshot for every connected player. Spending more of that budget than your single-thread clock can actually sustain produces the exact symptom players hate: rubber-banding and inconsistent hit registration during fights.

The Per-Tick Budget, In Milliseconds

Tick rate is simply the inverse of your time budget. The lower the budget, the less slack you have for garbage collection pauses, disk stalls, and OS scheduling jitter. That is why the same hardware that holds 64 tick comfortably can fall apart at 128 tick under a full roster.

Tick rate	Budget per tick	Typical fit	Headroom needed
20 tick	50 ms	Survival, sandbox, MMO, 64+ slots	Low
30 tick	33 ms	Casual shooters, large lobbies	Low-moderate
64 tick	15.6 ms	Competitive FPS, ranked play	Moderate
128 tick	7.8 ms	Tournament and scrim hardware	High

A useful rule: target a sustained frame time no higher than 60–70% of the tick budget. If a 128 tick server needs to hold 7.8 ms, you want the worst-case simulation step closer to 5 ms so a garbage collection pause or a disk flush does not blow through it. Servers that run hot with no margin are the ones that stutter whenever a player throws an ability or a chunk loads.

Why the Single-Thread Clock Sets the Ceiling

Most game engines run the main simulation loop on one thread. The snapshot and replication work can sometimes be parallelised, but the core simulation is serial. That means the sustained clock of one physical core — not your total core count — sets the hard ceiling on how many ticks per second you can guarantee. A chip advertised at 3.7 GHz that thermally throttles to 2.9 GHz under continuous all-core load is delivering an effective budget roughly 22% tighter than the box claims.

This is why two servers with identical CPU model names can perform very differently: one is in a chassis with adequate airflow and a power profile that holds boost, the other is not. Before you raise tick rate, verify that the node holds its boost clock for a full hour under the simulation load, not just in a 30-second benchmark. See our guide to dedicated hosting hardware for the checks worth running before you rent anything.

Packet-Rate Math to Do Before Choosing

Bandwidth scales roughly linearly with tick rate and player count, because each tick produces a state snapshot per player. The figures below are order-of-magnitude outbound estimates for typical snapshot compression; voice chat can add another large chunk on top.

Scenario	Approx. outbound	Notes
32 players @ 64 tick	6–12 Mbps	Mostly sustained
32 players @ 128 tick	12–25 Mbps	Doubles replication load
128 players @ 64 tick	25–50 Mbps	Before voice traffic
128 players @ 128 tick	50–100 Mbps	Competitive-scale, rarely worth it

The point is not the exact figure. It is that tick rate is a network and CPU decision at the same time. Doubling tick rate roughly doubles per-player replication cost while the number of players stays fixed — so the penalty lands hardest on populated servers.

Symptom-to-Cause Table

What players report	Likely cause	Fix
Rubber-banding in fights only	Tick overrun under load	Lower tick or cap players
Constant high ping for everyone	Routing or uplink saturation	Investigate the link, not the tick
Inconsistent hit registration	Snapshot rate too low	Raise tick on a stronger core
Spikes every few minutes	Disk I/O or GC pauses	Move saves to NVMe
Stutter when new players join	Map/asset transfer burst	Rate-limit downloads, isolate traffic

Note that the most common complaint — high ping — is usually not a tick rate problem at all. Raising tick rate cannot fix a saturated uplink or bad routing; it only makes both worse by adding traffic.

The Mod and Plugin Multiplier

Modded and plugin-heavy servers change the equation because they add work to the same serial simulation loop. A paper or fabric Minecraft server, a heavily modded ARK cluster, or a FiveM server with a large resource pack all execute extra per-tick logic that a vanilla benchmark never sees. A server that held 64 tick cleanly on vanilla can miss ticks on the same hardware once thirty plugins are loaded.

The lesson is to benchmark the real configuration. Strip your mod list to the ten heaviest additions, measure frame time with a full roster, and add them back until the 99th percentile approaches your tick budget. That gives you the true slot ceiling for your specific setup rather than a vendor’s empty-server number. If the ceiling turns out to be unsatisfyingly low, the fix is a higher sustained single-thread clock, which is a hardware decision more than a software one.

How to Choose Your Tick Rate

Log frame time, not average FPS. You need the worst-case simulation step, not a smoothed mean. Track the 99th percentile.
Measure with a full roster. Empty-server benchmarks are meaningless; load the server to your target slot count with realistic behaviour.
Set tick to the highest value your worst case sustains with margin to spare, then stop.
Prefer clock over cores. A 6-core CPU at 4.5 GHz sustained will out-tick a 32-core CPU at 2.4 GHz for a serial simulation loop.
Only go to 128 tick with proven headroom. If your 64 tick p99 is already near budget, do not.

A 64 tick server that never misses a tick beats a 128 tick server that stutters every team fight. Choose the rate your hardware can actually afford at peak, then invest the leftover budget in fast NVMe storage and network quality — those are the things players feel in the moment. If you are still deciding where to run the server, review dedicated server options sized for gaming and prioritise sustained clock speed over headline core counts.