HI GuysLOL, the thread has turned in to more of a discussion about bufferpools now as these things do.Just to say thanks to the first 6 or 7 posters for advice and explantions telling me the Graphics card is overheating and suggestions of what to do.I will have a look at increasing the fan and I have added the RejectThreshold=131072 as per Ryan's advice.When I have done a few flights i'll provide an update.Many thanksLazza

Lazza,This is happening because you are running unlimited framerates and overwhelming your graphics card (causing all the other reasons listed above). Try locking your framerates using the external framerate limiter tool that's floating around (if you need it I've got it). Locking with the framerate lock in FSX causes decreased performance for whatever reason.We have similar systems only I've got a gtx260, and I run this without issue. Let me know if you need further explanation. Thanks!

HI GuysLOL, the thread has turned in to more of a discussion about bufferpools now as these things do.Just to say thanks to the first 6 or 7 posters for advice and explantions telling me the Graphics card is overheating and suggestions of what to do.I will have a look at increasing the fan and I have added the RejectThreshold=131072 as per Ryan's advice.When I have done a few flights i'll provide an update.Many thanksLazza

You didn't say which video drivers you were using? I have had that problem with my setup. I would use BP=0 and get better performance particularly with the very demanding PNW scenery. However there was an occasional "noise" problem as you are mentioning. I was using then the drivers 195... something. Can't remember offhand.I then switched to the new 260.99 with Nvidia Inspector 1.93 and BP=0. The result is that I have been Simming for the past 2 days without any glitch.On my system (see the sig)those drivers are the solution without loss in FPS but I can use BP=0 continuously now and there is much less video flashing when panning views.Hope if helps, Pierre

freebird77,Pool Size is ...snip.... - it's only a threshold for where one block ends and the next one begins getting filled, not some sort of overall threshold where data above that value goes directly to the card. .... Cards that were around when this system was designed didn't have anywhere near the power today's do and it was very easy to overload them and crash the video driver without doing this. Because cards have gotten so much more powerful, the system can be tweaked today to let it utilize that power a bit more.

Ryan,Thanks for the reply.Are you saying that no matter what BP=X size there are now a number of buffers all based on the size you have chosen?Why then is the performance so imperceivably the same? In other words, why then if we set it up with a Poolsize=125000 does the sim act exactly like "RejectThreshold=128KB” (increased frames etc or lowering it further results in corruption) or any other low number that others have had success with? The definition you posted is the first one I believe that describes BP=x as a -->number of buffers of X size. Not saying for a fact that its inaccurate but it doesn't seem to jive with the results of simply lowering BP=X that everyone gets .Nor does that definition seem to match what Aces team members have communicated, hence the question as why all the old language/commands being used when Poolsize=x seems do exactly the same without cluttering up the cfg. As for the other point about more powerful cards it would seem that users of the 480GTX still have the same problem as users of 285GTX/460GTX as we can see even in this thread all though I’m hoping with the 580GTX out this month.

I use realtemp (4.64) which shows you the temperature of the GPU (and CPU of course).This will allow you find out if you are over stressing your GPU - with the bufferpools = 0option I find my GPU gets to about 55C which is good in a laptop and I have not yetsee this problem. (ATI 560v)

Ryan,Thanks for the reply.Are you saying that no matter what BP=X size there are now a number of buffers all based on the size you have chosen?Why then is the performance so imperceivably the same? In other words, why then if we set it up with a Poolsize=125000 does the sim act exactly like "RejectThreshold=128KB” (increased frames etc or lowering it further results in corruption) or any other low number that others have had success with? The definition you posted is the first one I believe that describes BP=x as a -->number of buffers of X size. Not saying for a fact that its inaccurate but it doesn't seem to jive with the results of simply lowering BP=X that everyone gets .Nor does that definition seem to match what Aces team members have communicated, hence the question as why all the old language/commands being used when Poolsize=x seems do exactly the same without cluttering up the cfg. As for the other point about more powerful cards it would seem that users of the 480GTX still have the same problem as users of 285GTX/460GTX as we can see even in this thread all though I’m hoping with the 580GTX out this month.

Apologize if this is too simplistic, or if I don't understand fully, so correct if I'm wrong pleaseThe Old bufferpools tweak and the BP=whatever line simply sets the SIZE of the buffer pools. When you use Usepools=0 you are telling FSX to ignore the bufferpools completely and send everything to the graphics card, thus freeing up CPU to process other stuff, making your flight smoother/better ideally. This only works if your graphics card is up to the task of processing all that graphical stuff in realtime. If the graphics card can't keep up you'll see what the OP is seeing. the tweak for this is to use the reject thresh. so when that is active FSX sends everything greater in size than the threshold, direct to the GPU and processes everything else in the CPU, so obviously you want that number to be as low as possible while not causing the stuff that the OP is seeing. The old bufferpools command sent NOTHING direct to the GPU, the poolsize you had in the BP just specified the amount of pool that you were working with.Of course the point is why do any of this if the results are the same. simply, do what works for your setup. none of these tweaks work for everyone, but I have had good success with the reject threshold and usepools 0 that I couldn't get with the old BP tweak. My graphics card is better than my CPU so it has no trouble keeping up, and I get a better experience. my CPU is still the limiting factor so in areas such as FTX downtown seattle, I'm still dragging, but everywhere else it's much better/smoother than it was. I get the occasional flash, but it doesn't bother me. SO, you may get the same results with either tweak, but they don't work the same, so others may have a different experience.

but they don't work the same, so others may have a different experience.

That’s a nice explanation, but I think I'll stick with what I know, thank you.I will just say that No I think that is wrong, and would say that BP/PS=X as Aces gave us as a tweak was used as the latest best way to control BP than these other controls that they chose to leave out of view and as is without all the graphic corruption for simply turning up the IQ or the unwanted clutter and mess to the cfg.So I'll just politely agree to disagree with Ryan and his "source" and apologize for hijacking this thread.Cheers!

That’s a nice explanation, but I think I'll stick with what I know, thank you.I will just say that No I think that is wrong, and would say that BP/PS=X as Aces gave us as a tweak was used as the latest best way to control BP than these other controls that they chose to leave out of view and as is without all the graphic corruption for simply turning up the IQ or the unwanted clutter and mess to the cfg.So I'll just politely agree to disagree with Ryan and his "source" and apologize for hijacking this thread.Cheers!

cool, do what you want. In the cfg NONE of these commands exist as default so to use the BP command at all you have to add two lines to the text where this tweak also adds two lines, three at most, so I'm not sure where you're getting the "clutter" from.Aces didn't document this, because they didn't want the hassle of troubleshooting clunky graphics cards and corruption issues like this, that DOES NOT mean it doesn't work. But hey, if it doesn't give you the results don't use it.

cool, do what you want. In the cfg NONE of these commands exist as default so to use the BP command at all you have to add two lines to the text where this tweak also adds two lines, three at most, so I'm not sure where you're getting the "clutter" from.Aces didn't document this, because they didn't want the hassle of troubleshooting clunky graphics cards and corruption issues like this, that DOES NOT mean it doesn't work. But hey, if it doesn't give you the results don't use it.

Bufferpools of 4mb is on by default. Aces did document for us Poolsize=x. Thats just one line under one header over the multiple commands that Ryan's source suggestand and the many combinations that can result that get people confused.I dont know if I would call a 480GTX or even a 280GTX "clunky".The results speak for themselves, just look at the topic and the many comments by others that run into the same wall as BP=x.See anything new? no, not really.Hopefully "Flight" will end all this nonsense. Now back to flying....Cheers!

I'm not sure why you're putting sarcasm quotes around my saying we talked to someone who helped program the engine - do you seriously think PMDG wouldn't have that sort of connection?Here's the direct quote from the person we corresponded with on this back when ******* Altuve discovered some of the then-unknown cfg settings:

Disabling buffer pools just means that each set of vertex\index data will allocate its own D3D9VertexBuffer. With it on it will create dynamic 4MB D3DVertexBuffer objects and combine multiple sets of vertex data together until it fills the 4MB buffer and then it will create another one. This was done to try to reduce the amount of memory fragmentation that can occur in D3D9 because each vertex buffer allocation has a large overhead (D3D9 reserves a fairly sizable header for the block of memory even for very small vertex buffer allocations). I believe the problem is that with buffer pooling enabled, FSX will combine almost any vertex buffer into a pool even if the vertex data is static. Dynamic vertex buffers have a huge perf hit because they live in video memory and get sent across the bus every frame.PoolSize= size of the pool to allocate, defaults to 4MB, this is probably a fine size RejectThreshold=if an allocation is bigger than this it doesn’t get pooled. It defaults to 2MB. You could probably reduce this a lot and get the perf improvements of UsePools=0 without the instability.

Bufferpools of 4mb is on by default. Aces did document for us Poolsize=x. Thats just one line under one header over the multiple commands that Ryan's source suggestand and the many combinations that can result that get people confused.I dont know if I would call a 480GTX or even a 280GTX "clunky".The results speak for themselves, just look at the topic and the many comments by others that run into the same wall as BP=x.See anything new? no, not really.Hopefully "Flight" will end all this nonsense. Now back to flying....Cheers!

my graphics card is well south of the two you mentioned and works with this tweak fine, it works fine because my CPU stinks and doesn't push the GPU much. so I imagine an overclocked i7 will tax even the best GPU around with this tweak. like ******* mentioned in his post about this, it's a race and the GPU has to win or it doesn't work. I made the clunky remark, because if Aces HAD documented this, EVERYBODY would have immediately added it to their cfg regardless of the type of hardware they have and ######ed because it didn't work for them. It's a risky tweak, it can make your hardware unstable, so from a support standpoint it would be a nightmare. It is well evident that this doesn't work all the time, everywhere. I'm sorry it doesn't work for you. For me it's enabling me to not have to buy a new system, because my performance is at least acceptable with it, where it most definitely was not before. I never said there weren't people who it didn't work for, in fact quite the opposite. but you're taking the tack that since it didn't work for you, that it must not work for anybody, and that anybody who insists it works is either wrong or deliberately lying, and that is definitely not the case.

