LRW

Hi Bryan, I installed 1.4 and there's a PDF that says: IMPORTANT ‘ULTIMATE GROUND CREW X’ INFO FOR NGX-U USERS! If using ULTIMATE GROUND CREW X for your pushback and ground services, please visit the FS2Crew Support Forum for important information related to the NGX-U! I can't find any topic under the NGX-U or UGCX about this. Can you point me to right place, please? Thanks.

I started getting these on my 1080 Ti in v5 so I fell back on the TdrDelay work-around that I had used on my previous PC. Microsoft documents it at https://docs.microsoft.com/en-us/windows-hardware/drivers/display/tdr-registry-keys. I don't remember what app I used it for before (FSX or P3D) and it didn't always prevent timeouts, but so-far-so-good this time. KeyPath : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers KeyValue : TdrDelay ValueType : REG_DWORD ValueData : Number of seconds to delay. 2 seconds is the default value. I set mine to 10 seconds. I wouldn't use too large a value or you might have to power cycle to recover.

Thanks. That did it. KMSP looked kinda barren without Delta.

This is from Rob's P3D Guide. This description was written from a 32-bit perspective, when OOM's were a major concern. Setting it to '1' in a 64-bit environment will result in higher VAS but keep textures available longer. ENABLE_MEMORY_OPTIMIZATION Section: [GRAPHICS] Source: LM – Beau Hollis Default: 1 (if no entry exists) Description: 1. Performs periodic cleanup of the geometric cache which stores buffers used for batched buildings. If you have high autogen settings and move spin the camera around, the geometric cache can get quite big. Looking strait up at the sky for a few seconds may get you back 100+ MB of VAS. This change doesn't really help with the worst case scenarios where 200+ MB of memory is needed for the current scene, but it could help a great deal if you were to start in london where autogen is very taxing and switch to FlyTampa Dubai, where autogen is mostly disabled and replaced with pre-batched placed models. 2. Clear textures out when changing airports. Going to a new airport would trigger loading of new texture before the current area's textures had been given their 10-seconds to page out. Clearing out textures on airport change, helps prevent a spike in texture memory related to this. Note that with MaintainSystemCopyOfDeviceTextures enabled, this is less important as the bulk of the memory associated with these textures should already be freed up before the switch. Benefits: Reduce VAS usage. Detriments: None.

Several people on the Flight1 UTL support forum have reported that they no longer see Delta mainline or AIr Baltic flights after the update. They still see Delta Connection flights. I'm holding off until I see that Delta is working.

Since the 32GB kit of the TridentZ 4400 is the only RAM at that speed on the QVL for the Maximus XI Formula, it will be interesting to see if you can get XMP to work or at least a higher speed. I know that it won't be a matched set of 4, but close enough maybe?

Rob initially wrote 32000 and later corrected it to 320000. I don't think the decimals matter.

It didn't eliminate 100% of autogen popping and also some black textures when I look perpendicular to the direction of flight, but it is a significant improvement for me.

Did you add the settings that Rob described in the v4.4 thread? That made a big difference for me. MAX_TEXTURE_REQUEST_DISTANCE=320000 ENABLE_MEMORY_OPTIMIZATION=0

Why? A mere 200 MHz will give you 1.2 frames per second at 30 frames per second! Not worth the extra strain on the CPU or the effort, or the extreme cost of a custom loop. However... if you are a competitive overclocker, or just curious as to what your CPU can do, or have an abundance of funds then fair enough. If I was on a budget I'd have gone with an 8086K. This is more in the category of trying something new for the fun of it.

I've watched that video a couple of times. It was helpful, although his conclusion was for most people to use AI overclocking, which I tried early on to see what it would do. I found that a run of Prime95 or even RealBench would lower the cooler score so much that AI would lower the multiplier to 47 or 48. Running only P3D would raise it to 51. For people who want to let AI overclocking do the work it's important to only run their normal day-to-day apps and not artificial loads, like benchmarks. I just set the mode to Adaptive and entered the OC voltage manually. When I booted into Windows the idle voltage showed 0.630V. I don't know what I did before when it was 1.15V. Maybe I'm confusing it with my tests in Offset mode. My spreadsheet with all of my benchmark runs doesn't include minimums, only max and avg. Oh well. I'll stick with Adaptive. I think today I'll try a long flight and stop tweaking for a bit.

What cooler are you using? Running Prime95 with my current settings would hit thermal throttling very quickly and individual threads would fail. I'm considering doing my first custom loop to see how much I could lower temps from the AIO and possibly go to 5.2 or 5.3 GHz.

I used Manual when I was pushing the voltage up to see what the speed/heat was, but I don't want the voltage to remain at that level when idle. The Auto setting allows the CPU to run with 0.630V at idle (800 Mhz) and, at 5.1 GHz, AI Suite shows an Adaptive OC Voltage of 1.315. I haven't been able to find an Adaptive setting of my own that drops below 1.15V at idle. My last 15 minute run of RealBench on Auto showed Vcore @ 1.279V under load with LLC 6 and AVX 0. My temps in P3D are mostly in the 50s and 60s, with some spikes in the 70s, so I'm not concerned about AVX. I'm still on this journey, so I don't know where I'm going to end up.

I just installed FLAi and AI2UTL and saw the same behavior. It appears to be an issue with UTL not resolving add-on.xml files, which is how my FLAi was configured. I manually added the FLAi directory path to simobjects.xml and then the FLAi repaints showed up in the UTL config tool. AI2UTIL is a major time-saver. Great job!