Fix: sys_ticrate Doesn't Change Server FPS

You set sys_ticrate 1000 expecting a buttery 1000-FPS server, but stats shows the FPS parked at a few hundred or bouncing around, unchanged by whatever number you type. This is one of the most misunderstood settings in CS 1.6: sys_ticrate is a ceiling, not a throttle you can crank, and on stock HLDS the engine simply cannot hold that ceiling. Here is what the cvar really does and how to get a genuinely high, stable server FPS.

1. What sys_ticrate actually controls

sys_ticrate is set on the command line and defines the maximum rate the server loop is allowed to run:

./hlds_run -game cstrike +sys_ticrate 1000 +map de_dust2

Crucially, it is an upper bound. Setting it to 1000 does not make the loop run at 1000 — it merely permits up to 1000. Whether the loop reaches that depends on the engine, the OS timer, and the CPU. Raising the number above what the engine can achieve changes nothing, which is exactly why "I set it to 1000 and FPS didn't move" is so common. First, measure the real number:

stats
# read the FPS column

2. The stock HLDS limitation

On Valve's original HLDS, the server loop is tied to the OS scheduler in a way that makes it unable to hold a steady high FPS. It oscillates and typically will not sit anywhere near 1000 no matter how high sys_ticrate is set. This is not a misconfiguration you can cvar your way out of — it is a property of the old engine's timing loop. So the honest answer to "why doesn't sys_ticrate change my FPS" is often: because you are on stock HLDS, and it cannot deliver the FPS you are asking for. The unstable FPS is also what makes a lightly-populated server feel laggy, covered in why a server lags with only 10 players.

3. The real fix: ReHLDS

The reliable way to get a high, stable server FPS is to replace HLDS with ReHLDS, the reverse-engineered engine that reworks the timing loop so it actually holds your target ticrate steadily. On ReHLDS, sys_ticrate 1000 genuinely produces a loop pinned near 1000 with far less oscillation, and that steadiness — not the raw number — is what improves movement and hit registration. Follow the ReHLDS install guide; it keeps your existing cstrike/, so it is a low-risk swap and it is the single most effective server-side performance change you can make.

4. Do not rely on sketchy FPS boosters

You will find old "FPS booster" tricks — wrapper libraries, forced high-precision timers, LD_PRELOAD hacks — that claim to lift stock HLDS FPS. Some raise the number in stats without making the loop genuinely stable, and several are unmaintained or unsafe on modern kernels. A misleading high FPS reading with an unstable underlying loop is worse than an honest low one because it hides the real problem. Prefer the supported route: ReHLDS on a host that is not oversold. If stats shows the CPU column near 100, no ticrate setting will help — the loop has no spare time.

5. Give the loop real CPU

Even on ReHLDS, the loop needs CPU cycles it actually owns. A cheap VPS that oversells cores will steal time from your server and cap the achievable FPS regardless of sys_ticrate. On Linux check for stolen time:

top
# watch the %st (steal) column
# also compare stats FPS on an idle vs full server

Sustained non-zero %st means the hypervisor is handing your cycles to other tenants — the fix is a better host or a dedicated core, not a cvar. A dedicated box or a VPS with guaranteed CPU is what lets ReHLDS hold your ticrate under load.

Troubleshooting

• FPS unchanged by any sys_ticrate value — you are on stock HLDS, which cannot hold a high loop rate. Move to ReHLDS.
• FPS high but movement still stutters — the number is inflated by a booster while the loop is unstable. Use ReHLDS for genuine stability.
• FPS drops as players join — the CPU is saturated or stolen. Check the stats CPU column and top %st.
• FPS steady on idle, collapses on a full server — not enough dedicated CPU. A better host, not a cvar, fixes it.
• Set sys_ticrate in a config, no effect — it is a command-line parameter, not a runtime cvar. Put +sys_ticrate on the launch line.

Verification

Run stats on an idle server and note the FPS, then again under a full load. On a healthy ReHLDS box with real CPU the number should sit close to your sys_ticrate target and stay steady in both cases — steadiness matters more than the peak. If the FPS holds under load, the loop is genuinely fast and further tuning belongs in the rate and CPU checks. If it still sags under players, you are CPU-bound and no ticrate value will change that.