A high, stable server FPS is what makes hit registration feel honest. The number itself is set by sys_ticrate, but whether the server actually holds it depends on the engine's timing, the -pingboost mode you launch with, and how much CPU headroom that single core has. Chasing 1000 FPS on stock HLDS with a busy server is often a losing battle; the same box on ReHLDS holds it comfortably. This guide walks the levers in the order that matters.
First, measure honestly — do not tune blind. Read how to measure real server FPS and get a baseline empty and under load.
1. Set the target with sys_ticrate
sys_ticrate is the requested main-loop rate. Set it on the command line or in the launch script:
./hlds_run -game cstrike -pingboost 1 +sys_ticrate 1000 \ +map de_dust2 +maxplayers 20 +sv_lan 0
Common targets are 500 and 1000. There is no point setting 1000 if the box can only hold 400 — a rock-steady 500 beats a jittery 1000 every time. Start at 1000, measure, and drop the target if it will not hold.
2. Choose the -pingboost mode deliberately
-pingboost selects how the server waits between frames on Linux. The modes trade CPU for timing precision:
| Mode | Behaviour |
|---|---|
-pingboost 0 | Default timing. Relies on sys_ticrate; lightest, least precise. |
-pingboost 1 | Alternative wait method, tighter timing than 0. A common sweet spot. |
-pingboost 2 | Another timing method; behaviour varies by kernel. |
-pingboost 3 | Most aggressive; can pin the core and may cap the effective FPS rather than raise it. |
There is no single correct mode — it depends on the kernel and hardware. The honest method is to test: launch with -pingboost 1, measure with stats under load, then try -pingboost 0 and compare. Do not assume a higher number is better; -pingboost 3 frequently produces worse, more CPU-hungry results than 1.
3. Give the process a full, fast core
HLDS is single-threaded, so one saturated core caps your FPS regardless of sys_ticrate. On a Linux host you control:
Set the CPU governor to performance so the core does not clock down:
sudo cpupower frequency-set -g performance
Give the server process priority (run as a normal user, renice as root):
sudo renice -n -5 -p $(pgrep -f hlds_linux)
On a box running several servers, pin each to its own core so they do not fight:
taskset -c 1 ./hlds_run -game cstrike ...
If the core hits 100% under load, no launch flag will save you — see HLDS at 100% CPU.
4. Switch to ReHLDS — this is the real fix
Stock HLDS timing is imprecise, which is exactly why "stable 1000 FPS" is so hard on it. ReHLDS reworked the frame loop and holds high tick rates far more consistently for the same CPU. If you are serious about a stable high FPS, the engine swap does more than every other step combined. Follow install ReHLDS on Linux, then the ReHLDS-specific tuning in ReHLDS performance cvars.
5. Keep the plugin load light
Every AMX Mod X plugin runs inside that single frame. A plugin doing heavy work each frame — a badly written stats or anti-cheat plugin — will drag FPS down under load even on a fast core. If FPS is fine empty and collapses with players, suspect a plugin before the engine; low server FPS on Linux covers isolating it.
Common errors
- FPS caps at exactly 100 or exactly your
sys_ticrate-minus-something — usually a-pingboostmode fighting the kernel. Try a different mode. - 1000 empty, 300 full — CPU-bound. Faster core, fewer plugins, or a lighter target.
- FPS swings wildly — the governor is scaling the clock, or another process shares the core. Pin the core and set the performance governor.
- Setting
sys_ticratehigher does nothing — you are already CPU-bound, or on stock HLDS whose timing cannot hold it. Measure, then move to ReHLDS. - Higher FPS but players still lag — FPS was never the problem; check rates and choke via the rate cvars guide.
Verification
Load the server with bots or players, run stats several times during a firefight, and confirm the FPS sits close to your sys_ticrate target with the CPU column comfortably under 100. Change -pingboost and re-measure to prove your chosen mode is genuinely the best on this box. A server that holds 500 rock-steady under a full load is finished; one that holds 1000 is a bonus, not a requirement.
