2 things:1) you cna use a tool called FRAPS (free download) to do a recording/log of your demo flight and it will capture the min/max/avg FPS you're getting throughout.2) I would HIGHLY consider turning HT OFF. The reason is that when HT is enabled 1/2 of your L2 cache is being dedicated to that 2nd "virtual" core's work which means that the main thread running on the 1st logical core (FSX's main render loop) is being given only 1/2 the cache to work with. Considering how sensitive the P4 design is to cache misses, I suspect you're getting worse performance with HT ON than you would with HT OFF.--2002cbr600f4i

Thanks for the infor on FRAPS. I will download it and reconduct the tests.Not sure on the HT, although your arguement is logical... I believe I had worse performance with it disabled in BIOS than I did with it enabled. I need to find the raw data to prove it though.

I have re-run these tests and found that consistantly (at least on the test machine), I always have just about 1 Gig of memory free.It LOOKS like FSX itself uses 1 gig of RAM but no more...It also LOOKS like hard drive speed is not relevant...Data seems to indicate that processor and video card are the big two... Basically if you want to increase performance, have more than 1 gig of ram...but it LOOKS like more than 2 is not needed.It also looks like the other big thing is Video card and then finally processor.It does NOT look like a faster hard drive will help at all, and I also looks like a SLOW hard drive will not impede performance....Anyone else see anything different in the data?Is there any other Performance Testing Data out there (hard numbers)?

"It LOOKS like FSX itself uses 1 gig of RAM but no more..."I believe I read somewhere that FSX will use upto 2GB and FSX used 1.6 GB of my 2GB only last night. CheersDave March

---

http://www.oncourse-software.co.uk/forum_images/fdc_dev.jpgEmail:[email protected] Website:http://www.oncourse-software.co.uk

On my setup fsx has not used more than 1.1 gigs ever, But I use resized textures for almost everything. It uses 1 gig at klas with lots of scenery going.. It usually hovers around 700-900mb elsewhere.Andrew

>"It LOOKS like FSX itself uses 1 gig of RAM but no>more...">>I believe I read somewhere that FSX will use upto 2GB and FSX>used 1.6 GB of my 2GB only last night. >>Cheers>Dave-I have suspected that it would use more-- it seemed unusual that it would not--- but I have not been able to get the PC to do it with the test simulation that I have been running...(Thats why I said it LOOKS like it instead of it doesn't use more)...thanks VERY much for the informationWas this for the FSX process alone? or what this for the machine itself? Do you have any other data on what the machine is doing?One of the more interesting things I have noticed while testing is that when I have done testing using a second vido adapter (a Radeon PCI 7000 that I normal use to display avionics) that PAGE FAULTS increased by a factor of 40!!! while memory (RAM) utilization remained constant... I am getting ready to test this an a friends machine as well to verify that it is no just a problem with my configuration.As I stated in my orignial, I posted a zip file of the raw data because I am hoping it will be usefull-- I would actually like to gather data from other users-- I "think" that getting hard data and being able to analyze it will probably be of benefit... at least to those that are trying to decide what types of hardware to buy-- For myself, I was able to decide that in my situation, I would not buy a "faster" hard drive-- the FSX platform does not appear to do a lot of disk reads while flying... instead, I am going to spend additional money on video..As a developer, what additional parameters are you looking for? Is there a better way to provide data? Is the data of value?Thanks again for the input on the memory by the way :-) -- any additional input you can provide would be appreciated.Matt

>On my setup fsx has not used more than 1.1 gigs ever, But I>use resized textures for almost everything. It uses 1 gig at>klas with lots of scenery goingThat is what the perfmon data that I have shows as well... over five minutes, polling every 5 seconds, with the scenery constantly changing, it never exceed 1.1-- It ALSO barely accessed the hard drive and the page file...I would love to get more data from more people-- It would definately help in looking at where to do my next upgrade--- and I am sure it will also help in developing new addons...Thanks..Matt

Hi Matt, Sorry, that was a slightly inaccurate post as I was checking total memory. Having said that I was running with all unnecessary services/processes disabled. Been running the sim for a couple of hours, tweaking this 'n' that till I now have it running quite nicely.My guess is the system was utilising .2GB to .3GB. Whatever the exact figure it must certainly be beneficial for anyone to have more than 1GB of RAM.I'm sure it was one of the ACES team who mentioned the amount of RAM FSX would/could utilise... maybe it was during the beta... now if only someone could find a tweak for my memory :-lolCheersDave March

---

http://www.oncourse-software.co.uk/forum_images/fdc_dev.jpgEmail:[email protected] Website:http://www.oncourse-software.co.uk

Hello Matt,This is very interesting information and it is good that someone is doing real tests instead of just repeating what is said in the forum.Have you taken into account the display settings, by any chance? In this version of FS, much, if not most, of the data is now pre-calculated and included in the loaded files. The purpose of this is to save on processing in game - since so much is already calculated, all the game needs to do is display, and not waste processor cycles.This explains the very smooth flight that so many experience. But, the amount of data loaded will change drastically with different settings, particularly Level of Detail Radius, and Global Textures.So, have you tried your tests with different settings to see the results?Thanks for doing all of this.Best regards.Luis

I have done some testing with different settings and plan to do more this weekend. I actually got rather engrossed with flying the ultralight around areas that I grew up and I have been amazed with how accurate things can be!But back to testing--I have run a round of tests adding in my second video card. The data showed an INCREDIBLE jump in page faults, but did NOT show any increase in memory utilization-- The jump in page faults was a factor of 40 (forty-- just so people know I didnt miss type that and really mean 4 :-) ). So I am going to run this round again to see if I can replicate the data....I am also going to start some testing based on aircraft type....This has had an intresting side affect. Spending this time looking at how to better optimize my Flight Sim machine at home has provided me with some new insights into performance tuning that I am able to apply to the user desktops at my office (I am director of information technology for a large commercial real estate firm)--- This is certainly an enjoyable and beneficial project....Matt

> I now have>it running quite nicely.>>My guess is the system was utilising .2GB to .3GB. Whatever>the exact figure it must certainly be beneficial for anyone to>have more than 1GB of RAM.>>I'm sure it was one of the ACES team who mentioned the amount>of RAM FSX would/could utilise... maybe it was during the>beta... now if only someone could find a tweak for my>memory :-lol>>Cheers>Dave-I do very little coding/development work, so I am hoping you can answer this for me... Could it be that FSX is, I dont know, Reserving, up to the 2Gbs that you mentioned? I mean, could it be that the base platform (FSX I me) is using the 1st Gig of memory and holding the 2nd gig open for add-ons or other applications to run within FSX?I was really quite suprised how FSX utilized memory--- it never really fluctuated... It also never accessed the page file, although there was a tiny (less than 2%) amount of the page file that was designated as being used by the FSX process. The zip file in my original post has all the data....Now if you could find that personal memory tweak let me know--- I could use it too!!! :-lolMatt

>I do very little coding/development work, so I am hoping you>can answer this for me... Could it be that FSX is, I dont>know, Reserving, up to the 2Gbs that you mentioned? I mean,>could it be that the base platform (FSX I me) is using the 1st>Gig of memory and holding the 2nd gig open for add-ons or>other applications to run within FSX?I doubt that very muchCheersDave March

---

http://www.oncourse-software.co.uk/forum_images/fdc_dev.jpgEmail:[email protected] Website:http://www.oncourse-software.co.uk

Matt,Great test! I'm a system architect for a large business software company (not MS) and your method is very professional. My background includes designing and tuning enterprise scale SMP database applications on various Unix, Linux and Windows platforms for some of the world's biggest financial institutions.I conducted some similar tests but looked at some different parameters, including:- Processor Queue Length- Pages/sec- IO Data Operations/sec FSX- IO Other Operations/sec FSXProcessor Queue Length is usually the first thing I look at. It shows how many ready threads are waiting for a processor to execute them. From perfmon, "Processor Queue Length is the number of threads in the processor queue. Unlike the disk counters, this counter shows ready threads only, not threads that are running. There is a single queue for processor time even on computers with multiple processors. Therefore, if a computer has multiple processors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than 10 threads per processor is normally acceptable, dependent of the workload."Pages/sec is another favorite. This, combined with available memory, is a good indication of a system that needs more memory. Again, from perfmon, "Pages/sec is the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It is the sum of MemoryPages Input/sec and MemoryPages Output/sec. It is counted in numbers of pages, so it can be compared to other counts of pages, such as MemoryPage Faults/sec, without conversion. It includes pages retrieved to satisfy faults in the file system cache (usually requested by applications) non-cached mapped memory files." (Hard page faults occur when a process requires code or data that is not in its working set or elsewhere in physical memory and must be retrieved from disk.) IO Data Operations/sec FSX: How many total IO calls is FSX making. I wanted to determine how much IO was generated, and to what extent I could separate disk IO from device IO. Unfortunately, there is no monitor for device-specific IO (e.g., IO to/from the video card). From perfmon, "The rate at which the process is issuing read and write I/O operations. This counter counts all I/O activity generated by the process to include file, network and device I/Os."IO Other Operations/sec FSX: How many non-data (e.g. control calls) is FSX making. From perfmon, "The rate at which the process is issuing bytes to I/O operations that do not involve data such as control operations. This counter counts all I/O activity generated by the process to include file, network and device I/Os."My system specs:P4 3000 HT, 1GB PC3200 (400mhz) RAM, ATI 9700 Pro (overclocked to 360mhz GPU, 340mhz VRAM), Turtle Beach Santa Cruz audio.I use FSAutoStart to disable all possible processes and shutdown running applications.I run FSX in 1024x768 and have tried many of the tweaks discussed in this forum. I have not resized any textures.TEST RUN 1: Paging was high, available memory was almost none. CPU0 was 100%, CPU1 was around 25% average, Queues were high (4-24). IO Operations were high, both Data (peak 258/s) and Other (peak 750/s). I decided that first I needed more memory, since this was easily corrected. TEST RUN 2: Added 1GB RAM for 2GM total. Paging dropped off to almost 0. Plenty of available memory. Overall FSX performance improved.TEST RUN 3: Disabled HyperThreading. Since CPU1 was previously running with idle time, I wanted to see what would happen if I devoted all CPU resources to CPU0. The result was that CPU0 was still 100% and queue length was still high. However, on my system I saw an small increase in performance.So, the memory issue is solved, disk and page file activity is very low, but the CPU is running 100%, and there is a lot of IO. Many of the tweaks that have been discovered by others serve to reduce IO to the graphics card (reducing the number of objects, simplifying objects, reducing textures, etc.). I think this is the most productive path available for the current technology. I have tested before and after each tweak, and have seen the most improvements with these types of tweaks.For the future, I'm optimistic that DirectX 10 will offer significant improvements, particularly in handling large numbers of objects. I have been researching DirectX 10, and I came across an interview with ATI by Brent Justice titled, "DirectX 10 & the Future of Gaming". See http://enthusiast.hardocp.com/article.html...W50aHVzaWFzdA== In this article, they discuss the limitations of DirectX 9 to handle large numbers of objects, and how it drives CPU:"One of the biggest limitations is API object overhead. In fact game content developers are currently being bottlenecked by this overhead. Out of all the improvements that could be pushed into DirectX 10, the issue at the top of the list for most game developers was to lessen API object overhead. What we mean by API object overhead is that the API is using CPU cycles to achieve tasks necessary for rendering before being output to the video card for drawing. When rendering a game, the application first has to call to the API and then the API calls to the driver before it ever interacts with your video card

> My background includes designing and tuning>enterprise scale SMP database applications on various Unix,>Linux and Windows platforms for some of the world's biggest>financial institutions.>Glenn--This is interesting --Prior to my current job, I was doing Performance Tuning, Migrations and Systems Assesments for AIX, VMS and Windows platforms for enterprise scale Health Care platforms (Yes our team was the PMS Team- ;-) HR REALLY had an issue with that when they found out!!!!)>I conducted some similar tests but looked at some different>parameters, including:>>- Processor Queue Length>- Pages/sec>- IO Data Operations/sec FSXI went back and looked at what I uploaded and discovered that on at least one of the files, I lost the Pages/sec and IO Data Operations/sec colunms... IO data Operations for the FSX process average 45 per second over 5 minutes and Pages/sec was 1.4 /secondDoes this match with what you are seeing numerically?I dont know if you saw my page faults post-- What was interesting was that when I ran FSX on 2 video adapters, page faults increased by a factor of 40!!! I am re-testing to see if the data was >Builder/Owner Velocity Elite RG N697RGWow!!!-- My best friend and I spent the weekend looking at the Velocity RG models-- I think I have decided that I am going to build a Velocity RG "Dash 5"!!! I would be VERY GREATFUL if I could correspond with you about the plane!!! Have you found a good MSFS air model of the Velocity? I saw one in the FS9 Original Aircraft library but I am not sure how it REALLY comparesI would LOVE to see picture and discuss -- Let me know if you are open to sharing about your aircraft and I will get you my email address.Thanks, Matt

According to "memstatus", my video ram usage grows past my 256 hardware video memory limit to about 400mb...and my system memory usage at that point nears 1.6 gb. Never maxes my 2gb system ram, but comes somewhat close.bob