Great question mate. From an architectural standpoint, here is how this actually works:
The old-school lockstep model had rendering, physics, and network updates all glued to a single loop. At 64 tick that meant everything only updated 64 times a second, so your position and shots were only being sampled that often. When you raise it to 128 tick, the server takes twice as many snapshots of every player per second, so a shot in flight gets caught between two samples instead of being missed entirely. That’s the core reason 128 feels more accurate.
But here’s the part most people gloss over: the physics doesn’t need to run at network rate. Modern engines decouple these. The render loop runs as fast as your GPU allows (240+ FPS no problem) for smooth visuals, while the physics simulation runs on a fixed timestep — in tournament Source servers it’s often locked to 1 kHz. The network layer then sends state at 128 Hz. Because physics is decoupled from both, you get a stable, deterministic simulation without melting the CPU. On the client side, your input gets timestamped to the nearest 0.1 ms and applied at the next physics step, and the server logs deterministic hashes so admins can audit suspicious matches afterward.
Practical takeaways for your crew:
– The server CPU cost of 128 vs 64 is real, so use dedicated Linux boxes, not shared hosting.
– Make sure clients have interpolation on and enough buffer (~100ms) so remote players interpolate smoothly instead of snapping.
– If you’re building your own setup, keep physics on a fixed substep and let render run free — that’s the whole trick to scaling without the bottleneck.
"[Case: FormD T1 9.95L] • [CPU: i7-14700K] • [GPU: RTX 4070 Ti Super]"
