SimForums.com Homepage
Forum Home Forum Home > General Discussion Forums > Flight1 General Discussion and Announcements
  New Posts New Posts RSS Feed - FSX Tweaks Demystified
  FAQ FAQ  Forum Search   Register Register  Login Login

Topic ClosedFSX Tweaks Demystified

 Post Reply Post Reply
Author
Message
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Topic: FSX Tweaks Demystified
    Posted: January-16-2011 at 6:47am
THIS POST CONTAINS INFORMATION THAT IS USELESS FOR FSX TUNING PAST DROPPING SETTINGS AND SCENERY FOR THE HARDWARE, WHICH DOES MAKE SENSE. HOWEVER CALCULATING TBM AND TREE AMOUNTS USING THIS IS QUITE RIDICULOUS
 
There is a lot more WRONG with this thread/post than I ever wanted to get involved with which is why I stayed out of it and let the math 'experts' spin their wheels
 
But... I never thought people would actually buy into this. http://www.simforums.com/forums/partial-ground-textures-blurries-popping-up_topic41742_post245113.html#245113 I guess if something looks complicated enough and the math works and checks (of course the math only works if the variables are correct) then people will think there may be something to it and after that the placebo starts..    therefore I am canning this thread and posting a DEBUNK
 
 
FSX ignores any figure in TBM that is not a multiple of 5 and the lowest value possible is 10, the highest 400. If the sim finds a value that is out of range it defaults back to 40 (or PERFBUCKET SET VALUE) regardless of what is in the config, and, if the sim is set internally to unlimited frame lock TBM is ignored completely
In other words and in just ONE example of why none of this works ( I can list several more), when posted a TBM of '57' the sim defaulted back to 40 which means all the calculations past that point mean nothing!
 
Based on how FSX works (FS9 is different and TBM will be 240 or 400, one of the two), TBM in FSX should be either 40, 80 or 120.. pick one based on the video memory of the card, video memory amounts that were not available when FSX was designed!1.2-1.5GB+ = 120  <1.2GB = 80, 512MB = 40 OR in all cases sometimes default of 40 is best or even 80 with any of the video cards simply due to the scenery being pushed! More often than not, on modern video cards 80 or 120 is fine..
 
 
 When you establish which of the 3 to use, set it and forget it and leave TextureMaxLoad= out of the config, which by the way is set to a default of 6 in FSX and a default of 3 in FS9.
 
Thats it.. there is no magic demystified tweaks in this thread and you will spin your wheels playing with these formulas for nothing.
 
If you see changes in your sim screwing around with this it is because you are changing values that end up reducing CPU load and trimming Vsync stutters by random chance.... flipping frame lock and changing autogen in the config as well as changing scenery settings to lower values.... and has nothing to do with calculating TBM
 
Using FRAPS or any benchmark to try and prove a point about settings is also moot as the FRAPS application itself will skew the result, in which I provided evidence to that years ago in a multi-page thread with supporting images and data at AVSIM.
 
Setting a frame lock of 30 internally in FSX with a single montior setup will have a defined impact on the sim simply because we are running 1/2 the typical refresh rate (60Hz) of a LCD monitor, an issue with Vsync that was brought on by FSX SP's as announced by Phil Taylor when SP1/SP2 was released.. The issue with Vsync was noted at one time at FSInsider in the original release notes for the SP as well as Phil's blog. 
 
Running FPS closer to 1/2 the refresh rate with Vsync enabled (OR 60FPS = ultimate as it matches refresh rate but this is hard if not impossible to obtain with the aircraft and scenery packages out there) alone will influence test results especially if the sim settings are properly tuned to maintain 25-30 FPS with the hardware aircraft and scenery installed. Nvidia is currently in the process of releasing access to Vsync settings we never had in the past to deal with this issue as it effects far more titles than FSX.
 
You have been advised..   Have at the calculations if you want to! LOL   Any result you see is not based directly on TBM numbers, of that I can assure you.
 
I added my comments below to the summary of all this..
====================================================
 
 
 
 
 
 
This thread will introduce some of the mathematical calculations that have been floating around on various forums and put them to the test. First the math...

----- MAX_TEXTURE_DATA -----

Legend:
Memory Bandwidth = Memory Clock in MHz
GDDR = GGDR3 is DDR2 (use a multiplier of 16), GDDR5 is DDR3 (use a multiplier of 24)
Target Frame Rate = Desired Frames Per Second (defaults to 30)
Maximum Bytes Per Frame = MAX_TEXTURE_DATA

Mathematical Formula:
(Memory Bandwidth * GDDR) / Target Frame Rate = Maximum Bytes Per Frame

Calculation for EVGA GeForce GTS 250:
(1100 * 16) / 30 = 586.66666666666666666666666666667

----- TEXTURE_BANDWIDTH_MULT -----

Legend:
Maximum Bytes Per Frame = MAX_TEXTURE_DATA
Global Texture Resolution = TEXTURE_MAX_LOAD
Texture Bandwidth Multiplier = TEXTURE_BANDWIDTH_MULT

Mathematical Formula:
(Maximum Bytes Per Frame / Global Texture Resolution) * 100 = Texture Bandwidth Multiplier

Calculation for EVGA GeForce GTS 250 with TEXTURE_MAX_LOAD=1024:
(586.66666666666666666666666666667 / 1024) * 100 = 57.291666666666666666666666666667

----- MAX_TEXTURE_DATA -----

Legend:
Global Texture Resolution = TEXTURE_MAX_LOAD
Maximum Textures Per Frame = TextureMaxLoad (defaults to 3)
Texture Bandwidth Multiplier = TEXTURE_BANDWIDTH_MULT
Target Frame Rate = Desired Frames Per Second (defaults to 30)
Maximum Bytes Per Frame = MAX_TEXTURE_DATA

Verification Formula:
Global Texture Resolution * (Maximum Textures Per Frame * Texture Bandwidth Multiplier) / Target Frame Rate = Maximum Bytes Per Frame

102.4MB * (3 * 57.291666666666666666666666666667) / 30 = 586.66666666666666666666666666667

----- RESULTS OF CALCULATIONS -----

