Tickloop Tuning for 64 and 128 Tick: Deadlines, Jitter Sources and Missed-Tick Budgets

A server that advertises 128 tick and delivers 45 is worse than one that advertises 64 and delivers 63. Tickrate is a promise about how often the simulation advances and how often state is sent to clients; jitter is the variability around that promise. Players feel the second far more than the first. This article covers where tick deadlines come from, which sources of jitter actually move the needle on a dedicated box, and how to budget missed ticks instead of discovering them during a fight.

Deadlines: The Arithmetic Behind Tickrate

At 64 tick, each simulation step has 15.6 ms to complete. At 128 tick, 7.8 ms. At 20 tick, 50 ms. Those are hard deadlines in the sense that missing one means the server either runs the tick late or skips it — both of which show up on the client as stutter, rubber-banding, or hit registration that feels wrong.

Tickrate	Tick budget	Missed-tick budget per hour	Practical use
20	50.0 ms	< 0.05% (~360 ticks)	Survival games, large worlds
60	16.7 ms	< 0.02%	Minecraft default target
64	15.6 ms	< 0.02%	Competitive shooters, standard
128	7.8 ms	< 0.01%	Competitive shooters, at cost

Note what the table implies: doubling the tick rate halves the budget, so every source of variance that was tolerable at 64 tick becomes twice as damaging at 128. A 3 ms hiccup that never mattered becomes a missed tick at 128. This is why teams that switch tickrate upward often report worse feel despite better numbers on paper.

Where Jitter Actually Comes From

On a dedicated machine, jitter sources fall into four groups, roughly in order of impact for a small-to-medium server:

• Scheduler and CPU frequency. A governor that ramps frequency up and down produces variable per-tick compute time even at constant load. Locking the frequency or setting a performance governor removes a surprising amount of variance.
• Memory allocation and GC. Allocating inside the tick loop creates latency spikes that the allocator may defer to an inconvenient moment. Object pooling and preallocation flatten the distribution.
• Disk I/O on the main thread. Synchronous world saves, log flushes, and anti-cheat file writes block the tick. Moving saves to a background thread or a separate volume is often the single highest-value change.
• Network stack and NIC. Interrupt coalescing, offload settings, and driver-level buffering can add several milliseconds of variance to packet processing. Receive-side scaling and interrupt moderation settings matter more than most operators expect.

There is also a fifth, frequently overlooked source: other tenants. On a VPS, steal time from a noisy neighbour appears as unexplained tick variance that correlates with nothing in your own logs. Check CPU steal before you tune anything else — if it is non-zero and spiky, no amount of application tuning will fix it, and the answer is a dedicated machine.

Measuring Jitter Properly

Average tick time is nearly useless. A server averaging 8 ms with a p99 of 22 ms is in far worse shape than one averaging 11 ms with a p99 of 13 ms, even though the second looks slower on a dashboard. Record the full distribution, not the mean.

The minimum viable instrumentation is three numbers sampled per tick: tick start timestamp, tick duration, and player count. From those you can compute p50, p95, p99, p99.9, and the count of ticks that exceeded the budget. Log them once per minute as a summary, and keep the raw series for the last hour for post-incident review.

On the host side, correlate with CPU time per core (not total), context switches per second, and disk queue length for the world volume. A tick spike that coincides with a disk queue spike is a save problem; one that coincides with context-switch spikes is usually lock contention or too many threads competing for the tick thread.

Missed-Tick Budgets Instead of Blame

Define an explicit budget: for a 64-tick competitive server, allow no more than 0.02% of ticks to exceed the budget in any 24-hour period, and zero consecutive missed ticks at peak hours. Those two rules catch different things — the percentage catches slow degradation, the consecutive rule catches the stalls players actually notice.

When the budget is exceeded, the question is not “why did it lag” but “which of the four jitter sources changed.” If nothing in the application changed, look at the environment: a hypervisor migration, a patched NIC driver, or a backup job that now overlaps peak play. The most common cause of a sudden jitter regression on an otherwise stable server is a scheduled task that nobody remembered to move.

Tuning Sequence That Works

1. Confirm the hardware is not the problem: check CPU steal, memory ballooning, and per-core frequency stability.
2. Move all disk writes off the tick thread — world saves, logs, backups, anti-cheat telemetry.
3. Preallocate or pool the hot-path allocations and confirm GC or allocator pauses no longer appear in the tick-duration series.
4. Pin the simulation thread if the engine supports it, and stop the OS scheduler from migrating it across NUMA boundaries.
5. Review NIC settings: interrupt moderation, RSS, and offloads; change one at a time and re-measure.
6. Only then consider raising the tickrate, and only if the p99 at the current rate fits inside the new budget.

Step six is the one teams skip, usually under commercial pressure to advertise a higher number. If your p99 at 64 tick is 14 ms, you cannot hold 128 tick — the budget is 7.8 ms — and advertising it will produce exactly the complaints you were trying to avoid.

When the Host Is the Limit

There is a ceiling to what tuning achieves on shared hardware. If per-core performance is low, if the CPU is oversubscribed, or if the network path introduces buffering outside your control, the jitter budget cannot be met regardless of application changes. Determine which of those applies before spending another evening on engine flags — the hosting team can confirm the CPU allocation model and NIC configuration for your specific plan.

For servers that genuinely need a sub-10 ms p99, bare-metal hardware with dedicated cores and a non-contended network path is the structurally correct choice: the tick loop gets an entire physical core, the network queue is not shared with other tenants, and the frequency stays where you set it. Everything in the tuning sequence above still applies, but it has a chance of working.

A Short Reference

64 tick gives 15.6 ms per tick and is the right default for competitive shooters unless you can prove the p99 supports more. 128 tick gives 7.8 ms and is worth it only when the jitter budget has been met at 64 for weeks. Survival games run comfortably at 20–30 tick with larger budgets, and chasing a higher rate there buys nothing players can feel. Whatever the rate, publish the missed-tick budget alongside it — a number you can defend is worth more than a number you cannot.