Bob Scott

I have a 55" 4K TV on my P3D machine, and a 34" 3440x1440 ultra-wide on my XPlane/MSFS box. The lack of vertical real estate on the UW is an issue--it's not a showstopper, but it does detract somewhat. The large-format 4K display does as much as the UW w/r/t horizontal FOV. So I think a large-format 4K display is the best view solution overall, if you have room for the big display. One thing, though--if you want VRR, finding a large display with flicker-free G-Sync "compatible" VRR that can rival a true G-Sync equipped UW display is something of an undertaking.

On the 13900K with HT on, you have 32 virtual processors, not 24 (2 on each of the eight p-cores, and one on each of the 16 e-cores). With HT off, you have 24 VPs, all of which are physical processors. If you want to cool things down to get some thermal headroom, in addition to turning off HT, you can disable a bank of four e-cores, leaving you with 8p + 12e, or 20 VPs, which is more than enough. That's how I'm running my 13900KS--I have the CPU overclocked to 6.0 GHz on one core where P3D's main thread runs and 5.8 GHz on the remaining seven P-cores, but I also run very aggressive water cooling in an 18 deg C room -- two 360mm deep radiators in series plumbed with 0.5" ID tubing and a high flow Laing D5 pump. To disable e-cores (you need to do it in groups of four) you enable "Per E-Core Control" and you'll then see a list of the 16 e-cores...you can then disable e-cores individually. To confirm you have an entire bank shut down, you can go into Extreme Tweaker -> Specific Efficient Core, and you should see E-Core ratio limit and voltage for only three active banks, which is indication that the fourth and unlisted bank is shut down. If you don't disable all the e-cores in the bank (aka "Group"), you'll still see the ratio limit and voltage setting options listed, which indicates the bank is still powered-up and producing heat. In my case, I have the last four e-cores (12-15) disabled, and on the Specific Efficient Core page I see ratio limit and voltage setting options only for Group0 (e-cores 0-3), Group1 (e-cores 4-7) and Group2 (e-cores 8-11), and nothing for the now-depowered Group3. With HT off and a bank of e-cores shut down, if you use an AM it should be 20 bits, reflecting the 20 operating VPs.

Congrats. Take her on a nice simulated flight to Saint Maarten, perhaps? 😃

In the FSUIPC for Advanced Users document, see the section on traffic limiter ini parameters--should be in one of the appendices of the document. There's a parameter called Ground Preference that controls how much traffic gets deleted on the ground.

OK, but those are operator and/or acft manufacturer polices/procedures, which can be more (but not less) restrictive...the approach itself does not have published DH minima.

No, I'd much rather see competition and multiple options. It's not a "win" for me to have a market where a spotty dev is permitted to "stake his claim" by rushing out a half-baked scenery add-on and then everyone else stays away from doing that airport better because there's already a (poor) commercial offering out there.

When you see something like DA(H) 232 (200) on a plate, that 200 isn't radar altitude--it's the height above the runway touchdown zone elevation when at the decision altitude. On a Cat II you'll also see radar altimeter minimums expressed as "RA xxx", which is the height above the terrain directly below the acft when on the published glidepath at the missed approach point. On a Cat III there are no decision height minimums, only RVR visibility minimums.

On their website it says "Discontinued". Strange to take a completed product off the market while there's still some demand for it. No idea why...maybe the r/w airport is getting a runway extension or major changes to the terminals and they don't intend to keep it current (??)

RA is only used on Cat II/III approaches where the TERPS criteria requires the approach designer to take the terrain off the approach end of the runway into account to determine the DH. The RA is obtained by bouncing a radar signal off the ground directly under the acft...if the terrain on short final is significantly lower than the runway, then using the RA will put you in the weeds. Try that in IMC where the runway sits on a plateau (e.g. Telluride) or at the edge of a cliff (e.g. Andersen AFB, Guam) and you'll be a candidate for a Virtual Darwin Award.

Huh?? The WD 850x is an SSD.

Back in the FSX days, I encountered a similar problem several times, and found that copying the Acceleration installer from the CD to the hard drive made it work. Why? Who knows... There are components in the SP1 and SP2 updates that are *not* included in Acceleration...installing all of the service packs in order is the right way to do it. Similarly, the SDKs for RTM, SP1, SP2, and Acceleration should all be installed in order as well, as they install different versions of Simconnect that coexist in a side-by-side library, and some add-ons do use the older versions.

Yes, "symlink" is a contraction of symbolic link. That's done at the OS level, so a symlink to a folder on another drive appears to a program the same as if it were physically located at the link origin.

You can create a symlink and put one or more folders (e.g. community folder) on another drive.

The people that coded Windows have crafted a broad one-size-fits-all scheduling solution that isn't necessarily always optimum. Sometimes, additional tailoring of the scheduling priorities can be useful. I don't think Windows makes any special accomodation in its scheduling for real-time processes...there are use cases that warrant keeping other processes separated from them. That said, the loading on the P3D threads running the less-critical texture loading and other ancillary threads rarely rises to the point where sharing with a small number of low-load external (to the sim) processes would affect performance. Most texture processing is done ahead of time by lookahead code, anyway. Restricting the external stuff to the slower e-cores gives P3D more headroom on the faster p-cores on the 13900K. Though there may not be any appreciable gains, I don't see any downside in doing it that way.

I disagree. With P3D on my 13900KS, I use the AM to force the main thread to run on my fastest core, which is clocked independently and higher than the others to 6 GHz. I have HT turned off (and four e-cores disabled to reduce heat) because 20 physical cores is more than enough to handle the workload, and that way the cores aren't sharing cache memory with an unloaded or lightly-loaded virtual CPU. On older CPUs like my 10900K that can't set HT independently per-core, I use AM to block the OS from trying to put additional threads on the virtual CPU paired with the core that the main thread runs on. If I let the OS "do its job" without an AM, it loads threads onto the vCPU that shares the core running the main thread, and in the process reduces performance, more evident by the appearance of microstuttering than by a meaningful reduction in frame rate. P3D can still max out the main thread on a modern high-end CPU, e.g. with a lot of AI traffic. I'm not saying it averages 100%, but rather that utilization is maxxed-out often enough to produce stuttering. Keeping some headroom available on the main thread's core so that workload peaks don't drive the core all the way up to the wall has long been a key to smooth, stutter-free performance in P3D. If you were to graph demand alongside performance, you'd see demand peak up above the 100% line, and on the performance side a flat plateau where the CPU has maxxed out...in analog amplification waveforms it's commonly known as "clipping", e.g. the output waveform has its peaks "clipped" off because the amplifier can't produce enough power to keep up. Optimizing the performance on one core and assigning it to the main thread via an AM setting does make a difference for me. And keeping demand under control to leave headroom on the main thread also makes a difference. There still isn't a CPU made that can run P3D all-out with utter impunity...some configuration control is still needed for smooth performance.