MAX_TEXTURE_DATA=586
TEXTURE_BANDWIDTH_MULT = 57
TEXTURE_MAX_LOAD = 1024
UPPER_FRAMERATE_LIMIT = 30

At this point, my suspicion was that TEXTURE_BANDWIDTH_MULT could be raised higher despite what the math was telling me but we'll see. Furthermore, I suspected that using the math with a TEXTURE_MAX_LOAD of 2048 or 4096 wouldn't make much sense because there were very few addons that used textures above 1024. REX was one of those exceptions (e.g., 2048 x 2048 or 4096 x 4096 HD cloud textures).

The next step was to test these values in combination with the most basic tweaks as follows:

[Display]
TEXTURE_BANDWIDTH_MULT = 57
UPPER_FRAMERATE_LIMIT = 30

[DISPLAY.Device.NVIDIA GeForce GTS 250.0]
Mode=1920x1080x32
TriLinear=1

Note: I used NVIDIA Inspector 1.9.4.3 to override FSX's default AA and AF settings so this had to be set to TriLinear=1 according to Nick_N's guide.

[GRAPHICS]
ForceFullScreenVSync=1
TEXTURE_MAX_LOAD=2048

Note: I was using a 3D cloud resolution of 2048 x 2048 (HD - High Definition). If I lowered this value to match the above calculations, I wouldn't get my HD clouds so I kept it this way because all of my other textures are most likely 1024 x 1024 resolution or less.

[JOBSCHEDULER]
AffinityMask=14

Note: This runs Fibers (CORE0), Scheduler (CORE1) and Terrain (CORE2/CORE3).

[Main]
DisablePreload=1

Note: This disables preloading the default flight.

[TERRAIN]
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=1376
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=907

Note #1: This is equivalent to 1376 trees per 1.2km cell squared. This value was based on a city in South Yorkshire, England called Sheffield that is known for having more trees per person than any other city in Europe.

Note #2: This is equivalent to 907 buildings per 1.2km cell squared. This value was based on the building density per 1.0 km squared in the city of Hong Kong, China.

Note #3: I also want to mention that an LOD_RADIUS of 4.5 all around the aircraft is equivalent to about 64 cells. 1376 * 64 = 88,064 trees per 64 cells and 907 * 64 = 58,048 buildings per 64 cells. A lot of this thinking came from Phil Taylor's "back of the envelope" post on his blog.

I didn't include BufferPools and regardless of how people say that RejectThreshold makes your GPU work harder it didn't make mine work harder at all and I logged it with GPU-Z. In fact, playing with this in any way, shape or form simply introduced unnecessary stuttering.

Despite the above mathematical calculations, using TextureMaxLoad with an external frame limiter is totally pointless. I was getting the same Min/Max/Avg frame rates with the FSX internal frame limiter as I was when I used FPS_Limiter 0.2 with UPPER_FRAMERATE_LIMIT=0. Your experiences may vary but I would start with the internal frame limiter first. On my machine using an external limiter introduced unnecessary stuttering.

Another claim is that AC_SELF_SHADOW saves you 2-3% CPU usage and while that may be true, Nick_N clearly stated in his guide that this generates an extra shader pass. Therefore, I keep it set to 0 (disabled).

Before we get to testing, keep in mind that my machine is only a 2.4GHz quad with 8GB DDR2-800MHz RAM and an NVIDIA GeForce GTS 250 1GB with two SATA hard drives. It's NOT a powerful machine compared to everyone else I'm seeing on the forums. Furthermore, here are some of my additional settings in case you want more detail but there's probably no need to post my whole configuration. I mean, that's what Nick_N's guides are for right?

[Display]
BLOOM_EFFECTS=0

[GRAPHICS]
NUM_LIGHTS=8
AIRCRAFT_SHADOWS=0
AIRCRAFT_REFLECTIONS=1
COCKPIT_HIGH_LOD=1
LANDING_LIGHTS=1
AC_SELF_SHADOW=0
EFFECTS_QUALITY=2
GROUND_SHADOWS=0
TEXTURE_QUALITY=3
IMAGE_QUALITY=0

[SCENERY]
LENSFLARE=1
DAWN_DUSK_SMOOTHING=1
IMAGE_COMPLEXITY=4

[TERRAIN]
LOD_RADIUS=4.500000
MESH_COMPLEXITY=100
MESH_RESOLUTION=25
TEXTURE_RESOLUTION=29
AUTOGEN_DENSITY=3
DETAIL_TEXTURE=1
WATER_EFFECTS=4

[Weather]
CLOUD_DRAW_DISTANCE=3
DETAILED_CLOUDS=1
CLOUD_COVERAGE_DENSITY=8
THERMAL_VISUALS=0

The aim of the first test was to determine the highest Min/Max/Avg FPS that my machine could push so I used UPPER_FRAMERATE_LIMIT=0 without an external frame limiter.

Frames, Time (ms), Min, Max, Avg
  9029,    300000,  21,  39, 30.097

Now that I knew this, I knew that I could gladly set UPPER_FRAMERATE_LIMIT somewhere between 21-39. It was just a matter of finding the "sweet spot" for my machine. I ran this test and all future tests using FSXMark07 while looking out the left window of the virtual cockpit in the exact same position. Prior to this post, I experimented with every single tweak available from Nick_N and Bojote only to find that very few tweaks actually make a real difference and that most problems can be solved by mainly tweaking the TEXTURE_BANDWIDTH_MULT and UPPER_FRAMERATE_LIMIT values. The key to smoothness definitely had a lot to do with tweaking these values and it solved a lot of issues.

Here were the results of the next test with frames locked at 30:

Frames, Time (ms), Min, Max, Avg
  8201,    300000,  20,  31, 27.337

The Min dropped by 1 FPS, the Max dropped by 8 FPS but that's because I locked at 30 FPS and the Avg dropped by 3 FPS. However, that wasn't a huge drop, I was even using the FSX internal frame limiter and the simulation remained smooth with frames locked. Did I need a machine with over 3.0GHz cores, DDR3-1600+ and an NVIDIA 480+ to achieve this FPS with 99% of the issues resolved? No and I saved myself a pile of money in the process.

