128-Tick vs Rollback Netcode: 2026 Performance Cost Benchmark

You’re in a firefight. You peek, fire, and start moving back behind cover. Then the game freezes for 50 ms as a shader compiles. When the picture catches up, you’re dead.

That moment has nothing to do with whether the server runs at 60, 100, or 128 ticks. A 128 Hz server advances simulation every 7.81 ms, but it can’t repair a client hitch, poor prediction, excessive interpolation, or a correction that arrives too late.

That’s the central trade-off in 128-tick vs rollback netcode. Faster simulation can reduce timing error, but it’s only one part of the experience. Prediction, reconciliation, frame pacing, hit validation, and deterministic replay often offer a better return for the next engineering dollar.

Key takeaways

• Tickrate matters when timing errors are measurable under real entity and player loads.
• Rollback can make combat feel immediate, but it requires reproducible simulation and CPU headroom.
• A 50 ms client hitch is more damaging than several milliseconds of server-side improvement.
• Most competitive games benefit from server authority, client prediction, and selective rollback rather than choosing one networking model.

What 128 Tick Actually Buys

A server tick is the interval between authoritative simulation updates:

Moving from 60 to 128 Hz reduces the simulation interval by about 8.86 ms. That can help when two players fire or cross a hitbox near the same instant. It doesn’t mean the entire game responds in 7.81 ms.

The client may sample input at a different rate, send commands less often, interpolate remote players, and render a state that is already several milliseconds old. A 240 FPS client also has a 4.17 ms frame budget, but server ticks and client frames are separate clocks.

Valve’s Source networking documentation describes 66.67 Hz as a traditional 15 ms timestep and discusses the higher CPU cost of 100-tick simulation under its tested conditions. That comparison is useful directionally, not as a universal multiplier: entity behavior, physics, scripting, and engine implementation all change the result.

A simple planning model is:

Simulation work ≈ tickrate × active simulation cost

The important qualification is “active simulation cost.” Twenty players aren’t equivalent to twenty physics-heavy vehicles. A projectile, AI agent, destructible object, and dormant networked prop can each impose very different workloads.

Bandwidth may not double with tickrate, either. If snapshot and input rates are decoupled from the simulation loop, the server can simulate at 128 Hz while sending network updates at a lower cadence. The CPU still has more simulation work, but packet volume may remain largely unchanged.

For a competitive game, benchmark:

• Hit-registration disagreements
• Input-to-confirmation time
• Correction distance
• Server frame-time p95 and p99
• CPU headroom during peak fights
• Snapshot loss and interpolation delay

If those values don’t improve, extra ticks are an expensive specification-sheet feature.

Rollback and Client Prediction Solve Different Problems

The phrase rollback netcode vs client-side prediction suggests a choice that most production games don’t actually make. They commonly use both.

Client prediction lets the local player move, aim, and shoot without waiting for server confirmation. The server remains authoritative and sends a correction when the predicted state differs from the approved one. Interpolation smooths remote players, while lag compensation can evaluate actions against the shooter’s recent view of the world.

Rollback addresses a different problem. The game stores recent state, rewinds to an earlier point when late input arrives, applies that input, and re-simulates the affected frames. This is especially effective when the relevant state is small and deterministic, as in many fighting games.

A 100 ms rollback window requires approximately:

The number of steps isn’t the whole cost. Replaying 13 lightweight player-movement steps may be cheap. Replaying 13 frames containing physics contacts, AI decisions, destruction, animation events, and inventory side effects can consume substantial CPU and produce inconsistent results.

That distinction should shape the architecture. A shooter might roll back player positions, aim state, and weapon traces while leaving large-world physics on the forward simulation path. Rewinding the entire world is much harder to make stable and much more expensive to test.

Rollback also creates a determinism project:

• Random streams need stable seeds.
• Side effects must not fire twice.
• Physics results need to be reproducible enough for replay.
• Object ownership changes need explicit rules.
• Late joins and resynchronization need dedicated handling.

