Are you sure the default settings in MSFS are actually “Dynamic Settings 30”?
In my opinion testing with dynamic settings doesn’t really make sense, since it distorts the raw performance measurements.
Yeah, I think MSFS does some hardware checking to determine what “Defaults” are on a PC. For example, when I first installed MSFS on the newly build PC, on the setup screens you choose “Low, Medium, High, Ultra” and it defaults to Ultra, and the Dynamic setting was on. And this has been consistent every time I reset “as new” (after deleting cloud save and reinstalling). It is also on when I click “Reset to Defaults”.
But to your point, it does mask the raw FPS performance - by trying to maintain 30 FPS it instead reduces LODs (first TLOD, then OLOD, then Buildings LOD) - by design, and that does show in the results.
Now that I at least have a method to test, I’ll retry with Dynamic off, to see the raw FPS while it keeps LODs steady.
My next test will be to target 50 FPS instead of 60, which I think will allow me to maintain 4K on all 3 screens AND high LODs. It gives each frame slighly more time to process. My TV’s VRR range is 48 to 144 Hz. I must turn VRR off when using FSR Frame Gen (there is some frame pacing issue with that combo), but, by using VSync set in the NVCP, there is no tearing, and 50 is only slighly less smooth than 60, but I gain the clarity of 4K on all 3 screens.
The actual method I use is:
- Windows > Display Refresh = 120 (or 100)
- NVCP
- … GSync Compatible = Off
- … Monitor Technology = Fixed Refresh
- … Vertical Sync = Adaptive Half Monitor Refresh
- … which equates to 60 (or 50 depending on Windows setting)
- MSFS > Frame Gen = FSR
The other interesting thing I see is the pattern of memory allocation - I’m guessing it is hobbled by the upper 36 GB limit imposed by Asobo (in a Dev Q&A from MSFS 2024 launch). I’m going to try to ask if Asobo would consider lifiting that limit to 48 when it detects a PC has plenty of extra RAM…
On a friendly note, is this more of a triple screen settings discussion than a BIOS Optimization discussion at this point? Just wondering where all this is going. Cheers!
Sorry if that took a tangent - my intent was to measure performance:
- with no BIOS tuning
- after BIOS tuning
- on 1 and then 3 screens
Regardless of number of screens, the results show there can be significant improvement with tuning - most of the gain comes from memory tuning in my opinion, but the undervolting does also help with temps and creates headroom for boost clock when MSFS demands it. At least that’s what I’ve measured.
It also shows there is another limit being hit when the number of pixels being calculated goes up - there is diminishing return on the BIOS tuning (which mostly affects memory and CPU) and it’s either hitting a memory or GPU limit of some kind, I haven’t figured that part out yet.
I remember that after reinstalling MSFS 2024, even with an RTX 5090, MSFS 2024 automatically enabled DLSS and Frame Generation for me.
Right after that, I disabled Frame Generation and switched from DLSS to TAA manually.
And since we’re talking about BIOS optimization, most flight sim users only use a single monitor anyway. Because of that, I think it would make more sense if you tested using something like default ULTRA,HIGH,MEDIUM,LOW settings, but with FG and Dynamic Settings disabled.
So for example:
- Frame Generation: OFF
- Anti-Aliasing: TAA
- V-Sync: ON
- Dynamic Settings: OFF
Also, the monitor or TV refresh rate shouldn’t be limited, because that can affect benchmark results as well. And I think it’s important to test using only one monitor/TV connected.
That kind of setup would give us a much better baseline for comparing performance differences between different BIOS settings.
It would also help a lot if you included screenshots of the MSFS settings, just so there’s no guessing or misunderstandings about the exact configuration used.
If you look at the screen shot, that’s what I did. 4 of 5 of the columns are:
- Low to Ultra pure defaults
- Max Frames off
- FG off
- VSync off (because that limits FPS to monitor refresh)
- Dynamic On (in order to measure LOD reduction)
I used DLAA instead of TAA because I also wanted to measure the difference between DLSS versions (310.1 used by MSFS by default, vs 310.6 installed by DLSS swapper)
In the final column, “Custom”, I enabled Max Frames, FG, VSync.
The ‘dash’ means ‘off’
On a friendly note, as someone between the average PC pilot and a power user, PC-wise (which I will never be), not much of this is helpful to me around BIOS optimization. Too many things in play to make findings relatable, but you do you and good luck with your testing regimes!
There was a lot of discussion, but in trying to solve a problem I wanted to measure (however unscientific) and share the results. I can help simplify what it all means:
Memory timings matter most. MSFS moves so much data around in RAM and VRAM, that those timings have the largest benefit. Enabling EXPO (or XMP for Intel CPUs) matters - that by itself is an instant gain, but most people already do that.
If you want to go further, then tightening the memory subtimings is the best way to get additional performance. Best to make sure your RAM is on the motherboard’s QVL list, so that the subtiming options in the RAM can be read and used by the motherboard vis BIOS. On some motherboards you can choose from a list of a few presets in BIOS based on the RAM detected. I stumbled across it while building my pc and was amazed at the results.
On 1 screen, I get about a 20% improvement in FPS from Memory timings.
From the screenshot above, we also don’t know whether traffic is enabled, and if so, what exactly is active. We also don’t know the size of the rolling cache file. That’s exactly why full settings screenshots are important.
In the “Test Setup” Section of my post.
- Traffic is disabled.
- Rolling Cache was default 16 GB in “default” tests, 32 in “tuned”, forgot but will amend it.
- I used the “Few Clouds” preset because clouds affect performance.
You guys are free to do your own tests too if you don’t like my methods - I’m just sharing my results if anyone finds them useful.
I think I missed that part - thanks for the reminder and for pointing it out. One thing I’m wondering about is the exact moment the PrtScn key is pressed. For example, if the aircraft is on the apron, even a few seconds difference in when the screenshot is taken can noticeably affect the results. The same applies when on the runway - FPS and frametime can vary depending on what has already loaded and what is being rendered at that exact moment. That’s why even seconds or minutes can make a real difference for the comparability of the results.
So I had planned on doing full flights, and taking screen shots as best as I could at the exact same position… and I did that for a few flights, but quickly realized 60 variations would take me forever, and wasn’t necessary.
I compared the FPS of the A330 and C172:
- Cold and Dark
- Ready to Taxi
- Lined up
- Over NYC
- “at Minimums”
- At roll out
… and wanting to compare whereever the performance was worst (eg landing when objects are coming in to LOD range).
Just sitting at the parking spot with APU on and flight plan loaded was the next most stressful compared to landing or taxiing - but is the easiest to be consistent across tests, and takes the least amount of time to test. So I simply loaded in cold and dark, did a routine startup process, loaded same flight plan, got to the point of being ready to taxi, and took a screen shot from the default camera view.
So, yes, in general even as you sit there and watch the fluctuations, they do move, but by doing basically the same thing each time, it’s consistent enough for me to get repeatable results that are good enough for comparison. I’ll add that the act of taking a screen shot does consistently dip the FPS by 1 or 2.
In short, I did my best to make the set up consistent from test to test, to compare apples to apples - and the inevitable differences are minor enough that they don’t change the overall outcome (for me).
I will note, however, that something must have changed server side on May 3 or 4… I was in the middle of trying to figure out how to test, and suddenly the results were all different. I went back and re-did tests from the prior day and sure enough they were different too.
So I made sure to all of the tests above on the same day (60 variations took me about 6 hours)
Results can also be influenced by whether, for example, in external view the camera was previously rotated 360 degrees to force surrounding objects to load, as well as whether the same was done while in the cockpit. This also means that the exact timing of pressing the PrtScn key to capture the data is critical, since FPS and frametime can vary depending on what is currently being streamed, loaded, and rendered at that moment.
I agree that something must have been changed along the way without us being informed about it, because I also noticed differences in the data. That’s exactly why these kinds of tests are very valuable- we learn more from them and we also gain confidence in what we’re actually seeing.
Also, if someone claims that with an RTX 5090 and a Ryzen 7 9800X3D or 9850X3D a single monitor you need to significantly lower settings such as LOD, that is simply not true. I’ve been testing MSFS quite intensively myself recently, probably for a week or even two, and these differences have been consistently observable. From multiple tests, it’s clear that the stuttering we’re seeing is not caused by our hardware.
I wouldn’t mind an informal “standard test” scenario - a repeatable set of conditions and settings that is good enough for rough comparison on the same pc between sim versions, and comparision between users (to highlight differences in hardware, and even settings).
I test with default planes, streamed, no addons, and intentionally select a location that will represent a heavy scenario - the idea being if it can work there, it should work almost anywhere. So that’s how I ended up with the C172 at Teterborough and the A330 at KJFK - proximity to NY, PG, etc.
I used sitting at the gate because trying to do a lot of tests in the air just takes too long, and sitting at a parking spot or gate is so much easier to be consistent, and takes less time. Also, it still represents a good test of LODs. Landing and taxiing do put more stress and would be better for testing, but is so much harder to be consistent from test to test since you are busy flying the plane.
If I have the energy I’ll repeat my tests with TAA instead of DLAA, and possibly with DLSS Quality, Balanced, etc. Because I sit close to a large screen, and got used to full scale rendering details, I notice when the details are less due to render scaling. I do prefer TAA on instruments, but DLAA (with updated DLSS version 310.6) provides better detail in scenery. (My larger goal is get to the mountain top of Max settings on triple screens with smooth frames, eventually, and I’m almost there - and tuning is the key to that).
But if anyone wants to help define the parameters of the testing, let me know - I’m willing to adjust in order to make results comparable.
PS, to get the FPS overlay, I don’t open Dev mode - I use the command line when launching MSFS… I’m not sure if there is a difference in performance hit.
I’m open to that as well. I think we should agree on a fixed set of settings so everyone can run the same test conditions and we get truly comparable results - ideally with everything like DLSS, frame generation, and other performance-enhancing features turned off for a clean baseline.
I don’t use Developer Mode for the FPS overlay either.
How to Enable FPS Overlay Without Developer Mode - User Support Hub / Miscellaneous - Microsoft Flight Simulator Forums
From what I remember, having Developer Mode enabled used to have a noticeable negative impact on benchmark results.
@GimbalAxis in the ‘Chasing Stutters’ thread you mentioned to only set the PBO curve optimizer to negative 10-15. I’ve been running -30 all core since building the system. But seeing your mention of running a lower Curve, it’s got me thinking that whilst my -30 appears stable across the board, could it actually be hurting my sim performance?
9800x3d, x870e tomahawk
Well, maybe. Again I’m not an expert, but here’s how I understand it.
-
Higher frequencies require higher voltage
-
Every CPU and core is slightly different - some are better (requiring less voltage) some are not as efficient (requiring more voltage).
-
So AMD (and Intel) set the Voltage Frequency curves with the voltage set high enough that virtually all units will have margin (and not starve) to meet the rated speeds…
-
That means there is usually room to reduce voltage and increase frequencies, depending on the silicone lottery - you may have a great sample with -30. (On my CPU my best core can only be reduced by -15, and worst core by -30, so I actually measured and did Per Core…)
-
Undervolting itself doesn’t improve performance - it reduces voltage, which reduces heat, power and current. By itself that is a benefit for temps and longevity.
-
But undervolting DOES create headroom for the boost clock, so that IF or when the CPU does boost, it doesn’t hit the thermal / power limit. And, it creates room to increase the boost clock manually (assuming stability). This is significant both for momentary boost spikes, but also for sustained boost (like when approaching an airport and you are CPU limited).
-
When I tested mine, I started with the assumed goal of undervolting as far as I could, but when I started comparing numbers, I think I was overdoing it, and the further you go, it’s diminishing returns, so I backed off. There is a grey area between modest and extreme, where it doesn’t crash, but, cores that are starving will do something called “clock stretching” where it starts skipping clock cycles, leading to lower performance.
-
At stock BIOS settings, my 9800X3D likes to run at 1.2 V (in HWInfo, CPU VDDCR_VDD (SVI3 TFN) value.
-
If I undervolt by about -12 and then add 100 or 150 MHz boost clock, I’m at about 1.17 V, cooler and still faster.
-
I found if I undervolt further, I don’t gain anything in performance, and started getting some benchmark scores that were less, so I think I was starving some cores and thus losing a bit of performance.
-
The most significant benefit is combining a modest undervolt (to allow boost clock) with proper Memory timings - which has the most direct benefit for MSFS performance. That’s why I’m mostly focussed on memory.
Sorry I didn’t have time to write a “shorter” answer!
Here are a couple of screen shots from a while back, Cinebench at stock, and then tuned (screen shot taken at end of test, so it’s the Average column that matters).
In the first post of this thread I mentioned the Curve Optimizer settings - from my experience, around -15 all cores is kind of the sweet spot for 9800X3D or 9850X3D CPUs.
I was running -15 when I had the AMD Ryzen 7 9800X3D and I’m still running -15 now with my Ryzen 7 9850X3D. Both have been working perfectly fine for me.
Lower values like -30 all core can appear stable in normal use and even pass stress tests, but they can still affect overall system stability and also MSFS performance. In some cases it can actually lead to slightly lower FPS and/or stutters.
It also depends heavily on the individual CPU sample and motherboard. There are some CPUs and boards where even -20 all cores can result in full system instability. On the other hand, there are good samples and solid boards - like your setup - where -30 is not really an issue at all.
EDIT
Another thing is CPU Loadline Calibration - every motherboard has different default LLC behavior. If your motherboard runs a relatively “higher” CPU Loadline Calibration setting, then PBO all cores -30 may not be a problem for you, because LLC prevents Vcore from dropping too much under load.
Thanks Gimbal and Ten! Will reassess and see how it does.
The ‘best’ test imo is to use FSIPanel to repeat an approach or approaches over and over