---
title: "Kernel Timers, HZ and CONFIG_HZ_1000 for Game Servers"
excerpt: "How the Linux timer tick historically limited HLDS fps, why CONFIG_HZ_1000 mattered, and how modern high-resolution timers and ReHLDS changed the picture without eliminating jitter."
category: "optimization"
tags: "kernel, linux"
image: ""
read_time: "8 min read"
---
<p>There is a long-standing belief that you must recompile your kernel with <code>CONFIG_HZ_1000</code> to run a smooth 1000 fps CS 1.6 server. On older systems that was genuinely true; on modern kernels the story is more nuanced. Understanding <em>why</em> the kernel timer ever mattered lets you decide whether it is worth touching on your box — and stops you cargo-culting a kernel rebuild that a modern <a href="/tutorials/hlds-vs-rehlds-explained">ReHLDS</a> install does not need.</p><h2>1. What the HZ value is</h2><p>The kernel's <code>CONFIG_HZ</code> sets the frequency of the periodic timer interrupt — how often the scheduler wakes up to make decisions. Common values are <code>100</code>, <code>250</code>, <code>300</code> and <code>1000</code> Hz. Check yours:</p><pre>grep CONFIG_HZ /boot/config-$(uname -r)</pre><p>Historically this value was also the granularity of <code>usleep()</code> / <code>nanosleep()</code>: on a 100 Hz kernel a sleep could only resolve to ~10 ms boundaries, so a game loop that slept between frames could not pace itself finely enough to hit a steady 1000 fps. A 1000 Hz kernel gave 1 ms granularity, which is why <code>CONFIG_HZ_1000</code> became folklore for HLDS boxes.</p><h2>2. Why high-resolution timers changed this</h2><p>Modern Linux kernels ship <strong>high-resolution timers</strong> (<code>hrtimers</code>) and <code>NO_HZ</code> / tickless operation. With hrtimers, <code>nanosleep()</code> no longer rounds to the <code>CONFIG_HZ</code> boundary — it can resolve to microseconds regardless of the periodic tick frequency. Verify hrtimers are active:</p><pre>cat /proc/timer_list | grep resolution
cat /sys/devices/system/clocksource/clocksource0/current_clocksource</pre><p>You want a <code>tsc</code> or <code>hpet</code> clocksource and nanosecond resolution. On such a kernel, the old hard link between <code>CONFIG_HZ</code> and achievable fps is largely broken — the engine can pace itself finely without a 1000 Hz periodic tick.</p><h2>3. What ReHLDS does differently</h2><p>Stock HLDS relied on the engine's <a href="/tutorials/sys-ticrate-truth">sys_ticrate</a> and coarse sleeps, which is exactly the code that suffered on low-HZ kernels. ReHLDS rewrote the timing loop to use finer sleeps and better frame pacing, so on a modern kernel it can hold high, stable fps largely independent of <code>CONFIG_HZ</code>. This is why the practical advice today is "run ReHLDS on a recent kernel" rather than "recompile with HZ 1000". See <a href="/tutorials/stable-1000-fps-linux-server">the stable 1000 fps guide</a> for the engine-side settings that actually move the needle now.</p><h2>4. Where the HZ value still matters: jitter</h2><p>Even with hrtimers, the <em>periodic</em> tick still governs how often the scheduler can preempt and re-balance. On a heavily loaded box running multiple instances, a higher <code>CONFIG_HZ</code> reduces scheduling latency and therefore frame-time jitter — the fps average may be fine on any HZ, but the <em>consistency</em> improves with a higher tick and with a tickless-idle configuration that keeps busy cores responsive. For a single lightly loaded server the difference is negligible; for a box packed with servers it can be the difference between smooth and periodically stuttery.</p><h2>5. Practical tuning that beats a kernel rebuild</h2><p>Before recompiling anything, get the cheap wins:</p><pre>cpupower frequency-set -g performance
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor</pre><p>Force the <a href="/tutorials/cpu-governor-performance">performance CPU governor</a> so cores do not downclock between frames — a downclocking core causes far more fps jitter than a suboptimal HZ value ever will. Then pin instances with <a href="/tutorials/cpu-affinity-taskset-hlds">taskset</a> so scheduler migrations do not disturb frame pacing. On most modern VPSes, governor plus affinity plus ReHLDS gets you a stable 1000 fps without ever touching <code>CONFIG_HZ</code>.</p><h2>Common errors</h2><ul><li><strong>Recompiled kernel to HZ 1000, no fps change</strong> — hrtimers already gave fine sleep resolution; the bottleneck was the governor or the engine, not the tick.</li><li><strong>fps average fine but visibly stuttery under load</strong> — scheduling jitter. Pin instances and force the performance governor before blaming HZ.</li><li><strong>Cannot check CONFIG_HZ</strong> — on a VPS you often cannot change it anyway (shared host kernel). Focus on governor, affinity and ReHLDS.</li><li><strong>Clocksource is not tsc/hpet</strong> — a poor clocksource (e.g. <code>acpi_pm</code>) hurts timing; investigate why the kernel fell back.</li><li><strong>Expecting HZ to raise a single server's ceiling</strong> — the ceiling is single-core speed and engine timing, not the periodic tick.</li></ul><h2>Verification</h2><p>Check your clocksource and governor, then measure real server fps under load:</p><pre>cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
stats</pre><p>A <code>performance</code> governor plus a stable <code>fps</code> reading near your target on a modern kernel means the timer subsystem is not your problem — do not rebuild the kernel chasing a myth. If fps is unstable, confirm with <a href="/tutorials/measure-server-fps">the fps measurement guide</a> and work through <a href="/tutorials/sys-ticrate-truth">the sys_ticrate truth</a> and <a href="/tutorials/fix-low-server-fps-linux">low server fps on Linux</a> before touching <code>CONFIG_HZ</code>. On a VPS you frequently share the host's kernel and cannot recompile it at all, which makes the governor-and-affinity route not just easier but the only one available — and on modern hardware it is enough.</p>
