FAQ: Guide to Rates, FPS, and Tickrate.

CS 1.6, DoD, TFC, etc.
Locked
User avatar
bOoya
Former staff
Former staff
Posts: 886
Joined: Thu Jan 15, 2004 3:46 pm
Location: Corona, CA
Contact:

FAQ: Guide to Rates, FPS, and Tickrate.

Post by bOoya » Mon Feb 21, 2005 7:03 pm

One of the most important features of gameplay is the overall smoothness of the game. Lots of times people notice their connections to certain servers become choppy; even to the point of un-playability. Its also noticeable that this choppiness varies from server to server; and will inherently lead you to believe that something is wrong with one of the servers.
Now I wont say always, but 99% of the time, this is false.
The problem of choppiness or "choke" as its known, is almost always related directly to the client side rates. specifically, "rate", "cl_updaterate", and "cl_cmdrate".
Let me explain:
  • cl_updaterate (Counter-Strike default is 20; most players use 75-100)
The updaterate is basically the rate at which the client (you), requests information from the server. Typically, the HLDS (Half-Life Dedicated Server) doesnt send all that much data per second, so the cl_updaterate command isnt devestatingly crucial. However, the instant you have a server hooked up to a large amount of bandwidth, or you have a server that is "accelerated" it starts sending gobs and gobs of data, often too much data for the clients to handle. Generally, this is the cause of choke. The server senses that it will soon max the clients allotted dataflow (based somewhat on the "rate" setting) and holds back a certain amount of data (which is then displayed as choke and choppiness). One of the best things about this game we call counter-strike is the ability to limit the updaterate! Of course, this is using the cl_updaterate command. A typical "optimal" updaterate is ~45. This can always be adjusted up or down a few at a time untill you either start getting too much choke, or untill the choke goes away. Notice that most players use updaterates of 75-100; this is really unfortunate since these rates will actually decrease the quality of their game, as long as the server is even capable of sending them that much data :wink:.
  • cl_cmdrate (Counter-Strike default is 30; most players use 80-100)
The cmdrate can be described as the rate at which the client sends data to the server. As you can tell, this is most closely dependent on the upload speed of your internet connection. A typical broadband connection (~1.5mpbs and up) can handle cl_cmdrates in the 80-100 range, assuming all other internet traffic is kept to a minimum. Obviously, if you are on a dialup or longrange DSL connection, you might have to lower this rate inorder to lower your ping. Have you ever noticed that while either you or someone on your home network is uploading a file to the web, your CS lags absolutely horribly? Well, the same type of thing applies here. If you are noticing higher-than-norm latencies, try lowering your cmdrate a bit to compensate. On the flipside, if cmdrate is too low for your connection, you might notice choppiness in other aspects of the game, such as voicecomm.
  • rate (Counter-Strike default varies)
The "rate" command is the the actual speed of dataflow between the client and server. You can find charts for this all over the place, such as the one in the STEAM client settings window (accessable through your steam main menu). Typically, a fast broadband connection can be set all the way up to 20000, which is a standard max that most servers allow. Now as I mentioned before, the cl_updaterate command simply controls the volume of data requested by the client. So, it makes sense that having a high "rate" along with a high "cl_updaterate" is potentially very problematic.

Now, there's one other rate that you may have heard of called "ex_interp".
ex_interp by itself really doesnt do anything, but is good to adjust depending on your settings for your other rates. Generally, the higher your updaterate/cmdrate values, the lower your ex_interp should be.
For example, if you're one of the lucky few who can handle 100, 100, 20000; your ex_interp should be around .01. If you have more conservative rates like 50, 75, 15000; try ex_interp ~.05. As a rule, interp shouldnt be set lower than .01 nor higher than .1.

[Important]
To set all these rates, use your ingame CS console. Current rate settings can be viewed by entering just the command itself. See this picture for an example.

Using the proper client rates will help you get the most out of your internet connection and improve your game. If you are having lag problems that dont appear to be rate-related, please preform a tracert and send it to us, as outlined on the "Trace" page in your control panel and here.
Last edited by bOoya on Tue Jul 19, 2005 12:14 pm, edited 1 time in total.

User avatar
Edge100x
Founder
Founder
Posts: 12285
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

Post by Edge100x » Mon Feb 21, 2005 9:58 pm

Here's my take on it.

An "update" contains messages to the server with event(s) such as lateral movement, firing, jumping, turning, switching weapons, using the flashlight, etc.

cl_updaterate specifies the number of updates per second the client would prefer to get from the server. There are corresponding commands sv_maxupdaterate and sv_minupdaterate on the server side to limit what the client can request. If the updaterate is too low, gameplay may not feel as responsive, since there could be extra delay in sending time-sensitive data (though the ping will appear lower); too high, and the extra updates might overwhelm the client connection or machine, causing some of the less-important messages to be ignored (this is called choke).

