Physics Tick Rate Calculator
Calculate tick timing and bandwidth for networked game physics.
About this calculator
Tick Rate sets the beat your whole physics loop runs on -- Time per Tick is simply 1000 divided by Tick Rate, so it is the only input that changes it: raising Tick Rate from 64 Hz to 128 Hz halves the time budget for every physics step, from about 15.6 ms down to roughly 7.8 ms, with Max Players, Entities per Player, and Bytes per Entity Update having no effect on that number at all. Bandwidth is the opposite case: it climbs with all four inputs together, because every tick the server has to push an update for every tracked entity to every player, so bandwidth is proportional to Tick Rate times total entities (Max Players times Entities per Player) times Bytes per Entity Update. CPU Budget takes the fixed 70% share of Time per Tick this calculator assumes physics logic gets, leaving the other 30% for networking, game logic, and rendering handoff on the server thread.
What this calculator does not model: interest management or area-of-interest culling, which in a real engine means a player only receives updates for nearby entities rather than the whole world, delta-compression of unchanged fields, or unreliable/lossy transports that trade bandwidth for latency instead of raw packet size. Real production netcode almost always sends far less than the raw per-tick figure here because of those optimizations -- treat Bandwidth as a worst-case naive ceiling, not a provisioning target.
Inputs
Results
Time per Tick
15.63 ms
How to Use This Calculator
- Enter the Server Tick Rate in Hz (ticks per second) — 64 Hz is common for competitive shooters.
- Enter Max Players per server and average Entities Per Player.
- Enter Bytes Per Entity Update to model the network payload size.
- Review Time Per Tick in milliseconds and Bandwidth in Mbps to check server requirements.
- Use CPU Budget and Frames Per Tick to balance physics fidelity against server performance.
How the result changes with Tick Rate
| Tick Rate | Time per Tick |
|---|---|
| 32 | 31.25 ms |
| 48 | 20.83 ms |
| 96 | 10.42 ms |
| 160 | 6.25 ms |
What each input means
- Tick Rate
- Server physics update rate in Hz (ticks per second).
- Max Players
- Maximum concurrent players per server.
- Entities per Player
- Average number of networked entities per player.
- Bytes per Entity Update
- Size of each entity state update in bytes.
How this is calculated
Worked example, using the default values
- Identify Input Parameters4 parametersTick Rate = 64, Max Players = 32, Entities per Player = 5, Bytes per Entity Update = 64 = 4 input(s) provided
- Calculate Time per TickTime per Tick15.63 = 15.63
- Calculate BandwidthBandwidth5.24 = 5.24
- Calculate BandwidthBandwidth5242.88 = 5242.88
Engine last updated . Checked against 1 independently-derived test — how we verify calculators. Built by Paul Gunder, a software engineer, not a licensed financial, medical, or legal professional.
Frequently Asked Questions
Why doesn't adding more players change Time per Tick?
Time per Tick is purely 1000 divided by Tick Rate -- it's the length of one physics step, not the work done inside it. Max Players, Entities per Player, and Bytes per Entity Update all affect how much data and computation has to fit inside that window (via CPU Budget and Bandwidth), but the window's length itself is set entirely by how many times per second the server ticks, which only Tick Rate controls.
What's a reasonable tick rate to start with?
64 Hz is a common baseline for competitive shooters and fast-paced action games because it balances responsiveness against server CPU and bandwidth cost; slower-paced games (strategy, simulation, many shooters at scale) often run 20-30 Hz to keep server costs down, while some competitive titles push past 100 Hz for elite responsiveness at a real bandwidth and CPU premium. Start low, measure actual server load, and raise it only if latency-sensitive gameplay demands it.
Why does Bandwidth scale with all four inputs instead of just Tick Rate?
Every tick, the server has to send one update per tracked entity to every connected player, so the total data pushed per second is Tick Rate times total entities (players times entities per player) times the size of each entity's update in bytes. All four numbers multiply together rather than add, so doubling any one of them roughly doubles Bandwidth -- there's no single dominant knob the way there is for Time per Tick.
Is the CPU Budget figure a hard limit my server has to hit?
It's a planning assumption, not a measured limit: this calculator reserves 70% of each tick's time window for physics simulation and leaves the remaining 30% for networking, game logic, and rendering handoff. A real server's actual physics cost per tick depends on your engine, entity count, and collision complexity, so use CPU Budget as a target ceiling to profile against, not a guarantee that your simulation will fit.
Related Calculators
The questions that sit next to this one — chosen by subject, including calculators filed under a different category.
More in Creative, Media & Design.