Why do I think there’s a caching issue? I chose EGLL for the test. I load on runway 27R. Takeoff is smooth. When turning toward London, slight stuttering begins as objects load. I circle and enter runway 27L. Approach and landing are smooth. During moving, stuttering and a drop in FPS appear. I turn and taxi onto runway 27L. During takeoff and climb, there are serious stutters related to object rendering. It seems like the cache has completely reset. After takeoff, I turn left, circle, and enter runway 27L again. When approaching near the runway, severe slowdowns begin. I look to the right and see objects intensively rendering there. However, all the objects on the left are there; they were cached during takeoff and the left turn, but not on the right. After landing and re-takeoff from 27L and circling London, the landing is relatively smooth, just like the first time after loading. This is all reproducible. I apologize for the possibly confusing description.
I would like to see the output of the FPS Window in developer mode. There you can see the transfer in and out the Rolling Cache.
And then deactivate Rolling Cache and test again. There is no other caching mechanism, so it should be a difference without Rolling Cache.
I’ll test it with rolling cache disabled. I’m using VR, so it’s pretty hard for me to track anything during the flight. But if possible, you could try repeating the flight using the algorithm described. I think the results will be similar.
Interesting observations regarding the rendering behavior. However, since disabling the rolling cache doesn’t resolve the issue, the bottleneck likely isn’t disk write speed, but rather how the main thread and the streaming pipelines handle heavy data allocation.
Regarding the rolling cache itself, its ideal size heavily depends on flying habits and hardware. A large rolling cache is highly beneficial if you frequently fly in the same regions or do repetitive patterns (like testing approaches at EGLL). It prevents the system from redownloading the same heavy assets. Conversely, a small rolling cache (or disabling it entirely) is mainly suited for users who constantly fly to new areas.
For context, I live in Paris on a 2 Gbps fiber connection and monitored my bandwidth live with the simulator running. Even with massive overhead and stable speeds, I still observed these severe stutters when the cache resets or struggles during approach. This clearly shows that raw download speed cannot bypass the internal engine bottleneck.
What you are describing—assets suddenly losing priority and having to intensively re-render during a turn or approach—points toward core memory management and pipeline congestion within the current SU5 architecture. When the engine’s data streaming boundaries get overwhelmed, the main thread stalls, causing those sudden stutters even while hardware utilization remains low.
You’re probably right. But Asobo doesn’t acknowledge this issue, even though it’s been around since MSFS 2020. How can we get the developers to pay attention to this? There are a lot of similar threads on the forum. The problem exists for everyone, but for some it’s just a minor inconvenience, while for others it’s a game-breaking obstacle. As I understand it, the higher the settings, the more severe the problem. Consequently, those with more powerful systems suffer. I can crank up almost all the settings to the max and still get acceptable fps in VR, but the stuttering makes it pointless.
I did several tests around a year ago, but there was no big difference between Rolling Cache enabled or disabled in terms of stutters. Except the loading of complex airports takes longer, objects and buildings are popping up over several seconds, textures are blurry in the beginning. This is far better with cache.
I did a test again today, and found out, that small Rolling Cache files have negative influence on the performance. With 16 or 32 GB Rolling Cache I could see stutters. There were completely gone with 256 GB Rolling Cache.
I tried rolling cache to 256 GB, and it made no difference. No matter the size, objects remain, loading as they approach.