Granted, in other scenes my system may chug more but it's better than spending another $3,000 for a brand new system for me at this point. I look at it this way, if I had a brand new system and I used this same approach, things could only get better. The main thing I would be able to do is increase my scenery complexity and my autogen density settings. It's important to note that I'm running Very Dense and Dense because my CPU can only handle so much.

On to the next set of tests...

The configurations below were based on using the MAX_TEXTURE_DATA and TEXTURE_BANDWIDTH_MULT formulas above. As you lower the frame lock, your video card can process more MAX_TEXTURE_DATA and your TEXTURE_BANDWIDTH_MULT value can be adjusted upward as a result.

Here are more test results with frames locked at various settings and I included some data from GPU-Z as well:

Test #1:

TEXTURE_BANDWIDTH_MULT=44
UPPER_FRAMERATE_LIMIT=39

Frames, Time (ms), Min, Max, Avg
  8327,    300000,  20,  34, 27.757

Max GPU Load: 71
Max Memory Controller Load: 45

Test #2:

TEXTURE_BANDWIDTH_MULT=52
UPPER_FRAMERATE_LIMIT=33

Frames, Time (ms), Min, Max, Avg
  8281,    300000,  20,  33, 27.087

Max GPU Load: 71
Max Memory Controller Load: 40

Test #3:

TEXTURE_BANDWIDTH_MULT=57
UPPER_FRAMERATE_LIMIT=30

Frames, Time (ms), Min, Max, Avg
  8160,    300000,  20,  31, 27.200

Max GPU Load: 72
Max Memory Controller Load: 37

Test #4:

TEXTURE_BANDWIDTH_MULT=63
UPPER_FRAMERATE_LIMIT=27

Frames, Time (ms), Min, Max, Avg
  7825,    300000,  20,  28, 26.083

Max GPU Load: 72
Max Memory Controller Load: 35

Test #5:

TEXTURE_BANDWIDTH_MULT=71
UPPER_FRAMERATE_LIMIT=24

Frames, Time (ms), Min, Max, Avg
  7109,    300000,  20,  25, 23.697

Max GPU Load: 68
Max Memory Controller Load: 33

As you can tell by the results, this method can be used to bridge the gap between the Min and Max FPS that could result in less FPS fluctuation. However, that doesn't necessarily mean smoother flight because in Test #5 I started noticing micro stutters again. In the end, tests #2 and #3 were the most promising and I ended up settling on test #3 that matched my original calculations above. SEE MY NOTE AT THE END OF THIS ABOUT TEST #3

Overall, this configuration solved 99% of the issues I had and you'll notice the tweaks below that I didn't use whatsoever are noted in paratheses below:

I edited the following with my comments - NickN
- Autogen popping (no need for MAX_ASYNC_BATCHING_JOBS)  - Autogen will always POP one way or another as there is no alpha-fade in FSX.. how bad and how far way from the aircraft it is noticed is based on CPU/GPU ability and the scenery settings/load... and when you set AG level to 3 in FSX, then cut out more autogen using those silly FSX.cfg lines, you WONT notice it as much.. your autogen is so low it doesn't visually impact you and especially with a low end GTS 250 video card in use for this.

- Blurry textures (no need for FIBER_FRAME_TIME_FRACTION or SWAP_WAIT_TIMEOUT) - This is nonsense, all we have done here is trim the scenery settings where you dont need to play with FFTF. SWTO- leave it out of the config, period
 
 
- CPU usage (no need for AC_SELF_SHADOW) - You should not run this anyway it is a another shader pass and un-needed

- Flashing textures (no need for HIGHMEMFIX) - HIGHMEMFIX is NOT for flashing textures and should be in all config files as it was a FIX that was left out of SP2 by accident

- Image tearing (no need to turn off VSync) - You should never turn off Vsync unless you dont mind the tearing or if your system does not display tearing to the point of annoyance. PTaylor defined that with SLi and multi-GPU with the issues the SP introduced it was better to run without Vsync in SLi (see his blog about FSX and SLi) but the result is always problematic to the system and based on what the user will put up with in visual tearing if it does appear.  This is a problem with far more than just FSX and Nvidia is working to release driver settings that will address this in many games.

- Micro stutters (no need for TextureMaxLoad) - There is no need for TextureMaxLoad being changed or in the config as all we are doing with this edit is robbing peter to pay paul and using a lower or higher value to trim TBM instead of correctly rebalancing the scenery load or in the case of using 2048/4096 clouds, which I would NEVER do. We can accomplish the same goal by trimming TBM without TextureMaxLoad..   its just a multiplier for TBM.
6x<FSX textures size in KB> x TBM
 
Assuming we maintain a TBM that is not out of range, 40. 45, 50, 55, etc..  how can we know how many textures are in the scene? How do we know when that value fluctuates out of range for the hardware and comes back again, and, what that value is in a 'constant' range at any point in time in the render?
 
We dont! And never will.
 
Therefore, we use established reasonable TBM values that work with the video card memory and then trim TBM based ONLY ON the the individual user scenery load. 40, 80 or 120 does the job and you will find there are far better settings to work with to trim and stabilize stutters.
 

- Lag spikes or pops (no need for BufferPools) - Bufferpools HAS a function for some systems and it depends on the system itself, the hardware the drivers and the scenery being flown if BP makes a difference. You are far better off using REJECT THRESHOLD method with BP since you do not need to set water to 2xHigh in order to use it.. flashes clear up in minutes if the user pans the external locked spot area around the aircraft when the flight starts.. if they still appear there are other issues involved.

- Making your GPU work harder (no need for RejectThreshold) - Same as above

- Shader support (no need to ALLOW_SHADER_30=1 on NVIDIA) - Shader 3 does nothing for Nvidia cards. Users should buy a Nvidia card for FSX.. With ATi you take on more nonsense than its worth in FSX including running a hacked shader that is not complete shader 3.0 support.
 
 
 
 Test #3:

TEXTURE_BANDWIDTH_MULT=57
UPPER_FRAMERATE_LIMIT=30

