There's a lot of misconception within the Counter-Strike: Source community about proper netcode settings. To the casual player or person still honing their computer skills, knowledge collected from other users is often one's primary source of information, as most people simply lack the time, will, or technical expertise to perform thorough, empirical testing of their own.
After acquiring countless hours of CS:S play under my belt, and getting a real feel for the game, I, like many others before me, became dissatisfied with my shot-registration performance. When you play first-person shooter games for as long as I have, you develop a very good feel for "leading" lagged shots, especially after playing older games on wretched dial-up connections. As is obvious to many, it became very apparent to me as well, that my shot-registration issues were not lag related.
Thus, I embarked on a journey I loathed to give thought to:
drudging through Google searches for accurate data. I shuttered, wept a bit, then pressed on.
I found before me a festering hive of forums, blogs, and other websites, all of which professed to have the right answer. Not to my surprise, many claims from the denizens of these places offered no supporting evidence, nor counter-evidence to refute arguments which they disagreed with. I shuttered, wept a bit, then pressed on.
I, in many information gathering attempts on the Internet for various subjects, have a hard time taking many arguments at face value. When someone makes a post without any
reason as to why they think the way they do, then it often leads me to believe they haven't thoroughly investigated the issue at hand, and very likely could be altogether wrong. Again, this is not always intentional, word of mouth is often accepted as 'fairly accurate', and various real-life constraints can leave people with no other choice but accept the given answer.
After searching for
real, supported data for a long time, I've arrived at a point where I know of only 2 well researched, supported, coherent, and reliable sources of information. Both authors, Raggi and Whisper, frequent the Source administration community, and are extremely careful to advertise only information that has a reference for accuracy. Their data is primarily documented at
Raggi's "Simplest Rates Guide Ever" thread, and
Whisper's Wiki.
I will compile current information below for ease of use and simplicity, as changes have occurred with recent Steam updates, my hope is that this will prove useful to those trying to understand their CS:S netcode issues, and that having the information at hand will save a lot of time, and headaches.
_________________________
Launch CS:S, and open the console by pressing "`". If the console does not appear, make sure it's enabled under
Options -> Keyboard -> Advanced.
- Understanding the Netgraph
Once connected to a server, open the console and type "net_graph 3". You will see something similar to this picture:
I will quote a solid explanation of the graph from
Whisper's Wiki:
Quote:
1. fps is how many frames per second the client is rendering. This is limited by the clients fps_max setting or the refresh rate of the monitors vertical refresh rate if Vertical-Sync is enabled.
2. ping is:
a) netgraph ping is the round trip time for game packets, NOT including any tickrate or updaterate induced calculation delays
b) Scoreboard latency (ping) is one way trip latency (I have to find out in which direction)
c) rcon status command ping, well nobody really knows what this means yet, but I am aiming to find out.
IN is what is being received by you the client, FROM the server.
OUT is what is being sent by you the client, TO the server.
The IN & OUT both have 3 components, starting from left to right:
3. The size of the game packet in bytes being sent and received (Not sure if this includes UDP Segment + IP Packet overhead)
4. The Average amount of KiloBytes Per Second being Sent or Received of GameData + UDP Segment + IP Packet overhead
5. The Average amount of Updates being Sent or Received per Second
If you multiply 3. by 5. and then divide by 1000 you will get a close approximation of the value of 4. which includes rounding errors because 4. and 5. are only averages. So using the numbers we see above, for IN we get (154*102.4/1000)=15.7696 with the value shown in the picture above for net_graph 3 being 15.16. Meh, close enough. 
The amount of IN Updates received by the client per second (controlled by cl_updaterate) will in most cases equal the servers tickrate, but will NEVER exceed:
* The Clients cl_updaterate
* The Servers sv_maxupdaterate
* The Server/Clients tickrate which are always the same, as the client will always use the same tickrate as the server it connects to
Which ever is the smallest of those 3 numbers will determine the number you see for Updates per second RECEIVED by the client.
If the clients AND/OR servers bandwidth is not sufficient, or is limited by the clients rate or servers sv_maxrate, then the client will NOT see the IN Updates received by the client per second equaling the servers advertised tickrate. This is one example of when the client will see choke.
If the server does not have enough CPU to sustain the servers fps above the servers tickrate, the client will NOT see the IN Updates received by the client per second equaling the servers advertised tickrate. This is another example of when the client will see choke.
The amount of OUT Updates sent by your computer per second (controlled by cl_cmdrate) will NEVER exceed:
* The Clients cl_cmdrate
* The Server/Clients Tickrate
* The Clients Frames Per Second
Which ever is the smallest of those 3 numbers will determine the number you see for Updates per second SENT by the client.
It may look like the OUT Updates sent by your computer per second does exceed the fps, but it reality it does not. It is that the net_graph 3 readings are not always perfectly in sync or there are rounding errors in the calculations, because the the two per second counts 4. and 5. shown in net_graph 3, are only averages. There is also the error in the net_graph 3 that occurs when the Average Updates Received by you per Second magically seem to exceed the servers sv_maxupdaterate, servers tickrate, and the clients cl_updaterate, which were all set to 100 at the time the screenshot was taken above, despite what is shown in the picture above.
6. Loss Are lost packets due to Network problems, either with your computers connection to your ISP, your ISP, or the ISP that is hosting the Server or anywhere in between. If you have loss then you will probably have choke. Do not bother trying to solve Choke problems if you have Loss problems. Resolving loss problems is done by following standard Network Trouble Shooting Procedures. Get a friend to help you or call your ISP, or ask in the Game Server Providers Forum for help. Helping you with network problems is outside the purview of this document, and people who know what they are doing get paid 3 or 4 figure dollar amounts an hour to solve them.
7. Choke Is quite simply the server wanting to send you data but cannot. The reason for this though are not always simple to understand, diagnose or fix. See the Choke explanation above.
|
Now that you have a comprehensive overview of how the netgraph actually works, you can begin to diagnose specific issues and correctly set the various client variables appropriately for your system.
In the console, type "rate". The console will output:
Quote:
|
Max bytes/sec the host can receive data
|
This means that you should set the "rate" variable to the maximum number of bytes your computer can receive per second, or, more simply, your Internet connection's maximum download speed.
If you have a 1mbps download speed, that equals approximately 100,000 bytes per second, which would translate to "rate 100000".
You will need to adjust accordingly to suit your connection speed. You will also want to ensure you are actually getting the speed you're paying for, as many connections do not reach their advertised theoretical maximum speed.
DSLReports.com has a nice toolset you can test with to determine your actual speed.
Justification: The in-game console documentation specifies that rate should be set as such. Rate is a capping variable, you will get choke if the amount of incoming data exceeds this value, and loss if your connection is not fast enough or stable enough to handle the specified value. Both are bad, so proper rate flagging is essential.
As of the last CS:S update, testing has shown that rate is now capped at 30000. A higher value will still stick within the client, though, so feel free to keep a higher value set if applicable to your connection speed, as the limit may be removed in the future. The in-game documentation shown in the console for cl_updaterate is:
Quote:
|
Number of packets per second of updates you are requesting from the server
|
Take your value for "rate" and divide it by 200, this is your connection speed based maximum value for cl_updaterate. If you have a 256Kbps connection download speed, or 25,600 bytes, then 25,600 / 200 = 128.
A server generates one packet, or "tic", per frame.
If your calculated cl_updaterate value exceeds the servers tic rate, then cl_updaterate instead should be set the equal the servers tic rate. If the server is not actually reaching the advertised tic rate, then set cl_updaterate to the amount of actual packets being sent. Justification: Valve has stated that 53.6Kbits per second, per player, of bandwidth usage on servers can be expected (
Here.) On a 33 tic server, 53.6/33 would be around 1.6Kbits per packet, or roughly 200 bytes.
cl_updaterate shouldn't exceed the servers actual FPS rate. cl_interp_ratio Interpolation utilizes a timeline delay to make the client's 'view' smooth. If the interpolation delay runs out, then extrapolation occurs, which often results in a very inaccurate bullet registration, as the client is trying to guess correct player positions.
Server FPS will drop the actual packetrate to below the set ticrate. If your client is expecting a packet per tick, (i.e. cl_updaterate 100 on a 100 tick server,) and one doesn't arrive, you may expire your interpolation delay, and then extrapolation occurs, which causes stuttery gaming. The solution is to increase your interpolation delay by either setting cl_interp_ratio higher, or cl_updaterate lower to match the physical packet rate, which is the recommended choice for correct application, as your client will then no longer be expecting too many packets from the server, which causes choke. cl_cmdrate is often one of the most important variables to consider to set correctly to ensure the most accurate possible hit registration!
For cl_cmdrate, you'll need to calculate your connection's upload speed. If you have 64Kbps upstream, or 6,00 bytes, divide the value by 200, which would equal 32.
Your average framerate is your second maximum limit for this value. So, set cl_cmdrate to the LOWER of either your bandwidth limit, or your average fps, OR an in game maximum of 100, if you're lucky enough to have an over 100 per-second framerate. Justification: If you try to send more packets than your computer can generate, (as it will only make 1 packet per frame,) then you will get server side choke for your command packets, (such as your movements or firing). On the other hand, if your outbound connection can't take it, you'll get loss.
- CL_INTERPOLATE, CL_INTERP_RATIO, & DEPRECATED CL_INTERP
Before the last CS:S update, it was often necessary to tweak cl_interpolate and/or cl_interp for proper hit registration. cl_interp, however, is now deprecated and is no longer used by Steam.
cl_interp_ratio replaces this old variable, and goes a long way to fix hitbox issues all across the board. Unless you're sure you're receiving the correct amount of incoming packets from the server with the correct cl_updaterate set, cl_interp and cl_interp_ratio are now best left at their default values to ensure optimal hitboxes.
- Other Miscellaneous Variables
There are other lesser known variables, such as
cl_smooth,
cl_smoothtime,
cl_lagcomp,
cl_lagcomp_errorcheck, and others which have been discussed over time in various places. These are generally best left at their default values. Some have had bug issues in the past and have been resolved in later updates, others have been mis-explained and mis-applied and simply won't help improve hitbox registration. Again, I recommend leaving these variables at their defaults.
I'll be glad to help answer constructive questions in regards to ensuring you have the correct variables, or discussing any of the information at hand. Please make sure you've fully read all of the available material before asking questions which have already been outlined.
I hope this guide helps people get the most out of their CS:S gaming experience, and clears up some misconceptions about Source netcode.
With a little patience and time, you can ensure your client is setup as best as possible, to deliver the best possible results in your gaming.
Good luck!
Gaming Admin. PM 
