Interpolation and extrapolation are two fundementally different things. Extrapolation (or prediction) is used primarily in real-time networked games, while interpolation is used in lots of games, regardless of whether/how they are networked.

Here's a very simply example of using interpolation (forget all about networked games for the moment): You design a game that uses a game loop which updates the game logic (or physics) at fixed intervals, say every 100 milliseconds. Without interpolation, the movement in the game would appear very choppy, since you're effectively only rendering at 10 fps. However, let's say that you game logic decides where every object will be 100 ms from the time at which the logic is actually executing. Your rendering code can then "see" one update into the future. If your rendering code know where an object was at time A, and where it will be at time B, then it can render the object smoothly moving between point A and point B instead of jumping from one point to another. The disadvantage of this system is that the rendering code is at most 1 logic update behind the update loop, though the difference is usually insignificant if you're updating sufficiently fast.

Extrapolation, as explained by other posters, is the act of predicting where an object is (or will be) at a particular time. For example, your game recieves an update from the server saying that an object is now at such-and-such a location and has such-and-such a velocity. The client may not recieve any updates for a long time, but it can "predict" very accurately where an object will be at a certain time, assuming that the object does change its course.

Interpolation meets extrapolation when an object DOES change its course. Let's say that the client recieves another update from the server that says the object now has position P and velocity V. Unfortunately, this means that the object's actual location is not where the client predicted it would be. The easy solution is simply to "snap" the object to its new location, but this looks ugly. The good solution is to gradually slide the object from its previously-predicted location to the new, accurate position, which looks much nicer. This is interpolation used in the context of a networked game.

Does that mean, that the client will always render an out-of-date world (with T lag)?
When client receives a packet with data corresponding to server time T, the client begins to interpolate the unit from its current position to the extrapolated position at T+1. But by the time the unit reaches its position at time T+1 on the client, it is already time T+2 at the server. So the client appears to be always late by one T. Is that right?

Quote:Original post by dummynet
Does that mean, that the client will always render an out-of-date world (with T lag)?
When client receives a packet with data corresponding to server time T, the client begins to interpolate the unit from its current position to the extrapolated position at T+1. But by the time the unit reaches its position at time T+1 on the client, it is already time T+2 at the server. So the client appears to be always late by one T. Is that right?

This depends on how you do the interpolation towards the server's position. For examply, in my game, the client's position is moved towards the current predicted server's position by 1/4 the distance for every T. This causes the client's position to accelerate towards the server's position such that after a small amount of time it has completely caught up to the server (or where the client thinks the server is). The idea is to make the acceleration brief but unnoticeable, which can be a tricky balancing act.