Ok, thanks, I’ll test your tips this evening and let you know
This seems to me really interesting. Thanks for the info.
In practice, you have to make sure that a) the CPU load never sends it red, and therefore that b) the GPU load is increased until the latency is kept close to, but not higher than, 32ms. This last thing I can only achieve by increasing the rendering, which I never thought I’d have to do (on the contrary, I thought that 2k, which is the resolution I play at, was already too expensive for the SIM).
If the CPU load is green / yellow, why does the SIM take advantage of a higher GPU load?
The goal is to make sure you are always limited by the GPU which therefore works constantly at 100% in this way. Temperatures go up a bit, but they stay around 66 degrees for me (EVGA 3070 XC), which seems like a good value to me. Is this the correct configuration?
The LOD, which affects the CPU, obviously causes very different loads depending on the zones. 150 seems to go well in KJFK with A32X but obviously - for example - in St. Moritz with a TBM you can go further. Should the GPU parameters (rendering percentage) also be raised at the same time?
Should the FPS value still be considered at this point? And if so, on what values should it stabilize?
Raising the rendering values, however, seems to negatively affect the internal panning (cockpit). Is there a solution for this?
Realizing that the GPU is loaded by the resolution regardless (or with less difference) of the complexity of the scenario, I am interested in why the headroom between the CPU and the GPU is so important.
In fact, even for me it does not remain fixed at 100% but varies between 90 and 100. And that temperature is certainly not worrying.
This is absolutely consistent with what I have observed for weeks: stutters even with FPS over 40, certainly due (but I did not notice) to the excessive load on the CPU (“limited by main thread”)
I have to look better, I’ll be able to tell you today or tomorrow. But I think it depends on the GPU because the problem also occurs in areas that are not very demanding for the CPU and sometimes even in flight, when presumably the CPU does not reach the limit.
In any case, thank you because this is one of the first discussions in which I can understand the reason for certain settings: one thing is to move the slides following some advice, another is to do it while you understand what you are doing and therefore also have a way to measure the results.
Which is more impacting terrain LOD or objects LOD? To me it’s the former as I can leave the latter at 200 with no fps degradation.
CPU headroom is important because the CPU being over loaded is the cause of the stutters. Even though the overall percent of usage is low, the threads can can only process so much information per cycle. Slowing down the FPS with the GPU load gives the CPU time to think between those cycles. That’s all there is to it.
Settings that increase FPS also increase stutters.
People who are trying to get the sim to run at max FPS in flight are also the ones experiencing the heaviest stuttering when they get back to the ground. The obsession with high FPS and not grasping that they are causing their own rendering problems is lost on a lot of people. That’s why I keep trying to explain this stuff. There might be a lot for the developers to work on as far as this sim is concerned. But stutters in high density lies solely on the end users, and their lack of understanding.
A nice side effect for those who use my method is that most of them can run Ultra settings and don’t even know it yet.
I’m trying my very best to provide the education for those willing to take it.
And what about V-SYNC and especially G-SYNC? Do these settings affect the parameters that are in question here?
They can. Prior to SU7 I used the in-game vsync at 30, in conjunction with my settings, to prevent microstutters. Things seem to have changed and now I am getting smoother performance with the vsync at 60, but will probably end up setting it back to 30 anyways just to reduce system load and save wasted energy.
I do always recommend keeping the vsync on though, because screen tearing seems to be more of an issue when the CPU is the bottleneck.
I can’t speak to Gsync or any other monitor syncing tools, because I don’t have a monitor that utilizes them.
Grabber523 thank you for your tips and methods, very interesting and I think helpful too.
I have a 10900K and RX 6800 16 GB 32 GB of RAM and I’m seeing little red hiccups on my normally green CPU bar every so often even when I’m doing nothing but staring straight forward and touching nothing?
I’m not running AIG traffic at that point nor do I see any malicious background peocesses eating CPU…but when I pan around at Burbank or some other photogrammetry area my green CPU and 30 locked FPS drop to red and 28 FPS (stutters)…any tips?
Do you recommend Hyperthreading to be turned on or off in the BIOS and how about the Threaded Optimization in the NCP?
It’s all in the thread above. Small ticks of red aren’t a big deal, and with the FPS counter off, you won’t notice those. But I addressed panning just a few posts ago. If it’s CPU, reduce LOD. If it’s GPU, reduce render scale.
Keep doing that until you feel that the balance between panning and overall quality are where you want them.
Just keep it from saying mainthread limited when the CPU load is high. As long as your GPU is loaded to ~32ms, then LOD and traffic are the only things left to reduce.
You don’t need to mess with either of those. By default hyperthreading and threaded optimization are on. Leave them alone.
There is too much bad advice and speculation out there if you’re going into the BIOS to change anything for this sim.
I happened to experience stutters especially usually at the point of touchdown… as i chance upon your post and started adjusting the settings in dev mode and monitoring the gpu and mainthread as you described and flew same route and airport to finally get stutter-free touchdown in dev mode…
BUT one qns i have is… does smoothness and stutter free performance in dev mode = the same when one exited the dev mode? Do you or anyone tested and can confirm? Reason i asked is because on one occassion i tried to land same airport the stutter started again even though i have adjusted setting and tested the airport in dev mode prior without any stutter.
Also i would have just flew in dev mode except that the present of top bar in dev mode is something i would rathet not have when flying in 787 cockpit view for better immersion…and i dont see hw i can hide the top bar…anyone know if possible?
[Correction] Just realized i can hide the top bar by selecting autohide under one of the avail dropdown.
Yes, the dev mode is just a toolbox. You will get the same performance whether it is on or off.
You have to understand that once your settings are adjusted to run smooth on the ground in high density, you have done your part. Even with everything set perfectly, you will still get the occasional ticks of red when you are sitting still. Just make sure you stay GPU-bound.
There are things outside of your control that will still cause CPU spikes that you cannot do anything about. Loading scenery will still hit your CPU, and you will see that on your latency bar in flight. Other things like weather, and especially lightning cause periodic spikes. You can’t fix those things, but making sure your CPU has headroom makes them far more sparse and less intense. In addition, you are always at the mercy of the servers and your internet service.
So do what you can to prevent mainthread limited conditions in your heaviest load area, then shut the dev mode fps counter off, and go fly.
Thanks for the advice…make sense .
Thx for the great explanation. I have been testing my VR performance for several months and knew that 32ms was the target to achieve. Never new exactly why…
I was trying to tune up using methods above and noticed if I went into the menu and then back to the cockpit, Render Latency would suddenly rise to 45 ms (from 30-32) and FPS would tank. To release this strange increase in resources from opening the settings screen, I would then have to go back into settings, change a setting and then put it back to its original value immediately, effectively just so I could then “save settings,” go back into the cockpit and Render latency would be down to 20-25ms, with the same settings I had just one minute earlier tuned to get to 30ms, making this whole process for me pretty impossible…
Are you giving it like 30 seconds to stabilize after you leave the menu? It takes a little time for the sim to redraw everything after you change settings.
Ah maybe not…i’ll be a bit more patient when i try again!
For me everything is fine until approach, landing and taxi. I have the same processor and overclock as you @Grabber523 (I have a 3080, not sure what GPU you have) running Ultra settings and RS at 130-150 (with clouds, buildings and grasses at high) in the A320 and CRJ. I’m thinking now I need to reduce LOD to 150 or even 100 to improve the situation. I seem to be constantly MainThread limited regardless of settings.
I have a 3060ti. And all of my graphics settings are maxed out.
Airliners do seem to hit the CPU harder, so lower LOD settings are most likely appropriate. Another member of the forum who used my process with great success settled on LODs of 150 as well, tuning for airliners.
Curious about something someone else brought up recently. Do you have a variable sync monitor? Like gsync or whatever? I’m wondering if something like that is making a difference. I don’t have it, so I can’t test for it.
When I initially came up with this procedure, I had my in-game vsync set to 30, and honestly prefer that over letting the FPS rise after takeoff. It seems to give just a little more headroom. If you haven’t tried that yet, turn it on, set it to 30, and see if your CPU load improves.