System Tuning for X-Plane
Work in Progress
The kernel tuning parameters are currently still under review and may not all work as described. Subject to change.
Distributions and Their Target Profiles
Linux distributions differ not just in package manager and desktop environment, but primarily in the interplay between kernel and system software. Each distribution makes configuration decisions for a specific use case:
- General-purpose distributions (Debian, Ubuntu, Fedora) — optimize for stability and broad hardware compatibility. The kernel is conservatively configured, power saving has high priority.
- Gaming/multimedia distributions (Nobara, Pop!_OS) — ship with pre-tuned kernel parameters, scheduler settings, and driver configurations for low latency.
- Audio production (Ubuntu Studio, AV Linux) — use realtime kernels and prioritize audio pipelines.
- Server distributions (Debian Server, Rocky Linux) — maximize throughput and stability under sustained load.
The combination of kernel version, scheduler configuration, power management, drivers, and sysctl parameters determines system behavior. Distributions that are already optimized for low latency or gaming include many of the settings described here out of the box.
Debian as baseline
The following guides are based on Debian (Trixie/13) as the starting point — a general-purpose distribution that requires no adjustment for general use but can be specifically optimized for latency-sensitive applications like X-Plane. The standard kernel is replaced with the optimized Liquorix Kernel.
If you're using an already-tuned distribution like Nobara or Ubuntu Studio, you should not blindly apply these recommendations. There, a kernel swap can break existing optimizations, and double-tuning often leads to worse results. In that case, it's better to check individual parameters selectively rather than applying the entire profile.
Performance and Latency — An Important Distinction
When people talk about "performance," they usually mean high FPS. That's correct for shooters or racing games — throughput matters there: as many frames per second as possible. A flight simulator like X-Plane is different.
X-Plane calculates a complex world with physics, weather, scenery, and input devices. Individual frames are expensive, and the target framerate is typically 25–35 FPS. What matters is not the average, but consistency — frame-time regularity. A system delivering a stable 35 FPS produces smoother motion than one fluctuating between 25 and 50.
The cause of inconsistency is usually not insufficient computing power, but latency — short delays from system events that interrupt the main thread.
Typical symptoms of poor latency:
- Micro-stutters despite stable CPU/GPU load
- Delayed input response (joystick, rudder pedals)
- Inconsistent reaction time in the same scene
Key insight: For X-Plane, latency optimization matters more than throughput maximization. Temporal predictability beats raw computing power.
Understanding Latency Sources
System latency doesn't originate from a single source but from four independent categories:
| Category | Impact | Typical Symptom |
|---|---|---|
| Scheduling | Delayed thread start | Stutters after load spikes |
| Power Management | Wake-up latency from sleep states | Periodic brief interruptions |
| Interrupts | Competition for CPU time | Stutters during I/O or input |
| Memory/IO | Blocking background operations | Stutters when loading new scenery |
Scheduling
The Linux scheduler decides when a thread gets CPU time. A conservative scheduler waits longer before reacting — this saves power but increases latency. Modern schedulers use deadline-based task selection and adaptive preemption, allowing latency-sensitive threads to be scheduled more efficiently.
Power Management
CPU load doesn't cause stutters — transitions between power states do. When a core wakes from a deep sleep state, delays of up to several hundred microseconds occur. NVMe SSDs in power-saving mode also produce noticeable wake-up latencies (details under Disable NVMe Power Saving).
Interrupts
Hardware interrupts (USB devices, network, storage) preempt the running thread. A single interrupt at the wrong time can violate a frame deadline:
Memory/IO
The kernel optimizes throughput through batched background work (writeback, cache cleanup, paging). This creates rare but noticeable blocks — especially when loading large ortho textures.
Two Optimization Models
The right tuning strategy depends on the kernel. The standard kernel and Liquorix follow fundamentally different approaches:
Standard kernel = open-loop control → response must be forced
The generic Debian kernel prioritizes fairness and throughput. It reacts conservatively to load changes. Tuning here means: explicitly giving the application priority.
Liquorix = closed-loop control → disturbances must be removed
Liquorix uses the PDS (Priority and Deadline based Skiplist) scheduler with shorter preemption windows and a 1000 Hz timer frequency. It responds autonomously to load changes. Tuning here means: minimizing external sources of interference.
Same setting, opposite result
Identical parameters can have opposite effects depending on the kernel. A performance governor helps with the standard kernel but can be counterproductive under Liquorix (thermal headroom is lost). CPU isolation helps with the standard kernel but prevents Liquorix's adaptive optimization.
| Parameter Area | Standard Kernel | Liquorix |
|---|---|---|
| CPU clock | Constant high | Adaptive |
| Scheduler influence | Reinforce | Don't restrict |
| CPU pinning | Possible | Avoid |
| Interrupt routing | Optional | Essential |
| Power saving | Limit | Fine-tune |
| Writeback | Neutral | Smooth |
Which kernel am I using?
- Contains
liquorix→ Profile B (Liquorix) - Otherwise → Profile A (Standard kernel)
For installing Liquorix, see Liquorix Kernel.
Profile A: Debian Standard Kernel
Goal: Scheduler reacts conservatively → actively prioritize the application.
1. CPU Governor
Set the governor to a fixed high-performance clock to reduce reaction time and compensate for the lack of load prediction.
Switch immediately:
Verify:
To make the setting persistent across reboots, extend GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub:
2. Limit CPU Sleep States
In /etc/default/grub, extend GRUB_CMDLINE_LINUX_DEFAULT:
AMD vs. Intel
AMD Zen: Exports only C1 and C2 to the OS via ACPI. Deeper hardware C-states (C6) are managed autonomously by firmware. The value 2 ensures all available OS-visible C-states are used. Additionally, amd_pstate=active can be set for modern Zen processors with CPPC support.
Intel: Deeper ACPI C-states (C3, C6, C8, C10) are visible and controllable. Here, processor.max_cstate=3 can be useful to limit deep states. On systems using the intel_idle driver (default on modern Intel), intel_idle.max_cstate may also be needed.
Apply:
Reboot required.
3. Prioritize the Application (Affinity + Priority)
A launcher script that pins X-Plane to specific cores and starts it with elevated scheduling priority:
Launch:
About the priority
SCHED_FIFO priority 45 is below critical kernel threads such as IRQ handlers (priority 50) but well above normal processes. Values above 50 can preempt kernel housekeeping and cause instability.
4. Optional: CPU Isolation
Only useful under high background load. Add to /etc/default/grub:
Deprecation notice
isolcpus is marked as deprecated in the kernel documentation. The modern alternative is cpusets, which can be configured at runtime without rebooting. For a simple desktop use case, isolcpus remains the more straightforward option.
5. Memory Behavior
vm.swappiness=20
vm.dirty_ratio=20
vm.dirty_background_ratio=10
vm.vfs_cache_pressure=100
Apply:
Result Profile A
The kernel reacts faster because CPU time is guaranteed for the application.
Profile B: Liquorix Kernel
Goal: Scheduler already works optimally → remove external disturbances.
Important: No isolcpus, no taskset — these would prevent the scheduler's adaptive optimization.
1. Adaptive CPU Governor
Switch immediately:
Verify:
Why ondemand instead of schedutil?
schedutil relies on utilization signals from the mainline CFS/EEVDF scheduler. However, Liquorix uses the PDS alternative scheduler, which does not provide these signals — schedutil is therefore not compiled in. ondemand also adjusts CPU frequency based on load but works independently of the scheduler.
Optionally set Energy Performance Preference:
echo balance_performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
To make the setting persistent across reboots, extend GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub:
Persistence
The terminal commands apply until the next reboot. The GRUB method makes the setting permanent. For permanent EPP settings, create a systemd unit or udev rule.
2. C-States and Power Management
AMD vs. Intel
AMD Zen: Only C1/C2 are OS-visible — no C-state limitation needed. Deeper hardware C-states benefit the thermal budget.
Intel: processor.max_cstate=5 allows moderate sleep states while avoiding the deepest states. On systems using intel_idle (default), also set intel_idle.max_cstate=5.
In /etc/default/grub — for Intel:
3. Interrupt Shielding
The most important measure under Liquorix. Concentrate hardware interrupts on the first cores so the scheduler can use the remaining cores undisturbed for the application.
IRQ affinity on modern kernels
Modern kernels use managed interrupts for MSI-X devices (NVMe, GPU, etc.). The kernel controls affinity allocation for these IRQs, and writes to /proc/irq/*/smp_affinity are rejected by design — regardless of kernel variant. This is not Liquorix-specific but a general kernel mechanism.
The userspace daemon irqbalance handles redistribution of non-managed IRQs and respects these kernel constraints automatically.
For non-managed IRQs, irqbalance provides effective CPU exclusion. In /etc/default/irqbalance, add:
This excludes the specified cores from interrupt distribution. CPU 0–3 = system/interrupts, rest = application.
Why irqbalance instead of manual affinity?
irqbalance with BANNED_CPULIST is more maintainable than manual affinity: it automatically adapts to new hardware IRQs and distributes load intelligently across the allowed cores.
4. Disable NVMe Power Saving
NVMe SSDs in power-saving mode can have wake-up latencies in the millisecond range — longer than a complete frame at 60 Hz. Exit latencies vary by manufacturer and power state.
To disable NVMe power saving, extend GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub:
Reboot required.
Runtime changes
The sysfs parameter /sys/module/nvme_core/parameters/default_ps_max_latency_us only affects newly initialized NVMe devices. For already-active devices, use per-device PM QOS:
5. Smooth Memory Writeback
vm.swappiness=10
vm.dirty_background_ratio=3
vm.dirty_ratio=10
vm.vfs_cache_pressure=100
Apply:
6. Light Prioritization
Under Liquorix, a moderate nice adjustment is sufficient:
Result Profile B
Not maximum performance — but minimal frame-time spikes. The scheduler can optimize freely because external disturbances are reduced.
Switching Between Kernels
If you have both kernels installed in parallel (standard Debian + Liquorix), you can choose which one to boot. This lets you use the matching tuning profile depending on your use case — without uninstalling either kernel.
List Installed Kernels
Identify GRUB Menu Entries
GRUB numbers entries starting from 0. Kernels in the "Advanced options" submenu are addressed with >:
The format for submenu entries is "Parent>Entry", e.g.:
One-Time Switch
Prerequisite
grub-reboot requires GRUB_DEFAULT=saved in /etc/default/grub (see Permanent Switch below). Without it, GRUB ignores the saved entry.
Boot a specific kernel on the next reboot, then return to the default:
sudo grub-reboot "Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 6.12.6-1-liquorix-amd64"
sudo reboot
Permanent Switch
Change the default boot entry permanently:
-
In
/etc/default/grub, set: -
Set the desired kernel as default:
After this setup, grub-reboot also works for one-time deviations from the saved default.
Check Current Kernel
What Can Be Switched at Runtime?
Not all settings require a reboot. The following table shows which parameters can be changed while the system is running:
| Parameter | Changeable at runtime? | Method |
|---|---|---|
| Governor | Yes | echo ... \| sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor |
| NVMe APST | No | GRUB only — sysfs parameter only affects newly initialized devices |
| sysctl (vm.*) | Yes | sudo sysctl --system |
| irqbalance service | Yes | sudo systemctl stop/start irqbalance |
| nice / chrt / taskset | Yes | Set when launching the application |
| IRQ affinity | No (managed IRQs) | Kernel manages MSI-X affinity — use irqbalance with BANNED_CPULIST for non-managed IRQs |
| processor.max_cstate | No | GRUB only, reboot required |
| isolcpus | No | GRUB only (alternative: cpusets) |
Match your tuning profile
After switching kernels, use the matching profile: Profile A for the standard kernel, Profile B for Liquorix. The governor and sysctl settings differ fundamentally — the wrong combination will degrade performance.
Overall Comparison
| Area | Standard Kernel | Liquorix |
|---|---|---|
| Governor | performance |
ondemand |
| CPU pinning | Yes (taskset) |
No |
| Interrupt separation | Optional | Important |
| NVMe APST | Optionally disabled | Disabled |
| Writeback | Normal | Smoothed |
| Prioritization | SCHED_FIFO + affinity |
nice -n -10 |
| Goal | Force responsiveness | Prevent disturbances |
Core rule
Standard kernel needs prioritization — Liquorix needs quiet.
Configuring both kernels the same way almost always makes things worse.
Sources
The most important sources for the topics covered on this page:
- CPU Performance Scaling — Linux Kernel Documentation — CPU frequency governors and scaling drivers
- CPU Idle Time Management — Linux Kernel Documentation — C-states and idle drivers (acpi_idle, intel_idle)
- amd-pstate CPU Performance Scaling Driver — Linux Kernel Documentation — AMD P-State driver modes
- Liquorix Kernel — PDS scheduler, Zen Interactive Tuning, kernel features
- irqbalance(1) — Debian Man Page — IRQ distribution daemon configuration
- Solid State Drive/NVMe — Arch Wiki — NVMe power management (APST)
- sysctl.d(5) — Linux Man Page — sysctl drop-in configuration
- GNU GRUB Manual — GRUB configuration and kernel selection