After a few more days of troubleshooting, I still can't get to the bottom of the issue. I have run benchmarks/stress tests on my CPU and GPU, checked my hard drive for errors using three different services, updated the BIOS, and can't find a single issue with any of my hardware. Flawless hardware with a fresh install of W7 and FSX, and these problems are still manifesting themselves. Other games that I have installed since my fresh install are absolutely smooth with excellent FPS, but FSX is still stuttering like crazy, even with the sliders on minimum. There has got to be something conflicting with FSX, but when the problem was occurring with only a W7 install and FSX, I can't imagine what it could be.

I'm not familiar with ATI cards, I run an Nvidia 880GTS with only 320mb. Needless to say my rig had some wild stutters, especially with PMDG's NGX. However following Ryan(Tabs - PMDG) advice, I turned my anti-aliasing down to 4xS. I don't notice much difference in graphics quality, and my sim is now buttery smooth. - Roger

I assume you've turned the Search Indexing off for the FSX folder?

recently tried that tool that helps you build high performance fsx.cfg, and i started getting stutters, where as my old cfg was fine, putting back my old cfg was a pleasure, good performance again. One thing that also helped was upgrading to the free game booster 3, much far better than the older versions. But i advice you to delete some useless explorer tool bar app it also installs by defualt secretly. Just go to installed programs, and arrange by date installed to see it. After these two adjustments, all stutters were gone. Also use o&o defrag. 4.5GHz i7975 win764, nvidia gtx560ti The lesson i learnt is, never ever tweak if you dont need it, if you cant help it, tweak one thing at a time, and always make backup. One thing you could try is (!!!!!back up your controls file), then remove your fsx.cfg file to some other location, start fsx so that it generates brand new fsx.cfg file. copy back your controls file , so your keyboard / etc settings are restored. Then work your way up from there, as in my case my fsx.cfg file with few tweaks turned out to be far far much better than what was generated by , i think its ******* fsx.cfg auto config website. Also try not to have too many addons. As for using Game booster 1. It will stop a subset of wondows services 2. Then with fsx running, use task manager to see which programs are using lots of cpu, if any of them is service you dont need , add it to list of what game booster stops. for example, in my case i stopped Search Indexer and desktop themes.

to paul Ji got a mail back from you regarding spikes and bufferpools thanks for thatmy remaining question is in former forums you mentioned a bpoolsize 0f 30000how do i have to understand this in relation to the standard 8 million?if i could use 30000 what about the rejectthreshold of 131072?could you explain a little more so i can understand the diificult technic thanks

OK, I'll repeat it a little: First - just in case you don't have it - the prime fix for flashing, spikes, etc., is done by placing HIGHMEMFIX=1 in your [Graphics] section. This was (apparently) supposed to have been included in SP2, but was missed. It should be in all fsx.cfg's. BUFFERPOOLS is a section of its own in the fsx.cfg file. A buffer pool in the FSX world, is a piece of system memory used to cache graphics and index data pages as they are being read from disk, or being modified prior to being sent to the GPU. The buffer pool improves system performance by allowing graphics data to be read ahead from disk, and be accessed from memory instead of from disk - because memory access is so much faster than disk access. Because most data manipulation takes place in buffer pools, right-sizing buffer pools is important. Too little and there may well be a crash from a 'buffer overflow' error, too little, and the memory space is wasted. [bufferpools] // First set FSX to use a buffer pool:, so:-UsePools=1 // Then set the pool size, so:-PoolSize=8388608 // This is 8 MB, and is within the recommended 4-10 MB size. Then set the reject point:-RejectThreshold=xxxxxxx // 524288 for 512KB, 262144 for 256KB, 131072 for 128KB) Start with 524288, and if she's stable, drop it down to 256K, etc. This is the BufferPool bypass size, and tells FSX to send any data above the RejectThreshold size directly to the GPU. This 'system' was necessary with the early versions of the MS flight sim, because graphics cards had but a smidgeon of speed and memory that gpu cards have nowadays, and graphics processing was done by the maing cpu, and the BP parameter was pretty much set by Microsoft, and not touched or tweaked.

