Bob Scott

A word of caution, though--since the OP primarily flies the Fenix Scarebus, it needs to be noted that the approaches to 26L/R at FlyTampa's KLAS will fly you into the dirt well short of the runways. FlyTampa changed the field elevation, raising it by around 200 ft, and the Fenix A320 uses Navigraph navdata to synthesize the glidepath based on the r/w airfield elevation. You can force the FlyTampa scenery to a higher priority than the Navigraph data, which at least temporarily solves the problem for acft that use the scenery navaids for navigation source data, but the Fenix bird won't see that reprioritized scenery data as it creates the glidepath internally using only the Navigraph data.

Dell/Alienware sells a 38" diagonal (35.2" wide) 3840 x 1600 display that improves vertical size over the 34" 21:9 displays and doesn't involve the hassle of bezel management or the performance hit from driving multiple monitors. It sports G-Sync Ultimate, too.

Which sim? FSX? P3D? As a first step, try starting the sim with a default acft at a default airfield, and once the acft is loaded and ready to fly, then switch to the PC12 so that there are no lingering state variable carryovers from your last flight.

If you're certain that you will stick to 3 x 1920 x 1080 resolution, then I'd consider 16 GB of VRAM the sweet spot, with DX12 and 75% of the pixel bandwidth of a 4K display. Personally, VRAM considerations aside, I'd go with the 4080 just for its sheer processing power. That should give you a lot of increased flexibility handling performance challenges like 4+ cloud layers, night + dynamic lighting, etc.

So after some further testing, I've gone back to HT completely off--with HT on I was observing small microstutters in the Fenix displays in climbs/descents. With HT off those microstutters completely smoothed out, and there was no drop in frame rate. I did leave the all-core overclock at 4.8GHz, and slowed my RAM down a notch from 3600 to 3500 MHz, and MSFS is still running stable. My gut feel is that MSFS is hammering the IMC really hard, and that may have been the genesis of intermittent CTDs caused by memory access violations (0xC0000005 errors).

I'd try putting it back where it was, then running the uninstaller, then reinstall it where you want it.

No, it has nothing to do with how many memory modules are in the PC. "DDR" stands for double data rate--the memory module doubles the clock speed internally, so a 2800MHz memory clock speed results in the memory cycling at double that, or 5600 MHz. And "XMP" stands for extreme memory profile--it's the tested overclock profile the manufacturer has coded into the memory module. Most DIMMs use RAM chips that are rated at lower speeds and the manufacturer overclocks them and sells the module rated at the higher, overclocked speed.

It was a pretty complete blanket of snow when I did a flight in central Chile a week or two ago--I lived down there for years, and it didn't look like that in the summer. I also flew a leg from Juneau to Ketchikan a few days ago, and there was little to no snow on the mountains. Just the usual ugly fluorescent lime-green depiction of what I think is supposed to be grass, only maybe after some kind of nuclear accident. I sure wish they'd give Alaska some much-needed attention. But as to snow cover, me thinks something is amiss.

Autosave has always created long pauses when I've used it. Some time back, I wrote a lua script that triggered saves at particular points in a flight--e.g. when the power was first advanced over 70% during the power-up for takeoff, when the plane levelled off at cruise, and when it started descent from cruise. That way the save-related pauses occurred when nothing else was going on and it didn't distract too much.

Well, there's great snow cover in the Andes. Unfortunately, someone apparently forgot to tell Asobo that it's SUMMER in the southern hemisphere in December...

I observed MSFS processor loading using Process Lasso. The last processor available is loaded up at near 100%, while the others are typically much less, with occasional peaks, probably when processing/loading the next scenery tile. I turned HT off on my i9-10900K's last core (core 9), and MSFS consistently runs the main thread there, and turning off HT on that core prevents it from having to share the core with other threads running on its companion virtual CPU. Performance appears to be the same as when I managed it by setting a CPU affinity for MSFS externally with Process Lasso. I do prefer doing it in the BIOS, though, as it presents no interference with the Windows scheduler that way.

Hmmmm...I got a nice performance increase on a 10900K after moving from a 3090 to a 4090, even on DX11 without FG.

