Having your TF2 rates set correctly is important because the default TF2 rate values were set in order to cater for all TF2 players so that even players with old computers/internet lines could play on servers without running into network related problems. Because of this these default rate values are not very optimized for people with more powerful computers along with faster internet speeds. This guide gives a description of what each of the TF2 network related cvars (console variables) do and how to work out what their values should be for your current PC and internet connection. This advice on the values for these cvars should only be taken within the context of a 6vs6 pickup/clan situation and not a 12vs12 pub server situation because of issues of client bandwidth and framerate along with server limitations on pub servers. I recommend that you keep all of these values at their defaults when playing on a pub server except ‘rate’ which you can change as explained below. One way of doing this is using the built in source scripting language and creating an alias and binds as shown in the image under the cl_interp description.
For those who do not know, all of the cvars discussed below are set in the console made visible by the ~ key. You may need to enable the console from the advanced keyboard options if pushing ~ does nothing for you.
rate – (Default “12500”, well actually determined by the internet speed you set in steam)
This value is the maximum amount of data that can be sent from the server to your client each second measured in bytes/second (Bps). To convert this value to kilobytes/second (KBps) you need to divide the number by 1024. For example 12500Bps = 12500/1024KBps = 12.20703125KBps.
Increasing the value of this cvar allows larger packets to be sent to your client meaning that you will be receiving a better representation of what is really happening server side, but setting this value too high for your connection will cause major packet loss. I would not recommend setting a rate of lower than the default 12500 unless you are on a slow internet connection such as ISDN or dodgy 3G and even in this case you should not set a rate lower than that of 10000 in order to have a manageable amount of choke along with an accurate representation of what is happening around you ingame. For faster internet connections you can increase this rate value up to a maximum of 300000 = 29.296875KBps so even on a 384kbps ADSL line with a realistic maximum download speed of close to 40KBps you will be able to run at this rate. Even tough this is true you need to make sure that you have enough incoming bandwidth to cater for any third part apps you are running concurrently with TF2, for example a VoIP application such as TS, ventrilo or mumble. This limitation is only really a problem on slower lines such as 384kbps and sometimes 512kbps lines. I personally use a rate of 20000 or 25000 on my 384kbps line and I have not run into any problems.
cl_updaterate – (Default “20”)
This value is the number of packets, containing information about the world, requested by your client from the server each second. This value is closely tied to the FPS your client is rendering each second because if at any stage your client can not render more FPS than this value the server will be sending more packets than your client can handle each second and thus give you an inaccurate (and most of the time slightly jerky) interpretation of what is happening server side because you. So the main rule here is to make sure your client is at all times rendering FPS higher than the value you set for cl_updaterate. If FPS is not a limitation for you because of a powerful machine or a FPS config the maximum value for this cvar is 66.67. This is because all (except for a few servers running the latest version of TFTrue where a custom tickrate can be set) TF2 servers are locked at a tickrate of 66.67 (every 15ms) and therefore will never send you more than 66.67 packets per second. This is not true for other games running on a pre-orangebox source engine. So if your client can render more than 67FPS at all times you can set the value of this cvar to 66.67 otherwise work out the value you need to set for this cvar by the lowest FPS your client renders per second in a heavy battle in a 6vs6 pickup/clan game situation. The current SGS and IS servers have limited cl_updaterate to 60 (sv_maxupdaterate 60) so currently this is the maximum number of packets per second that these servers will send you.
cl_cmdrate – (Default “30”)
This value is the maximum number of packets your client will attempt to send to the server each second. These packets contain data about all of your actions such as movement, attacking etc. This value has the same constraints due to FPS as cl_updaterate in that your client will only be able to send as many packets to the server per second as the FPS your client is generating. It is also limited to 66.67 for the same reason as cl_updaterate (see above). The SGS and IS servers do not seem to have a limit on this cvar but it will do you no good to up the value above 66.67. Another thing to note about this value is that as you increase it you will be uploading more data to the server per second and because of this could run into bandwidth limitation issues on slower connections resulting in choke. Again you need to take third part apps into the equation here especially on slower connections such as 384kbps where you have a realistic maximum upload of 10KBps.
cl_interp – (Default “0.1”)
The default value of this convar means that the source engine is interpolating (smoothing out) entity movement over a 100ms time frame. Entities are rockets, pipes, players and everything that moves ingame so basically all elements of the game apart from hitscan weapons. By decreasing this value of this convar you can reduce the amount of time the source engine interpolates these entities meaning that you will see events such as your own rocket or pipe being shot quicker and player movement slightly before you would with the default value. Reducing this value will not effect whether you will hit or miss a player with a hitscan weapon, because of the way the source engine’s lag compensation works, but it will help when playing as a soldier or demoman because both of their primary weapons are entity based and thus will seemingly fire more quickly with a lower interpolation rate making hitting opponents slightly easier because of this reduced delay when firing.
The value of this cvar is bounded on the lower end by your cl_updaterate and your cl_interp_ratio. The lowest possible value for your cl_interp is given by cl_interp_ratio/cl_updaterate, so for example with a cl_updaterate of 60 and a cl_interp_ratio of 1 you can have a minimum cl_interp of 0.016667 meaning that the source engine will interpolate entities over a 16.7ms time frame which is a lot lower than the default of 100ms.
There is a drawback to having a cl_interp this low and that is because if you get any packet loss the source engine will not be able to interpolate entity movement properly because by default it has more than one packet to interpolate over thus displaying smooth movement even if a packet is lost. Basically if you do get any packet loss with a very low cl_interp all the entities ingame will be displayed as jerky. To make sure that this does not happen you can set your cl_interp_ratio to 2 meaning that now the lowest cl_interp value will be interpolating over 2 packets sent from the server so if one is lost the entities ingame will still be displayed smoothly. Also if the server you are playing on is not powerful enough to send you your maximum number of packets per second (your cl_updaterate value) you will not be interpolating over enough packets to create smooth movement if you are using the minimum cl_interp value. You can look in your net_graph (‘net_graph 4’ in the console) display for the value of lerp, this value is the time interval over which the source engine is interpolating. If this lerp value is white you are receiving at least 2 packets per lerp time interval meaning that entities will still be smooth even if one of these two packets are lost. If the lerp value is orange you are receiving 1 packet per lerp interval meaning that if any packets are lost you entities will appear jerky. If the value is yellow you are not receiving even 1 packet per lerp interval and this is a bad thing which will result in jerky entities. If you are playing a class such as soldier or demoman you are fine having the lerp value in orange because slightly jerky players over short intervals (if/when you get packet loss) is not going to effect your ability to hit other players because of the splash damage of the weapons, but if you are playing scout or another hitscan based class you are better off having the lerp value in white (setting cl_interp_ratio 2) so to have smooth entity movement if packets are lost and thus making it easier to hit players with your hitscan weapons. You never really want the lerp value in yellow but it should only go into the yellow if the server you are playing on is not powerful enough to send you your total number of requested packets per second (cl_updaterate value).
You can simply set yout cl_interp to the lowest possible value that should be in the orange at all times (if it ever changes to yellow you will need to increase the value of cl_interp) and use cl_interp_ratio at either 1 or 2 dependent on the class you are playing, 1 for soldier and demoman and 2 for any other class.
I have binds on my numpad -, +, / and * keys to change between these different interpolation settings as well as a switch from public server rates to 6vs6 server rates as shown below:
I use cl_interp 0 in the above image to get the lowest possible cl_interp value.
This guide ended up being a lot longer than I anticipated and if you managed to read up until here you should now have a better understanding of how the TF2 network related cvars work and what they should be set at for your connection.
If you would like to read a more detailed description of the way the source engines networking works along with what each of the cvars mentioned in this guide do you can check out these links from ‘The Valve Developer Community’:
Feel free to ask any questions in the comments here or find me as ‘Bobalas’ in #tf2 on the za.shadowfire.org IRC network.