(Rafael Cintron, FS Graphics and Terrain team, in a post, 2007) "In RTM, the default setting was 1MB (1000000). The lower this number, the more pools the allocator will have to rummage through to find space for buffers and the more stutters you may have. In Sp1, we raised the default to 4MB (4000000) and optimized the underlying algorithm for finding free buffers"So be careful here, making this smaller can hurt you, since searching for space takes time and can cause stutters, and making the number too large can waste space. 4-10m is probably the range to be thinking about using unless you have a very high memory graphics card ( >512 )

Fast forward: The situation with the modern GPU is - not only does it have its' own very fast processor - it also has its' own fairly large memory bank - 2 gig is becoming quite common. The result is that it can read, manipulate and write to the screen just as fast or almost as fast as the system proc can push data to it. The system is almost 'balanced'. This means that using a buffer pool might actually slow down the process of writing to screen. If the proc can send data directly to the gpu - why do we need a buffer pool? Well - some folks have found their system will work without a bufferpool altogether - so... BufferPools=0. The downside is that one might get a little flash or two here and there - maybe too much for your taste - so, make it a small pool: UsePools=1, and PoolSize=8388608 (or 8MB). This is a figure which lots of flyers have played with for a couple of years: it has been higher and lower,but 8 MB seems about right, and is what MS techs have suggested to use. This on it's own, will work, but data is sometimes in lots of small chunks, and sometimes in quite large chunks. Because the high speed gpu can process lots of data very quickly, it is possible to use the bufferpool for all only small data chunks, and send the large data directly to the gpu - set by the RejectThreshold parameter. At this moment I'm using a RejectThreshold of 262144 - 256KB, so anything above this size is sent directly to the gpu. This size is the one to play with if you still have flashing, so keep the 8 MB for the pool size, and move the RT up or down. Hope this helps..

Paul, Thank you for your very detailed explanation of BP's, I am always trying to find the sweet spot, and your post will help a lot. Very much appreciated.

OK, I'll repeat it a little: First - just in case you don't have it - the prime fix for flashing, spikes, etc., is done by placing HIGHMEMFIX=1 in your [Graphics] section. This was (apparently) supposed to have been included in SP2, but was missed. It should be in all fsx.cfg's. BUFFERPOOLS is a section of its own in the fsx.cfg file. A buffer pool in the FSX world, is a piece of system memory used to cache graphics and index data pages as they are being read from disk, or being modified prior to being sent to the GPU. The buffer pool improves system performance by allowing graphics data to be read ahead from disk, and be accessed from memory instead of from disk - because memory access is so much faster than disk access. Because most data manipulation takes place in buffer pools, right-sizing buffer pools is important. Too little and there may well be a crash from a 'buffer overflow' error, too little, and the memory space is wasted. [bufferpools] // First set FSX to use a buffer pool:, so:-UsePools=1 // Then set the pool size, so:-PoolSize=8388608 // This is 8 MB, and is within the recommended 4-10 MB size. Then set the reject point:-RejectThreshold=xxxxxxx // 524288 for 512KB, 262144 for 256KB, 131072 for 128KB) Start with 524288, and if she's stable, drop it down to 256K, etc. This is the BufferPool bypass size, and tells FSX to send any data above the RejectThreshold size directly to the GPU. This 'system' was necessary with the early versions of the MS flight sim, because graphics cards had but a smidgeon of speed and memory that gpu cards have nowadays, and graphics processing was done by the maing cpu, and the BP parameter was pretty much set by Microsoft, and not touched or tweaked. Fast forward: The situation with the modern GPU is - not only does it have its' own very fast processor - it also has its' own fairly large memory bank - 2 gig is becoming quite common. The result is that it can read, manipulate and write to the screen just as fast or almost as fast as the system proc can push data to it. The system is almost 'balanced'. This means that using a buffer pool might actually slow down the process of writing to screen. If the proc can send data directly to the gpu - why do we need a buffer pool? Well - some folks have found their system will work without a bufferpool altogether - so... BufferPools=0. The downside is that one might get a little flash or two here and there - maybe too much for your taste - so, make it a small pool: UsePools=1, and PoolSize=8388608 (or 8MB). This is a figure which lots of flyers have played with for a couple of years: it has been higher and lower,but 8 MB seems about right, and is what MS techs have suggested to use. This on it's own, will work, but data is sometimes in lots of small chunks, and sometimes in quite large chunks. Because the high speed gpu can process lots of data very quickly, it is possible to use the bufferpool for all only small data chunks, and send the large data directly to the gpu - set by the RejectThreshold parameter. At this moment I'm using a RejectThreshold of 262144 - 256KB, so anything above this size is sent directly to the gpu. This size is the one to play with if you still have flashing, so keep the 8 MB for the pool size, and move the RT up or down. Hope this helps..

