I am running unlimited...locking frames gives me about 5FPS avg loss.BP=0 definitely gives me a smoother sim experience. Here are some quick results with TBM=400:1. BP=0 // GPU max load 47% and max Memory Used (GPU) 571MB -- FPS 18-22 but smooth2. BP=400000000 // GPU max load 83% and max memory used (GPU) 508MB -- FPS 15-19 but very choppyInteresting results. I'll keep playing.

then my friend, you don't need to worry :) you are not even close to stress the sim ;) by the way... co-relate results 1 and 2 with what I wrote earlier.. in number Two GPU usage is higher because it is a more 'realistic' indication of what the GPU load is (you are not overloading the command buffer) see?

then my friend, you don't need to worry :) you are not even close to stress the sim ;) by the way... co-relate results 1 and 2 with what I wrote earlier.. in number Two GPU usage is higher because it is a more 'realistic' indication of what the GPU load is (you are not overloading the command buffer) see?

Understood, and thanks! Funnily enough, I just managed to crash...not only the sim, but the entire OS. No BSOD, just a texture corruption followed by an immediate reboot.Scenario was same as above except concorde out of KJFK on 31L. I did not log GPU-Z sensor data to a file, since I was only expecting a sim crash....this time I will try and reproduce and get the data written to a file.

Hi *******, I have been following this with interest and look forward to a condensed version of the current wisdom that is lurking around the forum in several very long threads at the moment! I found out myself earlier last year that increasing the TBM multiplier to 400 helped immensly when using purely photoscenery and had a similar reception from some of the more sceptical readers, when I publicised it here, so I know how you are feeling. I can see that you have spent a huge amount of time very cleverly testing & providing this additional imformation, so thank you so much. My question is this: Now we have possibly up to ten .cfg file variables: ( all of which it is accepted can help performance in certain circumstances by being tweaked) TBM multiplierTextureMaxLoadShader variationsBufferpoolsHighMemFixAffinity maskand some others.What is the percieved wisdom in mixing the use of all these together, as there are quite possibly thousands of combinations of settings. I would very obviously like to be able to get my install set up as it should be, however I feel the sheer number of possible variations is going to make this tricky for many people. I am hoping that your guide will clarify this and that we can get some kind of definitive answers down in much the same way that NickN has done with the some of the above in his guide. Cheers, and thanks again, Mark

*******,HIGHMEMFIX=1 WORKS! Thanks.I currently have my fps locked at 30 with Dense AG and all systems are a go.I can now enjoy FSX and all my wonderful sceneries and airplanes.

This is exactly the kind of behavior I can see in my system.If we are not stressing the sim, what keeps it from running faster then? maybe overclocking the PCIe bus could boost the whole thing?

I am running unlimited...locking frames gives me about 5FPS avg loss.BP=0 definitely gives me a smoother sim experience. Here are some quick results with TBM=400:1. BP=0 // GPU max load 47% and max Memory Used (GPU) 571MB -- FPS 18-22 but smooth2. BP=400000000 // GPU max load 83% and max memory used (GPU) 508MB -- FPS 15-19 but very choppyInteresting results. I'll keep playing.Edit: Just dialed back Autogen to Dense and performance was definitely better...avg of 22-27 FPS and smooth.GPU max load was similary...52% and memory was 573MB.

then my friend, you don't need to worry :) you are not even close to stress the sim ;) by the way... co-relate results 1 and 2 with what I wrote earlier.. in number Two GPU usage is higher because it is a more 'realistic' indication of what the GPU load is (you are not overloading the command buffer) see?

What is the percieved wisdom in mixing the use of all these together

Don't worry, you'll see everything in the tweaking documents... for now, I just only wrote the one for BP=0 and HIGHMEMFIX=1 give me some time asI'm trying to document everhything and get confirmation from MS itself :) like a said earlier, I'm sure that I'm sure :) but we NEED MS to 'bless' it ;) lets just be patient...if something is going to be 'pinned' it has to be 200% accurateas for the other guides (part 2, 3 etc) you'll have to wait (or) search the forum... all the knowledge is scattered :) search for my last post about FIBER FRAME and Affinity Mask I guess thats the kind of info you are looking for.

