Linux Desktop Latency: Find the Cause Before Tuning
A desktop can report high frame rates and still feel slow. Start by identifying which delay you are actually trying to reduce.
Updated
Frame time is not input latency
At 60 Hz, a display refresh interval is about 16.7 milliseconds; at 144 Hz, it is about 6.9 milliseconds. Those numbers describe the refresh cadence. They do not tell you how long a mouse click takes to produce a visible response.
Input travels through the device, application, rendering queue, compositor and display. A frame-time overlay measures only part of that path. A claim such as “under 2 ms” needs a named measurement, hardware details and a repeatable procedure. Without those, it is not a useful comparison.
For desktop troubleshooting, start with a narrower question: does scrolling hitch, does dragging a window feel delayed, or does a game pause during asset loading? Each symptom suggests a different investigation.
Write down a baseline you can repeat
Pick one workload: the same game scene, a particular page to scroll, or a window dragged across the same desktop. Keep the resolution, refresh rate, power source and application settings fixed. Let the machine warm up before recording a result.
Record the GPU and driver, kernel version, desktop or compositor, display configuration and whether the session uses Wayland or X11. These read-only shell commands help identify the kernel and session; a blank session value means you should check your desktop settings.
uname -r
printf '%s\n' "$XDG_SESSION_TYPE"- Describe the symptom precisely, including when it happens and how often.
- Save a frame-time trace if your application supports one. Averages can hide occasional long frames.
- Repeat the baseline several times. Note background downloads, compilation and temperature changes.
Follow the symptom to the bottleneck
If stutter appears only under a heavy workload, compare CPU, GPU, memory and disk activity while it occurs. A busy resource is a clue, not proof: correlate it with the actual pause.
For a GPU-heavy scene, try a lower rendering resolution while leaving other settings fixed. For pauses during file loading, investigate storage and memory pressure. If only one application stutters, test its settings before changing the entire desktop.
For problems that occur only with multiple monitors, compare a single-monitor session and record the refresh rates. For desktop effects, temporarily disable one effect at a time. Keep the original settings so every experiment is reversible.
Treat scheduler changes as an experiment
A scheduler decides which runnable tasks receive CPU time. Linux EEVDF uses eligibility and virtual deadlines to make those decisions. That is one part of responsiveness; it cannot by itself fix a saturated GPU or a slow display.
Before testing an alternative scheduler or custom kernel, establish that CPU contention is related to your symptom. Keep a known-working kernel available and understand your distribution’s recovery process. A different scheduler is not a universal upgrade.
Keep a small experiment log
Use the same workload for each comparison and change one variable. Record regressions as carefully as improvements. A smoother desktop that uses substantially more power may be the wrong tradeoff for a laptop.
This is a measurement workflow, not a published Aetheris OS benchmark. Reliable results need traces and a documented setup before they become performance claims.
Workload and duration:
Hardware / driver / kernel:
Resolution / refresh rate / power mode:
Baseline observations (three runs):
One setting changed:
Results (three runs):
Power, temperature or visual tradeoffs:
Keep or revert, and why:
