Rollback vs. Lockstep: The 33.3ms Resimulation Window

At 60Hz, a single display refresh consumes exactly 16.67 milliseconds, leaving developers with a razor-thin margin to process inputs, update game logic, and render frames before the next cycle begins. This fixed timing constraint fundamentally dictates how multiplayer synchronization protocols operate under pressure.

When studios adopt rollback netcode, they allocate a strict 2-frame budget to rewind and replay simulation states, totaling 33.3 milliseconds of computation per correction cycle. If a studio ports this architecture into a simulation costing more than 8.3 milliseconds per frame, the system exhausts its entire allowance on CPU catch-up rather than masking network latency, producing a noticeably worse feel than traditional lockstep.

Missing that 33.3 millisecond window even once forces the client into aggressive state reconciliation, triggering correction stutters that players perceive as input lag or rubber-banding. Consequently, the industry assumption that rollback universally outperforms lockstep collapses below this resimulation performance floor, proving that deterministic synchronization remains the optimal choice when hardware cannot guarantee identical mathematical outputs across diverse architectures.

The 33.3ms Resimulation Window

Lockstep enforces strict synchronization by stalling every peer's simulation until inputs for tick N arrive from all connected clients. This architecture guarantees zero resimulation cost because the state never diverges, but it imposes a hard latency floor: perceived input delay equals RTT/2 plus any mandatory buffer frames. At 60Hz, an 80ms round-trip time forces roughly five frames of dead input lag—approximately 83ms—before the first action registers on screen. Producers often mistake this silence for "perfect" netcode stability, yet the trade-off is a rigid responsiveness wall that scales linearly with distance, leaving no mechanism to recover lost time once the frame budget expires.

Rollback inverts this constraint by decoupling rendering from validation, executing a precise pipeline within a single 16.67ms render window. When a late packet arrives containing corrected input for tick N-2, the system restores the last confirmed state snapshot, injects the new input vector, and resimulates ticks N-2 through N-1 before finally rendering tick N. This entire sequence must complete inside one frame interval; if the CPU cannot finish the work, the frame drops, causing stutter that degrades playability faster than static input delay. The critical metric here is not average latency, but the worst-case serialization and computation time required to replay game logic without violating the display refresh cycle.

The 33.3ms resimulation window represents the total simulation time that must be replayed when correcting two frames of prediction error. Calculated as 2 frames multiplied by 16.67ms per frame, this budget dictates why GGPO reference implementations cap the rollback window at 2-3 frames; exceeding this threshold introduces corrections large enough to become visually jarring, breaking player immersion. Determinism serves as the absolute precondition for this model, as both lockstep and rollback require identical floating-point or fixed-point results across heterogeneous hardware. According to production analyses of GGPO-licensed titles like Skullgirls, studios enforce fixed-point math and explicitly avoid STL container nondeterminism in the simulation layer to guarantee bitwise reproducibility, ensuring that a correction applied on a high-end PC matches the state derived on minimum-spec hardware.

Input-delay buffers function as the primary defense against network jitter, with rollback games shipping configurable delays ranging from 0 to 8 frames under GGPO's default parameters. The effective rollback window only needs to cover RTT/2 minus this pre-configured buffer, meaning the actual prediction burden shrinks as the buffer grows. For instance, a 2-frame buffer at an 80ms RTT leaves just 1 frame of actual prediction required from the rollback engine, significantly reducing the computational load. However, increasing the buffer directly increases base input lag, forcing producers to balance responsiveness against stability. The decision hinges on whether the target platform can consistently resimulate the remaining frames within the 16.67ms render deadline; if the simulation cannot meet this throughput requirement, the correct architecture defaults to lockstep with a fixed 2-frame input delay, accepting higher base latency to preserve frame integrity.

Measured Costs

Rollback netcode is frequently marketed as a latency-free solution, but the architecture does not erase delay; it converts unpredictable network jitter into predictable visual corrections. Every shipped implementation still enforces a fixed input-delay buffer before simulation begins. According to GGPO creator Tony Cannon’s own breakdowns of rollback frame counts in fighting games, shipped titles typically run 1–3 rollback frames per correction at 60fps, meaning the simulation replays 16.7–50ms of state per bad input. That baseline buffer is non-negotiable because the host must collect joint actions from all peers before advancing the deterministic tick. The real cost emerges when that buffer is exceeded and the engine must rewind history.

