Okay So I have disabled the AutoSave function in FSUIPC. So far the stutters are gone. To check I re enabled the autosave for every 10 seconds and then witnessed the long stutter every 10 seconds.... This could be it. I remember that the 747 suffered from the same situation for me.. it maybe something that happens if you are running a multi monitor setup (buffer overflow)?? Please let me know if this works for anyone else.... Hamish.

Noel Are you sure you disabled the auto save function in FSUIPC? would love to know if anyone else has encountered this issue... Hamish.

Zach I did try the antilag FPS limiter, but I didn't notice any difference. The RenderAheadLimit was set at "0". But, I was using it in Full Screen Mode (and also experiencing the Black Screen thing). Lately, I've been experimenting with Windowed Mode, so I'll try the antilag tool again. Richard, I was having the issue prior to going to 275.33, but if you're saying this version caused you grief, perhaps I'll revert back down. Oddly enough, sometimes it's smooth sailing for quite some time. This is aggravating. hammish777 - Thanks for the link to the process monitor. I downloade it and I'll install it later...I was looking for something like this. Much appreciated; I'll share what I find out. Hopefully it's not too hard to use and I can recover something meaningful. Cheers

Just recently upped to a GTX560 as you can see in my sig. I Upgraded to the 275.33 driver at the same time and started getting full blown crashes thinking it was my new card untill i dumped the 275.33.

Noel Are you sure you disabled the auto save function in FSUIPC? would love to know if anyone else has encountered this issue... Hamish.

I never had the auto save function enabled in FSUIPC, and have the problem I describe, virtually identical to Gump's post. I did double check on that and it's true, no auto-save happening.

Noel and hammish777, I installed the Process Monitor (PM) and noticed the same items in your screen capture Noel. I set the PM to filter just the D:\Microsoft Flight Simulator X\ directory first, and later whittled it down to just the D:\Microsoft Flight Simulator X\...Bucket\ directory. Those unsuccessful process calls appear during the stutter, but also seem to appear at other times not associated with the stutter. (??) Something else I noticed. When I start PM, it causes EZdok to crash. When that happens, I can't use TIR or the various EZdok cockpit views. I tested with it anyway. PM sure has an effect on FPS, but by itself, doesn't cause the hard stutter. I will say, looking around with TIR naturally causes the view to change rapidly which would seem to 'stress' the graphics more than a static view. The airplane itself doesn't turn that fast. Kind of like the stutters folks can get when turning the airplane while taxiing on the ground. That is the time when the outside view changes the quickest. The other thing I noticed, was that more than once I got the stutter when using elevator trim. May have been coincidental, but I've seen this all along sporadically. I didn't capture that with PM. And by the way, I was flying with one finger on the Pause button, to and capture the stutter. Or really, to shorten the list the PM is putting out. Too bad we don't have an Event Trigger. Maybe PM has one, but I couldn't find it. It's odd that FSX is looking for file names that don't exist. What's up with that? Odd. Wish I knew where to turn that off. I've not heard back from PMDG yet. Cheers,

Interesting, Noel. I wonder if just the sheer number of unsuccessful calls leads to the hard stutter, whereas when fewer are happening you don't get the hard stutter. Makes sense. As you say, what's triggering these at times frequent calls to the buckets directory that seem to be an unused drain on processing resources. When you get a whole slew of them bunched together you can see how the hard stutter would occur. One possibility as a work around is to disable your page file. You can use Performance Monitor to see something very cool: if you configure it to look ONLY at the drive you have FSX on, when you use System Managed pagefile size versus NO pagefile, you will see frequent recurrent I/O events to the FSX drive virtually disappear. Gotta be a good thing if you have enough ram. I'll try it and report back. I also just change Vista 64 advanced system settings to max performance. I've had great perf overall, but these two things should be interesting.

Interesting, Noel. I wonder if just the sheer number of unsuccessful calls leads to the hard stutter, whereas when fewer are happening you don't get the hard stutter. Makes sense. As you say, what's triggering these at times frequent calls to the buckets directory that seem to be an unused drain on processing resources. When you get a whole slew of them bunched together you can see how the hard stutter would occur. One possibility as a work around is to disable your page file. You can use Performance Monitor to see something very cool: if you configure it to look ONLY at the drive you have FSX on, when you use System Managed pagefile size versus NO pagefile, you will see frequent recurrent I/O events to the FSX drive virtually disappear. Gotta be a good thing if you have enough ram. I'll try it and report back. I also just change Vista 64 advanced system settings to max performance. I've had great perf overall, but these two things should be interesting.