All that happened in this setup is the user reduced the load on their GTS 250 card and low-end DDR2 800 memory with slow clocked CPU to the point where the locked 30 value in FPS could be run. The sim would run close to that value --and-- Vsync issues were minimized with FPS @ 1/2 the refresh rate..    We do not need to calcuate any specific TBM value to accomplish that. The GTS 250 comes in 512 and 1GB video memory and a TBM of 40, which the sim defaulted to in these tests makes perfect sense (could have been set to 40, 50 or 60 with the same result) since the entire system itself is a low-end for FSX. I would need to cut autogen and scenery settings down significantly as well to make that system work smooth in FSX too.
 
Calculating values for trees was not needed. It was simple enough to run 1/4 the default values which would have defined the same result.
 
 
No surpise here at all. If we try this with Orbx and a PMDG aircraft on a system like the one used here, TBM and tree calculations are not going to fix stutters..   Wink
 
 
and last...   do we really think Aces is that ignorant? If it is possible to use 'constant' formulas to establish frame lock, TBM, autogen values, sliders and checkboxes based on installed hardware would they not have applied such formula's to the perfbucket setup on initial FSX start? Of COURSE they would! Lets get real!  LOL None of this math means a hill of beans because it is nonsense to the sim and how it works.
 
 
The sim has a automatic PRIORITY RENDER system built into it, meaning, regardless of numbers in the config or scenery settings the sim will prioritize rendering flight control over scenery if the resources drop. Therefore, it does not matter what you 'calculate' and how exact that calculation is, the sim will change rendering elements moment to moment based on available resources. What we strive for is a balance that does not overtax hardware and force a lower priority to scenery over flight control.
 
 
 
Here is the real lesson that should be taken from this experience..   pony up for the real hardware, dont buy cheap hardware, do not overdrive the scenery and you will not need to spend endless hours trying to figure out how and what to chop out of the config and the scene to enjoy FSX.
 
 
Good luck, and may the force be with you...
 
 LOL
 
 
Back to Top
luap View Drop Down
Certified Professional
Certified Professional


Joined: December-11-2003
Points: 8087
Direct Link To This Post Posted: January-16-2011 at 12:43pm
Since when has MIT offer a PhD in FSX???
 
Wink


Paul Scott Bartelt

The grass is always greener over the septic tank



Back to Top
Phase View Drop Down
Senior Member
Senior Member


Joined: October-15-2004
Location: Antipodes
Points: 1565
Direct Link To This Post Posted: January-16-2011 at 4:44pm

I have to disagree with your calculations on tree density.  Iused the calculation of the number of trees per acre in your typical sylvan setting.Smile

 

