Forum

Maybe you’ve noticed it now, but they changed it months ago and I haven’t seen any problem with it during this time.

Quoted from longas

Maybe you’ve noticed it now, but they changed it months ago and I haven’t seen any problem with it during this time.

^This.

Also, this may help jog people’s memories of the logic behind that particular update.

Hi all –

Free to Play brought a huge influx of new users to Team Fortress. To help server counts scale up to match the demand, we are reworking the dedicated server for performance. We want to improve player responsiveness as well as to reduce CPU usage so that hosts can run more servers per physical server.

Some of those changes addressing CPU usage went out last night. Server operators should see a big decrease in CPU load and can potentially run more instances per physical box now. However, a side effect that many of you have noticed is that server FPS has an effective cap of 500 instead of the previous 1000, or possibly even lower than 500 depending on your Linux kernel HZ setting. This should not have a noticeable impact on gameplay as the tick rate is still locked (well, mostly locked) at 66 updates per second and the frames that are being dropped are “empty” frames that do not actually run a server tick.

We’re going to address this further in another set of performance improvements. Sorry for the temporary confusion, but we wanted to get these CPU load reduction changes out quickly to help with the Free to Play user crush.

Longer term, we want to move away from FPS as a measure of performance and instead show actual load and responsiveness (jitter/latency) statistics. The difference between a tick and a frame is complicated, and fps_max sometimes affects performance in counter-intuitive ways. We would like to retire fps_max for servers and replace it with a more obvious server performance setting. We’ll give you all a heads up before we do so.

Henry G.

Had to fish that out from my HLDS Mailing List archive. ;)

Quoted from WARHURYEAH

I wish I could subscribe to every post DjShrew makes…

You can, go to my profile and sub to rss feed?

Anyway like I said this was the answer I found, it had just been bugging me for a few months and only had chance to look into it today.

In an high-performance network environment, where the server and all clients have the necessary hardware resources available, it’s possible to tweak bandwidth and tickrate settings to gain more gameplay precision. Increasing the server tickrate generally improves movement and shooting precision but comes with a higher CPU cost. A Source server running with tickrate 100 generates about 1.5x more CPU load than a default tickrate 66. That can cause serious calculation lags, especially when lots of people are shooting at the same time. It’s not suggested to run a game server with a higher tickrate then 66 to reserve necessary CPU resources for critical situations.
Note:It is not possible to change tickrate on CSS, DoD S TF2, L4D and L4D2 because changing tickrate causes server timing issues. The tickrate is set to 66 in CSS, DoD S and TF2, and 30 in L4D and L4D2.

Source: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Quoted from Sylosin

[…]

I remember yonks ago (like a year and a half ago) when you played against us on our shitty Dedifrag server, and you spent the entire game bitterly complaining that our server fps was 66

If I complained (obviously I don’t remember a specific match that far back), it would have been because the server was dipping *below* 66, not because it was *at* 66.

Slightly related, but there is an issue with srcds lately that causes massive fps drops client-side… like from 120 fps down to 40-80. Valve haven’t responded to it being raised on the mailing list several times, but I think it’s something to do with map changes.

Quoted from Sylosin

[…]

cool

ironically, the exact same server became yours when your team became Core Gaming

indeed, much to my annoyance.