For the impatient.... please, this is WORK in progress, not 'the official' ;) but at least you get to play now ;)Hi, I'll try to consolidate, as much as I can, the following 'tweaks' are what I consider must haves.. I'm alsoproviding an explanation, so you can 'adjust' the values to your particular situation. Attention Sarcastic Police:If you want to start a flame war, please.. don't 'quote' or 'google' stuff.. surprise us with your insightful technical knowledge and analysis, but don't come here posting DPC latency checker screenshots. I suggest PIX forWindows on the XNA Tools (you'll need the D3D SDK) [bufferPools]UsePools=0 // Use 1 if you experience crashes (if ENABLED PoolSize defaults to 4000000 bytes, 4 MB)When you see 'toggle' values (1 or 0) it means ON/OFF - UsePools its an ON / OFF value (1 or 0)PoolSize its a 'size' value (in bytes) If you 'DISABLE' the pools, you will get increasedperformance, AND ALSO, instability if you don't 'balance' your components and sliders apropiately, in case of instability, then simply DO use pools by changing the value of UsePools to 1 and 'adjust' PoolSize. BE CAREFUL (and forget everything you have been told about this value)it does NOT use video memory, PERIOD. it uses SYSTEM memory, because its a special type of poolcalled Explicit Vertex buffer which DOESN'T GO INTO VIDEO MEMORY unless they have A VERY SPECIFIC FLAG(and they don't) more info here: http://msdn.microsoft.com/en-us/library/ff539490.aspx you can also do your own tests and see how 'increasing' PoolSize affects the size of the fsx.exe process proportionally.[GRAPHICS]SHADER_CACHE_VERSION=1 // Increment this number EVERYTIME you change fsx.cfg (it simply rebuilds the shader cache)HIGHMEMFIX=1 // Fixes WDDM texture addressing modes and initial render states (for single pass shaders) and COMPLETELY fixes the dissapearing texture problems[DISPLAY]TextureMaxLoad=9 // Carefull. CAN induce stutters on LOW END systems! use multiples of 3 *ONLY* (3, 6, 9 etc) perfect for PhotoRealistic scenery and PNWThe formula on how to determine your 'optimal' TextureMaxLoad goes like this (credit to Steve Lacey here http://www.steve-lacey.com/blogarchives/20...blurries.shtml)If UPPER_FRAMERATE_LIMIT exists, then:MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMITIf UPPER_FRAMERATE_LIMIT doesn't exist (UNLIMITED FRAMES) then:MAX_TEXTURE_DATA = TextureMaxLoad * TEXTURE_MAX_LOADAs you can see above, TEXTURE_BANDWIDTH_MULTIPLIER its just that, a multiplier. Evidently, changing it DOES change things, however,when running UNLIMITED frames, it is USELESS, so you are better of playing with TextureMaxLoad directly. be VERY CAREFULL, the 'resulting'value of this formula (MAX_TEXTURE_DATA) corresponds to the MAXIMUM number of bytes the TEXTURE MANAGER is allowed to 'upload' perframe. If the resulting value (in bytes) for MAX_TEXTURE_DATA is TOO HIGH you will spike your GPU! (and cause a stutter), so this is a 'test and see' value. Ideally, you'll see an impact on COMPLEX high resolution textures sceneries like PNW and/or PhotoReal scenery. It is important to mention that THIS value does NOT have an impact on CPU if you are running a Multiple core setup, due to the texture manager threads running in the cores responsible for texture loading and object batching. (which are the last 3 if you have 4 cores)Now, the following requires a careful explanation... please, READ. This 'assumes', you have an i7 With Hyperthreading OFF.. so, it goes like this;CORE0 CORE1 CORE2 CORE3CORE0 is responsible for: Fibers and main schedulerCORE1, CORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)'Fibers' are like small processes that do 'things' cooperatively with other 'processeses' (sorry, I know this is not I high tech explanation)I'm just trying to cater for everyone. In FSX. Fibers are responsible for the 'loading' of the terrain system. They need to communicate with themain scheduler (which also RUNS on CORE0) to 'coordinate' and cooperatively multitask on terrain rendering every time a 'frame' is rendered.Those two, the fibers AND the main scheduler are running on the SAME CORE... now, here's a trick. Fibers are STUCK to CORE0, you can not move themout of there, however, YOU CAN move the main scheduler to run on another core!! so, if you do this:[JOBSCHEDULER]AffinityMask=14you are telling FSX to use only CORE1, CORE2 and CORE3.. so, what about CORE0? it STILL runs the FIBERS! because they are not bound to the AffinityMasksetting. so, what you are doing is making things now much more efficent. So now, FSX will run like this:CORE0 CORE1 CORE2 CORE3CORE0 is responsible for: FibersCORE1 is responsible for: main schedulerCORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)thats great balance! (and a little increase in performance too!) thats why so many people say FIBER_FRAME_TIME_FRACTION affects their performancewhen they lower it! of course it does, we'll talk about that now :)Now, lets micro manage the 'fibers' and the terrain loading system. Consider this:[MAIN]FIBER_FRAME_TIME_FRACTION=0.25the above value means that 0.25 (which means 25%) percentage! is the % ammount of 'time' that the 'fibers' will 'cooperate' with the main schedulerto 'render' the terrain system. So, assume you run you sim LOCKED to 25 FPS... thats 25 Frames EACH second, correct? 1 second is the same as1000 miliseconds. So, if you divide 1000 miliseconds / 25 frames what do you have? you have Miliseconds PER frame. That number is 40 Milisecond.so, now we KNOW that EACH frame, takes aproximately 40 Miliseconds to render (if running frames locked at 25). Now, out of those 40 millisecondsPER frame, HOW MUCH time (or % of time) you want the fiber to cooperatively multitask with the main scheduler? well.. if you read re-read and analyzewhat Adam told Phil Taylor you'll see Adam hinted Taylor on 'what' the 'optimal' time is to do just that, Adam 'optimal' value required for the fiberto communicate with the thread is 10ms read here: (thats why they came up with the 0.33)http://blogs.msdn.com/ptaylor/archive/2007...-week-or-2.aspxSo, that value should be adjusted according to your frame rate. Of course, it REALLY doesn't have any IMPACT whatsoever UNLESS you are running a SINGLE core machine (so you can not offload the scheduler) or you run tileproxy or something VERY heavy. For cases like tile proxy or VERY complex terrain I assume 10ms is simply not enough so you need to give the fiber MORE TIMEotherwise, the blurries are going to be TERRIBLE!And talking about blurries, terrain and fiber time... :) we have: [TERRAIN]SWAP_WAIT_TIMEOUT=10And you sure are asking why I have '10' there? 10 what? frames? well.. according to Phil this is a value between 1-60 'frames' regardless of that Phil said, this SWAP_WAIT_TIMEOUT only has an impact when the time allocated to fibers is increased.. to meSWAP_WAIT_TIMEOUT is not about 'frames' is about 'timeouts' in Miliseconds (per frame) so probably it was easier to say it was 'frames' so we wouldnot get confused ;) play with it (specially if using HIGH FIBER_FRAME_TIME_FRACTION values) but don't expect a SINGLE frame in performanceincrease.. this only helps with terrain loading and blurries. so try to adjust the timeout to the time fraction that it takes for the fiber to communicatewith the main thread. thats why I have '10' there.Now... lets talk about 'frame locking'You need to understand the following:When you 'fly' in FSX, each 'frame' its like a 'photo' it contains certain objects and textures that need to be 'drawn' for EACH 'photo'. When you play this 'photos' in rapid succesion, say, for example 25 'photos' per second, the perceived sensation is that you are 'moving' at 25 frames per second. FPS = Frames per Second, each 'frame' is the 'photo' I'm talking about.So, the above is VERY important to take into account, because in FSX, all operations! terrain rendering, object batching etc occur at the single 'frame' level... what does that mean to you? I means, the HIGHER the frames, the MORE work FSX needs to do.. so, say for example, that you run your SIM at 30 FPS and you like it.. but, then someone got into your head the idea that if its not 60 FPS then it is NOT real, well.. from 30 to 60 FSX will DOUBLE the ammount of things that it needs to do! so, don't be surprised when you start seening a christmas tree and strange spikes coming from the ground :).. I won't get into the 'FPS eye perceived thing' that has plaged our forums since day 1. run the sim at the FPS you like! I personally, got USED to run at 25, and let me tell you its perfectly fine to me.. because I got USED TO IT.. I hated it, but after a week, you simply 'adjust' your eyes to it.So, should you use the FPS limiter or run to UNLIMITED? well it depends on your flying style... if you run default planes or non CPU intensive planes or only 2-D cockpits, then your CPU is NOT going to be overworked.. in that case, simply go for the frame lock inside FSX.. period.Now, if you fly COMPLEX a/c specially using the VC you NEED to set it to unlimited! however... there is a problem ;) what happens with what I just told you about the sim working HARDER the higher the frames? what happens if frames start jumping from 30 to 60 then to 25 and again to 60? where is the 'balance' here?? what if you have UsePools=0? what do you expect will happen when you get a 'sudden' jump to 70 FPS? CRASH! ;) besides... the 'perceived' sensation (because is not real) when frames 'jump' is a 'stutter' so you need 'smoothness' consistency... and thats were the EXTERNAL frame rate limiter can help you ;) capiche?Now... use this as a REFERENCE... specially if using a HIGH SPEED CPU, and simply increase the Scenery Complexity and Autogen on at at time, and run your frames locked either in FSX or with the external limiter and setting the option to unlimited inside the sim. you want to find your 'sweet' spot, or the point where the GPU is not being overworked, I suggest, as 'reference' you use a GPU monitoring tool.. again, as reference, because what you see there is NOT 100% accurate.And... if you really want to get the inside scoop on 'how' to make UsePools=0 work... then, here's a post I made on FSDeveloper.http://www.fsdeveloper.com/forum/showthread.php?t=19460

