Up to date version can be found here: http://whisper.ausgamers.com/wiki/index.php/Tickrate
Definitions
tickrate: From Valve: 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.
THE ONLY PLACE YOU CAN CHANGE THE TICKRATE IS VIA THE COMMAND STARTUP LINE. NO, THERE IS NO WHERE ELSE, GOT IT?
Client fps: is the number of times per second the game checks for inputs either from keyboard/mouse and incoming game packets, basically any I/O operation.
Server fps: because there are no keyboard or mouse I/O's occurring, it only deals with how often the server checks for game packets.
sv_maxrate: The Maximum amount of data in Bytes per Second the server will send to the client. Conversely, the Maximum amount of data in Bytes per Second the Client can request from the Server. sv_maxrate overrides the clients rate setting if sv_maxrate is less than the clients rate setting.
sv_minrate: The Minimum amount of data in Bytes per Second the server will send to the client. Conversely, the Minimum amount of data in Bytes per Second the Client can request from the Server. sv_minrate overrides the clients rate setting if sv_minrate is greater than the clients rate setting.
sv_maxupdaterate: The Maximum amount of Update per Second the server will send to the client. Conversely, the Maximum amount of Updates per Second the Client can request from the Server. sv_maxupdaterate overrides the clients cl_updaterate setting if sv_maxupdaterate is less than the clients cl_updaterate setting.
sv_minupdaterate: The Minimum amount of Update per Second the server will send to the client. Conversely, the Minimum amount of Updates per Second the Client can request from the Server. sv_minupdaterate overrides the clients cl_updaterate setting if sv_minupdaterate is greater than the clients cl_updaterate setting.
rate: The Maximum amount of Bytes Per Second the Client will request from the server. rate overrides the servers sv_maxrate setting if rate is less than the servers sv_maxrate setting.
cl_updaterate: The Maximum amount of Updates Per Second the Client will request from the server. cl_updaterate overrides the servers sv_maxupdaterate setting if cl_updaterate is less than the servers sv_maxupdaterate setting.
cl_cmdrate: The Maximum amount of Updates Per Second the Client will Send to the server.
NB: sv_maxupdaterate and cl_updaterate cannot cause more data to be sent to the client than the sv_maxrate and rate settings allow, or the servers, or most likely the clients actual available bandwidth allows. Choke occurs when either;
The servers sv_maxupdaterate causes the amount of bandwidth to exceed the bandwidth allocated per client by sv_maxrate or the total amount of bandwidth the server has access to,
Or
The clients cl_updaterate causes the amount of bandwidth required by the client to exceed the clients rate setting or the total amount of bandwith the client has access to.
More Info here: Valve's Source Multiplayer Networking Explanation
Instructions
1. tickrate is set by adding the -tickrate 100 (for a tickrate 100 server) in the command line start up parameters. Tickrate cannot be changed on the fly via console, HLSW or rcon, it can only be changed in the commandline and the server must be restarted for the change to take effect.
2. If you want your tickrate changes to have any noticeable benefit you must change a few other server variables as well as change the Windows Kernel Timer Resolution (pingboosting)
3. To change the Windows Kernel Timer Resolution (pingboost a server) all you need to do is run Windows Media Player. It does not need a file open, it just has be running in the background, if you do not do this, your servers fps will be limited to around 64 frames a second.
You can also use a little app that somebody wrote, which you can find here: srcdsfpsboost.zip
The file now includes the Source Code so you can compile it yourself if you wish and I can confirm that the version is safe.
Thank you needforspeed for the source code
Thanks to trog for compiling it
4. The servers fps can be seen by issuing the stats command in console or via HLSW or via the RCON STATS if you are logged in via rcon on the server.
5. The server fps is regulated by the fps_max command. The default is 300, which, for whatever reason ends up producing around 250 fps in RCON STATS. Don't ask me why, I've asked Valve, but the next step up is to run your fps_max at 600 so you then get 500 fps in RCON STATS. It can be set somewhere between 500 and 600 via console or HLSW and permanently by adding the commandline parameter +fps_max 600 but if you set it at 500 you will see that your FPS according to RCON STATS will still sit at 250 fps even after a map change, so you must set your fps_max higher than what you actually want to achieve the desired affect. Don't take my word for it, test it yourself!
6. So you have a high tickrate, your server is pingboosted and is running at high fps, none of this is of any use to your clients (the players) if you do not change your servers rates, specifically the sv_maxrate and sv_maxupdaterate variables.
7. sv_maxrate by default is set to 0, I personally have found that this setting is detrimental to server performance (purely subjective opinion, but there you go, feel free to ignore it until your clients start complaining about stupid lag and player warping issues that don't correlate to any actual network or cpu usage or over usage issues as the case may be) then set your sv_maxrate to 20000
8. sv_maxupdaterate (default 60) setting must be changed to start using all this server generated data more effectively and get the data out to your players who want to run 101/101/20000/10000 cl_cmdrate/cl_updaterate/rate/cl_rate (yes I know cl_rate is defunct but some people can't be told so I humour them and leave it in) settings, thus you need to change your sv_maxupdaterate to something like 1.2 times tickrate. You only have to do this if you run a tickrate higher than 50. eg for tickrate 66 run sv_maxupdaterate 66 or even 100, for tickrate 100 run sv_maxupdaterate 100. If you do not do this, your clients will NEVER see the full benefit of your tickrate changes, and even then, because of server load the clients will not see the full sv_maxupdaterate or tickrate reflected in a net_graph 3.
9. Do not run tickrate higher than 100, Valve have admitted that there will be issues if you push the tickrate too high.
10. Make sure you have the bandwidth and CPU to cope with SRCDS running with these settings. If you don't have at least a 10Mbps Full Duplex link , you probably do not have the bandwidth to see the full benefit of following the above instructions. This is aimed at people with servers in dedicated data centres with appropriate high speed Internet connections. Most home users will not have the necessary bandwidth or hardware to take full advantage of ALL of these settings. You may though be able to increase your end users overall experience, just by pingboosting your server and increasing the tickrate and fps_max whilst leaving the sv_maxrate and sv_maxupdate rate settings low.
11. 24, 32 & 40 player servers should be run with a tickrate of no more than 66 and sv_maxupdaterate of 100. I've tried higher but you get strange issues for the clients if you do.
12. The fps_max setting of 600 does not appear to hit the CPU as hard as other settings I have mentioned here do, your mileage may vary, but try reducing this back to default of 300 if your clients get strange lag issues and you have tried reducing the other server variables mentioned here. i.e. Change this one last!
13. For competition servers, or any server at the 18 player or less mark, then you should be able to use a tickrate of 100 and an sv_maxupdaterate of 100 successfully without any issues, so long as you have the bandwidth and CPU to cope!
14. For changes to take affect, the settings must be changed in the server.cfg file (except tickrate & fps_max which should be command line variables) and the server restarted, or if done via RCON, a map change must be done.
15. This information is for Windows Source Dedicated Server only, do not ask me about LINUX, I cannot help you.
16. This was written on the basis that your SRCDS is a default SRCDS Installation with no Mods/Plugins or Non-Standard anything else, such as sounds, skins, maps etc on the server. Using them (Mods/Plugins) will increase CPU utilisation and thus limit the final result. Obviously you need to monitor these for your particular situation.
17. Finally, you need to actually play on your server for several hours with all SRCDS processes full to see if there are any issues that do not show up by normal performance monitoring tools, to ensure everything is running ok. Subjective in game experience can deviate significantly from Objective Server Statistics, thus you will not know there is a problem unless you are on the server playing at the time it happens.
18. Sample SRCDS Command Startup Line:
Summary:
< 20 Player servers
-tickrate 100
sv_maxrate 20000
sv_maxupdaterate 100
fps_max 600
> 20 Player servers
-tickrate 66
sv_maxrate 20000
sv_maxupdaterate 66
fps_max 600
Make sure you have the CPU and bandwidth to cope
Server Bandwidth Calculation for Dummies:
sv_maxrate and rate are the 2 variables that decide the maximum amount of bandwidth each player will use. Both are measured in Bytes per Second, so an sv_maxrate of 20000 = 20,000 Bytes per Second! A Rate of 15000 = 15,000 Bytes per Second.
Network Speeds are by convention quoted on bits per second, whether Kilobits (Kb) 1,000 bits, Megabits (Mb) 1,000,000 bits or Gigabits (Gb) 1,000,000,000 bits.
The other convention is b is for bit, B is for Byte, it is important not to confuse the two.
In any case, to calculate the minimum amount of upload bandwidth your server must have, you multiply your sv_maxrate by the number if players on the server. Thus a sv_maxrate of 20000 with 20 players will require at least 20 * 20,000 = 400,000 Bytes per Second of Bandwidth. I say at least, because your theoretical maximum upload speed is just that, theoretical, and you will find that most connections will not sustain their theorectical maximums for long periods of time, which is exactly how GameServers must operate to provide a positive end user experience.
Now going back to our example, we have calculated that you are going to require at least 400,000 Bytes per Second of Bandwith to serve 20 players effectively. We now need to convert this to normal Networking conventions, so we can compare apples with apples. To do this, the calculation for this example is as follows:
400,000 Bytes * 8 bits / 1,000 = 3,200 KiloBits/Second (3,200Kbps) or 400,000 Bytes * 8 bits / 1,000,000 = 3.2 Megabits/Second (3.2Mbps)
Whatever Bytes Per Second you have, you need to convert that into a bit speed, by multiplying it by 8 (8 bits = 1 Byte) and then convert that into either kilobits or megabits, by dividing by 1,000 for kilo or 1,000,000 for mega to give you a value in Kilobits per Second (Kbps) or Megabits per Second (Mbps), whichever is easier to read.
Please realise that your X Mbps connection maybe rated very close to what you need, but it is nearly always necessary to leave an overhead of between 10%-25% to make sure the server can always cope. So an sv_maxrate 20000 server with 20 players is probably going to require a 4Mbps Upstream Connection to adequately cope with the load.
sv_maxrate * {player number} * 8 / 1,000 = Minimum Upstream Speed in Kbps your server requires.
This calculation will work for mulitple SRCDS processes on the one physical server.
If you want to turn this calculation around, and wish to calculate the maximum theoretical sv_maxrate your server can run for a given upload speed (in kbps) and player number, the calculation is as follows:
upload bandwidth in kilobits per second / 8 * 1000 / player number = the theoretical maximum sv_maxrate you can run your server at.
This Calculation only works for a single SRCDS process on a single physical server.
Hopefully now, you can all work out just how much Upstream Bandwidth your server requires for any given sv_maxrate, upstream bandwidth and player number values.
Here is a little table I've thrown together if it is still too hard for you!
Hardware Spec Example:
We run 6 x 16 Player SRCDS on DUAL Xeon 3.0GHz (or better) Servers with 3GB of RAM with 100Mb Switched Network Connections into 1Gbps or 10Gbps BackBones with a 66 tickrate. So when I say good hardware with good Network Connectivity, this is the benchmark I am basing my opinions on.
Suffice it to say we could probably run 4 x 12player 100 tickrate servers, BUT although the difference between 33 tickrate and 66 tickrate is the difference between night and day, the difference between 66 tickrate and 100 tickrate is negligable on the Internet, when all issues are taken into consideration. Also some maps and player numbers caused intermitant issues at 100 tickrate that a GSP does not really want to have to worry about, especially when you can have 6 x 16 player servers that run excellently at 66 tickrate!
In conclusion:
I hope this helps clear up some of the mystery of setting up a server with high tickrate, don't worry if it does not, I am still asking questions myself.
------------------------------------------------------------------------------------
THE MAIN CAUSE OF BAD CHOKE IS A CLIENTS STEAM INTERNET CONNECTION SPEED BEING SET INCORRECTLY
Please ensure that all clients STEAM Internet Connection Speeds are setup correctly.
http://whisper.ausgamers.com/choke/steamchoke.htm
Notes regarding Netgraph Updates per second measurements you need to be aware of:
You won't get higher updates than;
a) The servers tickrate
b) The servers sv_maxupdaterate
c) As fast as your server fps allows (Limited by fps_max, hardware and the Windows Kernel Timer Resolution)
d) As fast as your servers sv_maxrate allows
e) As fast as the clients rate allows
f) As fast as the clients cl_updaterate allows
g) As fast as the client/server connection allows
h) As fast as the clients fps allows (Limited by fps_max, hardware, and Refresh Rate)
NB: Other than tickrate, Choke is caused by any of the above list of things not being large enough. This usually occurs because the sv_maxupdaterate or cl_updaterate being higher than the sv_maxrate or rate allows, since the server will not send more data per second than sv_maxrate or rate allows.
Special Thanks to Alfred Reynolds and Martin Otten for their input that helped me put this guide together.
Cheers
Whisper
Whisper's Very Basic Competitive Counter-Strike War Strategy Guide
P.S. If anybody else has any insights to share, then please do. I am more than happy to get some hard facts and reproducible results myself.
13October2005 Edit: Major Update to reflect changes on original STEAM Forum Post
01January2006 Edit: Added link to up to date wiki page
Definitions
tickrate: From Valve: 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.
THE ONLY PLACE YOU CAN CHANGE THE TICKRATE IS VIA THE COMMAND STARTUP LINE. NO, THERE IS NO WHERE ELSE, GOT IT?
Client fps: is the number of times per second the game checks for inputs either from keyboard/mouse and incoming game packets, basically any I/O operation.
Server fps: because there are no keyboard or mouse I/O's occurring, it only deals with how often the server checks for game packets.
sv_maxrate: The Maximum amount of data in Bytes per Second the server will send to the client. Conversely, the Maximum amount of data in Bytes per Second the Client can request from the Server. sv_maxrate overrides the clients rate setting if sv_maxrate is less than the clients rate setting.
sv_minrate: The Minimum amount of data in Bytes per Second the server will send to the client. Conversely, the Minimum amount of data in Bytes per Second the Client can request from the Server. sv_minrate overrides the clients rate setting if sv_minrate is greater than the clients rate setting.
sv_maxupdaterate: The Maximum amount of Update per Second the server will send to the client. Conversely, the Maximum amount of Updates per Second the Client can request from the Server. sv_maxupdaterate overrides the clients cl_updaterate setting if sv_maxupdaterate is less than the clients cl_updaterate setting.
sv_minupdaterate: The Minimum amount of Update per Second the server will send to the client. Conversely, the Minimum amount of Updates per Second the Client can request from the Server. sv_minupdaterate overrides the clients cl_updaterate setting if sv_minupdaterate is greater than the clients cl_updaterate setting.
rate: The Maximum amount of Bytes Per Second the Client will request from the server. rate overrides the servers sv_maxrate setting if rate is less than the servers sv_maxrate setting.
cl_updaterate: The Maximum amount of Updates Per Second the Client will request from the server. cl_updaterate overrides the servers sv_maxupdaterate setting if cl_updaterate is less than the servers sv_maxupdaterate setting.
cl_cmdrate: The Maximum amount of Updates Per Second the Client will Send to the server.
NB: sv_maxupdaterate and cl_updaterate cannot cause more data to be sent to the client than the sv_maxrate and rate settings allow, or the servers, or most likely the clients actual available bandwidth allows. Choke occurs when either;
The servers sv_maxupdaterate causes the amount of bandwidth to exceed the bandwidth allocated per client by sv_maxrate or the total amount of bandwidth the server has access to,
Or
The clients cl_updaterate causes the amount of bandwidth required by the client to exceed the clients rate setting or the total amount of bandwith the client has access to.
More Info here: Valve's Source Multiplayer Networking Explanation
Instructions
1. tickrate is set by adding the -tickrate 100 (for a tickrate 100 server) in the command line start up parameters. Tickrate cannot be changed on the fly via console, HLSW or rcon, it can only be changed in the commandline and the server must be restarted for the change to take effect.
2. If you want your tickrate changes to have any noticeable benefit you must change a few other server variables as well as change the Windows Kernel Timer Resolution (pingboosting)
3. To change the Windows Kernel Timer Resolution (pingboost a server) all you need to do is run Windows Media Player. It does not need a file open, it just has be running in the background, if you do not do this, your servers fps will be limited to around 64 frames a second.
You can also use a little app that somebody wrote, which you can find here: srcdsfpsboost.zip
The file now includes the Source Code so you can compile it yourself if you wish and I can confirm that the version is safe.
Thank you needforspeed for the source code
Thanks to trog for compiling it
4. The servers fps can be seen by issuing the stats command in console or via HLSW or via the RCON STATS if you are logged in via rcon on the server.
5. The server fps is regulated by the fps_max command. The default is 300, which, for whatever reason ends up producing around 250 fps in RCON STATS. Don't ask me why, I've asked Valve, but the next step up is to run your fps_max at 600 so you then get 500 fps in RCON STATS. It can be set somewhere between 500 and 600 via console or HLSW and permanently by adding the commandline parameter +fps_max 600 but if you set it at 500 you will see that your FPS according to RCON STATS will still sit at 250 fps even after a map change, so you must set your fps_max higher than what you actually want to achieve the desired affect. Don't take my word for it, test it yourself!
6. So you have a high tickrate, your server is pingboosted and is running at high fps, none of this is of any use to your clients (the players) if you do not change your servers rates, specifically the sv_maxrate and sv_maxupdaterate variables.
7. sv_maxrate by default is set to 0, I personally have found that this setting is detrimental to server performance (purely subjective opinion, but there you go, feel free to ignore it until your clients start complaining about stupid lag and player warping issues that don't correlate to any actual network or cpu usage or over usage issues as the case may be) then set your sv_maxrate to 20000
8. sv_maxupdaterate (default 60) setting must be changed to start using all this server generated data more effectively and get the data out to your players who want to run 101/101/20000/10000 cl_cmdrate/cl_updaterate/rate/cl_rate (yes I know cl_rate is defunct but some people can't be told so I humour them and leave it in) settings, thus you need to change your sv_maxupdaterate to something like 1.2 times tickrate. You only have to do this if you run a tickrate higher than 50. eg for tickrate 66 run sv_maxupdaterate 66 or even 100, for tickrate 100 run sv_maxupdaterate 100. If you do not do this, your clients will NEVER see the full benefit of your tickrate changes, and even then, because of server load the clients will not see the full sv_maxupdaterate or tickrate reflected in a net_graph 3.
9. Do not run tickrate higher than 100, Valve have admitted that there will be issues if you push the tickrate too high.
10. Make sure you have the bandwidth and CPU to cope with SRCDS running with these settings. If you don't have at least a 10Mbps Full Duplex link , you probably do not have the bandwidth to see the full benefit of following the above instructions. This is aimed at people with servers in dedicated data centres with appropriate high speed Internet connections. Most home users will not have the necessary bandwidth or hardware to take full advantage of ALL of these settings. You may though be able to increase your end users overall experience, just by pingboosting your server and increasing the tickrate and fps_max whilst leaving the sv_maxrate and sv_maxupdate rate settings low.
11. 24, 32 & 40 player servers should be run with a tickrate of no more than 66 and sv_maxupdaterate of 100. I've tried higher but you get strange issues for the clients if you do.
12. The fps_max setting of 600 does not appear to hit the CPU as hard as other settings I have mentioned here do, your mileage may vary, but try reducing this back to default of 300 if your clients get strange lag issues and you have tried reducing the other server variables mentioned here. i.e. Change this one last!
13. For competition servers, or any server at the 18 player or less mark, then you should be able to use a tickrate of 100 and an sv_maxupdaterate of 100 successfully without any issues, so long as you have the bandwidth and CPU to cope!
14. For changes to take affect, the settings must be changed in the server.cfg file (except tickrate & fps_max which should be command line variables) and the server restarted, or if done via RCON, a map change must be done.
15. This information is for Windows Source Dedicated Server only, do not ask me about LINUX, I cannot help you.
16. This was written on the basis that your SRCDS is a default SRCDS Installation with no Mods/Plugins or Non-Standard anything else, such as sounds, skins, maps etc on the server. Using them (Mods/Plugins) will increase CPU utilisation and thus limit the final result. Obviously you need to monitor these for your particular situation.
17. Finally, you need to actually play on your server for several hours with all SRCDS processes full to see if there are any issues that do not show up by normal performance monitoring tools, to ensure everything is running ok. Subjective in game experience can deviate significantly from Objective Server Statistics, thus you will not know there is a problem unless you are on the server playing at the time it happens.
18. Sample SRCDS Command Startup Line:
Code:
[color=blue]C:\srcds\srcds.exe -console -game cstrike -tickrate 66 +fps_max 600 +maxplayers 18 -port 27015 +exec server.cfg +map de_dust2[/color]Summary:
< 20 Player servers
-tickrate 100
sv_maxrate 20000
sv_maxupdaterate 100
fps_max 600
> 20 Player servers
-tickrate 66
sv_maxrate 20000
sv_maxupdaterate 66
fps_max 600
Make sure you have the CPU and bandwidth to cope
Server Bandwidth Calculation for Dummies:
sv_maxrate and rate are the 2 variables that decide the maximum amount of bandwidth each player will use. Both are measured in Bytes per Second, so an sv_maxrate of 20000 = 20,000 Bytes per Second! A Rate of 15000 = 15,000 Bytes per Second.
Network Speeds are by convention quoted on bits per second, whether Kilobits (Kb) 1,000 bits, Megabits (Mb) 1,000,000 bits or Gigabits (Gb) 1,000,000,000 bits.
The other convention is b is for bit, B is for Byte, it is important not to confuse the two.
In any case, to calculate the minimum amount of upload bandwidth your server must have, you multiply your sv_maxrate by the number if players on the server. Thus a sv_maxrate of 20000 with 20 players will require at least 20 * 20,000 = 400,000 Bytes per Second of Bandwidth. I say at least, because your theoretical maximum upload speed is just that, theoretical, and you will find that most connections will not sustain their theorectical maximums for long periods of time, which is exactly how GameServers must operate to provide a positive end user experience.
Now going back to our example, we have calculated that you are going to require at least 400,000 Bytes per Second of Bandwith to serve 20 players effectively. We now need to convert this to normal Networking conventions, so we can compare apples with apples. To do this, the calculation for this example is as follows:
400,000 Bytes * 8 bits / 1,000 = 3,200 KiloBits/Second (3,200Kbps) or 400,000 Bytes * 8 bits / 1,000,000 = 3.2 Megabits/Second (3.2Mbps)
Whatever Bytes Per Second you have, you need to convert that into a bit speed, by multiplying it by 8 (8 bits = 1 Byte) and then convert that into either kilobits or megabits, by dividing by 1,000 for kilo or 1,000,000 for mega to give you a value in Kilobits per Second (Kbps) or Megabits per Second (Mbps), whichever is easier to read.
Please realise that your X Mbps connection maybe rated very close to what you need, but it is nearly always necessary to leave an overhead of between 10%-25% to make sure the server can always cope. So an sv_maxrate 20000 server with 20 players is probably going to require a 4Mbps Upstream Connection to adequately cope with the load.
sv_maxrate * {player number} * 8 / 1,000 = Minimum Upstream Speed in Kbps your server requires.
This calculation will work for mulitple SRCDS processes on the one physical server.
If you want to turn this calculation around, and wish to calculate the maximum theoretical sv_maxrate your server can run for a given upload speed (in kbps) and player number, the calculation is as follows:
upload bandwidth in kilobits per second / 8 * 1000 / player number = the theoretical maximum sv_maxrate you can run your server at.
This Calculation only works for a single SRCDS process on a single physical server.
Hopefully now, you can all work out just how much Upstream Bandwidth your server requires for any given sv_maxrate, upstream bandwidth and player number values.
Here is a little table I've thrown together if it is still too hard for you!
Hardware Spec Example:
We run 6 x 16 Player SRCDS on DUAL Xeon 3.0GHz (or better) Servers with 3GB of RAM with 100Mb Switched Network Connections into 1Gbps or 10Gbps BackBones with a 66 tickrate. So when I say good hardware with good Network Connectivity, this is the benchmark I am basing my opinions on.
Suffice it to say we could probably run 4 x 12player 100 tickrate servers, BUT although the difference between 33 tickrate and 66 tickrate is the difference between night and day, the difference between 66 tickrate and 100 tickrate is negligable on the Internet, when all issues are taken into consideration. Also some maps and player numbers caused intermitant issues at 100 tickrate that a GSP does not really want to have to worry about, especially when you can have 6 x 16 player servers that run excellently at 66 tickrate!
In conclusion:
I hope this helps clear up some of the mystery of setting up a server with high tickrate, don't worry if it does not, I am still asking questions myself.
------------------------------------------------------------------------------------
THE MAIN CAUSE OF BAD CHOKE IS A CLIENTS STEAM INTERNET CONNECTION SPEED BEING SET INCORRECTLY
Please ensure that all clients STEAM Internet Connection Speeds are setup correctly.
http://whisper.ausgamers.com/choke/steamchoke.htm
Notes regarding Netgraph Updates per second measurements you need to be aware of:
You won't get higher updates than;
a) The servers tickrate
b) The servers sv_maxupdaterate
c) As fast as your server fps allows (Limited by fps_max, hardware and the Windows Kernel Timer Resolution)
d) As fast as your servers sv_maxrate allows
e) As fast as the clients rate allows
f) As fast as the clients cl_updaterate allows
g) As fast as the client/server connection allows
h) As fast as the clients fps allows (Limited by fps_max, hardware, and Refresh Rate)
NB: Other than tickrate, Choke is caused by any of the above list of things not being large enough. This usually occurs because the sv_maxupdaterate or cl_updaterate being higher than the sv_maxrate or rate allows, since the server will not send more data per second than sv_maxrate or rate allows.
Special Thanks to Alfred Reynolds and Martin Otten for their input that helped me put this guide together.
Cheers
Whisper
Whisper's Very Basic Competitive Counter-Strike War Strategy Guide
P.S. If anybody else has any insights to share, then please do. I am more than happy to get some hard facts and reproducible results myself.
13October2005 Edit: Major Update to reflect changes on original STEAM Forum Post
01January2006 Edit: Added link to up to date wiki page
![[Image: stuartjk.png]](http://miniprofile.xfire.com/bg/bg/type/0/stuartjk.png)
![[Image: netgraph31jf.jpg]](http://img296.imageshack.us/img296/7355/netgraph31jf.jpg)
![[Image: 3dflagsdotcom_denma_2faws.gif]](http://www.3dflags.com/media/icon/classic/d/3dflagsdotcom_denma_2faws.gif){kind=icon}
![[Image: 216.69.179.161:27035.png]](http://www.game-monitor.com/server-stat-image/216.69.179.161:27035.png)