ITT reddit finds out what cl_interp is

all that experiment did is pull back the veil on some clever netcode tricks riot has instituted to keep movement smooth on all clients while playing

Importantly, this means that a client running a 30hz physics simulation will slowly drift from a server running its physics at 128hz and would need to be frequently corrected. To prevent this, we decouple our simulation updates from game ticks (your render framerate). Regardless of render framerate, clients and servers always update movement, physics, and other related systems with a fixed timestep: exactly 128 times per second.

Shown above, a client running at 60 FPS will simulate multiple movement ticks per frame, while a higher frameright client might blend a single simulation update across multiple frames. We simulate slightly into the future (e.g. move #408) as needed to make sure we know exactly where the client will be at frame boundaries. We then linearly interpolate the state of the world within a move update to draw things exactly where they should be when the frame is rendered.

you can validate this information with the fact that the moment the tickrate halves, the size of those packets doubles. its hilarious that no one in the thread mentioned that when the graphs are literally right next to each other.

this is also the reason why the amount of packets sent changes based on how many frames over 128 the client is achieving.

if all this is too much, the simplified version is: at 128fps and under you are providing the 128hz simulation with a packet every second of minimum info, above that your packets are doing double-time and end up transmitting at a multiple of your framerate vs 0-128fps that best fits the interpolation timeline

read more here

https://technology.riotgames.com/news/peeking-valorants-netcode