LEFT4 DEAD, SV AND CL CMD RATES

[funkytoes]

hello, I have a specific question on how the l4d server and client configurations are set. specifically.

-sv_memlimit : listed as cheat can this be set to a fixed value in the server config without cheats.

-sv_mincmdrate :sets the minimum value for cl_cmdrate.
-cl_cmdrate : 30 : , "a", "user" : Max number of command
packets sent to server per second.
-sv_mincmdrate 66
-sv_maxcmdrate 100

here is my current server cfg.

rcon_password "xxxx"
sv_rcon_banpenalty 5
sv_rcon_maxfailures 10
mp_forcecamera 1
mp_allowspectators 0
mp_friendlyfire 0
mp_footsteps 1
sv_timeout 300
sv_maxspeed 250
sv_consistency 1
decalfrequency 110
sv_voiceenable 1
sv_alltalk 1
mp_chattime 10
sv_allowupload 0
sv_allowdownload 0
sv_download file size. Default is 15
sv_downloadurl ""
sv_minrate 20000
sv_maxrate 30000
decalfrequency 300
sv_maxupdaterate 100
sv_minupdaterate 30
sv_mincmdrate 66
sv_maxcmdrate 100
sv_logbans 1
sv_logecho 1
sv_logfile 1
sv_log_onefile 1
sv_set_steamgroup
sv_lan 0
sv_region 0
sv_contact
sv_pausable 0
sv_pure 1
sv_pure_kick_clients 1
exec banned_user.cfg
exec banned_ip.cfg

according to the hlds emails the server and client communication cvars are locked and cannot be changed but this forum has numerous posts that recommend the settings listed in my server cfg
so what is the correct way.

[EntropicLqd]

I've been struggling with the same sort of thing tbh.

I'm new to the whole srcds thing (having spent the last few years playing with Unreal Engine servers) and so far, the UE servers are proving to be much simpler to configure.

Assuming srcds isn't telling lies when it starts up, the following variables are not legal for L4D servers (reported as unknown commands):

• sv_allow_color_correction
• sv_minupdaterate
• sv_maxupdaterate
• sv_client_cmdrate_difference
  

Also, weirdly, I don't actually seem to be able to set the maximum number of players on the server. It seems to force itself to 14 all the time despite my best efforts.

I've come across this equation (source: http://planethalflife.gamespy.com/View.php?view=HL2Guides.Detail&id=4&game=3) for calculating the sv_maxrate (which apparently is the maximum amount of data to send to a client per second):
Upload Bandwidth (in kbps) * 128 / Maxplayers (4 for co-op, 8 for versus) = sv_maxrate

I'm guessing you should at least half the value given the amount of AI stuff going on; but really that's just a guess.

There's an X-Box 360 config file that comes with the server that uses the following settings:
sv_minrate 5000
sv_maxrate 8000

Although there's no mention (or indication) as to what upload bandwidth they've sized that to.

[Drocona]

Me being the writer of that article you used as source, I can give a bit of explanation.

The sv_maxrate is usually for people that have slow/low internet upload connection speeds which usually happens in normal homes. In these cases you can set the maximum amount of Bps a client will use to avoid the ping spiking up due to a shortage of bandwidth availability.

This equation doesn't have much to do with how many AI there is or whatever since all it does is divide the upload speed available by the amount of players so it matches your maximum amount of bandwidth usage. Example: There are 4 players in your server on 512kbps. When you add 100 bots(AI) to this, the upload connection will still be shared by only 4 people.

The risk of setting sv_maxrate though is setting it too low, resulting in choke (packets waiting in line to be sent/received) and eventually tickrate drops when choke becomes too high. When on a low speed upload connection there's also the risk setting the sv_maxrate too high which will result in high pings because the needed bandwidth is unavailable.

[EntropicLqd]

Drocona Wrote:Me being the writer of that article you used as source, I can give a bit of explanation.

Thanks for the article. It was very helpful and well written. And more to the point, thanks for taking the time to reply to this thread.

Drocona Wrote:....This equation doesn't have much to do with how many AI there is or whatever since all it does is divide the upload speed available by the amount of players so it matches your maximum amount of bandwidth usage....

Ah yes. I was just being dense. I have a cold; it's obviously affecting my ability to think clearly. It took me a while to figure where the "* 128" came from (conversion from bits to bytes).

I assume that the server takes all of the packet framing into account when calculating the data sent to each client?

Drocona Wrote:....The risk of setting sv_maxrate though is setting it too low, resulting in choke (packets waiting in line to be sent/received) and eventually tickrate drops when choke becomes too high. When on a low speed upload connection there's also the risk setting the sv_maxrate too high which will result in high pings because the needed bandwidth is unavailable.

Hmmm, let me see if I understand.

• The server generates updates to each client at a constant rate (the tickrate).
• Updates to each client are queued when the maximum bandwidth that can be sent to that client in a second has been reached (set by sv_maxrate).
• If the queue size gets too large the server will reduce it's tickrate (or choke as you call it) to reduce the amount of data being generated to each client per second.
• If sv_maxrate is too high, the server will dump UDP packets onto the network at whatever value it is set to.
• Because UDP is used the server cannot know whether delivery takes place or not (and throttle accordingly) so when the upload bandwidth is exceeded some packets are simply dropped and/or ping increases.
  

[Drocona]

Yes, that's correct
You will see though that you will hardly get any loss at all when you run out of bandwidth, 99% of the time the ping will simply skyrocket.
Also as for choke, choke doesn't matter much as long as it's at a steady point, servers with 20 constant choke can play fine.
When choke reaches what I call the "critical" point, which normally is around 50, the tickrate will start to drop accordingly.

[EntropicLqd]

Cool. Thanks.