Server Tick Rate Configuration for Competitive FPS: CPU Budget Math and 64 vs 128 Tick Thresholds

Tick Rate Is a Budget, Not a Setting

Most guides tell you to set sv_tickrate 128 and move on. That instruction ignores the fact that tick rate is a hard CPU budget: each tick the server runs the full simulation for every player, every entity, and every networked prop. Doubling the rate doubles that cost and halves the time available to finish one step. This is a concrete configuration guide: what to measure first, the exact cvars, and the hardware thresholds where 128 tick stops being free.

The two numbers that decide whether your box can hold a given tick rate are single-core clock speed and packets-per-second filtering capacity — both are broken out in the dedicated server comparison.

The Arithmetic: What One Tick Costs

A 64-tick server has 15.625 ms of wall time per step. A 128-tick server has 7.8125 ms. The simulation, entity updates, and network receive/transmit must all complete inside that window; anything left over is deferred and shows up as tick variance. Measure with stats on a Source 2 server or net_graph 1 plus server-side frame timing.

Player count 64 tick bundle (Source 2) 128 tick bundle (Source 2) Overhead ratio
5v5 competitive (10) ~1.8 ms ~3.4 ms 1.9×
10v10 (20) ~3.1 ms ~6.0 ms 1.9×
16v16 casual (32) ~4.9 ms ~9.6 ms 2.0×
32v32 with vehicles ~9.2 ms ~18.4 ms 2.0×

Read the last row carefully. A 32v32 server at 128 tick needs 18.4 ms of simulation per step but only has 7.8 ms. That is a guaranteed overrun: the server runs at effectively 40-55 tick under load and players feel worse registration than a clean 64-tick server. Tick rate does not fail loudly; it fails as rubber-banding.

Hardware Thresholds That Actually Hold 128 Tick

Holding a stable 128 tick requires single-thread performance above a floor, because Source, CS2, and most FPS engines are only lightly multithreaded for the simulation step. Observed thresholds on bare metal:

  • 5v5 competitive (10 players). A modern 4.5-5.0 GHz desktop-class core (Ryzen 7 7800X3D or Xeon E-2488) holds 128 tick with p99 tick time under 8 ms. This is the only scenario where 128 tick is reliably free.
  • 20-32 players. You need a 5.0+ GHz core and dedicated (not shared) CPU time. A 128-tick 32-slot server on a shared vCPU will jitter; on bare metal with isolcpus isolating the game thread, it holds.
  • 64+ players. 128 tick is not viable at any price point with current engines. Run 64 tick and spend the margin on bandwidth and anti-cheat instead.

One more variable: X3D CPUs carry a large L3 cache (96-128 MB on modern parts) that noticeably reduces tick-time variance at high player counts, because the simulation working set fits in cache. If you are choosing hardware specifically for 128-tick servers, a cache-heavy CPU beats a higher-clock CPU with a small cache.

Configuration: The Settings That Matter

Tick rate is set at startup, not through a live cvar. On a Source 2 dedicated server this is a +sv_tickrate 128 launch argument; in CS2 the active tick rate is fixed by the game mode, and the value you control is sv_maxrate and the tickrate flag in the launch line. The settings that actually change perceived quality:

# Launch line, 24-slot competitive CS2 server
./game/bin/linuxsteamrt64/cs2 -dedicated \
  +sv_tickrate 128 \
  +sv_maxrate 0 \
  +sv_minrate 128000 \
  +sv_maxcmdrate 128 \
  +sv_mincmdrate 64 \
  +sv_maxupdaterate 128 \
  +fps_max 0 \
  -port 27015

Set fps_max 0 on the server. A server capped at 64 or 128 FPS forces the simulation loop to align with the render loop and adds up to one full tick of latency. Uncapped, the loop runs as fast as it can and the tick scheduler hits its target more consistently. Watch CPU headroom when you do this — uncapping raises average load by 20-35% on a busy server.

Also set sv_minrate to 128000 on competitive servers. The default allows clients to request a low update rate, and a client at 64 updates per second on a 128-tick server receives no benefit from the higher rate while still costing the server to simulate.

How to Verify Your Tick Rate Holds

  1. Connect a full server and run stats (or your engine’s equivalent) while all players move and shoot.
  2. Record tick time for 10 minutes at peak. You want p99 under the tick budget (7.8 ms at 128 tick), not just an average under it.
  3. If p99 exceeds the budget, lower the tick rate one step before buying more hardware. Reducing 128 → 96 or 64 recovers roughly 35-50% of simulation time for no cost.
  4. Only after the tick rate is right should you upgrade CPU. A correctly sized 64-tick server feels better than an overloaded 128-tick server in every competitive test.

If you are moving off shared hosting to get dedicated CPU time for 128-tick servers, a price-locked dedicated machine is the cheapest way to guarantee the clock speed and isolation you need. InterServer dedicated servers keep the same monthly price for the life of the plan, and promo code TRYINTERSERVER drops the first month to $0.01 for benchmarking your real tick-time p99 on bare metal.

Leave a Reply