Hi all,I just had an interesting find. I use DisablePreLoad=1. With *******'s recommendation to cycle the SHADER_CACHE_VERSION, which I do when making a change to fsx.cfg, I noticed the following.Although I use DisablePreload, the default flight pre loads! Upon closing FSX, and reloading with no change SHADER_CACHE_VER #, the sim does not preload.I have double checked and it does it everytime.Now that's weird eh?RegardsBob

>>you want to find your 'sweet' spot, or the point where the GPU is not being overworked, I suggest, as 'reference' you use a GPU monitoring tool.. again, as reference, because what you see there is NOT 100% accurate.How do we know if our gpu is being overworked and what monitoring tool would you suggest we use ? Thanks for your help *******,Vic

How do we know if our gpu is being overworked and what monitoring tool would you suggest we use ?

GPU-Z just google itAnd you know it is overworked if you fly 360's for 1-2 minutes and you analyze the graph... did it spike or dipped? was it consistent? thats all you need. remember... GPU-Z its only a REFERENCE... If you want (for example) see where you KILL it, then UsePools=0 and run frames UNLIMITED on a VERY basic area.. go over water! and you;ll see what i mean ;) the GPU usage grows in proportion to the NUMBER OF FRAMES that need rendering... but, our problem is that GPU's don't just 'render' frames, they also need to 'read' instructions from a 'buffer' and that 'activity' doesn't show on any GPU usage meter because it happens outside of what is called the 'user space' it happens at the kernel level... that % usage, is not shown! thats why you could propably KILL the card and it won't even show going over 10%! ;) so, if you REALLY want to know a 'realistic' measure, you enable the Pools again (for testing) USePools=1 and monitor card usage, you'll see it goes to 100% :) why? because now you are not choking it, there is a 'middleman' (bufferPools) controlling what goes into the command buffer the card reads its instructions from, but the CPU sufffers trying to do this 'artificial' syncronization killing your frames in FSXEvidently, UsePools=0 'shifts' the balance in FSX towards the GPU.... it turns FSX into a more GPU bound app ;) which is a great thing (but bad if you don;t know what you are doing)

