Google Search

Google
 

duminică, 21 octombrie 2007

Choke problem and solutions

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. Choke is quite simply the server wanting to send an update to the client, but cannot.

  • 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

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 Kernel Timer Resolution)

d) As fast as your servers sv_maxrate allows

e) As fast as the client/server connection allows

f) As fast as the clients rate allows

g) As fast as the clients cl_updaterate allows

h) As fast as the clients fps allows (Limited by fps_max, hardware, and Refresh Rate)

h) Client FPS controls how fast the client can send updates to the server, this the OUT on the net_graph 3

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.

Fixing Clients Choke

Besides making sure clients set their STEAM Internet Connection Settings correctly, the only 2 Variables that are going to really help the clients choke problems are RATE and CL_UPDATERATE.

  1. If in doubt about your STEAM Internet Connection Setting, set it 1 higher than what you have.
  2. If you are getting choke and the throughput on the net_graph 3 is lower than what you expect then raise your RATE.
  3. If you still get choke, then make sure you set the CL_UPDATERATE to the servers tickrate and then in steps of 5, lower CL_UPDATERATE until choke disappears or is at least minimised. eg. Start at 100 and try 95, 90, 85, 80 etc. etc.
  4. The blame may not always be with you, the client! Try another server, or another server on another Game Service Provider.

Finally, don't buggerise around trying to fix choke problems if you have loss problems. You are just wasting your time and everybody elses if you ask them to help fix your choke problems if you have LOSS!!! Loss is a network problem

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. 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.

8. You bring up your net_graph by typing net_graph 3 into console. You may find it helpful to centre the net_graph using the net_graphpos 2 command, and raising it a little so it does not overlay your HUD using the net_graphheight 100 command in console. The net_graphheight command is a function of your screen resolution, so you will need to adjust it accordingly with net_graphheight 100 working well for 1024x768. Increasing the value of net_graphheight makes the net_graph higher and Decreasing the value of net_graphheight lowers the net_graph.

Important Information for both Players and Server Administrators

The Server will not send more data and/or updates than the Client is setup to receive unless the clients violate the server minimums, in which case the servers sv_minrate and sv_minupdaterate will be used by the client.

The Client cannot make the Server send more data and/or updates than the Server is set up to send

You should, after reading the entire article above, now know what it is that controls what the Server & Client can and cannot send & receive, how often, and why.

If you do not, you either did not read what I have written, or some part of my explanation was not clear to you. Suffice it to say all the information you need is in here, even if you do not realise it.