Hmmm, that's interesting. Please do let us know how you make out on that.I'm also optimistic that PMDG may be able to get to the bottom of this. I'll bet they know more about FSX than anyone. In the meantime, this is forcing me to turn over every rock, and in the end, I may end up with better performance as a result. Thanks for your continued involvement in this.All the best,

Hmmm, that's interesting. Please do let us know how you make out on that.All the best,

No improvements noted when we changed to no page file. Still had the hard stutter, in fact overall performance seemed considerably worse. I really wonder what's up with all the unsuccessful calls. One would hope you wouldn't see this at all with a new installation of FSX. The other thing worth testing is flying something other than the NGX, maybe the PMDG 747, and seeing if you get these serial sets of unsuccessful transactions. It's hard to tell if the NGX is maybe just less tolerant of these sorts of potentially competing demands than other planes.

I am only experiencing a second or so of stutter right before touchdown, somewhere below 30'RA, as if it is loading something large... I run FSX off an SSD, which is a dedicated drive for FSX, no pagefile on it, though I will double check that later. Andrew

Hi Tim, You're right, I didn't include the things that were basic.  Heck, it would be too long a post!  I figured the reference to NickN's hallowed guide would suffice.  (Talk about a long post!)   You may not have noticed in one of my subsequent posts that I indeed tried the system at stock clock, and that didn't help.  Thanks for the thought just the same; sometimes we overlook the easy things.  It can just be something little. My RAM is not overclocked, but rather is at stock speed.  I've stress tested the memory as part of the system overclocking process.  But, I've not tried removing one stick.  I have observed the memory useage as part of the troubleshooting and can see that I should easily be able to get by on 4G...so I'll try that tonight.  Thanks for that suggestion! Your comments are very much appreciated. Cheers,

Gumps Sorry it didn't help. I hope you can sort it out quickly.Tim

I've spent quite a few hours on trying to solve this, but no real luck so far. I have... ...tried several Nvidia drivers, including 270.xx and the latest 280.xx. ...I put my two GTX580's in SLI for laughs. ...used various Nvidia Inspector settings. ...tried 1680x1050 resolution on my 30" monitor (yuck!). ...installed the PMDG Hotfix. ...removed one DDR DIMM, leaving one 4GB. I messed with the timings and speed. I will say, this had a significant impact on performance, all bad unfortunately. Turns out all was good with the original settings I settled on when setting up the system. This Mushkin Redline is rated at 1600, which is where I'm running it. Makes me want faster RAM though. ...replaced the NGX Trim *.wav file with a blank one, since I've seen the hiccup while trimming and coincidental with other sounds. BTW, I've used this to replace other annoying *.wav files that I got tired of listening to on other airplanes..."Don't sink", "Caution Terrain" etc. Hey, it's my business if I want to hit the terrain! ...and yes, I even tried loading the 747X first. Whew, talk about a primitive looking VC...in comparison to the NGX, that is. Noel - I experimented with creating some of those missing files in the .../Bucket/ folder, like the soundAI.CFG. I figured if the program was looking for a file, well then I'd give it one! It worked for one or two, but the *.CAB files didn't work out. Besides, when using PM, I notice a big stutter when a bunch of Orbx textures were loading. I'm a bit hampered when using PM since it kills EZdok and TIR. I've noticed that if I don't look around with TIR, but rather leave it paused, I get less hiccups. FWIW, one of the places I've been testing is Helena, Montana (KHLN) which has Orbx scenery. I've just done closed circuit work. Sometimes it's only 1 or 2 stutters in the course of a takeoff and landing. Other times it's 6 or so. If they were the "microstutter" variety, I wouldn't be so concerned. But these are sudden stoppage, really jerky, At this point, I've run out of ideas. Perhaps PMDG can sort it out. I'll be leaving for a month of vacation in a couple of days. Hopefully my computer will heal while I'm gone. Cheers,

Noel Are you sure you disabled the auto save function in FSUIPC? would love to know if anyone else has encountered this issue... Hamish.

Hamish, This seemed to work for me. I'll have to test more to see if it resolves the "hiccups", but after disabling the save my current flight isn't stuttering. Knock on wood. Thanks for the advice.

Yes, this does in fact sound like FSUIPC's auto save feature, which basically saves the flight, and the panel states of the aircraft, at whatever interval it is set to. Disable, or set to a reasonable time frame (like every 30 minutes or something).

Yes, this does in fact sound like FSUIPC's auto save feature, which basically saves the flight, and the panel states of the aircraft, at whatever interval it is set to. Disable, or set to a reasonable time frame (like every 30 minutes or something).

Hi Vic Thanks for weighing in. I will say, I've triple checked that the AutoSave feature in FSUIPC is not checked. I've been through every tab in the app, making sure the weather features are not enable, etc. Also, I'd have thought I would have seen this interference in Performance Monitor. (Discussed earlier in this thread.) It seems that something else is going on...come gremlin somewhere. Cheers,

"Sorry to be blunt, but you don't understand the first thing about how your computer actually runs software, or anything about bus architecture. If you did, you'd know that there are multiple items that could cause the system to momentarily freeze, or that 80% of the hardware you just listed has nothing to do with it." Best regards,Robin. =========================================== Hi Robin I was just trying to make the point that I'm surprised at seeing a performance issue with a higher end system. Surely one's hardware, including the CPU, GPU and HDD's play a role in the performance. Not that it can't happen with such hardware, of course...my guess is that it is a software issue. The NGX is the only addon exhibiting this behavior. It sounds like you're well versed in these matters. Do you have any suggestions (beyond those I've listed previously in this thread)? I would appreciate any insight you might have. Thank you

Hi, Did you remove the FSUIPC auto-save feature? Remember that FSUIPC runs inside the FSX process, and so it has the ability to momentarily steal time from FSX, causing FSX to apparently stop for a moment. If you have, try the following: First, I'd remove the overclock and try it without. Second, have you applied any tweaks to FSX.cfg? If so, delete the FSX.cfg file and let it build a new one. Try it without tweaks. Add back in the line HIGHMEMFIX=1 if you get graphical issues. Third, I'd list your current FSX configuration (as set in the GUI). AutoGen, Bloom, AI traffic, and all types of shadows kill FSX performance and introduce stutters. AI traffic has a memory leak bug, and AutoGen appears to do so too. Disable *all* of these, and see if it fixes the issue. Restart your computer after making these changes, and then test - there are numerous issues with these, that are best cleared by totally restarting the system to ensure you start clean. Fourth, stop all background processes (including any anti-virus, etc.). AV particularly eats resources, slows the computer, and isn't worth the CPU cycles to begin with. It will take a couple of hours to test all the above, but you should get there in the end. Post back here with the results of each item. Don't restore each item after testing - just try the next item. Just to clarify my earlier comment: the system doesn't know or care what kind of hard disk you've got - it only knows/cares about the SATA III interface. This is connected to either the Northbridge or Southbridge of your chipset. If it is connected to the Southbridge, things can be a bit slower than connecting to the Northbridge. Overall, this has little impact on the system except when it is directly using the device, then the speed of the disk can be a factor in delays incurred reading/writing the device. Regardless, you can't exceed the bus speed (and note that you can NEVER achieve the maximum bus speed due to overhead by the SATA protocol and other bus/device management data). The CPU doesn't care about your graphics card. DMA permits the hardware to directly access the memory bus without requiring CPU access. HOWEVER... only one device can access the memory at one time, and this includes the CPU. If a device on the bus is doing a memory access, ALL other devices must wait (including the CPU). FSX itself is not the best coded application. For all the talk of it being designed for future hardware, it was largely an excuse for its very poor performance on current hardware. FSX is largely FS9, which was largely FS2002, which was largely FS2000, which started with FS98. As you can see, it has been added to over the years, become bloated, and is now paying the price. The new features of FSX have quite serious problems, and some of the things they did (e.g. batch processing of AutoGen using fibers) was just a total disaster. Dig around MSDN for more tech info on that if you're interested - I can think of no time you'd want to micro-manage an application to that degree. It takes overhead, and ultimately runs slower, not to mention being so full of "gotchas" that it isn't worth the hassle. Does your processor have hyper-threading? You may want to try disabling it. Best regards,Robin.