Forum

Quoted from compleat

Afaik, interp is basically an additional client-side “lag” that is assigned to the game to allow it to predict (interpolate) between ticks (since you only receive at best 66 updates per second).

You can receive more updates than 66, it’s just that that is the maximum tickrate. It’s not really a client side “lag”, it’s more of an “averaging” of the data (but yes, this does have a comparable effect).

Quoted from compleat

Now if all this is right, then when setting cl_interp 0; cl_interp_ratio 0; cl_updaterate 66 (and without having the server limiting anything) one should be setting the interpolation time to 0, therefore disabling it (since the client has no time to predict).
This should cause the game to just show the 66 information packages it receives, with no prediction in between, and a jerky game overall. However, when setting interp to 0 (when I see “lerp: 0.00 ms” in net_graph), the game still feels pretty fluid, so it doesn’t make much sense…

Firstly, don’t do that. cl_interp_ratio 0 is bugged on the server. When you set cl_interp_ratio to 0, the server acts as if you have it set to 1. This causes hit registration issues as the server lag compensates for an interpolation which isn’t occurring.

I don’t understand why you expect the game not to be fluid at 66 updates a second without any interpolation, anyway. On most monitors, you will be at a factor of 110% compared to your screen refresh rate.

Quoted from octochris

Firstly, don’t do that. cl_interp_ratio 0 is bugged on the server. When you set cl_interp_ratio to 0, the server acts as if you have it set to 1. This causes hit registration issues as the server lag compensates for an interpolation which isn’t occurring.

Oh no, I don’t. I stick to my cl_interp_ratio 1 and cl_interp 0.0152 in most cases. It’s just that I have seen a couple of people using both in 0, and arguing in its favor, and I got asked today about it and remembered I had that doubt, so I came and asked.
Quoted from octochris

I don’t understand why you expect the game not to be fluid at 66 updates a second without any interpolation, anyway. On most monitors, you will be at a factor of 110% compared to your screen refresh rate.

I don’t quite understand your last sentence, would you mind explaining a bit more?
But apart from that, I don’t expect it to be fluid because having 66 updates per second, there is a lapse of 1/66 s ≈ 15.2 ms where your client isn’t receiving any information between packets, which generally is fine since the client predicts using the past ticks received and fills in the missing parts. If you give no time for the client to do that, then there is nothing to fill that with. At least that’s how I understand it works, but I’m clearly missing something or just plain mistaken in some part, so I’d be very glad if you could correct me.

btw anyone know why with cl_interp 0 and cl_interp_ratio 1 my interp go 14.9ms some times? isnt 15.2 is a minimum?or its just a bug

The way you said it now… I think I got it. Yes, seems I was thinking 15.2 ms was more than it really was. Thanks for the answers!

Quoted from Ordinator

btw anyone know why with cl_interp 0 and cl_interp_ratio 1 my interp go 14.9ms some times? isnt 15.2 is a minimum?or its just a bug

This indicates a misconfiguration somewhere.

Quoted from TviQ

[…]
Im pretty sure 10.0 is minimun but i think ive heard its unstable or some shit like that but 10 is reachable

You’re mistaken. 10 would only be reachable if you had 100 updates a second. This is possible in the old Source engine (as was used for a long time in CSS/etc), but is not possible in TF2.

Quoted from MIndYe

cl_cmdrate 20001, cl_interp 0, shows lerp 0.00ms on white. Chris, wat is this?

Why would that not be expected?

Quoted from Daerados

I’ve got rates 100, interp ratio 1, interp 0 and got 10.0ms yellow – does it affect hitscan reg, i mean worse or better than your configs ones?

If this isn’t a troll, then I just don’t know what to say.