Hi *******, i read your referenced post at FSDeveloper with interest. I appreciate you are very busy fielding questions, but could you just answer 2 of mine if possible? 1) I use tileProxy and photoscenery exclusively, and lock my frames at 25 using the in game limiter. Would I be better using the frame rate lock mod? I could not quite decide after reading the advice. Also, what would your recommended setting for FFTF and swapout be? From the post I have set mine at 0.75 and 75 respectively. Incidentally Christian Buchners recommmeded setting is 1.33 using tileproxy, which after reading your explanation I did not really understand, as surely that is saying use 130% of the available time - surely the upper limit is 100%? Apologies in advance if I am missing something very obvious here....2) In the FSdeveloper post you advize against using Nhancer and the ENB series mod. I particularly love the EMB series for the flexibility it gives me in adjusting the sometimes very washed out colours you get with much photoscenery and TileProxy imagery. Are you saying that using them means the tweaks will not work ? If so, why is that? Hope you time to answer my queries, like yourself, i have been questing ever since I installed this programme to find the optimum set up and several pieces of the jigsaw have just fallen into place for em, thanks so much ( Not all however, hence the questions...)best, Mark

1) I use tileProxy and photoscenery exclusively, and lock my frames at 25 using the in game limiter. Would I be better using the frame rate lock mod? I could not quite decide after reading the advice. Also, what would your recommended setting for FFTF and swapout be? From the post I have set mine at 0.75 and 75 respectively. Incidentally Christian Buchners recommmeded setting is 1.33 using tileproxy, which after reading your explanation I did not really understand, as surely that is saying use 130% of the available time - surely the upper limit is 100%? Apologies in advance if I am missing something very obvious here....