The financial and engineering weight of that rewind depends entirely on how fast your minimum-spec platform can resimulate. The Slippi Project’s rollback work on Super Smash Bros. Melee—a 60Hz deterministic sim from 2001—demonstrates that even a legacy engine can hit 2-frame resimulation when state size is small. Slippi reports resimulation of multiple frames in under one frame's budget on modern hardware, which directly validates the thesis: if your state footprint is tight enough to replay 33.3ms inside a 16.67ms render window, rollback pays for itself by avoiding hard stalls. When the state grows heavier, the math flips.

Published telemetry from major studios confirms this crossover behavior. NetherRealm’s published latency numbers for Mortal Kombat 11’s rollback (built on the GGPO model) show a fixed input delay of roughly 2–3 frames plus dynamic rollback windows scaling with connection quality, as documented in their GDC 2019 netcode talk. The system absorbs minor packet loss by rewinding exactly those frames, but once the network degrades past the buffer, the CPU cost scales linearly with the rollback window size. Conversely, For Honor’s deterministic lockstep-style approach (Ubisoft’s connection-quality data from their GDC talks showing hit reactions tied to fixed simulation delay) proves that lockstep remains shippable at scale when the sim is too heavy to resimulate. By stalling until all inputs arrive, For Honor trades variable CPU spikes for a constant, predictable delay that players adapt to over time.

