If requests wait for the next tick to be processed and the results wait for the tick after that to be sent, the tick interval is added twice.
Why Received requests are processed on the next tick → Effect Results are also batched and sent on the next send tick → On screen Ping on the connection is low, but responses are consistently late by about 1.5 times the tick interval. On a 10-tick server, 0.15 s on average and 0.2 s at worst
Send the response on the same tick that processes the request, raise the tick rate, send important responses immediately.
Ballpark numbers
On a 10-tick server one tick is 100 ms, so the tick waits alone add 150 ms on average and 200 ms at worst. With a single wait, it’s 50 ms on average.
On the graph
Always high · Time from request arrival to response send
Where to look
Server-side packet capture while a test account repeats the same action (e.g., using an item), measuring the gap between the request packet’s arrival and the response packet’s departure. With server logs, request arrival time, the tick number that processed it, and the time the response was sent
Confirmed if
Time spent inside the server averages about 1.5 times the tick interval, up to about 2 times, and stays constant regardless of RTT
Ruled out if
Time inside the server is around half the tick interval on average: only one tick wait. Longer than the tick interval and uneven: check tick overrun
Check with
Infra tools (no game code needed)
Sources
Peeking into VALORANT's NetcodeRiot Games An arriving input waits up to one tick for the tick boundary, and applying and sending take another frame; this shrinks as the tick rate goes up
VALORANT's 128-Tick ServersRiot Games Part of the latency comes from the network, part from the server tick rate