I'm not sure why you're putting sarcasm quotes around my saying we talked to someone who helped program the engine - do you seriously think PMDG wouldn't have that sort of connection?Here's the direct quote from the person we corresponded with on this back when ******* Altuve discovered some of the then-unknown cfg settings:

Ryan,If puting "sources" in quotes offends you suggest you get a thicker skin, really no such sarcasm intended nor neccassary and you are reading way too much into it my freind.Thanks for posting your info, but as for what connections we may or may not all have is a pissing contest of some sort that we dont need to play.When you have a chance you might ask your source about the question raised in my comment and ask him to explain why we get such a similar result.Thanks again for the reply.Cheers!

but you're taking the tack that since it didn't work for you, that it must not work for anybody, and that anybody who insists it works is either wrong or deliberately lying, and that is definitely not the case.

I dont recall making any staments about "it" working or not, so your deffending a possition that you created, not me. The "it" (oh no, quotes) works just as you see (well if you had a faster system), push the IQ with complex add-ons on a state of the art system and we all know what will happen, hence all the neccassary caps on certain settings.You sure it wise to make assumptions about how someone else came to a conclusion when you dont have any info about where their knowledge comes from?:( Sorry again to the original poster, who really probably just needs to dial things back a bit, increase Poolsize back from zero to 100000 etc a bit at a time or use the reject rejectThreshold method as Ryan suggest. Cheers!

I will just say that No I think that is wrong, and would say that BP/PS=X as Aces gave us as a tweak was used as the latest best way to control BP than these other controls that they chose to leave out of view and as is without all the graphic corruption for simply turning up the IQ or the unwanted clutter and mess to the cfg.

Aces did not intend to use the RejectThreshold as a tweak, not even UsePools, they simply discovered the fact that dynamic vertex buffers were very CPU dependant while testing Train sim. This lead to some internal testing which resulted in some of the team members realizing that completely eliminating the vertex buffers (the dynamic implementation) was benefitial for performance but introduced some instability. The 'threshold' was a way to 'tweak' the engine for the selective use of vertex buffers based on the size of the vertex data.Having a SMALL BP value, effectively is similar to having a small rejectthreshold value, however, if you were in a very autogen intensive area you WILL experience stutters becase the pool will FILL very quickly and will have to be cleared, this means wasted CPU cycles. that IS the reason its called a threshold.. you fine tune it without sacrificing the size of the actual pool.

Aces did not intend to use the RejectThreshold as a tweak, not even UsePools, they simply discovered the fact that dynamic vertex buffers were very CPU dependant while testing Train sim. This lead to some internal testing which resulted in some of the team members realizing that completely eliminating the vertex buffers (the dynamic implementation) was benefitial for performance but introduced some instability. The 'threshold' was a way to 'tweak' the engine for the selective use of vertex buffers based on the size of the vertex data.Having a SMALL BP value, effectively is similar to having a small rejectthreshold value, however, if you were in a very autogen intensive area you WILL experience stutters becase the pool will FILL very quickly and will have to be cleared, this means wasted CPU cycles. that IS the reason its called a threshold.. you fine tune it without sacrificing the size of the actual pool.

Hi,I experimented a great deal with UsePools but could never get rid of the graphic artifacts when my GeForce 8800 GTS 640MB was under pressure. The RejectThreshold tweak resolved this issue while maintaining generally reasonably good stutter-free performance on my now significantly less than stellar system:[bUFFERPOOLS]// UsePools=0 // Tweak// RejectThreshold=524288 // Tweak sends vertex batches below a certain size to the dynamic bufferpools and the rest above the setting directly to the GPU. // As you lower it you're essentially getting closer and closer to the equivalent of UsePools=0RejectThreshold=262144 // Tweak <-- this one works for me// RejectThreshold=131072 // TweakAs you see, I've marked all the tweaks in my FSX.cfg and, in time, I may delete those lines that have ultimately proved unhelpful. Meantime they help to jog my memory as to what has worked and what hasn't. Most of my flying is done away from the denser scenery areas anyway. I have accepted that I must cut my coat according to the cloth that is available to me.MikeASRock 939Dual-SATA2 (AM2CPU Board), AMD Athlon 64X2 6400+ (BE,3200MHz,Windsor), Arctic Cooling Freezer 64 Pro, 2GB Crucial Ballistix DDR2 PC2-6400 4-4-4-12(2T) (Dual Channel), NVIDIA GeForce 8800 GTS 640MB (DDR3) (Forceware 197.45 WHQL), SB Audigy2 ZS Platinum (Drivers version 6.00.0001.1371), Antec NeoHE 650W PSU, Windows XP Home Edition (SP3), DirectX 9.0c