Idle CPU cores drop into deep power-saving states (C-states) and lower their frequency to save power. Waking up and raising the frequency when a packet or timer arrives takes time, which adds delay to handling small packets.
Why The OS frequency scaling policy (governor) or the BIOS power settings allow deep C-states and low frequencies → Effect An idle core is up to hundreds of µs late every time it wakes from a deep power-saving state, and a frequency pinned low slows the tick computation itself → On screen Usually hard to notice, but with many server-to-server calls it adds up to input lag that gets worse when the server is quiet. With the frequency pinned low, ticks fall behind when crowds gather: slow motion
Set the BIOS power settings to performance, set the OS governor to performance (scaling_governor in cpufreq), limit deep C-states on latency-sensitive servers (tuned latency-performance profile, /dev/cpu_dma_latency in PM QoS, the intel_idle.max_cstate kernel parameter), and after the change compare round-trip time within the data center, tick-time jitter, and power usage.
Ballpark numbers
According to the intel_idle driver tables in Linux 6.12, Intel server CPUs take 1–2 µs to wake from the shallow C1 state and 133 µs (Skylake-SP) to 290 µs (Sapphire Rapids) from the deep C6 state. One wakeup is small, but when a request passes through several servers, the delays add up. The kernel picks deeper states the longer it expects to stay idle, so this shows up more on quiet servers where packets arrive only now and then. The generic cpufreq powersave governor pins the frequency at the lowest allowed value (the intel_pstate algorithm of the same name adjusts it to the load).
On the graph
Always high · Round-trip time within the same data center, core frequency
Where to look
Per-core C-state residency and actual frequency from cpupower monitor; for each state under /sys/devices/system/cpu/cpu0/cpuidle/, its name, latency (µs to wake up), and usage; scaling_governor in cpufreq; and the current profile from tuned-adm active
Confirmed if
Idle cores sit in the deepest C-state for long stretches or the frequency is pinned near the minimum, and switching to the performance governor and shallow C-states reduces the round-trip time and jitter of small requests
Ruled out if
Difference after the change stays within tens of µs: safe to ignore this cause. Spikes in the ms range: “CPU steal (virtual machines)” or another layer
Check with
Infra tools (no game code needed)
Learn more
For bare-metal servers in a data center, check the BIOS (firmware) power settings together with the OS settings. In the cloud, only some instance types let the OS change C-states and frequency, and AWS defaults to maximum performance, so most instances can be left as they are. The tuned latency-performance profile on Red Hat-based systems sets the governor to performance and uses PM QoS to allow only shallow C-states. Turning off power saving raises power consumption, so apply it only to latency-sensitive servers.
Sources
CPU Idle Time ManagementLinux kernel Each power-saving state has a wakeup time (exit latency) and a minimum stay (target residency), and deeper states are chosen based on expected idle time; per-state latency, usage, and time in sysfs; PM QoS (/dev/cpu_dma_latency) and intel_idle.max_cstate limit deep states
drivers/idle/intel_idle.c (Linux v6.12)Linux kernel Wakeup times of C-states on Intel server CPUs: Skylake-SP C1 2 µs, C1E 10 µs, C6 133 µs; Ice Lake C6 170 µs; Sapphire Rapids C1 1 µs, C6 290 µs
CPU Performance ScalingLinux kernel Check and change the governor with scaling_governor; performance requests the highest allowed frequency, powersave the lowest
intel_pstate CPU Performance Scaling DriverLinux kernel The intel_pstate powersave algorithm differs from the generic powersave governor and scales with load (similar to schedutil and ondemand)
Chapter 2. Getting started with TuneDRed Hat The latency-performance profile turns off power-saving features, sets the governor to performance, and uses PM QoS to allow only shallow C-states; check the current profile with tuned-adm active
Processor state control for Amazon EC2 Linux instancesAWS Only some instance types let the OS control C-states and P-states, which can be changed to reduce latency; the default settings give maximum performance and suit most workloads; Graviton runs at a fixed frequency, so the OS doesn’t control it