Zerotime wrote on Jul 14
th, 2007 at 3:13am:
Phil, first, thanks, second, please post here more, the annoying fsX bashers have left. We have tweaked fsX to the max and I would just like to ask a question.
A person called Nick Needhams son has found what appears to be a tie between Swap_wait_timeout and Texture_bandwidth_mult.
It was his grandson who emailed him with the information. Nick said he did not have time to check it out completely but would in a few weeks but that the quick tests he had run seemed to suggest he was on to something.
Nick N wrote on Jul 11
th, 2007 at 9:47am:
I did get an email from my grandson who may be on to something but I do not have time to completely test or work with it, but what I did test seemed to show quite a bit of promise.
Apparently in looking for a solution to the stutter issue brought on by high disk access it would appear he may have stumbled on a pattern or relationship between the SWAP_WAIT_TIMEOUT= and the TEXTURE_BANDWIDTH_MULT=
Here is what he sent me:
Try the following with the frame lock on unlimited or to the smoothest locked setting.
If TBM is set to X, set SWTO to Y
TBM SWTO
190 25
180 26
170 27 <--- he got best results with this but many of these worked well
160 28
150 29
140 30
130 31
120 32
110 33
100 34
90 35
80 36
70 37
60 38
50 39
40 40
Every system is different so the base (40 - 40) TBM - SWTO value may need to be increased or decreased depending on the processor/video card being used. It is possible the TBM - SWTO needs to start at 40 - 44 and then increase TBM 10 - reduce SWTO 1 as you move up the scale for slower cards and systems
----
I did a few quick runs early this morning and got noticeable positive visual results with less disk access stutter with 150 29 but I need to run through those numbers in a few weeks and see if his theory is holding up and if so find out why and what the relationship may be for different systems, if possible.
later guys..
Truth to it?
According to Phil's blog we should never exceed a TBM of 40 or it pushes the hardware too hard so I cant see how there would be 'truth' to the list. What I have seen in my own system is that many things we are told are not good or too high tend to fix the blur and stutter problems
That list also seems to work for me as well but that also includes using the driver settings and other tweaks we have discussed. There appears to be some type of relationship between the SWTO and the TBM. If I jack up the TBM and also raise the SWTO as suggested above, the amount of ground tecture blur is significantly reduced.
I am also not only seeing smoother frames at a lock of 31, but unlimited as well, if, I am as little as 3-4 miles away from a large city area 'unlimited is the smoothest FSX flying I have ever seen. Getting back around a city and I have to frame limit again. It was mentoned that the smooth results has somthing to do with LCD and possibly the refresh rate of the unit.
I dont understand it because it defies all the rules about limiting frame lock and not jacking up the texture bandwidth.
I do know one thing and that is FSX seems to run like FS9 when it comes to settings and hardware. If you dont push the settings up the hardware doesnt respond. If the settings are too low FSX runs with stutters and blurs just as bad as if they are set too high.
Another problem I have is I can get it tweak for one area and if I fly somewhere else that may have a different terrain or autogen layout it runs lousy and I think I may be dealing with a low raid-0 stripe because I can not set it higher than 64K. It was mentioned that at least 128K was needed with more than 2 drives or the disk access is way to high and I am really starting to think that is what I have been fighting all along with a 2 disk 64K stripe array. I am going to install FSX to a single SATA drive this weekend and see if that solves the ground texture load headache from one area to another that I have been chasing for months with this software.
Pages: 1
