During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. A higher tickrate increases the simulation precision, but also requires more CPU power and available bandwidth on both server and client. When a client connects to a server, the clients Source Engine matches the SRCDS (Source Dedicated Server) tickrate that the client connected to.
* Server tickrate 128 = Client tickrate 128
* Server tickrate 64 = Client tickrate 64Rate
Max bytes/sec the host can receive data.
This is the maximum amount of bytes per second that you use to transfer data. The hard coded upper limit in the source engine was previously 30000 bytes, which converts into 29.297 kilobytes.Cl_cmdrate
Max number of command packets sent to server per second.
This variables determines how many times you update the location of yourself and the things you do within the world. Setting this to 128 on a server with 128 tickrate server would normally mean that you get the full amount of update that is possible with the Source Engine, but this is often not the case. Server performance is the factor in what you see in net_graph 3's IN, if it's not at 128 (As in when it can't hold it at all, not just a small deviation from the number for short periods of time) then it's typically safe to say that the server can not sustain the tickrate because of either bandwidth or CPU requirement. (Most commonly an overloaded server host with too many game servers running off the single PC host AKA 'box'). Assuming the server and your own internet connection was able to handle it though, setting cl_updaterate 128 will mean that you get the full amount of updates as it is not bound by your own FPS in any way. You will want to keep this the same value of cl_cmdrate though, to avoid choke. More on choke later. The new hard coded maximum rate is 1048576 bytes, which works out to be 1024 kilobytes. Keep in mind however, that Valve only implemented this for Local Area Network environments and sv_maxrate 80000 is still the recommended and encouraged value for online servers to use.Cl_updaterate
Number of packets per second of updates you are requesting from the server.
This variables determines how many times you update the location of others around you. Since a servers tickrate will never exceed 128 in the source engine (Tickrate being the amount of times the server will update the 'world' per second), you will never have any need to set this variable above 128 as you can not exceed the amount of updates that the server allows. This cvar (Console Variable) is also directly proportional to the amount of Frames Per Second (FPS) that you get, as you can not update your own position more than one time per each and every frame. This very basically means that you don't need to get any more than 128 frames per second on a server with a tickrate of 128. This doesn't mean you should just set fps_max to 128 either, but more on that later.Fps_max
Frame rate limiter.
The frames per second limiter. The value you give it, will always return -1. EG: If you define 64, it will always hold 64. Since cl_cmdrate limits itself off the current amount of frames you get. I personally use 128. This should be set to the value of your monitors Hz (Usually 60/75/80/100), Any higher and you are making your PC work harder to render frames you can't even see.Choke
Choke is quite simply the server wanting to send an update to the client, but cannot.
It can be hard to completely remove choke on low end PC setups but if it's as low as you can get it, then that's about the best you can do.
The following is a list of (but is not limited to) the things that cause choke.
* If the server cannot sustain the tickrate, you get choke (You may not actually get choke, but the server will lag very badly).
* If the server cannot sustain the fps the tickrate requires, you get choke.
* If the server cannot sustain the fps the sv_minupdaterate requires, you get choke.
* If the server cannot sustain the the sv_minupdaterate, you get choke.
* If the server connection cannot sustain the bandwidth required to support the updaterate, you get choke.
* If the server connection cannot sustain the bandwidth required to support the sv_minrate, you get choke.
* If the required bandwidth demanded by the sv_maxupdaterate exceeds the sv_maxrate, you get choke.
* If the clients connection cannot sustain the bandwidth required to support the cl_updaterate you get choke.
* If the clients required bandwidth demanded by the cl_updaterate exceeds the rate, you get choke.The main variables...
There are cvars you will need to touch and ones to stay away from.
There are three main cvars that you should concentrate on:
Rate - The value of this is from 0 to 30000, 30000 being the typical online maximum.
Cl_cmdrate - The value of this is from 0 to 100.
Cl_updaterate - The value of this is from 0 to 100.
While there are other variables such as interp, it really is best to leave this alone unless you 100% know what you're doing.
If you do think you are that sure, then why are you reading this? :jerk:Choosing what's right for you.
How can you tell which are the best rates to use?
Grab and install PingPlotter Freeware
, get an IP of a server that has a tickrate of 66 (..and of course is geographically close to you!), set the trace delay down to 1 second and leave that running for two minutes. If everything looks fine, with pings in the green and packet loss at none, you now have a guideline to go off that it's not you having ISP issues and can leave you to focus on correctly adjusting your rates.
There are now two other scenarios:
* Your pings are high to the server or you're getting packet loss but this only occurs over half way down the trace
* Your pings are high or you're getting packet loss from the second/third 'hop'
If you've encountered the first issue, you've got a connection problem to the server and there's nothing you can do about this. Find another server or wait for the issue to be resolved. Just be aware that this could take a long time (Weeks!), so don't count on it being fixed by the next day.
If you've encountered the second issue with various servers, your problem is with the Internet Service Provider (ISP) that you're using. You will need to seek help with them. You can start by gathering information using PingPlotter to provide evidence that will help them resolve your issue.If either of these scenarios apply to you, this guide along with adjusting your rates will do nothing.
Now assuming that you haven't encountered the aforementioned two scenarios, launch your Source Engine (SE) game of choice (EG: Half-Life 2 Deathmatch), enable net_graph 3 via console (Keyboard > Options > Advanced > Enable Developer Console) on a server with a tickrate of AT LEAST 66 (Practically all servers from GameServers.com
have a tickrate of 66). This will show two things that you need to read - loss and choke.
You need to aim for absolutely minimal choke as possible, with next to no loss. Choke means that the server is sending you updates, but your rates are making you disregard them (EG: You're using 30000/66/66 and the server has max rates of 30000/100/100 - this means you'll be getting a choke of 34.. at least that's the theory because you have to disregard the updates as you're using as much as you already can). Loss is actual updates being lost between you and the server and is something you need to absolutely avoid as much as possible - assuming the problem does indeed lie on your end in the first place.
Optimally, you will want to use the following rates on a 100 tickrate server: rate 30000;cl_cmdrate 100;cl_updaterate 100. Try them and see if you get loss in the net graph. However, do not try this if you don't have AT LEAST 128k upload dedicated to your own PC playing your SE game of choice, as running 30000/100/100 on a 100 tickrate server will utilize almost all of the upload bandwidth you have to spare. You can also try running rate 20000;cl_cmdrate 66;cl_updaterate 66 if the above fails.
The next step down is rate 15000;cl_cmdrate 45;cl_updaterate 45. This is the absolute minimum you'll want to use on a broadband connection.Making the most of what you have.
You have one of the rate values that has been suggested, but you want to make the most out of that.
Remember that you need to keep in mind that you need to aim for absolutely minimal choke as possible, with next to no loss. With this in mind, you'll want to increase rate by 2500 each time (15000 > 17500 > 20000 > Etc), cl_cmdrate and cl_updaterate by 10 and then keep your eye on the net graph. When you've got as minimal choke as you can get with no loss (Along with the rates being as high as possible), then you've hopefully hit the sweet spot that you've been looking for. This can be a long and tedious process, but this what most people need to do in order to find what rates suit their internet connection speed.
Note that you won't get updates higher than
1. The servers tickrate.
2. The servers sv_maxupdaterate.
3. As fast as your server fps allows (Limited by fps_max, hardware and the servers' Kernel Timer Resolution).
4. As fast as your servers sv_maxrate allows.
5. As fast as the client/server connection allows.
6. As fast as the clients rate allows.
7. As fast as the clients cl_updaterate allows.
8. Client FPS controls how fast the client can send updates to the server, this the OUT on the net_graph 3.Fixing Choke
Besides setting your steam internet connection settings correctly, the only two variables that are going to really help the clients choke problems are rate and cl_updaterate.
* If in doubt about your Steam Internet Connection Setting, set it 1 higher than what you have.
* If you are getting choke and the output on [Tickrate#Net_graph_3_Explanation net_graph 3] is lower than what you expect, then raise your rate.
* The blame may not always be with you, the client! Try another server that's close by, and see if that makes much difference.
* Finally, don't bugger around trying to fix choke problems if you have loss problems. You are just wasting your time and everybody else's if you ask them to help fix your choke problems if you have LOSS!!! Loss is a network problem, that being a problem BETWEEN YOU AND THE SERVER. (See point 6. of the [Tickrate#Net_graph_3_Explanation net_graph 3] explanation)
The bare minimum you will want to use is rate 7500;cl_cmdrate 35;cl_updaterate 35. You should only run this if you absolutely have to, because you're disadvantaging yourself by running rates that are this appalling. Generally, this is what users of IDSN/56k should use if they insist on playing on a connection with such inadequate bandwidth for the games they're trying to play. Net_graph 3 Explanation
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. IN is what is being received by you the client, FROM the server.
3. OUT is what is being sent by you the client, TO the server.
4. 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.
5. 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.
The IN & OUT both have 3 components, starting from left to right:
* The average amount of kilobytes per second being sent or received of gamedata + UDP packet overhead (28 bytes)
* The size of the last game packet in bytes being sent and received as a rolling average (Includes UDP packet header overhead)
* The average amount of updates being sent or received per second (This one is the important one for you to be reading!)
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
There is a quirk in net_graph 3 that occurs when the average updates sent/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 screen shot was taken above, but this only occurs because lines 2 and 3 update twice per second and therefore what you see are averages that aren't always in sync with the server.Autoexec Startup Script
Making your rates stay when you restart your game.
Note down the values of rate, cl_cmdrate and cl_updaterate. Now browse to the folder on the hard drive that has Steam installed to (EG: C:\Program Files
), note the username of the current account you're logged into, typically referred to (Username
) or (email@example.com
) and then find the mod folder for your game of choice
(EG: C:\Program Files\Steam\SteamApps\Username\half-life 2 deathmatch\hl2mp\
) and look for a folder named 'cfg'. Open that folder and then before you do anything, make sure you can see filename extensions by going to the top toolbar and clicking on 'Tools', followed by 'Folder Options'. Then look for the tab that says 'View' on it and click it. Look for the option that says 'Hide extensions for known file types', disable this by clicking on the tickbox and then hit the 'OK' button. Now, download and install Notepad++
and be sure to associate the application with 'txt' files and 'cfg' files, then create a blank file and name it autoexec.cfg making sure it DOES NOT have a .txt extension on it. Open the file with Notepad++
editor and edit it with your rates then save it.
Use one console command per line, so it would look something like the following:
Then throw in the following line:
echo "Autoexec loaded..."
This is just a safety measure to know when the configuration file has loaded when you start up your game of choice, which will be visible in console. Your new found rates will now stick and you should hopefully be able to be more accurate while playing your game of choice and therefore be more enjoyable.Frequently Asked Questions
All those lingering questions that need to be answered. Most of which are already covered in the guide.
Q. Why is the maximum value of rate 30000 online?
A. This was the original hard coded maximum in the Source Engine. The sv_pure update however allows for a higher maximum rate, but is only to be used in a Local Area Network environment. It is NOT advised that you use anything above 30000 for online game play.
Q. Why is the maximum value of cl_cmd/updaterate 100?
A. This is because of the server tickrate and how it will never exceed 100. You can't send/receive more updates than the current servers tickrate!
Q. Why should I run higher rates in the first place?
A. So your shots are MUCH more accurate, instead of having to spray bullets to hit someone. Using less bullets is always a good thing!
Q. Why should I keep the value of cl_cmd/updaterate the same?
A. Take this example: If your updates are lower than you send, you would receive some information saying enemy player X is nearby. You go to shoot and send that information off. Before the server does anything (Such as confirm the shot), blood will get displayed on your side on the other player. When the server receives the shots, it will check the enemy player position and most likely say 'That player isn't there any more - you were too slow' because you were acting on old information.
Q. Why does my ping stay nice and low when I'm using lower rates?
A. This is because of the size of the 'packets' you're trying to send, are smaller than what they'd be if you had higher rates. While lower would normally be better, your true round trip ping (From you, to the server and back) is displayed in net_graph 3 and won't change drastically unless your connection can't handle the bandwidth.
Q. What is this 'hit registration' that people speak of?
A. When you aim directly at your enemy and shoot, good hit registration means your 'hits' (Bullets, etc) actually make contact and count with the other player you're shooting at. Better hit registration means you can be much more accurate and use less bullets to kill the other player. This is basically the whole point of this guide, to better this issue.
Q. I see people using a high rate, but low cmd/updaterates or vice versa. Should I do the same?
A. No. These people are absolutely misguided on which rates they should use. Stick to what has already been suggested in this guide.
Generally, this is a decent rule of thumb to go off:
* rate 30000, cl_cmdrate 100, cl_updaterate 100 for maximum of rate 30000.
* rate 30000, cl_cmdrate 66, cl_updaterate 66 for minimum of rate 30000.
* rate 20000, cl_cmdrate 66, cl_updaterate 66 for maximum of rate 20000.
* rate 20000, cl_cmdrate 50, cl_updaterate 50 for minimum of rate 20000.
* rate 15000, cl_cmdrate 50, cl_updaterate 50 for maximum of rate 15000.
* rate 15000, cl_cmdrate 35, cl_updaterate 35 for minimum of rate 15000.
* rate 7500, cl_cmdrate 35, cl_updaterate 35 if your rate is set to 7500 or below.
Q. Many people speak about cl_interp and how it should be at 0.01, should I use this?
A. ABSOLUTELY NOT. You should set your cl_interp_ratio to 1, so you can get an accurate interp value based off your rates (Final value works out to be your cl_interp_ratio value divided by your cl_updaterate to make the final value). Many people think that you should use 0.01, although this would only disadvantage yourself UNLESS you had a latency under 10 to the server on the net graph, was able to send & receive 100 updates a second and if the server tickrate was at 100.
Q. What's my true ping? The scoreboard and net_graph contradict each other!
A. Ping is a one way trip from your computer to the game server, this is displayed on the scoreboard. Lowering your rates means you're sending a smaller packet to the server and hence is lower (Although not good when you actually want to hit and kill the enemy!). Net_graph shows the latency between you and the server - the ping from you being sent to the server, the server receiving this and sending a ping back to you. The entire time for this 'round trip' is then displayed in your net graph.
Q. I heard some person state that you should get your cl_cmd/updaterate to match your average FPS, is this true?
A. Not quite. Cl_cmdrate will not send updates any more than your current FPS as you can't send more than one update per single frame. FPS is something that wildly fluctuates though, so set it as you would - based off how high you can go before the net graph starts to show choke/loss.
Q. Elsewhere, I've heard that I should match cl_cmd/updaterate to the same value of what my monitor HZ is (EG: 60/75/85/100), should I?
A. No. While your monitor might not display the updates when the FPS are higher than the monitor HZ, the game won't know the difference. Any legitimate advantage is a good advantage, no matter how small it may be!
Q. What the hell is tickrate?
A. Epic Fail! Read the guide again word for word and stop wasting my time.
Q. I'm on IDSN/56k and this guide still doesn't help me!
A. The Source Engine wasn't really designed with IDSN/56k in mind, so don't play the game at all until you can get a better connection. That or just put up and shut up.
Q. Someone else is warping around while playing, what are they doing and what should I do?
A. They are intentionally using very low rates or their ping is very high (200+). If their ping is low and they're warping around, spread the word about this guide and help them fix their rates. Generally, saying that they should use 'rate 20000 cl_cmdrate 66 cl_updaterate 66' will be adequate enough - even though their changes won't stick after they restart the game, so it's honestly a lost cause to not direct them to this guide.
Q. My friend told me that if I set my cl_cmdrate to +100 that I will have a ping of 1 and I wont lag or be kicked from a server for having a high ping. Is this true?
A. Okay first off :stupid: Secondly, it only mask your true latency it will not actually change it, nor will it keep you from lagging or keep you from being kicked from a server for having high ping. If you have high ping and you are being auto kicked from a server simply ask an admin of the server to give you ping immunity. Third, it actually makes you lag more as you are not sending enough information to the server, it makes your shots have poor registry and will decrease your killing ability. And finally, it will get you banned from any server I run or admin for. :ban: There is no way for a player to have a latency of 5 or less unless they are hosting the server they are playing on.
Q. This guide has helped a lot, thanks! What can I do to help?
A. Spread the word about this guide and raise awareness on people using low and/or default rates.