If I used all; (not rounded to the nearest tree per acre

1 ft trees I see 43,150.333333333333333333333333333333333333

2ft trees I see 21,780.454545454545454545454545454545454545

3ft trees I see 14,520.6666666666666666666666666666666666666

4 ft trees I see 10,890.000000000000000000000000000000000000

5ft trees I see 8,712.999999999999999999999999999999999999

6ft trees I see 7,260.83333333333333333333333333333333333333

10 ft trees I see 4,356.777777777777777777777777777777777777

12ft trees I see 3,630.344444444444444444444444444444444444444

20 ft trees I see 250.977777777777777777777777777777777777

50 ft trees I see 27.333333333333333333333333333333333333333

100ft and above I see: 6.8999999999999999999999999999999999

Total trees I might expect per acre = 114,952.33333333333333333333333

Now applying Tom random mix population of trees paradigm we end up with a calculation that looks like this:Tongue

 

(43,150.333333333333333333333333333333333333/114,952.33333333333333333333333333333) = % of 1 ft trees found in the Tom Mix sample per acre =37.6533333333333333% of the total of 1 ft trees per acre. Which equates to approximately 15965.353535353535353535 trees in a typical FSX acre would be 1 ft high or if you applied the excessive decimal configuration would actually 61/64 of a foot high.

 

Carrying the calculation with interpolation all the way down we end up with a figure of 99.99999999999999% make up of the trees which means we have lost 12 leaves somewhere.

 
This figure of 114,952.33333333333333333333333 per acre would equate in FSX to the more accurate figure of 1,382.3333333333333333333333333333333333 trees per cell.  Lets get the maths exactly right!

 

These are well within current statistical limits and have a CI of 0.95.

 

Sorry I just could not resist!!Tongue

Regards
PeterH 
Nil illegitimum carborundum est

FSX SP2; i7 2600K, OC 5THz liq N2 cooling 16GB 1600 DDR3 RAM, GTX670, WINDOWS 7 64; 256GB OCZ Vertex SSD; Samsung 2233RZ 120Hz Monitor
Back to Top
Ulf B View Drop Down
Senior Member
Senior Member


Joined: August-16-2004
Points: 556
Direct Link To This Post Posted: January-16-2011 at 4:48pm
 
 
LOL Beer
Back to Top
woodhick803 View Drop Down
Senior Member
Senior Member


Joined: July-21-2005
Points: 2938
Direct Link To This Post Posted: January-16-2011 at 5:18pm
Yes, but will it affect my FR's adversely?
Jetline Hellfire GTO
Intel I7 960 quad core processor O/C'ed to 3.7GHz
Nvidia GeForce GTX570 1.2Gb video card
6 Gb Muskin DDR3 CL 6 RAM
300Gb VelociRaptor dedicated hard drive
Win 7 Home Premium
Back to Top
Superglide View Drop Down
Senior Member
Senior Member


Joined: July-12-2004
Location: KPIE
Points: 1039
Direct Link To This Post Posted: January-16-2011 at 5:47pm
Phase,

Yous calculations make my eyes flicker. And they definitely gave me a case of the "blurries". Did Nick check these out?!Confused
Joe Brown
W7 Pro 64b|ASUS Z87 Pro|i7 4770K @4.5|CORS H80i|EVGA GTX780|16GB CORS DOMINTR|FSX ACCL DX11|Rosewill Blackhawk|
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-16-2011 at 6:09pm
Originally posted by Phase Phase wrote:

I have to disagree with your calculations on tree density. I used the calculation of the number of trees per acre in your typical sylvan setting.Smile

 

If I used all; (not rounded to the nearest tree per acre

1 ft trees I see 43,150.333333333333333333333333333333333333

2ft trees I see 21,780.454545454545454545454545454545454545

3ft trees I see 14,520.6666666666666666666666666666666666666

4 ft trees I see 10,890.000000000000000000000000000000000000

5ft trees I see 8,712.999999999999999999999999999999999999

6ft trees I see 7,260.83333333333333333333333333333333333333

10 ft trees I see 4,356.777777777777777777777777777777777777

12ft trees I see 3,630.344444444444444444444444444444444444444

20 ft trees I see 250.977777777777777777777777777777777777

50 ft trees I see 27.333333333333333333333333333333333333333

100ft and above I see: 6.8999999999999999999999999999999999

Total trees I might expect per acre = 114,952.33333333333333333333333

Now applying Tom random mix population of trees paradigm we end up with a calculation that looks like this:Tongue

 

(43,150.333333333333333333333333333333333333/114,952.33333333333333333333333333333) = % of 1 ft trees found in the Tom Mix sample per acre =37.6533333333333333% of the total of 1 ft trees per acre. Which equates to approximately 15965.353535353535353535 trees in a typical FSX acre would be 1 ft high or if you applied the excessive decimal configuration would actually 61/64 of a foot high.

 

Carrying the calculation with interpolation all the way down we end up with a figure of 99.99999999999999% make up of the trees which means we have lost 12 leaves somewhere.

 
This figure of 114,952.33333333333333333333333 per acre would equate in FSX to the more accurate figure of 1,382.3333333333333333333333333333333333 trees per cell.  Lets get the maths exactly right!

 

These are well within current statistical limits and have a CI of 0.95.

 

Sorry I just could not resist!!Tongue

Regards
PeterH 


First, let me just mention that I'm happy you are crunching the math on this because I am no math expert when it comes to FSX. I am just trying to go off of other posts I've read. I want to explain in this reply just how I arrived at the values I mentioned above so that you can reply back with a solution to my problem.

Here is a reference:
http://blogs.msdn.com/b/ptaylor/archive/2008/04/17/back-of-the-envelope.aspx

"Now, a typical scene has 50 1km x 1km cells in the scene." but I found out from the FSX SDK documentation that cells are actually 1.2km x 1.2km (1.2 squared is 1.44).

Go to the next reference...
http://blogs.msdn.com/b/ptaylor/archive/2007/05/15/performance-work-in-sp1.aspx

"The terrain grid system is radial around the current viewpoint, and, depending on level of detail radius can be up to 4.5 tiles in either direction, something like 64 tiles."

Therefore, that's why I did this:
1376 trees per cell * 64 tiles (cells) = 88,064 trees

Now, I might be totally incorrect on that calculation as you pointed out but now you understand where it came from. I had interpreted it as 1376 trees per 1.2km squared. If each cell in FSX is 1.2km squared that is equivalent to 296.526458 acres.


I don't fully understand the relationship between Autogen Density to TERRAIN_MAX_AUTOGEN_TREES_PER_CELL and how that affects how many trees get drawn inside a 1.2km squared cell but according to Phil Taylor's post he says:

"The (autogen) slider stops correspond to the following percentages:

0, 10, 20, 45, 70, 100"

In any case, the answer I was after was how many trees per 64 cells get drawn given that LOD_RADIUS=4.5 is roughly 64 cells and that each cell is 1.2km squared. My math is probably wrong on the subject but this is what I'm after.

Forgetting for a moment that each cell in FSX is actually 1.2km x 1.2km (it says so in the FSX SDK documentation)...

"
Now, a typical scene has 50 1km x 1km cells in the scene. Autogen trees are pegged at 4500 max per cell (when the slider is all the way to the right). You can set the max up to 6000, so letís call it 5000 for easier math. 5000*50=250,000 trees.

If I plug my value into Phil Taylor's formula I get this:
1376 * 50 = 68,800 trees.

I adjusted this to 88,064 trees based on the fact that each scene actually has 64 1.2 x 1.2km cells if LOD_RADIUS is set to 4.5.
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-16-2011 at 6:21pm
Originally posted by Superglide Superglide wrote:

Phase,

Yous calculations make my eyes flicker. And they definitely gave me a case of the "blurries". Did Nick check these out?!Confused


I don't know if Nick_N has checked out these calculations. I based all of this off the following post and I have also seen this math on other forums:

FSX CONFIG -TWISTFISH METHOD Based on Hardware Bandwidth//Revised
http://www.sim-outhouse.com/sohforums/showthread.php?t=44877&page=1

The distinction between my calculations and the ones in the original article I linked above is that I used "video memory" in my calculations and not "system memory". I haven't seen any arguments as to why this guy is using "system memory" in his calculations instead of "video memory".
Back to Top
Phase View Drop Down
Senior Member
Senior Member


Joined: October-15-2004
Location: Antipodes
Points: 1565
Direct Link To This Post Posted: January-16-2011 at 6:32pm
Bisailb
Your calculations are exemplary (and correct) my post was an attempt at a bad joke - my figures are meaningless!Embarrassed 
I used to do a lot of clinical statistical analysis and my calculations and always stopped at two decimal places!! (otherwise they were too difficult to prove)
 
I always thought that Sheffield had more knives than trees!Smile
 
Holger Sandmann has written quite a few posts on trees and buildings wrt to what FSX should render to emulate real life mainly on the FTX forums and they may be worth reading.
 
Thanks again for this post it did tie together the various calculations found on the web.
 
To SG - I daren't show these figures to NickN!
 
My apologies to you!
PeterH
Nil illegitimum carborundum est

FSX SP2; i7 2600K, OC 5THz liq N2 cooling 16GB 1600 DDR3 RAM, GTX670, WINDOWS 7 64; 256GB OCZ Vertex SSD; Samsung 2233RZ 120Hz Monitor
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-16-2011 at 6:44pm
Originally posted by Phase Phase wrote:

Bisailb
Your calculations are exemplary (and correct) my post was an attempt at a bad joke - my figures are meaningless!Embarrassed 
I used to do a lot of clinical statistical analysis and my calculations and always stopped at two decimal places!! (otherwise they were too difficult to prove)
 
I always thought that Sheffield had more knives than trees!Smile
 
Holger Sandmann has written quite a few posts on trees and buildings wrt to what FSX should render to emulate real life mainly on the FTX forums and they may be worth reading.
 
Thanks again for this post it did tie together the various calculations found on the web.
 
To SG - I daren't show these figures to NickN!
 
My apologies to you!
PeterH


Let me get this straight because you confused me for a moment. The whole intent of your post is to say that I should adjust my value of 1376 trees per cell to 1382 trees per cell correct? I assume you're basing this figure off statistics from Sheffield, UK?

Are you being sarcastic when you say:
"
Your calculations are exemplary (and correct) my post was an attempt at a bad joke - my figures are meaningless!"

I didn't mean to offend if that's the case and I'm not claiming that I'm right or that my math is correct. I posted it here so people could poke holes if there are any to help me arrive at the correct solution.

In any case, can you link me some of Holger Sandmann's posts to lead me down the right path of finding out more about emulating this? Furthermore, I understand that FSX is far from being able to do things like simulate the number of trees in the Amazon Forest (50,000 to 100,000 trees per km squared). I'm really after a realistic number of trees around urban areas based on cities in the world that contain the most dense trees per km squared so that I can limit what FSX tries to draw to achieve an appropriate number of trees. This should also have a positive impact on performance.
Back to Top
Phase View Drop Down
Senior Member
Senior Member


Joined: October-15-2004
Location: Antipodes
Points: 1565
Direct Link To This Post Posted: January-16-2011 at 6:58pm
No sorry, the figures and calcluations were just a figment of my imagination and I did check your figures in Excel and I state categorically they are correct mathematically.
I can assure you that I was not being sarcastic!  I was trying to explain my silly post that you may have thought that it had some basis in fact - it did not!
Again I can only apologise if you thought that I was being unfair.Embarrassed
Regards
PeterH
Nil illegitimum carborundum est

FSX SP2; i7 2600K, OC 5THz liq N2 cooling 16GB 1600 DDR3 RAM, GTX670, WINDOWS 7 64; 256GB OCZ Vertex SSD; Samsung 2233RZ 120Hz Monitor
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-16-2011 at 7:09pm
Do you know how the Autogen slider affects how many trees per cell get drawn? For example, if the slider is set to 100%, how many trees get drawn if trees per cell is 1382 as in your calculations above? I'm going to make an assumption here...

100% = 1382
70% = 967
45% = 621
20% = 276
10% = 138

If that's the case, then that means I need to adjust the value to get 70% to draw 1382 trees per cell because that's what I'm using for my Autogen Density setting. Since that also affects buildings it would mean I would have to also adjust my buildings per cell.

Is this correct?
Back to Top
luap View Drop Down
Certified Professional
Certified Professional


Joined: December-11-2003
Points: 8087
Direct Link To This Post Posted: January-17-2011 at 10:04am
Originally posted by Phase Phase wrote:

Bisailb
Your calculations are exemplary (and correct) my post was an attempt at a bad joke - my figures are meaningless!Embarrassed 
 
And here I was going to give you an education on (in)significant digits....
 
We like to intermingle business with humor here, Bis....  FSX makes many of us cry so we need a laugh now and then.


Paul Scott Bartelt

The grass is always greener over the septic tank



Back to Top
flydave123 View Drop Down
Senior Member
Senior Member


Joined: October-16-2005
Location: United Kingdom
Points: 1273
Direct Link To This Post Posted: January-17-2011 at 12:39pm
Either that or get an axe and chop down all the damn trees! LOL
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-17-2011 at 7:17pm
Originally posted by luap luap wrote:

Originally posted by Phase Phase wrote:

Bisailb
Your calculations are exemplary (and correct) my post was an attempt at a bad joke - my figures are meaningless!Embarrassed 
 
And here I was going to give you an education on (in)significant digits....
 
We like to intermingle business with humor here, Bis....  FSX makes many of us cry so we need a laugh now and then.


I was "truncating" without following any rules. However, I did go all out with the decimals on my end. I just thought that for presentation purposes it would be easier for people this way. However, note that I am laughing about this now (i.e., the humor) LOL

In any case, I want to add that I used FSXMark07 and Fraps to do my framerate tests.

In Fraps, under FPS I set it up as follows:

P for "Benchmarking Hotkey"
"FPS" and "Frametimes" unchecked
"MinMaxAvg" checked
"Only update overlay once a second" unchecked
"Stop benchmark after" 300 "seconds"

FSXMark07 is available at AVSIM:
http://library.avsim.net/download.php?DLID=113016

This does not mean that you won't get slowdowns in other areas of FSX (e.g., heavier scenery areas) but the idea is to repeat the exact same test in the exact same conditions each time in order to optimize FSX accordingly. Then, if you take it into another scenery area, your issues with blurries, lag spikes, micro stutters, etc. should be lessened to some degree. In the end, it all depends on what hardware you're running in terms of how much FPS you can push and still maintain smooth flight.

For example, in some areas where I fly it's 100% smooth and in others I still notice some degradation in performance but my machine is somewhat underpowered and I run heavy mesh and scenery with real-time weather. However, the bottom line was that I was able to optimize my system for the best possible result I can achieve in those situations and that's what matters. Therefore, I don't want people to think that this is a silver bullet to every problem. It's just a different way of approaching the problem of FSX performance and smoothness.
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-17-2011 at 7:22pm
Originally posted by flydave123 flydave123 wrote:

Either that or get an axe and chop down all the damn trees! LOL


LOL time to whip out the chainsaw... or should I use a matchstick? LOL

Actually, with this setting and Autogen at Dense the forests still look pretty nice to me. If I had a faster machine I could probably run higher settings. Most people have CPUs that are at least 1GHz per core higher than my machine right now. I'm only running a 2.4GHz with DDR2-800MHz RAM and an NVidia GTS 250 1G GDDR3. I don't even have SSD drives. So if I can pump more performance other people should have good results too I would imagine.
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-17-2011 at 7:49pm
Originally posted by woodhick803 woodhick803 wrote:

Yes, but will it affect my FR's adversely?


Sorry, I missed this post earlier. It's not really about how high or low your frame rates are going to be. It's about determining the optimal frame rate and texture bandwidth multiplier to ensure the smoothest flights. Given that I edited my posts after you replied, if you look over the results again you'll see what I mean. Furthermore, I added a little bit of info about autogen tweaking for trees and buildings based on Phil Taylor's blog.

In any case, it's going to be interesting to see what "Microsoft Flight" has in store for us in the future. I just hope it doesn't become "Microsoft Flight for Dummies". They made a stupid mistake killing the ACES team in the first place. They should make an offer to Phil Taylor and get him back on the development team if they haven't already. They lost a real asset there I think.
Back to Top
Henties View Drop Down
New Member
New Member


Joined: August-31-2009
Location: Namibia
Points: 35
Direct Link To This Post Posted: January-18-2011 at 1:46pm
HI !
I kinda like scientific approaches to problem solving, or alternatively to gleaning a better understanding of technical issues at hand.
FSX is however an unpredictable beast. I run 2 identical machines but established that for each of them to run optimally - smoothly - I have to use different values for some of the .CFG parameters covered in this thread. I think this is what NickN has tried to make us understand over and over again. There is just no one set of parameters that can universally be applied to every machine running FSX, yielding the same result, even if they are identical hardware and software wise. The manufacturing spread and tolerances are just not narrow enough to accomplish this wonderful dream. This also manifests itself when OCing 2 identical machines, one can just not transfer the settings of one to the other, for optimum reslts.
The calculation with umpty decimal places above take me back some years -decades perhaps - when Intel had a problem with some of their CPUs and in particular the onboard math co-processor. During those days we bent "the rules of mathematics'  in a way that our calculation results conformed to what one could expect if those calculation were perfomed with an Intel CPU of the time.Dead For that reason and, even up to today, when I add up 2 + 2  I get 5, this result being rounded to the nearest decimal - integer - and that merely to make provision for extra large numbers of 4. I guess that is why I am not one of the ten richest people on this planet with Bill Gates passing me in the street without even noticing me, it really saddens me when I think of it..Cry
Cheers
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-18-2011 at 7:22pm
Yes, my goal was not to guarantee that these settings could simply be copied to a machine to obtain smooth flight. In fact, the [Display], [GRAPHICS], [SCENERY], [TERRAIN] and [Weather] sections of the FSX.cfg that correspond to the FSX Settings tabs for GRAPHICS, AIRCRAFT, SCENERY, WEATHER and TRAFFIC all have performance impacts as well.

In fact, it's best to start tuning the FSX Settings using the default Graphical User Interface (GUI) interface first and then worry about adding the basic tweaks listed below to your FSX.cfg later.

- TEXTURE_BANDWIDTH_MULT (already in FSX.cfg; value adjusted)
- UPPER_FRAMERATE_LIMIT (already in FSX.cfg; value adjusted)
- ForceFullScreenVSync (added manually to FSX.cfg)
- TEXTURE_MAX_LOAD (already in FSX.cfg; value adjusted)
- AffinityMask (added manually to FSX.cfg)
- DisablePreload (added manually to FSX.cfg)
- TERRAIN_MAX_AUTOGEN_TREES_PER_CELL (added manually to FSX.cfg)
- TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL (added manually to FSX.cfg)

I only tweaked the above after I had already settled on some decent FSX Settings through the FSX GUI and I made sure to optimize Windows 7, defragment my hard drives, etc. as per Nick's advice. The math only really kicks in when optimizing TEXTURE_BANDWIDTH_MULT and UPPER_FRAMERATE_LIMIT to further enhance performance and smoothness. The math is intended to help people "get in the right ball park" so to speak but it's not a silver bullet.

However, I think that I was able to show that the majority of the other tweaks mentioned on other forums listed below are not likely needed to obtain an optimal frame rate with appropriate smoothness. I didn't use the following tweaks at all because they yielded absolutely no benefits in my tests on my machine and I still managed to achieve all of my goals on my older and slower machine.

- AC_SELF_SHADOW
- ALLOW_SHADER_30=1
- BufferPools (with UsePools=0 or RejectThreshold)
- FIBER_FRAME_TIME_FRACTION
- HIGHMEMFIX
- MAX_ASYNC_BATCHING_JOBS
- SWAP_WAIT_TIMEOUT
- TextureMaxLoad (with external frame limiter)

I think starting out with a default FSX config is the first step, then adding the basic tweaks is the second step. If after that you've managed to achieve a decent frame rate and smoothness then I suspect there's really no need for the other tweaks in most situations.

As far as default FSX GUI Settings are concerned, the ones that had the most impact on my machine in terms of smoothness were:

- Disabling light bloom
- Disabling aircraft shadows
- Water effects (Low 2.x)
- Scenery Complexity (Very Dense to show custom buildings properly)
- Autogen Density (Dense because I didn't like the visuals with Normal)
- Disable all traffic (Airport vehicle density set to Medium but everything else is 0)

I only enable traffic if I want to fly offline but I usually fly on VATSIM so my AI traffic gets resolved when I see other people's planes in the sky. In reality, these settings could be higher if I had better hardware but I don't so this is the max I can push in combination with the basic tweaks to have a decent experience in terms of frame rate and smoothness on my machine.

In the end, I just hope this thread is still of use to people.

Cheers!
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-22-2011 at 5:33am
I developed a calculator to automate the math:
http://www.mediafire.com/?11ovso4gg5wgkcd

You can download .NET Framework 4 (Web Installer) from:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9cfb2d51-5ff4-4491-b0e5-b386f32c0992&displaylang=en

In the next release I will add the math for the trees and buildings discussed here.

Big smile
Back to Top
Herky130 View Drop Down
Senior Member
Senior Member


Joined: June-18-2010
Location: UK
Points: 233
Direct Link To This Post Posted: January-22-2011 at 3:00pm
Hi bisailb,
 
Really fascinating information, has got me thinking!
 
My GTX285 has a memory clock of 1242 MHZ yet is rated at 2484 (x2) data rate. Therefore my system would, by your math, run with a Texture bandwidth multi of: 129.375. Given that I run with frame lock at 30 and Texture Max Load at 1024.
 
(2484*16) / 30 = 1324.8
(1324.8/1024) * 100 = 129.375
 
I had previously set a TBM of 120 and found this to be a smooth setting ( the sweet spot). This was done by trial and error! It would seem your calculations concur with my ( trial and error ) setup. 
 
Interestingly I have an i7 960 o/c to 4200 MHZ (6GB DDR3 at C7 timing and FSX on a dedicated SSD).  I say interestingly, since as we all know, FSX is a processor bound simulation, yet the maths involved in the display and hence GPU are a vital component when exploring smoothness of flight. ( Not to mention other settings which do impact upon frame rates and smoothness of flight) 
 
However as we all know FSX does not run equally on similar or same systems..........so there are yet more variables to ponder.Confused
 
Many thanks again for your information.
 
Oh and just by the way, I do run with HIGHMEMFIX=1 as a solution to blacked out graphics glitches when running complex aircraft like PMDG. ( AND I use Affinitymask=14, which I know is frowned upon by some but seems to work on my system!) I use no other "tweeks"Big smile
 
Regards
Herky
 
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-22-2011 at 4:24pm
Originally posted by Herky130 Herky130 wrote:

Hi bisailb,
 
Really fascinating information, has got me thinking!
 
My GTX285 has a memory clock of 1242 MHZ yet is rated at 2484 (x2) data rate. Therefore my system would, by your math, run with a Texture bandwidth multi of: 129.375. Given that I run with frame lock at 30 and Texture Max Load at 1024.
 
(2484*16) / 30 = 1324.8
(1324.8/1024) * 100 = 129.375
 
I had previously set a TBM of 120 and found this to be a smooth setting ( the sweet spot). This was done by trial and error! It would seem your calculations concur with my ( trial and error ) setup. 
 
Interestingly I have an i7 960 o/c to 4200 MHZ (6GB DDR3 at C7 timing and FSX on a dedicated SSD).  I say interestingly, since as we all know, FSX is a processor bound simulation, yet the maths involved in the display and hence GPU are a vital component when exploring smoothness of flight. ( Not to mention other settings which do impact upon frame rates and smoothness of flight) 
 
However as we all know FSX does not run equally on similar or same systems..........so there are yet more variables to ponder.Confused
 
Many thanks again for your information.
 
Oh and just by the way, I do run with HIGHMEMFIX=1 as a solution to blacked out graphics glitches when running complex aircraft like PMDG. ( AND I use Affinitymask=14, which I know is frowned upon by some but seems to work on my system!) I use no other "tweeks"Big smile
 
Regards
Herky
 


I agree that FSX does not run equally on identical or similar systems. No one can provide a silver bullet to a complex problem that involves "several" factors including both hardware and software configuration. However, I do hope that people realize that when they think "so there are yet more variables to ponder" that they don't go straight to adding a ton of unnecessary tweaks to their FSX.cfg when there are probably a lot more factors outside of FSX that could be causing the problem.

I agree that in some cases, people may need to run with the HIGHMEMFIX=1 solution. My system didn't need it but I have read about many people who have had to use it for the very same reason as you. There's nothing wrong with that.

As for AffinityMask=14 I believe that is the proper setting especially if you're someone who uses a lot of third party external programs while flying in FSX. I say this because 3 of your cores will be pegged and your first core will be at about 10-20% usage so that gives some headroom for running other applications outside of FSX such as VAFinancials, VATSIM, Weather, etc. Some people use a program called SetAffinity to run those types of programs on CORE0 so it doesn't affect the other cores FSX is using while they are flying. I tried the AffinityMask=15 setting on my system and it negatively affected FPS and smoothness. I did not post the results because people on other forums have experienced this issue as well. I would say if people really want to use 15 then they should start with 14 first and do some testing once everything is running smooth to determine if it really does improve anything.

I am happy that this thread is providing positive value to people in some way, shape or form. On a final note, I wonder if Microsoft will go more GPU bound with Microsoft Flight as opposed to CPU bound with FSX. I know that Phil Taylor said in the past that they would continue to be CPU bound but the old ACES team is gone so who knows. Thanks for your reply!
Back to Top
bisailb View Drop Down
New Member
New Member


Joined: December-31-2010
Points: 20
Direct Link To This Post Posted: January-22-2011 at 4:35pm
I wanted to add that some people use their "system RAM" in this calculation as opposed to their "video RAM". My calculator application that I posted in this thread allows for both.

However, this raises a question...

Lets say someone is using DDR2-800 system RAM with GDDR3-1100 video RAM on their video card. The calculation would yield MAX_TEXTURE_DATA=427 for the DDR2-800 system RAM and MAX_TEXTURE_DATA=587 for the GDDR3-1100 video RAM. See the discrepancy there?

While I have no way of testing whether this actually skews the TEXTURE_BANDWIDTH_MULT value or not, from a hardware point of view, I suspect that running system RAM that matches or exceeds the capability of your video RAM in this sense is probably a good idea.
Back to Top
Herky130 View Drop Down
Senior Member
Senior Member


Joined: June-18-2010
Location: UK
Points: 233
Direct Link To This Post Posted: January-22-2011 at 6:43pm
I believe you are correct in your assumptions. System RAM needs to be as fast as possible or the results will be poor. By results I mean not smooth flight, or micro stutters, or worse!
 
I believe anything greater than C7 timing in DDR3 RAM will under perform. Its all a balance, is it not?  ( Then there is the question of eliminating latency in the delivery of the program from its storage medium ie the Hard Drive.....Shocked.......Wink )
 
Due to its age and way its written, my belief is that FSX needs to be run clean with the fastest system RAM and fastest Video possible, together with the maximum cycles possible from the CPU....an i7 980 with 4.2 o/c or better.Cool  That way no "tweeks" need be even contemplated. As we know adding one tweek has an effect somewhere else, needing another tweek to fix the side effect and so on...............
 
As for your question for MS "Flight".........If it is to be a NEW coded engine, it may persue the GPU favoured route. It can look nice but not just the proverbial "eye candy"................ I just fear that it will lack the features a true simulator needs, or it will be just another "game" that comes with the "suitable for 3 years and above" on the labelSick Lets hope not!
 
Great thread.........Handshake
 
Regards
Herky
 
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.01
Copyright ©2001-2018 Web Wiz Ltd.

This page was generated in 0.125 seconds.