In your particular case, I would use EXACTLY .75 :) I think you got that perfectly right there... but I would run the EXTERNAL frame limiter and would tweak the TextureMaxLoad to 9.. it should give you an incredible experience (assuming you have the hardware) and swap_wait_timeout should be the 'fraction' of the time it takes to render the frames, for your case should be 30, not 75... specially if running at 25 FPS. (try the external limiter) and see if it makes a difference to you. also make sure you split the fiber core and scheduler core using AffinityMask.And NO.. 1.0 is not the maximum.. you can CERTANLY tell the fibers to allocate MORE TIME, but thats simply inneficient :) you are making the fiber run LONGER than what it takes the actual frame to be processed! ;) I think Phil was careful not to tell people they were wrong.. ;) but hey.. I did NOT program the terrain system, I'm just doing analysis based on the information at HAND, but.. thats what we have :)Note that, a theory I haven't yet tested is to make the fibers run EXACTLY what it takes the frame to render, meaning FIBER_FRAME_FRACTION=1.0 I don't know the internals, but if the 'extended' time allows to 'load more' without impacting performance (due to the fibers running on an isolated core), the results could be interesting... I would have to check, but.. you could do it too and report back. By the way.. there are two undocumented settings (I think they only work when frames are limited inside FSX) that have a MIN and MAX time for the fibers to run.. but, that is OVERKILL.. ;) the idea of the tweaks if to keep them simple, we are not going to the moon here :)

2) In the FSdeveloper post you advize against using Nhancer and the ENB series mod. I particularly love the EMB series for the flexibility it gives me in adjusting the sometimes very washed out colours you get with much photoscenery and TileProxy imagery. Are you saying that using them means the tweaks will not work ? If so, why is that?

the tweaks WILL work, they will just 'crash' your computer faster. UNLESS you reduce autogen, scenery and maximum frames per second.. so, yes you can still use nhancer and ENBSeries, but.. they will impair your computer's ability to reach its full potential, my posts are about 'balance' efficiency and performance... certanly not image quality... for that you need to go see Nick's guide.

Any suggestions for external frame limiter please?

Hi *******,i was pretty p### off of the MS attitude of leaning back and enjoying FSX's bright future when there are at the same time tons of unresolved problems, so many thanks for your work! I've tested your settings and i'm getting spike-like flashing of newly loaded textures, which is very fast, so i can't capture it in screenshots.Maybe with more tweaking there would be a solution for my system but at the moment i'm not in tweaking and testing mood. I just wanted to thank you for your work and dedication.

[bufferPools]UsePools=0 // Use 1 if you experience crashes (if ENABLED PoolSize defaults to 4000000 bytes, 4 MB)Is this added into the cfg as its own entry, or does it go inside something else, ie; [GRAPHICS]Thanks,Mark