After one stall, the game runs its backlog of calculations all at once, and that extra work puts it behind again.
Why The game simulation runs at a fixed interval and stalls once → Effect The backlog of steps is computed in a single frame → On screen A chain of long frames causes spikes, or the cap kicks in and the world slows down
Cap catch-up per frame, handle the leftover time with interpolation.
On the graph
Random spikes · Frame time, fixed steps per frame
Where to look
In a development build profiler, check how many fixed steps ran per frame (in Unity, the number of FixedUpdate-phase markers such as FixedBehaviourUpdate) together with frame time
Confirmed if
One long frame is followed by a chain of long frames that each run several steps; once the cap (Unity’s Maximum Allowed Timestep) is reached, game time runs slower than real time
Ruled out if
A single long frame that doesn’t repeat: “Frame time spike” or “Client garbage collection”
Check with
Game server or client logs and metrics
Learn more
Unity’s physics (FixedUpdate) is the classic fixed step (0.02 s by default, 50 times a second). Maximum Allowed Timestep in the Time settings (the most time the game catches up in one frame, about 0.33 s by default) is the catch-up cap. If a frame runs longer than that, the excess time is dropped, and the game clock falls behind real time by that much.
Handling variation in timeUnity Maximum Allowed Timestep defaults to 1/3 s (0.3333333): even if the game stops for 1 s, game time advances only 0.333 s. The cap prevents the vicious cycle where catch-up steps slow things down even more
Profiler markers referenceUnity FixedBehaviourUpdate: the section where MonoBehaviour.FixedUpdate runs; physics markers are called in the FixedUpdate phase