---
title: "Getting Stable 500/1000 FPS on a Linux CS 1.6 Server"
excerpt: "sys_ticrate, -pingboost and the CPU are the three things that decide whether your server holds a high tick rate. Here is how they fit together on Linux, and why ReHLDS is the real fix."
category: "optimization"
tags: "fps, linux"
image: ""
read_time: "9 min read"
---
<p>A high, <em>stable</em> server FPS is what makes hit registration feel honest. The number itself is set by <code>sys_ticrate</code>, but whether the server actually holds it depends on the engine's timing, the <code>-pingboost</code> 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.</p><p>First, measure honestly — do not tune blind. Read <a href="/tutorials/measure-server-fps">how to measure real server FPS</a> and get a baseline empty and under load.</p><h2>1. Set the target with sys_ticrate</h2><p><code>sys_ticrate</code> is the requested main-loop rate. Set it on the command line or in the launch script:</p><pre>./hlds_run -game cstrike -pingboost 1 +sys_ticrate 1000 \
+map de_dust2 +maxplayers 20 +sv_lan 0</pre><p>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.</p><h2>2. Choose the -pingboost mode deliberately</h2><p><code>-pingboost</code> selects how the server waits between frames on Linux. The modes trade CPU for timing precision:</p><table><thead><tr><th>Mode</th><th>Behaviour</th></tr></thead><tbody><tr><td><code>-pingboost 0</code></td><td>Default timing. Relies on <code>sys_ticrate</code>; lightest, least precise.</td></tr><tr><td><code>-pingboost 1</code></td><td>Alternative wait method, tighter timing than 0. A common sweet spot.</td></tr><tr><td><code>-pingboost 2</code></td><td>Another timing method; behaviour varies by kernel.</td></tr><tr><td><code>-pingboost 3</code></td><td>Most aggressive; can pin the core and may cap the effective FPS rather than raise it.</td></tr></tbody></table><p>There is no single correct mode — it depends on the kernel and hardware. The honest method is to test: launch with <code>-pingboost 1</code>, measure with <code>stats</code> under load, then try <code>-pingboost 0</code> and compare. Do not assume a higher number is better; <code>-pingboost 3</code> frequently produces <em>worse</em>, more CPU-hungry results than 1.</p><h2>3. Give the process a full, fast core</h2><p>HLDS is single-threaded, so one saturated core caps your FPS regardless of <code>sys_ticrate</code>. On a Linux host you control:</p><p>Set the CPU governor to performance so the core does not clock down:</p><pre>sudo cpupower frequency-set -g performance</pre><p>Give the server process priority (run as a normal user, renice as root):</p><pre>sudo renice -n -5 -p $(pgrep -f hlds_linux)</pre><p>On a box running several servers, pin each to its own core so they do not fight:</p><pre>taskset -c 1 ./hlds_run -game cstrike ...</pre><p>If the core hits 100% under load, no launch flag will save you — see <a href="/tutorials/fix-hlds-100-cpu">HLDS at 100% CPU</a>.</p><h2>4. Switch to ReHLDS — this is the real fix</h2><p>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 <a href="/tutorials/install-rehlds-on-linux">install ReHLDS on Linux</a>, then the ReHLDS-specific tuning in <a href="/tutorials/rehlds-performance-cvars">ReHLDS performance cvars</a>.</p><h2>5. Keep the plugin load light</h2><p>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; <a href="/tutorials/fix-low-server-fps-linux">low server FPS on Linux</a> covers isolating it.</p><h2>Common errors</h2><ul><li><strong>FPS caps at exactly 100 or exactly your <code>sys_ticrate</code>-minus-something</strong> — usually a <code>-pingboost</code> mode fighting the kernel. Try a different mode.</li><li><strong>1000 empty, 300 full</strong> — CPU-bound. Faster core, fewer plugins, or a lighter target.</li><li><strong>FPS swings wildly</strong> — the governor is scaling the clock, or another process shares the core. Pin the core and set the performance governor.</li><li><strong>Setting <code>sys_ticrate</code> higher does nothing</strong> — you are already CPU-bound, or on stock HLDS whose timing cannot hold it. Measure, then move to ReHLDS.</li><li><strong>Higher FPS but players still lag</strong> — FPS was never the problem; check rates and choke via <a href="/tutorials/sv-maxrate-maxupdaterate-values">the rate cvars guide</a>.</li></ul><h2>Verification</h2><p>Load the server with bots or players, run <code>stats</code> several times during a firefight, and confirm the FPS sits close to your <code>sys_ticrate</code> target with the <code>CPU</code> column comfortably under 100. Change <code>-pingboost</code> 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.</p>
