uitleg choke enzo ......
We've been talking a lot about choke lately and why some people get it. I have been getting more of it since the server was upgraded. I spent a few hours today trying to find some good info and I think I found it.
Client-Server Communication Configuration
There are four commands which configure the various aspects of client-server configuration;
cl_cmdrate is the number of times per second the client informs the server of its actions. Remember that the amount of data in an update depends on how much is going on.
cl_updaterate is the number of times per second the server tells the client what's been going on in the map. Likewise, more action, more data per update.
cl_rate sets a maxiumum limit of bytes per second the client can send the server. This value is necessary as the server cannot reliably determine the data transfer rate to the client. This value needs to be set to match the data upload rate of your connection to the server.
rate is the maximum limit of bytes per second the server can send to the client. sv_maxrate, the server specified limit, is used if rate is higher than sv_maxrate.
Updates from the client to the server usually contain very little data - perhaps 20 bytes. Updates from the server to the client contain (relatively speaking) a lot of data, from say 30 bytes in a quiet area of a map to 175 bytes in combat.
For example, a 56k modem has a maximum upload rate of 33.6k, and a maxiumum download rate of 56k. The values here are bits per second (e.g. 33600 bits per second upload rate). However, these are signaling rates, not data payload rates. The signaling rate is the number of bits per second; but not all of these bits can be used for data. Some - roughly 10 percent - are used for control information. So a 33.6k bits per second connection can in fact only transfer about 30.2k bits per second of real data, which is 3780 bytes - and this is the value cl_rate should be set to (assuming a perfect upload connection - if the modem is connecting over a noisy line and the data transfer rate is reduced, the rate value must accordingly be reduced).
Likewise, with a perfect 56k connection, 56000 bits per second are available. Reducing this by ten percent gives 6300 bytes per second. This is the value rate should be set to.
rate equals download speed times .9 divided by 8
cl_rate equals upload speed times .9 divided by 8
By and large, clients don't have very much to tell the server; client to server communication rarely suffers from bottlenecks even on a 56k modem.
Note that the control information overheads differ depending on the type of connection between the client and ISP, but that this is basically irrelevent for higher bandwidth connections since such connection types will always have much more bandwidth available than the maximum value the server will permit a client to use.
Fractional values for cl_rate and rate make absolutely no difference whatsoever. It is an urban myth that fractional values improve performance.
As previously mentioned, client to server updates are typically very small, in the order of 20 bytes. On a 56k modem with a perfect connection, 3780 bytes are available per second for updates to the server, so cl_cmdrate can be set 189. As it is, Half-life has a hard coded internal maximum for this of about 60.
Updates from the server to the client send more data. Large updates (e.g. combat situations) take something like 175 bytes. With 6300 bytes per second available on a perfect 56k modem connection, cl_updaterate should be set to 36.
cl_updaterate equals rate divided by 175
cl_cmdrate equals cl_rate divided by 20
Players with broadband connections will have configurations very different to the values derived so far. Firstly, a broadband connection will always have more bandwidth available than the server can provide. As such, rate and cl_rate both need to be set to their maximum values so that the client is using all available bandwidth.
The maximum value for both rate and cl_rate is 20,000.
The calculation for the correct setting of cl_cmdrate and cl_updaterate actually usually depend on the particular server the player is connected to, as it's sv_maxrate value will be the limiting factor for available bandwidth, and available bandwidth defines the correct update settings.
(Our server uses a sv_maxrate of 8000. Given that, the calculated cl_updaterate would be 40 and the cl_cmdrate would be 400 ( Although it will be capped to 60))
As previously mentioned, Half-life has an internal hard-coded maximum of about 60 for both update settings. The recommended setting is therefore 75 (to be on the safe side), which should be reduced in line with the sv_maxrate setting as necessary.
The net_graph (net_graph 3) command provides information about the state of the client-server connection in the bottom right hand corner of the screen.
The field we are interested in is choke.
Choke represents the number of updates not sent in either direction because the the communication link is saturated.
(Loss is rather different and rarely used, and represents the number of updates which were sent but never reached their destination. If a player experiences significant loss there is a technical problem with the network connection, which lies outside the scope of this report.)
Leave net_graph running and monitor the choke value. Gradually reduce the cl_updaterate and cl_cmdrate values if choke occurs, until choke no longer occurs during comabt.
The overall goal is to have cl_updaterate and cl_cmdrate as high as possible (to provide a better illusion of uniform motion) while still ensuring choke is low or zero
:strip_icc():strip_exif()/u/17623/crop60195077a696c.jpeg?f=community)
/u/44768/crop5e820cb772ffc_cropped.png?f=community)
.
)
/u/34819/avatar60x60.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/6751/928_icon_60x60.jpg?f=community){kind=icon}
