If the server checks movement speed, cooldowns, and range too strictly, it rejects even valid inputs that arrive bunched together because of jitter.
Why Strict rules such as “max distance per tick” or “0 ms cooldown tolerance” → Effect When jitter makes two commands arrive in the same tick, they’re judged as rule violations → On screen Rubber-banding, skills rejected even though the cooldown is up
Check against an accumulated allowance (token bucket), leave slack for ping and jitter.
On the graph
Random spikes · Server validation rejections and position corrections
Where to look
Server log for each validation rejection or position correction with the reason, how many commands from that player arrived in that tick, and the arrival gap from the previous command
Confirmed if
Rejections and corrections cluster at moments when 2 or more commands arrived in one tick, while movement and use counts summed over a few seconds stay within the rules
Ruled out if
Still over the limit even when summed over a few seconds: real speed hacking or cheating is possible. Rejections concentrated on one ISP in the evening: points to validation false positives concentrated on one ISP’s players
Check with
Game server or client logs and metrics
Sources
Source SDK 2013: player.cppValve A per-tick command processing budget that accumulates (up to sv_maxusrcmdprocessticks, 24 ticks) lets bunched-up commands through; a developer comment says stricter restrictions caused stutter even for legitimate players