Low flight simulator FPS with low CPU usage often means a main-thread bottleneck. Learn how to confirm it and which settings actually help.
For flight simulators in general, low FPS with low overall CPU usage usually means one main simulation thread is saturated while other cores are partly idle. The simulator cannot prepare frames any faster, so the GPU waits. Frame caps, thermal throttling, memory pressure, scenery streaming and add-ons can produce similar readings.
Does low CPU usage still mean a CPU bottleneck?
Yes. Overall CPU usage is an average across all processor cores and does not show whether the single thread controlling the simulation is overloaded.
A flight simulator must process aircraft systems, physics, traffic, scenery placement and draw calls in a particular order. Some supporting work can run on other cores, but the next frame often cannot proceed until the main thread finishes. On an eight-core processor, one heavily loaded core may contribute only about one eighth of the total usage before simultaneous multithreading and background work are considered.
The operating system can also move a busy thread between cores. Instead of one graph remaining at 100%, several cores may show moderate activity even though the same serial workload is still setting the frame rate.
Microsoft Flight Simulator can expose this directly through its developer performance display. If MSFS 2024 reports Limited by main thread, follow our targeted steps for reducing its main-thread workload. FSX is especially dependent on single-thread performance; its most effective adjustments are covered in our FSX-specific CPU and graphics tuning advice.
How do I confirm a main-thread bottleneck?
Compare CPU and GPU frame times under a repeatable test rather than relying on the overall CPU percentage alone.
- Remove artificial limits temporarily. Disable V-sync, external frame limiters, frame generation and VR motion reprojection while testing. These can cap or alter the reported FPS even when neither processor is fully loaded.
- Create a repeatable test. Use the same aircraft, airport, runway view, weather and traffic conditions after each change. Busy hubs and complex airliners are useful for exposing a main-thread limit, but they should not be compared with an empty rural flight.
- Inspect the right measurements. Use the simulator's performance display where available, together with per-core CPU graphs, GPU utilisation, temperatures and effective clock speeds. A CPU thread can be the limit without any individual graph staying permanently at 100%.
- Compare frame times. If the CPU or main-thread frame time is higher than the GPU frame time, the CPU side is setting the FPS. If the GPU is close to full utilisation and has the higher frame time, reduce graphics load instead.
Frame time makes the limit easier to understand: 30 FPS allows about 33.3 milliseconds per frame, while 60 FPS allows about 16.7 milliseconds. If the main thread takes 25 milliseconds, the simulator cannot exceed roughly 40 native FPS even if the other cores and GPU have spare capacity.
Which settings reduce flight simulator CPU load?
Lower settings that increase the number of simulated or submitted objects before reducing resolution and image-quality options.
| Likely limit | Change or test first | What should improve |
|---|---|---|
| Main simulation thread | AI and live traffic, airport vehicles, road traffic, ships and multiplayer object density | CPU frame time, especially at large airports |
| Scenery draw calls | Terrain or object level of detail, autogen density, object density and draw distance | Main-thread frame time in dense areas |
| Aircraft systems | Test a default, less complex aircraft; reduce cockpit display refresh rate if the simulator provides that option | Performance in the cockpit and during system-heavy operations |
| Add-on workload | Disable traffic tools, detailed scenery and external utilities in small groups | Identifies an add-on consuming CPU time or blocking the simulator |
| GPU rendering | Resolution, render scale, anti-aliasing, clouds, shadows, reflections and ambient occlusion | GPU frame time; these usually provide little help when the main thread is limiting FPS |
Setting names vary between simulators, but the principle is consistent: reduce traffic and scene complexity first when GPU usage is low. A mistake we see constantly is cutting resolution to its minimum while leaving dense traffic and long object draw distances untouched. That makes the picture worse without addressing the CPU bottleneck.
Test a default aircraft at a default airport before blaming the hardware. If performance recovers, re-enable add-ons in groups until the loss returns. For problems not isolated to the main thread, our simulator-wide performance checklist covers GPU, memory, storage and background-process limits.
More CPU cores are not automatically the answer. Once a simulator has enough cores for its supporting threads, stronger per-core performance, cache behaviour and sustained clock speed often matter more. A faster GPU will not fix a confirmed CPU main-thread limit, although it may permit higher resolution without reducing the existing FPS.
Why are both CPU and GPU usage low?
Low usage on both processors usually points to a frame cap, power or thermal restriction, memory stall, loading process or external software rather than raw rendering capacity.
- V-sync or an FPS limiter: A stable rate matching the display refresh rate—or an exact fraction of it—is usually intentional. VR reprojection may similarly hold the simulator to a fraction of the headset refresh rate.
- Thermal or power throttling: Check effective CPU and GPU clocks under load, not just their advertised boost speeds. Laptops should be connected to suitable power and set to an appropriate performance mode.
- RAM or storage pressure: Paging, asset decompression, shader compilation and scenery loading tend to cause uneven frame delivery or pauses rather than a clean, constant FPS ceiling.
- Add-on or network waits: Detailed scenery, external traffic tools and streamed assets can leave the processors waiting. Compare with a default aircraft, default scenery and temporarily disabled add-ons.
- Capture and overlay software: Recording can introduce encoder, memory-bandwidth or frame-pacing overhead even when average CPU use remains modest. Our explanation of how recording affects simulator FPS shows how to separate capture overhead from a main-thread limit.
If the simulator holds the desired frame rate smoothly, unused CPU capacity is normal and beneficial. If it misses the target, the highest frame time—not the lowest overall utilisation figure—identifies the component or process that needs attention.