Since a lot of people seem quite confused as to what interpolation is, prediction, lag compensation is, etc.
First off, what is interpolation? The server sends out updates to each client, the client stores the updates in a buffer. These updates form the basis of how interpolation works. Interpolation works by using your cl_interp value to decide the interpolation period and the interpolation period is also dependent on your updaterate and cl_interp_ratio. Interpolation works by using the oldest entry in the buffer, data that is in the past ( decided by cl_interp, cl_interp_ratio & cl_updaterate ) and smoothly animating to the latest update received. That's why animations are jerky when you disable interpolation because it is trying to animate using the freshest data all the time rather than having a buffer of updates to extrapolate between when animating. For instance, if we have an updaterate of 100, and fps_max of 300, we have to render data for 3 frames using 1 update. Or perhaps, updaterate of 100, and fps_max of 100, 1 update per 1 frame of animation.
The default value is 100 milliseconds of interpolation, that is we're using data from 100 milliseconds in the past up to the current update. This means that your view is 100 milliseconds in the past plus whatever your latency is. So for example if you have a 150 millisecond ping, your view with cl_interp set to 0.1 is 250 milliseconds in the past. If you set cl_interp lower than cl_interp_ratio / cl_updaterate, cl_interp is clamped to cl_interp_ratio / cl_updaterate. I won't bother discussing cl_updaterate but to say that it controls the number of updates per second that you are supposed to receive from the server under ideal conditions and that ideally should be set to the server tickrate. Remember that interpolation protects against dropped packets due to the way it works. See Extrapolation for a more detailed explanation.
Extrapolation, I really can't say too much about this because it's so intuitive. Extrapolation is used when we have nothing left to interpolate with. We try to predict where an entity will be and what it will look like in the future. For instance, we use the last received ping of the player, their velocity, their origin, and try to predict where their new origin will be. Keep in mind extrapolation is extremely inaccurate and only a last measure if interpolation totally fails. Example, we're dropping packets left and right. Normally in regular situations, interpolation is usually able to protect us against dropped packets by buffering updates to extrapolate between, but if we lose too many, we have to extrapolate ( try to predict the future - cue wonky music here ) with the last update(s) we got. This example is yet ANOTHER reason WHY YOU SHOULD NEVER DISABLE INTERPOLATION PERIOD. I can't stress that ENOUGH. I.E 0 lerp is fucking bad and will cause bad reg on a laggy server.
As far as prediction is concerned, cl_predict is the var here, and I don't have much to say about it. Prediction is simply so if you have a very high ping you don't wait for the server to tell you what changed with regards to your local player ( movement, firing your weapon, etc ). For instance if you had a 1000 msec of ping, or 1 second, if you pressed the fire button it would instantly fire ( on your client ). Whereas if you disabled cl_prediction you would have to wait a full 2 seconds for the server to tell your client you fired your weapon and animate it. Or if you moved, etc. Pretty obvious. This hearkens back to the Quake days when dialup was the predominate means of accessing the internet. John Carmack wanted to increase the responsiveness of the game ( for the local player ) to reduce perceived latency and therefore local player prediction using shared code just made perfect sense. Of course, the server is still authoritarian in regards to prediction, so if the client's prediction is too far off the server will set it right.
Now we come to lag compensation. One of the most important features and definitely a love/hate relationship with it for some players. What is it? Well lag compensation uses player data to remove the effect of latency when using hitscan weapons. Remember back to the Quake days, when you had to lead your target by your ping? Yeah this is what it's designed to fix. Lag compensation stores each player's usercmds in a buffer as well as their latency and interpolation. When a fire command is received and validated, lag compensation moves the server "back in time" to the moment when the fire event for that player occurred ( firetime = current server time - packet_time - player latency - interpolation period ). This means that player origins, angles, and such are moved backwards to that moment and the weapon's logic code is run. This can have some interesting effects for low latency players. For instance if a player with high latency attacks a low latency player, due to local prediction on the low latency player's computer he was out of the way of the shot, but to the lagged player ( due to interpolation and his ping ) the low latency player was in the path of the bullet. The server doesn't care and issues damage to the low latency player and he dies. Now you can understand why I whinge about people who have high pings (100+ms). There is another interesting piece. For instance, if a low latency player, for sake of of simplicity here, 15 milliseconds, and a high latency player with 150 milliseconds both press their fire button and both shots would kill either player, the lower latency player won't die. This is because the server processes his commands first because they were received before the high latency players.
Lag compensation is the main reason why ping prediction is unnecessary. However if you do care to use ping prediction to try and gain an advantage you will need to calculate the player's velocity and multiply it by your ping and add it to the aim position. Remember you will also have to disable interpolation or account for it.
Remember your ping fluctuates, and depending on the tickrate, and what part of the frame the server is in depends on whether you'll have an added penalty of having to wait another tick or so for the server to begin processing your commands. This can affect your TOTAL latency.
Total latency = lerp + latency
Total latency += ( 1 / tick_rate ); // IF the server did not receive your command at the start of the tick
That's all.
Subject: For those of you who think they know about Source Netcode (The ones that love their 0 lerp and are called NightHawk) 
Sun May 20, 2012 3:59 pm
