Quick answer: Project Settings → Time. Fixed Timestep = 0.02 (50Hz) for typical games. Maximum Allowed Timestep = 0.1 to bound worst-case catch-up. Move non-physics work out of FixedUpdate.

Game stutters under load. Profiler shows FixedUpdate running 4–6 times per Update. The physics rate is too high for what the budget allows; catch-up snowballs.

The Symptom

Frame rate drops cascade into worse drops. Heavy frames take 50ms+ because FixedUpdate catches up the gap, each step doing more work, frame stretches further.

The Fix

Project Settings → Time:
  Fixed Timestep:                  0.02      // 50Hz, comfortable
  Maximum Allowed Timestep:        0.1       // max catch-up = 5 steps
  Maximum Particle Timestep:       0.03
  Time Scale:                       1

50Hz physics is enough for most non-VR games. Bumping Maximum Allowed Timestep down prevents one bad frame from triggering many catch-up steps.

Move Work Out of FixedUpdate

Audit your FixedUpdate methods. Anything that’s not adding forces, calling Move on CharacterController, or running Physics queries should live in Update.

// Bad — runs N times per frame under load
void FixedUpdate()
{
    UpdateUI();           // 5ms
    ScanEnemies();        // 8ms
    rigidbody.AddForce(force);
}

// Good
void Update()
{
    UpdateUI();
    ScanEnemies();
}
void FixedUpdate()
{
    rigidbody.AddForce(force);
}

VR Exception

VR games typically run physics at 90Hz to match HMD refresh. Set Fixed Timestep = 0.0111. Watch CPU budget closely.

Verifying

Profiler → CPU Usage. Look at FixedUpdate.PhysicsFixedUpdate. Cumulative time should stay below 4–6ms per frame at target rate. Reduce work or rate until it does.

“50Hz default. Cap catch-up. Move heavy work to Update. Frame rate stabilizes.”

Related Issues

For Rigidbody2D interpolate, see interpolate. For Rigidbody sleep, see Rigidbody sleep.

Right rate. Bound catch-up. Lean FixedUpdate.