In this article, Jon Mellin gives us some insight into the recently updated netcode in 1.6. The article is enlightening and should help people in adjusting their settings correctly. Special thanks to Jon for sending in this wonderfully written article.

CS Netcode Explained
By: Jon Mellin

In this article, I hope to give some insight into the hotly debated netcode commands in Counter-Strike. Netcode is a relatively new subject, as most top players were only introduced to its effects when Europeans and Americans clashed for the first time in the 1.3 era. In 1.5, players began taking a more proactive approach to finding out the effects of certain commands. In fact, most people even adopted the correct settings. When the mystery of interp was solved back in 1.5, we all thought the debate was over. However, with the transition to 1.6, Valve fixed an error in the code, creating more confusion. If that wasn’t enough, the correct settings have been effectively blocked by the Valve Anti Cheat, or VAC. Until now, that is.

The opinions represented here are the culmination of about 2 years of experimentation and observation. Recently, certain events have again sparked my interest in the netcode issue: admins enforcing the wrong values, players being disqualified from LANs for using correct values, etc. Some of you may remember me as the guy that brought you the “ex_ commands explained” article from long ago. A recent series of emails I have exchanged with a Valve employee confirms much of the information contained in this article. (And for all of you wondering, they are looking into the demo problem). Again, the information contained here will not make you the next SpawN but should help to eliminate false accusations and provide a more level, accurate playing field.

Below, I’ll first give an overview of commands I consider important and provide background into their effects. Next, I’ll recommend values, and explain why I recommend what I do.

Notes:

• Commands preceded by sv_ or sys_ are server side commands and must be used in conjunction with the rcon command. Typing these commands without rcon will return the values set on YOUR computer, not the actual values used by the server.

• The relationship between ex_interp and cl_updaterate is extremely important; do not read one recommendation without reading the other.

• This article is written under the assumption that the main audience reading it will have access to a broadband connection.

General Info:

cl_cmdrate:
This command determines the number of packets per second that you, the client, will send to the server. Obviously, the higher this value is, the quicker the server will respond to commands you execute. If you have a broadband connection and you are the only person playing on it, there is most likely nothing wrong with a high value. If you’ve ever LANed at a friend’s however, and noticed insane lag spikes, this command is the culprit. Most broadband connections don’t provide you with an abundance of upstream bandwidth, which is what this command requires.

cl_updaterate:
cl_updaterate is analogous to cl_cmdrate, but works in the reverse manner. It controls the amount of packets (updates) per second you can receive from the server. Therefore, it is tied to your downstream bandwidth. The higher a value you use for cl_updaterate, the more synced you will be with the server. Since only the server’s opinion matters in determining whether your shots hit, you’ll want to receive plenty of updates.

sv_maxupdaterate:
Just as cl_updaterate controls the maximum packets per second a client is allowed to receive, sv_maxupdaterate specifies the maximum number of packets per second a server is allowed to send. Therefore, setting cl_updaterate above the server’s sv_maxupdaterate value will not increase the amount of updates you receive.

sys_ticrate:
This command sets the maximum “frames” per second the server can calculate. By default, this value is set to 100. Why are server fps important? This parameter alone determines the “feel” of your server. I’m sure we’ve all experienced servers that feel as if they are hosted on a TI-83 plus, and then we’ve played on those we could have sworn were on LAN.

sys_ticrate only specifies the maximum fps your server can calculate. By default, your server won’t achieve the value you specify because of the way operating systems deal with certain processes. Various methods exist to “boost” the fps of a server, but most (if not all) will have to be implemented by your server provider. Keep in mind, however, that boosting a server will subsequently increase the CPU load on the server provider’s box, something which deters most from offering this service. (For some reason, boosting causes insane CPU usage on de_inferno and de_aztec. You may or may not experience similar symptoms). By default, your half-life server will average 64fps for Win32 based servers and 50fps for Linux based servers. Boosting a server allows frame rates of 512 and above in some cases. The effects of such high server fps are debatable, but I feel you will notice a definite improvement up to around 200fps.

Consistency is the key. Fps spikes from 100 to 512 will probably create a worse gaming environment than just capping sys_ticrate at around 150, if that’s all your server’s hardware is capable of.

If you have rcon to a server and want to check the current server fps, type rcon stats, to check if your server is boosted, temporarily set sys_ticrate to 10000 and issue an rcon stats command. If your server’s fps are now above 100, your server is boosted.

ex_interp:

Before I begin, Webster defines interpolate as the following:

Main Entry: in·ter·po·late
3 : to estimate values of (a function) between two known values
intransitive senses : to make insertions (as of estimated values)

You cannot be perfectly synced with the server at every instant in time because you only receive a finite amount of updates per second. For example:

This graphic depicts a linear interpolation of a circle. As the number of data points (updates) increases, the interpolated figure becomes more accurate. In Counter-Strike you could consider this to be a player’s position over the span of one second. The server’s view in this case would be a perfect circle. The client has to interpolate between two “true” packets.

This is where ex_interp comes in. A small increment of time exists in between each update that is left to half-life’s prediction engine. ex_interp sets the amount of time (in seconds) to interpolate in between each successive update. In the figure above, these small time intervals correspond to the straight edges of the figure. Because interpolation is done client side, it is not perfectly consistent with the server’s view of the game. Nothing is a substitute for actual updates from the server, but interpolation generally does a good job.

Recommendations for online play:

rate:
I’ve been assured that rate is capped at 20000. Using anything above 20000 has no benefit, and could potentially lower performance.

Recommendation:
rate 20000.