Not sure--I'm not a VR guy. Just speculation on my part w/r/t VR and FG.

The improved smoothness is nice to have with FG...things like AI jets flying past while you're holding for takeoff look better. There is a downside, though--you have to use DX12 for FG to work, and there's a nasty bug in MSFS' DX12 implementation that's been around (and apparently unacknowledged by Asobo) for going on a year and a half where the ground textures on add-on scenery are randomly replaced by blurry Bing photo tiles--it's really exacerbated if you change cameras to an outside view. I've foregone FG because of this...I find DX11 at ~40 fps is a better experience than dealing with the DX12 bug just to gain the relatively small improvement in smoothness from FG. Now if you're a VR user, that frame rate boost probably makes enough of a difference to make dealing with the tile problem worth the distraction.

Aye...if only. One niggling scenery order problem in MSFS is that the navigraph navdata gets arbitrarily and automatically put at the top of the priority order (highest scenery order number) any time you make a change to the scenery config, and there are a few sceneries that need to be above the navigraph data in order to get some add-on navaids to work (a prime example being FlyTampa's Las Vegas scenery, which requires it to be above the navigraph data to make their ILS glideslopes to rwys 26L/R to work properly). So if you add or remove any scenery, including managing what's active with the add-on linker, or if you update the navigraph data, the scenery order gets rewritten with navigraph on top again. Aggggggggravating.

OK...I went back into the BIOS and looked, and sure 'nuf, you can. I stand corrected--and I'm gonna try that next!

Per-core HT isn't possible on a 10th-gen CPU. I can do that on my 13900KS, but not on the 10900K in my MSFS box.

That's normal--P3D is showing how much VRAM is available to it...the physical VRAM minus what Windows reserves for itself.

I think you meant 45:38 into the video...

In a variation on this theme, I had been running MSFS on my 10-core 10900K with HT off. I've observed that the main thread runs on the last core (core 9 in my case). As an experiment I lowered my all-core overclock to 4.8 GHz from 5.1 GHz, turned HT back on, and since MSFS doesn't have a config option to manage processor affinity, I used Process Lasso to externally set an affinity mask that keeps MSFS off of the paired virtual CPU on the core running the main thread, so the main thread doesn't share its core with other threads. In other words, Process Lasso allows MSFS to use virtual CPUs 0-18, and blocks vCPU 19 so that the core running the main thread doesn't have to share its processor time with other threads. This is an alternative to the all-or-nothing HT on or HT off approach, and it seems to have significantly mitigated the stability issues I was having with memory access violation (0xC0000005) crashes, and without any real performance hit.

This sounds like a Simconnect problem. There have been issues where add-on software bombards the Simconnect interface and overwhelms it to where it gets way behind and essentially stops responding. I recently had a number of panel lockups in the Fenix A320, but it was on SU13 the week before SU14 released. The panel froze and stopped responding, but the sim kept flying, sounds continued to work etc.

Check the control assignments of all your hardware in MSFS to make sure you don't have another device assigned to the rudder or tiller and fighting you for control. MSFS service updates have a history of messing with control assignments.

I have a 4090, and it's been nearly an omnipresent thorn in my side since I returned to tinkering with MSFS a few weeks ago. If I switch to an outside view (using DX12), patches of blurry Bing photoscenery tile replace some of the scenery tiles in my add-on sceneries. Turning on dev mode, then deselecting and reselecting "Draw on Terrain" fixes it temporarily. Was an intermittent problem, but became a persistent pain in the butt. Have not tried DX12 with SU14 yet to see if it's still as pervasively underwhelming.

Sounds like you're likely right on the ragged edge of the voltage needed to run stable at the manufacturer's XMP settings. Im my experience, usually you can stabilize an iffy XMP profile by adding one or two hundredths of a volt to the manufacturer's voltage spec and set that Vdimm manually in the BIOS--motherboards aren't super-accurate w/r/t actual applied voltage vs what's sensed/reported by the mobo's hardware, so the voltage being applied via the XMP profile might be just a hair too low. You might try that, and then run Memtest86+ through a 4-8 hour test cycle to verify stability.

SU14 now released, so I'm closing this prerelease thread.