You check stat or an FPS plugin and the server sits at exactly 100 FPS no matter what you set. Server FPS on the Half-Life engine is how many times per second the server simulates and sends updates; a server pinned at 100 feels laggier than its rate settings suggest, and hitreg suffers. On Linux the cap comes down to how the engine sleeps between frames and how you launch it. Here is how to raise it without setting the CPU on fire.
1. See what you actually have
On the server console:
stat sys_ticrate
stat prints the current server FPS. sys_ticrate is the requested maximum. If sys_ticrate is 100 (or unset), 100 is your ceiling by design — the fix is to raise it and to make the engine able to reach it.
2. Raise sys_ticrate
Set it on the launch line or in server.cfg. A common target is 500 or 1000:
sys_ticrate 1000
Or on the command line:
./hlds_run -game cstrike -pingboost 0 -sys_ticrate 1000 \ -ip 0.0.0.0 -port 27015 +maxplayers 20 +map de_dust2
Raising the number alone is often not enough on stock HLDS, because how the engine waits between frames — the pingboost mode — decides whether it can actually hit that rate.
3. Understand -pingboost and the timer
Stock hlds_run supports -pingboost 1/2/3, which switch the sleep strategy between frames. Higher pingboost modes busy-wait more aggressively and can raise FPS, but they burn CPU and some modes are unstable on modern kernels. This is the classic trade: a higher, steadier FPS costs CPU. Test each mode and watch both stat and host CPU:
-pingboost 1 -pingboost 2 -pingboost 3
Do not cargo-cult a mode from a forum — measure on your kernel. If a mode makes FPS erratic or spikes CPU to 100% for no players, it is the wrong mode for your box; see the 100% CPU guide.
4. Run ReHLDS and let it hold FPS properly
The clean answer in 2026 is ReHLDS. Its frame timing is far better than stock HLDS and it holds a requested FPS with much less CPU than pingboost hacks. On ReHLDS, sys_ticrate 1000 with the default sleep strategy typically gives a stable 1000 FPS on a modern core, and there are ReHLDS cvars to tune the sleep behaviour if needed. If you care about server FPS at all, the engine swap is the highest-leverage change you can make.
5. Do not confuse server FPS with client updates
Server FPS caps how often the server ticks; it interacts with sv_maxupdaterate. There is no point running 1000 server FPS with sv_maxupdaterate 20 — the updates a client receives are bounded by the rate cvars. Keep them coherent:
sys_ticrate 1000 sv_maxupdaterate 101 sv_maxrate 25000
6. Rule out the host and the timer
On a shared or heavily oversubscribed VPS you can set sys_ticrate 1000, run ReHLDS, and still not hold it — because the hypervisor is not giving your vCPU consistent time. Two quick checks separate "my config is wrong" from "my host is the problem". First, watch steal time on the host:
top # look at the %st (steal) column
Non-trivial steal means the hypervisor is scheduling you off the CPU, and no cvar fixes that — you need a better plan or a dedicated core. Second, confirm the measurement itself: idle FPS and loaded FPS are different worlds, so always judge with players on. A server that holds 1000 empty and 1000 with a full match on a dedicated box is genuinely healthy; the same config on a busy VPS is at the mercy of neighbours.
Common errors
- FPS stuck at exactly 100 —
sys_ticrateis at its default; raise it and confirm the engine can reach it. - Raised sys_ticrate, FPS did not move — stock HLDS sleep strategy is capping you. Try a
-pingboostmode or, better, move to ReHLDS. - High FPS but CPU pinned at 100% — an aggressive pingboost busy-wait. Expected trade-off; drop the mode or switch engines. See the CPU fix.
- FPS swings wildly under load — the box is oversubscribed (shared VPS with noisy neighbours) or the kernel timer is coarse. A dedicated core and ReHLDS fix most of this.
Verification
With players on the server (idle FPS is not representative), run repeatedly:
stat
You want the FPS to sit at or near your sys_ticrate target and stay there through a full round, while host CPU stays reasonable for the player count. A number that reads 1000 when empty but collapses to 300 under 20 players means you are CPU-bound — reduce pingboost aggressiveness, move to ReHLDS, or get a faster core. Watch it for a whole map, not a single sample.
