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.
* 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.
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 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.
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.
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.
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:
I’ve been assured that rate is capped at 20000. Using anything above 20000 has no benefit, and could potentially lower performance.
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.
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.
cl_cmdrate equal to or higher than the server’s fps.
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.
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.
cl_updaterate should equal the server’s fps, and shouldn’t exceed the server’s sv_maxupdaterate value.
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.
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.
Netcode explained CS 1.6 by BDS
I will start to explain the choke phenomenon since it has a vital affect on game play and net code settings.
Choke is determined as follows:
The next time a packet can be sent is:
Current time + 1/cl_updaterate
Current time + (number of bytes just sent / rate setting)
So, if you play with a high cl_updaterate value you are likely to get more choke if your bandwidth cannot handle it. Also, with a lot of players in the game world which means more data being sent you will also receive more choke (if your bandwidth cannot handle it). Finally, with a low rate setting, you also get more choke.
If choke is in effect, the server tries to see if it can send a packet to the client on every frame thereafter, rather waiting for the next multiple of 1/cl_updaterate, until the choke is gone.
The way the Half-Life engine uses interpolation is to store positions and times, when those (in game) positions were accurate, in its history. It then uses ex_correct to parse through the history for the best two positions (note that this does not have to be the two last positions). This means that a player moves at the same speed (the actual speed the player moves between those positions on the server) between its positions no matter what ex_interp value is used (as long as ex_interp set to 1/cl_updaterate or greater).
The only case when the player might move faster is after a huge drop of packets or if the player is under a great delay (because of latency) since he then is behind the game world and has to move fast into his correct position.
Why the default values are relatively low is because the game is designed to work for players with every type of connection and give them a smooth game play over the Internet. Another reason is that HLDS should work on most computers and not cause an immense load on the CPU.
As explained in my previous net code column the cl_updaterate and cl_cmdrate controls the server-client and client-server traffic. The higher values, the more traffic. However using low values won't create an inaccurate picture of the gaming world (that will only occur if the client starts to drop a lot of packets) because there doesn't need to be a one-to-one correspondence with the way the Half-Life engine works.
The bad thing about using too high cl_updaterate and cl_cmdrates is that:
Your client bandwidth doesn't handle all the traffic and you receive choke (as explained above).
The server you are playing on has to work under a lot higher pressure since much smaller and more movements are sent to the server for calculation which consumes CPU power and can cause server-lag.
The important factor here is to set values depending on personal choice and what your bandwidth and computer actually can handle. On LAN and in tournaments, these values should be set high for best consistency.
The much debated and dreaded cvar which has tons of myths around it. In Counter-Strike 1.5 the best value to use for ex_interp is default, 0.1. That is because of a small bug (on both the client and server) that affected how the interp was factored into the client and sent to the server (and because of that how it was factored into the lag compensation amount by the server). This lead to the 0.1 fudge factor being introduced which did an ok job at minimizing this bug. It worked best with ex_interp set to 0.1. Note that the ex_interp value of 0.1 is not hardcoded into the server as many people seem to believe.
As some of you already know the net code will change in Counter-Strike 1.6. The math which the client and server do for the lag compensation has been changed. This means that ex_interp now can (and should) be set to 1/cl_updaterate (0.01 with cl_updaterate 100) to 0.1. Why the new formula is 1/cl_updaterate is because, assuming that there is no choke nor packet loss, players and objects will move continuously and receive the next update from the server right after they are finished interpolating. Note that to be able to get full effect of ex_interp 0.01 the server needs to be able to send 100 packets per second and most of the servers can't run that fast.
With the old bug you could get up to half of a players bounding box inaccuracy and even higher with ex_interp set to something else than 0.1.
After the CPL (and other events) changed their net code policy from default cl_updaterate and cl_cmdrate to higher values we noticed a lot of choke in LAN tournaments. This is because the HLDS forces rate to 10000 on every client when the server is ran in sv_lan 1 mode. This was in the beginning created not to cap the rate to 10000 but to raise the default value on clients from 2500 to 10000 and achieve a better feel while playing on LAN. This will be fixed in the Counter-Strike version. The Half-Life engine however caps the rate to 20000, so any value above that is ignored.
This value caps the servers dedicated framerate. The higher the value the more packets can be sent to the clients.
This value caps the server’s maximum updaterate. The higher the value the more packets will be sent to the clients (if the servers frame rate is high enough).
As I said earlier, the important factor is to set values depending on personal choice and what your bandwidth and computer actually can handle. The Half-Life engine does a good job of making the client- and server world accurate even with low settings. In a good environment (read: LAN events) where the servers and clients actually can handle these high values the game play will get even more consistent.