A Guide to Source Engine Server Performance

Server Tickrate

What is tickrate?

How does tickrate affect performance?

As increasing the tickrate increases the number of simulations a servers runs in a given time frame, it enables the server to process client interactions with the world at a higher rate. The result, the player perspective, is a more responsive world which can in turn lead to better registration.

Increased tickrate however is not without its problems as it can cause errors with the aspects of the simulation that make assumptions about the tickrate.

Known side effect of increased tickrate above the default are:

• Doors opening and closing faster than they should
• Players stuttering when hitting the ground
• Firing mechanisms of certain guns misbehaving

Due to these problems, Valve have removed this option from the ability to change the tickrate in the OrangeBox engine update. While this does mean that the increased performance afforded by this can no longer be achieved, I'm sure everyone will agree that removing these bugs makes it the right decision.

Server FPS

What is Server FPS?

Server FPS is similar to tickrate but instead of altering the number of simulations that the server runs per second, it affects the frequency at which the server checks to see if it needs to run a new tick. A commom misconceptions is that FPS is how many times per second the server calculates the simulation, our understanding is this is not the case, that is tickrate.

This means that the accuracy of the server tick is increased in line with the servers FPS, the result is smoother more predictable gameplay which is key for servers used to play tournament and competition matches.

Server FPS Limits

By default the maximum FPS supported by the Source Engine is limited by the operating system function it uses to "sleep" between ticks. These sleeps are actually a fixed period, which means that a servers FPS will fluctuate due to the small differences in time it takes to process each tick, which results in a loss of smoothness and hence reduced hit registration accuracy.

Improving Server FPS

In order to increase the maximum FPS that the Source Engine supports, Multiplay created an addon which replaces the timing calculations used by the engine which significantly improves accuracy of engine ticks. This increased maximum FPS give Multiplay Match Servers smoother gameplay and unsurpassed hit registration.

The differences between the timing methods are depicted in the image above; as you can see with the standard timing method the total time elapsed between ticks varies resulting in frame time instability. This method is also susceptible to sleep errors due to the inaccurate timing function used, which further increases the overall error.

The method Multiplay uses eliminates both these problems first by using a more accurate timing method and second by implementing tick calculation time correction. You can see even in this small comparison that our method results in higher and more stable FPS, which is perfect for match servers.

Monitoring Server Performance

net_graph 4

The new orangebox engine adds supports for an additional net_graph type which includes some useful information about server performance.

To enable this on your client enter "net_graph 4" in the console. Once enabled your net_graph 4 will show both server fps "sv" and the standard deviation of the server's frametime "var".

Limitations of net_graph 4

Using net_graph 4 is great for monitoring standard FPS servers, unfortunately the calculation used for the display of server fps "sv" in net_graph 4 is limited to a 3 digit number. This means that when used on high performance match servers running at over ~990fps this value becomes meaningless as it is simply displayed incorrectly.

The reason for this is the fact that when the client updates its internal representation of the server fps baseed on what it recieved from the server it uses the following code

void CNetGraphPanel::UpdateEstimatedServerFramerate( INetChannelInfo *netchannel )
{
	float flFrameTime;
	netchannel->GetRemoteFramerate( &flFrameTime, &m_flServerFramerateStdDeviation );
	if ( flFrameTime > 0.001f )
	{
		m_flServerFramerate = 1.0f / flFrameTime;
	}
}
	

The result of this code is essentially that the client displays the value for the last server frame it monitored which took more thank 0.00101 seconds to generate, which is equivalent to ~990fps.

Given this limitation it is likely the case that a truely high performing server will show random values for the server FPS more often as its will be more likely to spend most of its time above this threshold and hence more values are ignored. This also explains why the value changes more often during round restarts where the server uses more disk access that can easily cause a frame to take longer to generate.

This actual effect of this calculation / display issue varies as the FPS increases

• 1000 FPS servers will often be seen to jump around rapidly, sometimes wildly even displaying 0 - 20 fps.
• 2000 FPS servers also can be seen to jump around but tend to stick at values for longer periods of time
• 10000+ FPS server tend to clamp at a value e.g. 15, 980.4 or 990.1 with few changes

This can be confirmed by checking the value of both "var" which shows the fps variation, and does appear to be accurate, as well as the output from the "rcon stats" command, which is also an accurate representation of the servers fps.

The following graphs show the results you would expect to see at various FPS values on high performance servers. As you can see the "sv" value never goes above 999 but "var" stays constantly low meaning that the FPS being achieved isn't varying very much, which is very important.

One thing to watch out for is servers which have a high "var" value as this indicates either inaccurate timing or machine overloading.

Example Netgraph 4 @ 1000 FPS

Example Netgraph 4 @ 2000 FPS

Example Netgraph 4 @ 10000 FPS

Example Netgraph 4 @ 50000 FPS

More details on the information displayed by the orangebox netgraph can be found on Valve's Official Netgraph Wiki page

Important Notes

• The value displayed by "sv" in net_graph 4 seems to be sensitive to changes Valve are making, the information in this guide is correct as of 2010-07-16
• To reiterate the "sv" values displayed are a bug with net_graph 4's ability to correctly calculate / display the FPS of these servers and it does not affect the servers actual performance.

Rcon stats

The rcon "stats" command is the primary way to check the FPS of your server is what it should be. While using this manually when logged in via your client is a great way to do a quick test, its also useful to do extended tests on your server to ensure that the FPS is constantly high and stable.
Extended period testing requires the use of an external tool such as the one which can be found over at http://www.fpsmeter.org/. Its easy to setup and will enable you to see a nice graph of your servers FPS over time.

Note: Servers will never achieve a 100% time at the given FPS so its ok to see brief drops in the graphs created by stats monitoring tools. This can be caused map changes and restarts which will result in FPS drops and missed values. This is not something to be concerned about and is normal.

Update History

• 2010-07-16 - Initial Version
• 2010-08-03 - Added information about the cause of the ~990fps display limitation on the client

Contact Multiplay

Thank you for reading this guide, like all guides its work in progress and constantly being updated. We hope you have found it useful, if you have any questions, additions or other freeback please let us know by posting in the Multiplay Games Server Forum and we will do our best to help.

If you are interested in renting a top performance CounterStrike: Source or Teamfortress 2 server, don't forget to check out our Multiplay Performance Match Servers!