Killer Instinct (2013, Double Helix/Iron Galaxy) provides another measured data point: the team publicly documented a 3–4 frame input delay plus rollback, and frame analysis by the community (e.g., tool-assisted frame captures) confirmed corrections resolving within 2 frames at 60fps. This aligns with the canonical rule—when the engine can comfortably resimulate two full frames inside the render budget, the visual pop-in stays below perceptual thresholds, and the architecture justifies its complexity. When it cannot, the CPU asymmetry becomes fatal. Resimulation cost is per-frame-of-history (linear in rollback window size), while lockstep cost is per-peer (linear in player count). That is why 2-player fighters tolerate rollback but 8-player RTS sims (StarCraft II's lockstep at its fixed logic rate) historically did not.

The decision matrix is mechanical, not aesthetic. If your deterministic simulation can resimulate two full frames in under 16.67ms on your minimum-spec platform, ship rollback. If it cannot, ship lockstep with a fixed 2-frame input delay. The myth that rollback eliminates input delay collapses under telemetry: every implementation holds a 1–3 frame buffer, and rollback only converts excess latency into visual corrections rather than zero delay. Measure your resimulation throughput first, then pick the architecture that matches your hardware reality.

The 2-Frame Crossover Test

Profile your deterministic simulation step on the absolute minimum-spec target hardware and measure wall-clock time for two consecutive ticks. If both steps finish in under 16.67ms—meaning each tick consumes less than 8.3ms of CPU budget—the crossover test passes and rollback becomes architecturally viable. If the profile exceeds that threshold, lockstep with a fixed two-frame input delay is the correct production choice. This single measurement collapses the entire netcode debate into a binary decision tree: you either have the resimulation headroom to absorb network jitter, or you do not.

The crossover math explains why the threshold exists. Rollback’s latency advantage equals (RTT/2 − input-delay buffer) in hidden milliseconds, while its cost is raw resimulation CPU. When RTT/2 drops below 33.3ms—which occurs at round-trip times under roughly 67ms—a two-frame-buffered lockstep matches rollback’s perceived latency at zero resimulation overhead. In that low-latency regime, lockstep wins by default because it avoids replay entirely. As RTT climbs past that boundary, rollback’s advantage scales linearly until it hits the ceiling of your render frame budget.

Player count shifts the crossover boundary significantly. In two-player deterministic sessions, the table above favors rollback once RTT exceeds ~67ms, since the single peer pair keeps lockstep stalls predictable. For four-or-more player sessions, lockstep’s stall compounds per-peer, turning acceptable latency into cascading freezes. Rollback’s fixed two-frame budget holds constant regardless of peer count, widening its win region substantially in larger lobbies. The architecture that survives local co-op often fractures under distributed matchmaking unless the resim profile clears the 8.3ms-per-step gate.

For 2026 60Hz production environments, rollback remains the explicit winner—but only when it passes the 8.3ms-per-step resimulation test. That condition is not a marketing promise; it is the canonical rule governing this guide. Ship rollback if your minimum-spec hardware proves the budget. Otherwise, ship lockstep with a fixed two-frame input delay and accept the latency tradeoff rather than burning CPU on failed replays.

What the Data Doesn't Tell You

The decision rule regarding the 33.3ms resimulation window is robust for standard deterministic simulations, yet it rests on assumptions that fracture under specific production constraints. The primary limitation of the evidence is that the crossover threshold assumes a uniform cost per tick. In practice, simulation complexity is rarely linear; it spikes during state transitions, physics resolution bursts, or AI pathfinding recalculations. When these spikes occur, the average frame time may satisfy the budget while individual ticks exceed the 16.67ms render deadline, causing rollback to drop frames or lockstep to desync despite passing aggregate profiling. You must verify not just the mean resimulation cost, but the tail latency distribution on minimum-spec hardware. If your profiler shows a p99 spike exceeding the render budget even once per second, the theoretical advantage of rollback evaporates because the visual correction becomes more disruptive than the input delay.

Variance across cases introduces significant friction when targeting heterogeneous platforms. The canonical rule presumes a single target architecture, but studios shipping cross-platform often face divergent CPU instruction sets and memory latencies. A simulation step that fits comfortably within the 2-frame budget on a desktop GPU-accelerated backend may fail catastrophically on a mobile SoC due to thermal throttling or cache misses. This variance means the "correct" architecture can shift mid-development as optimization targets change. Furthermore, the rule does not account for non-determinism introduced by floating-point operations across different compiler versions or SIMD implementations. If your codebase relies on IEEE-754 compliance without strict bit-exact hashing, the rollback buffer cannot reliably reconstruct state, forcing you to fall back to lockstep regardless of raw performance metrics. You must audit your toolchain consistency before trusting the benchmark.

The rule breaks in edge cases where the game loop itself violates the assumptions of fixed-tick determinism. Specifically, if your simulation requires asynchronous I/O, dynamic memory allocation with unpredictable fragmentation, or external service calls that introduce jitter independent of network latency, the deterministic model collapses. In these scenarios, rollback cannot correct what it cannot predictably resimulate. Additionally, the myth that rollback eliminates input delay persists among producers who conflate visual smoothness with responsiveness. Every rollback implementation retains a fixed input-delay buffer—typically one to three frames—to absorb jitter. On low-latency LANs or fiber connections, this buffer adds unnecessary delay compared to lockstep's minimal stall. If your deployment environment guarantees sub-10ms round-trip times, the overhead of maintaining a rollback buffer outweighs its benefits, and lockstep with a negligible delay buffer becomes the superior choice. The data supports rollback only when network jitter exceeds the cost of resimulation; otherwise, you are paying a precision tax for no gain.

What the 2-Frame Budget Hides

Resimulation benchmarks are routinely executed against stripped-down state dumps, but a live 60Hz match with forty active entities, layered particle systems, and streaming audio contexts routinely doubles snapshot-restore overhead. A simulation that clears the two-frame threshold in isolation will frequently stall mid-match when collision meshes and animation blending queues saturate the cache. The budget math assumes static memory footprints; shipping builds do not.

Latency measurement work published around FightingEX Layer and Street Fighter V's rollback patches consistently records four to six frames of total input latency on display chains. Rollback converts network jitter into visual corrections, but it cannot compress engine scheduling, display pipeline buffering, or VSync lockouts. The netcode layer stops at the render queue; everything downstream still dictates the player's perceived responsiveness.

No published metric quantifies the perceptual cost of 'teleport flicker' when a two-frame reversal undoes a knockdown or a dash-dance. Player telemetry from Slippi's Melee implementation indicates non-linear quality degradation once rollback frames exceed two or three, even when CPU utilization remains within spec. The human visual system registers micro-stutters as input desync long before frame counters register a violation.

Genre architecture dictates whether the two-frame budget is achievable or illusory. Turn-based simulations and low-entity puzzle games trivially satisfy the resimulation window, making rollback the unambiguous choice. Physics-heavy sixty-hertz titles relying on iterative solvers frequently fracture determinism across hardware generations. When floating-point divergence forces branch mispredictions, the budget calculation collapses regardless of raw clock speed.

The two-frame assumption silently requires inputs to arrive within half the round-trip time. Peer-connection studies document Wi-Fi environments where latency spikes routinely exceed two hundred milliseconds. When jitter pushes the correction window past two frames, GGPO-style implementations either cap the rollback buffer and stall the sim or expand the reconciliation range until rubber-banding becomes visible. Stable routing is a prerequisite for the math to hold.

Per-frame resimulation costs fluctuate between twenty and forty percent depending on console versus minimum-spec PC architectures. No public dataset aggregates these measurements across shipped GGPO deployments, which means the eight-point-three-millisecond threshold functions as an engineering estimate rather than a certified constant. Verify your own hardware profiles before committing to a netcode strategy.

Worked Case

Consider a production scenario on minimum-spec console hardware: a two-player 60Hz fighting game using deterministic fixed-point simulation. The baseline simulation step costs exactly 7ms per tick, and the network round-trip time (RTT) between peers is 80ms. We evaluate both architectures against the canonical decision rule.

Lockstep evaluation: Input delay equals half the RTT, yielding 40ms. At 60Hz, this spans approximately 2.4 frames; rounding up to the nearest integer buffer requires 3 frames of input delay, resulting in 50ms of total input lag. Because lockstep stalls until all inputs arrive, resimulation CPU cost is zero, and visual corrections never occur. The simulation step itself consumes 7ms, leaving 9.67ms of headroom within the 16.67ms render budget. Lockstep passes the frame budget with comfortable margin.

Rollback evaluation: Rollback enforces a fixed two-frame input buffer, introducing 33.3ms of deliberate delay. The remaining latency budget for rollback operations is calculated as (RTT / 2) - Buffer, which yields 40ms - 33.3ms = 6.7ms. This window accommodates approximately one frame of rollback. Resimulating a single frame costs 7ms. While 7ms exceeds the 6.7ms residual window by a negligible margin, the critical metric is whether the resimulation fits inside the 16.67ms render frame. Since 7ms < 16.67ms, the architecture passes the budget test with 9.67ms of headroom. Rollback ships.

The advantage vanishes immediately when simulation complexity increases. Rerun the same scenario with a heavier deterministic simulation costing 12ms per step. Two frames of resimulation now require 24ms, which exceeds the 16.67ms render budget. Rollback can no longer afford a two-frame window; it collapses to a single-frame rollback window. With an 80ms RTT, a one-frame window forces the input buffer to expand to four frames to prevent underflow, resulting in 66.7ms of input lag. This exceeds lockstep's 50ms lag, making rollback strictly worse-feeling than lockstep despite its marketing claims. In this configuration, lockstep remains the correct architecture.

The production takeaway is mechanical, not aesthetic. The decision flips purely on the measured sim-step cost—7ms versus 12ms—not on genre conventions, development budget, or the specific netcode library selected. Developers must profile the deterministic simulation on minimum-spec hardware before committing to an architecture. If the profile shows resimulation of two frames cannot complete within 16.67ms, ship lockstep with a fixed input-delay buffer. Only when the profiling data confirms the 2-frame budget can you safely deploy rollback.

Five Rules for Spending Your 33.3ms

Profiling your deterministic step on minimum-spec hardware is not a preliminary exercise; it is the architectural gate. Measure wall-clock time for two consecutive 60Hz ticks on the lowest supported CPU/GPU configuration. If both steps exceed 16.67ms, commit to lockstep with a fixed 2-frame input buffer and terminate rollback evaluation immediately. The crossover threshold shifts as you add entities, so treat the 8.3ms-per-step budget as a moving target rather than a static benchmark. Schedule the profiling gate at every content milestone, not once during pre-production.

When you do ship rollback, the input-delay buffer must be calculate

Frequently Asked Questions

What per-frame simulation cost forces a rollback system to exhaust its entire allowance on CPU catch-up instead of masking network latency?

A simulation costing more than 8.3 milliseconds per frame forces the system into CPU catch-up rather than latency hiding.

How many frames of dead input lag does an 80ms round-trip time create under lockstep synchronization at 60Hz?

An 80ms round-trip time forces roughly five frames of dead input lag, which equals approximately 83 milliseconds before the first action registers on screen.

What specific mathematical constraint must studios enforce across heterogeneous hardware to guarantee bitwise reproducibility during state corrections?

Studios must enforce fixed-point math and explicitly avoid STL container nondeterminism in the simulation layer to prevent non-deterministic state divergence.

How does increasing the input-delay buffer affect the actual prediction burden placed on the rollback engine?

Increasing the buffer directly shrinks the actual prediction burden because the effective rollback window only needs to cover RTT/2 minus that pre-configured delay.

What happens to player experience when a rollback correction exceeds the two-frame budget due to heavy state footprints?

Exceeding the two-frame budget causes rubber-banding that degrades player experience more than the static delay imposed by lockstep.

Why do 8-player RTS simulations historically rely on lockstep while 2-player fighters can successfully use rollback architectures?

Resimulation cost scales linearly with the rollback window size while lockstep cost scales linearly with player count, making lockstep shippable for large peer counts when simulations are too heavy to resimulate.

Quick answers

Also worth reading: Rollback Netcode: Free GGPO, Photon Fusion, and One Winner: Rollback Netcode: Free GGPO, Photon · Switching Strategy Games from Rollback to Deterministic Lockstep: Switching Strategy Games from Rollback