"Server FPS" has nothing to do with what you see on your screen. On a CS 1.6 dedicated server it is the rate of the engine's main loop — how many times per second the server simulates the world, processes player commands and sends updates. A server pinned at 1000 FPS feels tight and responsive; one that sags to 40 under a full house feels like every shot lands late. Before you tune anything, you need to measure the real number honestly, because the target you set with sys_ticrate and the number you actually get are frequently not the same.
1. Read it with the stats command
The console command stats is built into HLDS and ReHLDS. Type it in the server console (or over RCON) and it prints a single line:
stats
The output is roughly:
CPU In_(KB/s) Out_(KB/s) Uptime Users FPS Players 6.30 2.45 9.81 180 4 999.85 4
The column that matters is FPS. CPU is the percentage of one core the server is burning, In/Out are bandwidth, and Players is the live count. Run stats a few times a second apart — a single reading tells you almost nothing because FPS fluctuates frame to frame.
2. Compare the target against the reality
The server tries to run at the rate set by sys_ticrate. Check what you asked for:
sys_ticrate
If sys_ticrate is 1000 but stats reports 512, or 200, the server cannot sustain the target on this hardware or with this launch configuration. That gap — not the raw number — is the diagnostic. A machine holding a steady 500 FPS is healthier than one that claims to target 1000 and jitters between 300 and 1000.
3. Measure over RCON from outside
You do not need shell access to the box. From a connected client's console, authenticate and query:
rcon_password your_rcon_password rcon stats
This is the honest way to check a server you rent from a host — the panel's "FPS" widget is often the configured sys_ticrate, not the measured value. rcon stats returns the same line the local console does.
4. Measure under load, not empty
An empty server will happily report its target FPS. The number that matters is the one with a full server mid-round, because every connected player adds work to each frame. If you cannot wait for real players, add bots (for example with YaPB) to load the CPU, then watch stats during a firefight. A server that reads 1000 empty and 250 with 24 players and bots does not have a 1000 FPS problem — it has a CPU problem.
5. Watch CPU alongside FPS
The CPU column in stats is the single most useful companion to the FPS number. HLDS is single-threaded, so it can only ever use one core; a reading near 100 means that core is saturated and FPS will fall no matter what sys_ticrate says. On Linux, confirm from the shell:
top -p $(pgrep -f hlds_linux)
If hlds_linux sits at 100% of a core while FPS is below target, the loop is CPU-bound. That points you at the engine (stock HLDS timing), the -pingboost mode, or a heavy plugin — see HLDS at 100% CPU and low server FPS on Linux.
6. ReHLDS reports the same way
ReHLDS uses the identical stats command, so nothing about measuring changes. What changes is that ReHLDS keeps far more accurate frame timing than stock HLDS, so a sys_ticrate of 1000 is much more likely to actually be held. If you are chasing a stable high number, the engine swap does more than any cvar — see ReHLDS performance cvars and getting stable 500/1000 FPS on Linux.
Common errors and misreadings
- Reading FPS from a control panel instead of
stats— many panels display the configured tick target, not the measured rate. Always confirm withrcon stats. - Measuring an empty server and declaring victory — load changes everything. Measure with players or bots.
- Confusing server FPS with client
fps_max— they are unrelated numbers. Boosting your own client does nothing for the server tick; see the client FPS guide. - Expecting a Windows server to hit Linux numbers — the Windows timer caps sustained FPS far lower; 100–200 is normal there.
- FPS looks fine but players complain of lag — that is a rate/choke problem, not an FPS problem. Check the scoreboard for loss and choke, covered in choke and loss on the scoreboard.
Verification
You have a trustworthy measurement when: stats gives you a stable FPS reading across several samples; that reading is taken with the server under realistic load; and the CPU column is well under 100 at your target rate. Note the empty-server FPS and the full-server FPS separately — those two numbers are what every tuning change should be judged against. With a real baseline in hand, move on to setting correct rate cvars and, if the number is low, the Linux FPS guide.