cl_cmdrate is similar to cl_updaterate, but in the reverse direction. It represents the number of updates per second the client can send to the server. There are no server-side variables to control what cmdrates are allowed.

rate represents the number of bytes per second that can flow between server and client. This variable is necessary because UDP cannot intrinsically compensate for packetloss, and therefore can't determine the speed of a link on its own. The server can control what rate clients can use with the commands sv_maxrate and sv_minrate. If the rate is too low, choke (messages being held back) might occur because server feels it can't transfer all the necessary data to keep the game in sync. If the rate is too high, the game might try to send extra data that the connection can't handle and packetloss will be the result.

ex_interp determines how much guessing the client does between network frames. It's used to compensate for low cl_updaterate/rate settings by interpolating movement, making other players and objects move more smoothly. If you have a fast connection to an accelerated server, you may want to lower this since your client really shouldn't need to do much guesswork. Valve sets a lower bound on ex_interp at 0.05 in the engine, so setting it less than that will not be beneficial.

There are differences in behavior between accelerated servers and non-accelerated servers. Accelerated servers run at a higher server FPS (in the hundreds), while non-accelerated servers run at the win32 default FPS (around 64). This network FPS determines how often the server processes incoming data and sends it back out -- just as a higher update rate can make gameplay seem more responsive, so a higher FPS can make the server more responsive (and lower latency). One must be careful, because with a higher server FPS there can also be problems with too many updates needing to be sent to the client (since they are generated so often) -- it is important to have a high enough rate to handle them, and a low enough cl_updaterate so that the client doesn't get overwhelmed. By the same token, with non-accelerated servers, the client must be careful not to set cl_cmdrate too high, since that means more updates to the server per second and could cause something similar to choke on the server side.

We recommend using an accelerated server any time that there is a lot of data flying back and forth, and any time a high cl_cmdrate is critical, because the accelerated servers processes updates faster and can better keep up. That's why on the Price/order page we say "Highly recommended, especially for match servers and large public servers".

Finally, the best way to determine which cl_updaterate, cl_cmdrate, and rate are best for you is to try some different values out. Connect to your public server when it's full and change them through your client console, or in the case of a private server, have a friendly scrim, pull down the console and make adjustments when you're dead to see how it affects choke, packetloss, and the overall "feel" in the next round of the game.

User avatar
Edge100x
Founder
Founder
Posts: 12285
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

What tickrate does in CS:S

Post by Edge100x » Tue Mar 08, 2005 2:03 pm

Tickrate determines the number of world updates that the game performs per second. A world update is when the game recalculates everything from player positions, to where shots are firing, to objects that might be moving in the map.

This is different from server FPS, which determines how many input polls the server makes per second. When it polls, it makes a note of player commands, but it does not act on most of them until the next tick (world update).

In CS 1.6, the server tickrate and FPS were linked together and essentially synonymous, since changing the value of sys_ticrate affected both of them. In CS:S, they are not -- the server's tickrate is set on the command line, and its FPS is set in-game using the fps_max cvar.

Ping acceleration works by raising the maximum number of ticks and frames the server can process per second. On a nonaccelerated server, the tickrate could be set to 100 and the fps_max could be set to 1000, but the server would still only be able to process at most about 64 of each per second. In contrast, an accelerated server has a much higher limit, somewhere in the hundreds. This is why our CS 1.6 servers have a default sys_ticrate of 500 but only have a higher FPS/tickrate when accelerated, and this is why we can only offer a higher tickrate in CS:S for servers that are on accelerated boxes.

I would recommend using a tickrate of 66 on accelerated CS:S servers, because otherwise only your server FPS is higher than normal, and you're not getting the full value out of the ping accelerator. But, this can cause some game glitches, so you should test it carefully. (We no longer recommend using a tickrate of 100 for performance reasons.)

User avatar
Nick|NFo
Former staff
Former staff
Posts: 2252
Joined: Sun Mar 30, 2003 1:56 pm
Location: 127.0.0.1

Post by Nick|NFo » Sat Jun 04, 2005 7:59 am

Martin Otten, Valve Employee from HLDS Mailing List wrote:With tickrate 100, a CS:S server runs 3 times more simulation steps then
a 33 tickrate server, which may cause a 3 times higher CPU usage. Also
the client to server bandwidth increases by 300% since the client
samples 3 times more input command than usual. I think with the recent
fixes for lag compesentaion tickrate 100 isn't really needed, maybe 66
if people are hypersensitive about that.
Last edited by kraze on Thu May 23, 2013 8:55 pm, edited 1 time in total.
Reason: Link was dead, removed it.
-Nick

User avatar
Edge100x
Founder
Founder
Posts: 12285
Joined: Thu Apr 18, 2002 11:04 pm
Location: Seattle
Contact:

Post by Edge100x » Fri Jul 01, 2005 10:44 am

Martin did oversimplify it a bit there. It doesn't use quite 3 times the CPU, and it doesn't use quite 300% of the bandwidth, but close.

Locked