sv_maxrate:
This value will most likely be set to 0. I’ll explain why this might not be the optimal value for online play. sv_maxrate 0 will detect each clients’ rate setting and fulfill each players’ need. Assume for a second that the half-life engine did allow players to use a rate value of over 20000. If a player had rate set to an insanely high value (i.e. 999999999), the server would try to fulfill that need. This could potentially waste bandwidth and put more load on the server than needed. I suggest a safer, but equally well performing value of sv_maxrate 20000. In reality, sv_maxrate 0 and sv_maxrate 20000 may behave exactly the same, but added precautions never hurt.

Recommendation:
sv_maxrate 20000.

cl_cmdrate:
Ideally, this value should equal the server’s fps (NOT the client fps as some people originally thought). If you update the server more times than the server calculates frames over the same time period, the extra updates are most likely just dropped by the server. Therefore, too high of a cl_cmdrate shouldn’t be too harmful, but will waste your bandwidth.

Recommendation:
cl_cmdrate equal to or higher than the server’s fps.

ex_interp:
Set this variable to 0 and nothing else. Counter-Strike will automatically set your ex_interp to 1/cl_updaterate (i.e. your console will say: “ex_interp forced up to xx msec”). This is because the time in between each packet is exactly 1/(the # of updates per second), so this is how long you want your client to interpolate. Adjusting your cl_updaterate will automatically adjust your ex_interp (when ex_interp is set to 0). I recommend only changing your cl_updaterate, and letting Counter-Strike set your ex_interp. You cannot set this command lower than 1/cl_updaterate anymore, and setting it higher is an exploit. Using a value above 1/cl_updaterate forces you to shoot behind the actual model displayed on your screen, which should be considered an exploit. For example, if you use cl_updaterate 101, the correct value for ex_interp would be 1/101 = 0.009 (9 milliseconds), but by using the default value of ex_interp 0.1 with this high cl_updaterate, the aforementioned exploit appears.

Recommendation:

ex_interp 0.

cl_updaterate:
It has long been thought that the prescription for cl_updaterate was to start at 101 and work your way down until you receive and acceptable amount of “choke.” Choke can be viewed by using the command net_graph 3. Personally, choke is the last thing on my mind. The best value for cl_updaterate is much more complicated. The CAL server side config provides for an sv_maxupdaterate of 101, so one may conclude that your cl_updaterate should be set to 101. Ideally, this is correct, but in reality is not very useful. Most servers you will play on in North America won’t be able to calculate 100 frames per second; this means that there is no way the server can send out 100 updates per second. Therefore, a value of cl_updaterate 101 will tell your client to use ex_interp 0.009, but you won’t actually be receiving 100 updates per second, so the players will appear choppy. Since there is no way to determine a server’s fps without rcon (again use rcon stats), the optimum value is somewhat of a guessing game. You might say, “Well, just set cl_updaterate to 101 anyway and I’ll receive the maximum number of packets the server can send.” The problem here is the disregard of cl_updaterate’s effect on ex_interp and the delicate balance that must be maintained between them.

To find your optimum value of cl_updaterate (remember to set ex_interp to 0), start at 101 and work your way down until the models only slightly skip around. “Slightly skip around” is a matter of preference, as long as ex_interp equals 1/cl_updaterate, the models will be in the right place. You will need to readjust your cl_updaterate on a per-server basis. Don’t be afraid to use a value under 50, if necessary. The prediction engine will do its job. Note: most public servers will be using the default sv_maxupdaterate value of 30, so cl_updaterate 30 will work best in that situation.

Please note that starting from a low value of cl_updaterate (such as 20) and working your way up will not work. Once you increment cl_updaterate to a higher value, the ex_interp will not reset itself automatically; you will have to manually type ex_interp 0 again and again. Here is a convenient script I’ve written for adjusting cl_updaterate easily:

Update Rate Config File

Recommendation:
cl_updaterate should equal the server’s fps, and shouldn’t exceed the server’s sv_maxupdaterate value.

sys_ticrate:
Finding the optimum value for sys_ticrate involves some experimentation. First, recall that if your server is not boosted, raising this value above 100 will have absolutely no effect. If you happen to rent from a high performance server provider (read: your server is boosted), then you have some room to work. While generally more fps is a good thing, the effects of increasing sys_ticrate over about 200 (probably even lower) are almost non-existent. If you set sys_ticrate to 9999, your server’s fps may fluctuate between say 150-1000 depending on the complexity of the current situation. Setting sys_ticrate to a value under 200 would provide a more consistent environment with a minimal (if any) loss in performance. Also, every server host out there runs multiple instances of HLDS (Half-Life Dedicated Server) on one physical server (computer), so if every instance of HLDS is set on sys_ticrate 10000, the load on the CPU(s) could become too great. This type of situation could potentially degrade the playing experience for every server hosted on that computer (and raise your monthly rent).

Finally, server fps only works in multiples of certain numbers. For example, my server will only run at 85, 102, 128, 170, 256, etc. fps and not in-between. If you set sys_ticrate to 100, your server will run at the highest multiple that is under 100 (ex. 85), so try setting sys_ticrate 20-50 above your target fps.

Recommendation:
sys_ticrate 110-180, depending on the quality of your server.

Notes about LAN play:
The reason LAN organizations, such as the CPL, use cl_updaterate 101 has to do with the quality of servers they host. Usually on LAN, only a few servers will be running on any given box, so the servers use up fewer resources. If the servers are boosted to over 100fps, then cl_updaterate 101 becomes a realistic value. For a quick way to determine if a LAN server is boosted, look at the average ping of the players. A default server running at 50 or 64fps will yield pings above 15ms, while a boosted server will produce much lower pings, on the order of 5ms. To my knowledge, the CPL, ESWC and WCG all use boosted servers.

Special thanks to:
Alfred Reynolds, Valve Software
Yahn Bernier, Valve Software
Zibbo, UDPSoft
The HLDS Mailing Lists
The server.counter-strike.net forums