The following was asked on the Valve HLDS admin email list

So I was reading over [link]. It explains (in a general sense) as to what choke is and the fundamental reason for it happening. What I'm interested in, however, is if choke can still occur when there is more than sufficient bandwidth on a connection or not.

e.g. what network conditions can cause choke, assuming that there is no network saturation?

Also, is there a case where the half-life server itself can add choke to a game with certain settings? Thanks.
Leon, a valve employee response with the following answer

There is no connection whatsoever between choke and actual bandwidth limitations of either clients or the server. Choke is directly related to a client's game "rate" setting, which each client requests individually based on its own setting, but subject to your server's sv_minrate and sv_maxrate values. If the server would like to send a client some data but cannot because sending more data at that time would overrun the client's rate setting (because of a low rate setting, or lots of stuff going on in the server, or the client's updaterate being too high, whatever), then that client gets choke for that server frame. As an internet server op, if you want to reduce choke and at the same time lower the CPU usage of your server (depending on how many of your clients typically raise their cl_updaterate value from the default of 20), make sure to set sv_maxupdaterate to 20. As a LAN server op, hang tight for the next release where you can control the standard rate of all clients in the LAN environment...and/or follow the above suggestion.
The following was asked in response to Leon's above explanation

OK... but then what happens if a client has set his rate to higher then what his real world bandwidth is? Wouldn't that also create choke?
To which Leon responds.

No. To reiterate: The term 'choke' in the HL client/server relationship refers to the state of a given client when the server is preventing itself from sending data to the client because that data would exceed the data rate that the server believes (from in-game rate variables) that the client is capable of sustaining. In your example, the server would just keep pumping out UDP packets bound for the client and whatever happens to them happens to them. UDP is a connectionless protocol, so the server has little independent knowledge of what happens to the packets once they are unleashed. The client would basically just be under a UDP flood. If the server hasn't received anything from a client in sv_failuretime seconds (default 0.5), which seems likely in that kind of flood situation, then the server won't attempt to send anything more to the client until it hears from it again. So, there shouldn't be choke caused directly by this, but it would be a pretty crappy playing experience as the client tries to make sense of cycling continuously between being totally flooded and having a little breather time where it receives nothing, all the while missing a lot of updates from the server. Not to mention that this situation is a possible candidate for a "reliable overflow" server-side and subsequent drop of that client.
En hier volgt nog een stukje over een reactie van een admin waarop Leon weer reageert.

Comment made by an admin....

"Choke" is a term unique to Half-Life. You won't see choke anywhere else. As has been explained before, choke occurs when the server can't send you all the updates you have requested (determined by your 'rate' and 'cl_updaterate'). This is usually due to insufficient bandwidth on the client or at some point between the server and the client.
To which Leon responds

Actually, choke is a little bit different than this. Choke happens when the server would like to send data to a client but it cannot because the client is not yet ready for more data (based on the client's "rate" setting or the server's sv_maxrate). Some things are obvious causes for choke, such as the client's rate simply being too low for the number of players on a server. Other things might not be so obvious, such as a client raising their cl_updaterate value too high. On a similar note, LAN server ops might not be aware of this, but for LAN servers (sv_lan = 1), client "rate" settings (and sv_min/maxrate) are totally ignored and 9999 is used for the rate of all clients. This will be increased to the max allowed rate, 20000, in the next major release, but it's something to keep in mind for now.


bron: [link]


Quote:
Tweaking Rates

Some server admins dislike having LPB's (Low Ping Bastards) or HPW's (High Ping Whiners) on their servers. In the past, there was no way to set these options, but you can with using these two cvars: "sv_maxrate <#>" and/or "sv_minrate <#>". This does not disallow people with a rate not within the range specified on your sever from joining, but forces them to use an appropriate rate set by you.

For example, if you run a large maxplayer server, and do not want people with large pipes stealing all the bandwidth and irritating the HPW's, then you can set the maximum rate allowed on the server to 6000 by using "sv_maxrate 6000". This will not boot any LPB's from the server, but does force them to a rate of 6000 or below, allowing for a more even spread of the bandwidth between players.

Similarly, if you wanted to run a server specifically for a handful of LPB's, you can set the minimum rate allowed to around 9000 using "sv_minrate 9000". This obviously will not kick any HPW's from the server, but it does force their rate to 9000 and above, which will make their game almost unplayable, and maybe they will drop on their own.

You can also use both in combination with each other. In playing around with some servers, I found some interesting combinations. I have a Counter-Strike server running with an 18 maxplayer limit. It was fascinating playing with these settings and watching how they dramatically affect player's pings. After a few hours, I found the best combination for this particular server was sv_maxrate 6500 and sv_minrate 2000. With a server with a larger maxplayer limit, you may want to lower your maxrate to keep the bandwidth reasonable for all the players. On the other hand, if you run a smaller more personal server for you and a few friends in the neighborhood, you may want to make sv_maxrate 20000 and sv_minrate 9000. Also, if you run a server on a cable connection, you may have already noticed how much cable connections seem to fluctuate. You may want to set sv_maxrate 8000 and sv_minrate 4000. Whatever the number for the cable server, keep them closer together to lessen the fluctuating rates.

Please note this is not an exact science by any means. You need to test and find what’s good for you. If you are really pushing the limit and trying to run a server on cable(*gasps*), you could set a relatively low maxrate to squeeze as much bandwidth as possible. This act probably will cause lag to the clients.

Last words of wisdom: When someone complains about lag on your cable server, they are probably 90% correct. This is for a simple reason. If you are playing on the LAN side of your server, you will experience little to no lag. Though, if you ping ever goes above 15-20, you might start to reconsider if you have the basic requirements to run a server. In all honesty, don’t waste your time running a server on a cable connection. It will lag, and is probably against the Terms Of Service of your provider.


bron: [link]