Cl_interp interpolates object positions starting x seconds in the past. For example, the default cl_interp value interpolates object positions starting 100 milliseconds (.1 seconds) in the past, when your client is receiving 33 updates a second (1 / 33 = .03 seconds per update) this allows your client to receive 3 new complete updates (.1 seconds / .03 = 3.3 updates) in 100 milliseconds. In comparison, a 66 millisecond time frame would only allow 2 complete updates (.066 seconds / .03 = 2.2 updates), and a 33 millisecond time frame would obviously only allow 1 complete update (.033 seconds / .03 = 1.1). Basically the value of cl_interp is directly proportional to the the amount of updates received for interpolation, and doubling the time of cl_interp will have the same effect on the amount of updates used for interpolation as doubling the rate updates are received, assuming the rate can be doubled.
The default cl_interp value will work fine in most situations, but the problem is that it is not optimal for most situations and a better value could give you better results. The default cl_interp value (0.1) was designed to be optimal when your client is receiving 20 updates a second, which is coincidently the default value for cl_updaterate. When your client is receiving 20 updates a second your client will receive a new update every 50 milliseconds (.05 seconds), and with the default cl_interp value being 100 milliseconds (0.1 seconds) the client render time is shifted back to the exact time it takes your client to receive 2 updates, so this allows 2 updates to be used for interpolation. The advantage of using 2 updates is that your client does not need to receive both updates for interpolation, even if one update is lost, there will always be two valid updates to interpolate between. The problem with using a cl_interp value equal to the time it takes your client to only receive one update, is that if that update is lost your client has nothing to use for interpolation until it receives the next update.
However their is also a problem with using a cl_interp value that is set too high, the higher the cl_interp value the more the client render time is shifted back. This means if a player moves around a corner, the higher the cl_interp value the later they will be rendered on your client. This is because cl_interp is designed to interpolate object positions starting x (cl_interp value) seconds in past like I explained earlier, so the later interpolation starts the later objects will be rendered on your client. Using the values from my example, your client has time to receive 3 complete updates for interpolation with the default cl_interp value when your client is receiving 33 updates a second. If you adjust your cl_interp value to the time it takes for your client to receive only 2 updates, the value would be around .06 seconds (2 * 1/33). Now compared to the default cl_interp value of 100 milliseconds, object positions on your client will only be rendered 60 milliseconds in the past, this means object positions on your client will be more up to date, and since this is the exact time it takes for your client to receive two updates this value is still high enough to allow accurate interpolation even if an update is lost.
"Inker = king of the NHL Board bow down people." - da guy is back