Rate commands and CS:GO

[bmcirvin]

I don't know if the commands work the same as in source or 1.6. From what I understand with source all that mattered was the tickrate and in 1.6 it was about having a high fps server. Now with CS:GO I find that there is no cap on the rate commands so I can run them as high as I want (although cl_cmdrate is locked at 130, updaterate at 150, and rate at 128000 for clients).

Basically I want to know what these do now and whether it is important to have a fps server or a tickrate over 100. I have been running my server at 100 tick, cmd and update locked at 100, and fps_max 100. I want a very high quality server, so would raising any of these help with that or does it matter?

[Edge100x]

Tickrate matters most in CS:GO. If you allow/enforce an updaterate and cmdrate matching this, that should offer the highest performance. In terms of the FPS, running at a much higher server FPS (such as 1000) may result in slightly higher performance due to it checking whether it's time to run a tick more frequently (and thus potentially compensating for sleep inaccuracy and other factors), but the effect has always been debatable, and higher CPU usage will also result.

My hope is that Valve will change the system to lock the FPS to the tickrate and use more precise timer calls, as they do in Orangebox, but I haven't heard yet whether this is planned.

[bmcirvin]

Forgive me for picking your brain some more, but would there be reason to have a tickrate over 100 when you have cmd and update rates locked to 100? Also, I notice that when capping fps_max 100 the server most of the time runs under 100 fps (~85-95 fps). I find to get around 100 fps I have to have the fps_max at around 120-130. Also, for the client's net_graph to report getting around ~99 cmd and updaterates I find I have to set the fps_max around 200.

I'm going to do some research myself but any help would be much obliged.

[Edge100x]

would there be reason to have a tickrate over 100 when you have cmd and update rates locked to 100?

I can't immediately think of one.

I noticed in my testing that, at least right now, CS:GO is not exposing sv_maxupdaterate as a cvar and is instead locking it to match the server tickrate. I'm not sure why they've removed that level of admin control.

Also, I notice that when capping fps_max 100 the server most of the time runs under 100 fps (~85-95 fps). I find to get around 100 fps I have to have the fps_max at around 120-130.

Nod, this is a known glitch in the older Source engine. It likely happens because the game doesn't properly compensate for how long ticks are actually taking.

Our FPS Locker on Linux was designed to adjust for this situation and keep the realized FPS more stable, while simultaneously reducing overhead (for lower FPS rates). If you have a managed or shared Linux server, try setting fps_max to 0, and either set the desired FPS to the same as the desired tickrate (to try to reduce overhead), or go with something much higher, like 1000+ (to try to maximize performance/minimize jitter, or "var", on smaller servers).

Also, for the client's net_graph to report getting around ~99 cmd and updaterates I find I have to set the fps_max around 200.

That makes sense, in relation to the FPS sag.

[bmcirvin]

Ok I have spent an inordinate amount of time messing with my csgo server and I wanted to confirm some things. The graph below the cmdrate seems to correspond with the server tickrate. I have set it to 100, 200, and 1000 and the speed at which to moves correlates with this. This occurs even when the cmd and update rates are lower than the tickrate.

When I had the server tickrate set at 1000 I tested to see if I could force the cmdrate to 1000, and I found that I could but the actual amount of packets received still ranged from around 90-130. I'm guessing that there is a non-displayed lock around 130.

Would the fact that I can not force the rate over 128000 have anything to do with that or does that value have nothing to do with it?

Anyway if you're wondering I was an old school beta and retail competitive player in cs, so I learned a type of pickiness I can't seem to get rid of.

Also, the box is running on windows. I simply haven't had enough experience to run a linux box =\

[Edge100x]

The cl_cmdrate variable has a built-in hard maximum of 128, I believe. The game indicates the maximum when "cl_cmdrate" is typed into the client console.

[bmcirvin]

So in order to maximize performance without exhausting server resources, would this sound best to you: 128 tickrate, cmd 128, rate 128000, fps_max 200?

Also, I realized that my game fps would drop to 80-90 fps causing my cmdrate to only achieve 80-90 at times, so I believe that most people wouldn't even be able to utilize a cmd rate over 128 for the most part.

[Edge100x]

So in order to maximize performance without exhausting server resources, would this sound best to you: 128 tickrate, cmd 128, rate 128000, fps_max 200?

That sounds reasonable.

Also, I realized that my game fps would drop to 80-90 fps causing my cmdrate to only achieve 80-90 at times, so I believe that most people wouldn't even be able to utilize a cmd rate over 128 for the most part.

Roger that. A higher updaterate/cmdrate/tickrate than the FPS of the client doesn't help gameplay, which is a good reason for nearly games to stick to values below 100 (and nearly all do).

[cleco]

For tickrate, is it like previous CS and you have to put it in the command line "-tickrate 100"?

[Edge100x]

Yes, that's correct.

[cleco]

thanks