That's an OUTSTANDING explanation of a somewhat complicated tweak. I believe that BP=0 is a miracle tweak, if your card can handle it, because it improves performance and reduces stutters. Thanks for the thorough explanation.

yes thanks a lot for the explanationI assume you have played around with the poolsize because you also mentioned in other cases could be the poolsize =30000 instead off 8388608.does it mean that everything above the 30000 goes directly to the grafic card and what does in this case the rejectthreshold job do?

ok in the meantime I tried some settings and after a while I found out following settings are fine.[bufferpools]usepools=1poolsize=30000rejectthreshold=524288 when I use these settings I have no stutters,no flashes and no spikes.is this explanation right:bufferpool 30000 is a little buffer in memory instead of the harddisk and than the data goes to grafic card which one holds the first 524288 in stock and after this directly every data is used.

ok in the meantime I tried some settings and after a while I found out following settings are fine.[bufferpools]usepools=1poolsize=30000rejectthreshold=524288 when I use these settings I have no stutters,no flashes and no spikes.is this explanation right:bufferpool 30000 is a little buffer in memory instead of the harddisk and than the data goes to grafic card which one holds the first 524288 in stock and after this directly every data is used.

BP=30000 is a number that I tried after the BP=0 conclusion. I was just experimenting with different numbers and found that figure worked well with previous drivers. The latest driver allows me to run BP=0 with FSX locked at 30 fps. Everything is finally smooth as silk. BUT, I use Inspector setting at 16xS and 16anis and I set my water at High 2.x.

Hi, DJ! "The latest driver allows me to run BP=0 with FSX locked at 30 fps" Yup - doncha just love that 2600K? Yeah, 30K and a lot of other numbers have been experimented with, and I must confess I haven't played with mine since the new build. The fact that you can run a PoolSize of 30k indicates that your GPU is able to handle almost all the data the cpu can push. Making a reject threshold any higher than the pool size is immaterial - it will never get reached. If a 256K - even a 40K - data block hits the 30K buffer - boundary checking will ensure it doesn't cause a buffer overflow, and so it will bypass the buffer. Smaller than 30k-sized data blocks will be buffered per normal operation.

Hi, DJ! "The latest driver allows me to run BP=0 with FSX locked at 30 fps" Yup - doncha just love that 2600K? Yeah, 30K and a lot of other numbers have been experimented with, and I must confess I haven't played with mine since the new build. The fact that you can run a PoolSize of 30k indicates that your GPU is able to handle almost all the data the cpu can push. Making a reject threshold any higher than the pool size is immaterial - it will never get reached. If a 256K - even a 40K - data block hits the 30K buffer - boundary checking will ensure it doesn't cause a buffer overflow, and so it will bypass the buffer. Smaller than 30k-sized data blocks will be buffered per normal operation.

The 2600K and the gtx480 are a very good combination.

Paul, not sure about UsePools=1 ? FSX is using bufferpools by default (4 MB as we know). So why would we need this entry ?

FSX only uses Bufferpools if the section is added to fsx.cfg. I always thought this was correct? I've never added it because there are so many variables.