[Tutorial CS 1.6] Counter-Strike: 1.6 Netcode Explained

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.

Fonte: Gotfrag