Server rentals :: NFOservers.com

In the October 13, 2011 update, Valve locked all servers to run at a FPS equal to the tickrate, or 66.66. The game logic loop goes like this:

1. Run a frame/tick. (These two terms are equivalent now, though they previously differed.)
2. Calculate precisely when the next frame should occur and how long it needs to sleep to wait for it. For instance, by default, it puts 15ms in between frames; if the frame executed in #1 took 10.37ms to execute, it aims to sleep for 4.63ms.
3. Execute a system sleep call to wait the period of time previously calculated. If host_timer_spin_ms is set, it further subtracts that many milliseconds.
4. Check the current time and see if the goal time for the next frame has been reached. If so, it goes back to step #1. If not, it either:
   
   1. If host_spin_timer is not set: Sleeps for a bit longer, then repeats the check in this step.
   2. If host_spin_timer is set: Spin in a busy-loop until the goal time is reached, then goes back to step #1.

Previously, we split up our servers into two main performance levels:

• 500fps servers, run on Windows
• 1000fps+ servers, run on Linux, with a proprietary kernel FPS Locker to precisely maintain high FPS rates without fluctuations

As of October 13, because Orangebox no longer has different FPS rates, these two performance levels will become:

• Standard Windows servers
• Linux servers with the FPS Locker

The FPS Locker continues to increase the precision of kernel timers, which should result in a smoother gameplay experience. The FPS Locker makes host_timer_spin_ms unnecessary, which is good, because host_timer_spin_ms wastes CPU cycles.

The order page has been updated to reflect the changes, and to eliminate the "Extreme accelerator" option, as it is no longer needed. We are currently evaluating whether CPU usage will be lower following this update such that we can lower pricing.

For reference, this is how the Orangebox server previously handled FPS and tickrate:

1. Measure the time. If a frame is not due to occur (per the rate designated by the fps_max cvar), go to step #3.
2. Determine whether a "tick" is due to occur, executing one if necessary. A tick typically occurs every 15ms to achieve a tickrate of 66.66. A tick will not occur every frame unless the server FPS is very low, either because of a heavy load on the server or because fps_max is configured to be low.
3. Execute a fairly granular system sleep call to wait until approximately when the next frame is expected, or 1ms, whichever is longer. Then, return to step #1.

This method was less efficient than the new one because frames often did not have any work associated with them (i.e., no tick was needed), and this led to overhead from extra context switches. Under this system, a high server FPS had a benefit because it meant that more checks were performed to determine if a tick was needed, potentially reducing jitter. Jitter describes the variance between when a tick should occur under perfect conditions, and when it actually did occur.

For reference, CS:GO started with the old decoupled tick/FPS system, in its beta and after its release. On August 30, 2012, Valve switched it to the new locked tick/FPS system.