Instrument rollback frequency, replayed steps, replay CPU time, post-replay divergence, correction distance, and abandoned resynchronizations. A system that technically rolls back but produces visible teleports has not solved the player’s problem.

Frame Pacing Can Beat a Faster Server

A game running at 140 FPS on average can still feel broken. If a new weapon effect triggers a 50 ms shader or pipeline compilation hitch, the player experiences a long freeze during the exact moment where timing matters most.

This is why higher tickrate vs better frame pacing is often a false budget fight. A player can’t benefit from a 7.81 ms server interval while the client stops rendering for 50 ms.

DirectX 12 and Vulkan give developers more explicit control over pipeline creation, but that control makes first-use compilation a shipping responsibility. PC hardware, drivers, vendors, settings, and feature combinations create a large state space. Console hardware is more predictable, but it still needs content and patch testing.

A useful shader precaching benchmark should cover cold launch, first traversal of a shader-heavy area, the first combat encounter, warm launch, maximum frame time, 1% and 0.1% lows, cache-hit rate, and behavior after a driver update. A cache that works only on the development machine isn’t a solution.

Microsoft’s Advanced Shader Delivery work separates pipeline state information from compiled shader data and has reported major launch-time improvements in specific examples. Those results are encouraging, but they’re vendor- and game-dependent. The more reliable practice is to log the actual spike:

if (frameTimeMs > 33.0f) {
    LogFrameSpike(
        frameTimeMs,
        currentPSO,
        shaderCacheHit,
        sceneName,
        gpuModel,
        driverVersion
    );
}

The log should help distinguish shader compilation from asset streaming, garbage collection, CPU contention, or network correction. Each symptom needs a different fix.

Platform Economics Still Matters, but It’s a Separate Decision

Infrastructure and distribution economics belong in the plan, but they shouldn’t be confused with netcode performance.

A lower platform fee doesn’t automatically produce more profit. A storefront with stronger discovery, better conversion, or a larger matchmaking population may outperform a cheaper channel. More players can also mean shorter queues and healthier regional matchmaking, which directly affects retention.

The complete calculation includes:

Net platform contribution = sales revenue − platform fee − taxes and refunds − backend cost − support − incremental QA and certification

Cross-platform multiplayer adds account integration, certification, patch coordination, platform-specific testing, and sometimes anti-cheat restrictions. Ten thousand additional players can be a commercial win, but only if they improve lifetime value enough to cover those operating costs.

Treat console expansion and store selection as audience and retention decisions. Don’t use them to justify a 128-tick server that has no measured player-facing benefit.

A Practical 2026 Decision Rule

Use this compact rule when planning the next performance investment:

Use 128 Hz when testing shows fewer hit disagreements, shorter confirmation delays, or smaller corrections. Don’t pay for it because a competitor advertises the number.

Use rollback when the gameplay demands immediate response and the replay boundary can be kept narrow. Player-owned combat state is a sensible starting point; rewinding the whole world usually isn’t.

For most studios, the strongest default remains server authority with client prediction, selective rollback where it earns its cost, aggressive frame-time telemetry, and shader delivery designed before launch. The right answer isn’t the fastest server on paper. It’s the change that removes the largest error players can actually feel.

Frequently asked questions

Is 128 tick worth the server cost?

Only when measured hit validation, correction, or input-confirmation results improve enough to justify the CPU cost. Better prediction, lower interpolation delay, or stable frame pacing may deliver a larger gain.

Does rollback increase server costs?

Usually. The cost depends on rollback frequency and replay complexity. Lightweight player-state replay can be modest; physics, AI, effects, and ownership changes can make it expensive.

What tickrate does a competitive FPS need?

There’s no universal requirement. Sixty to 100 Hz can work well when prediction, lag compensation, snapshot delivery, and frame pacing are strong. 128 Hz makes sense when real tests show fewer timing errors under real match loads.