Great thread.Jim- what mobo do you have? I have the same CPU.Thanks, Bruce.

If you have enough fibers running, with enough context switches, could that not eventually create enough pages to overflow the L2 cache?Anyways, starting to confuse me now, I think the rest of the night will involve some cookies and beer. The woman is due back tomorrow night so I'm thinking I should relax and enjoy it before I get put to work on he parents basement.I did do some performance testing though. I will say that you can't easily monitor the CPU cache itself, but you can monitor the main system cache and page file. It doesn't really relate to what were talking about, but man... if you'd seen these results I am 100% you would agree that something just isn't right with FSX.Actually, here you go.Some performance counters during execution of the Aquamark benchmark.As you can see.... the software is quite taxing, running the processor at 100% most of the time. The faults on the left of the screen shot were me switching applications and starting the test. You can see how once the test was underway, that there was some stability here. Aquamark runs your system through some heavy duty rendering, shaders, fog, etc etc etc.... so comparitive to FSX, it is quite demanding. Notice how system cache (not processor cache) faults seem to be in line with the page faults... something I think is pretty normal.Now onto Call of Duty 2Again, fairly uniform performance here. Cache faults once again correlate closely to page faults. I think CoD2 has been really refined since the patches were released, I'm running it here with max settings all around, and using DX9 as opposed to the better performing Dx7 mode that we all had to use when this game first came to market.... right now it is maxed out with all effects on and high... she's locked and loaded.Alas... FSXI set FSX to the lowest of the low here. Running at almost 78fps max. Everything is either off or set to minimum. Where are the page faults? You can't see them because it's maxed out beyond what the graph can show. Cache faults are all over the place, and in some places seem to happen where even page loads are not taking place (center). I think the graphs, although not showing data we can use for the processor cache debate, shows that FSX is beyond the norm. It's settings were minimal, I even tried this at 800x600 by modifying FSX.cfg. Okay so it's built for nextgen platforms, but it was running superb besides looking like crap... yet still performance indicators show that all #### is breaking loose. The lack of any uniform data in the graph shows that the internal working of FSX really do need some more work.

Have you checked fs9 to see what its doing?

Not yet :( I admit, I was very pleased with the FSX demo and decided that I would give away my beloved FS2004 to my dad, who hasn't experienced a sim in many years. He has since gone out and bought himself FSX and given away FS9 to a young man at his workplace :(I have a backup copy of FS9 that I seriously considered installing then downloading the widely available patch to run it without the original disks.... but I decided against it. I don't wanna p-off anyone at ACES by running an illegal copy of FS9 or they will put a hex on my FSX and make it run like crap :) heh I just giggled... I actually giggled.... been a long time since I made myself laugh like that :) But no, the original disks are no longer in my hands and being in the business, I tend not to use software illegally.In other news though, I have got a rather decent collection of games here that I'll be installing over the next few days. Far Cry, Brothers in Arms 1 & 2, CoD, CoD:United Offensive (older but taxing), Pacific Assault (to this day I still cant run it maxed out), Company of Heroes.I'll run each of those games maxed out and see how they compare. I'll refine the performance counters as well, actually use a bunch of counters that will better provide an overall performance indication under hard loads. It will never bring any light to the debate about CPU cache levels, but still, insight is insight and its all good :) Fibers may not be the baseline cause of poor performance in FSX, but determining if poor performance is due to software or hardware is a valid effort I think. I don't believe that Vista, DX10, and true DX10 based graphics cards will offer that much of an improvement to FSX the way it currently sits... maybe it will look better overall, but FPS and smoothness wise I don't think we can expect it to be a magic bullet. Remember, FSX is currently coded for XP, DX9, and DX9 cards, the advanced patch to support future platforms will come when those platforms are available... so why wouldn't this run well on todays top of the line dx9 based XP machines? bah, I'm whining again.

________________________________________>>Processor : AMD 64 4000+ @2.6GHz>L1 Cache : 64k + 64k>L2 Cache : 1024k>FPS : 15 - locked and maintained 80% of the time>Fiber setting : 0.98>>>I think we will see a trend. Faster processors with larger>CPU caches will probably perform similar to a lower end>processor with a smaller cache. Just an experiment really...>could be worse, I could be asking you all to take your>temperatures and PH levels :)>>>Kev C I'm now getting 15 fps with FSX on my P4 at 2.8 Ghz. L1 cache is 16 kB. RAM is 512 MB. Cheap, $50 ATI AGP video. I have implemented the common 'tweaks'. Sliders are typically set around 2/3. Cache reloads can add a lot to processing time. Such details are in the fine print for the CPU instruction timings. Intel CPU's have instructions and timers for finding how much time is spent in cache flushes, etc. Few programmers know how to use them. If ACES were really good at writing efficient code they would use such features (also, SW and HW profilers) to see how instruction efficiency varied with coding and CPU differences. Then, they could provide guidence to users. As it is, they appear to be getting such information from the users. A Posteriori. Further, running apps that kept track of video, page file, etc. memory would do a lot to see where the stutters come from. RAF PS: As far as stutters go, I now think a lot of the problems are in the OS (XP) rather than in MSFS itself. And OS is typically used to run non-realtime apps, a half second pause now and then is no problem. XP swaps out as much of the running apps as it can over time. To make room for further apps that might be loaded. Running FS, no one is likely to load another app, thus there is no reason to swap out code and data that might be needed when one simply shifts to a different view, or flies into different scenery. This should be less of a problem when one has a lot of RAM, however, people with 2 to 3 GB ram still report stutters.

I haven't had any stutters since playing with Poolsize and Fiber Frame tweaks. I agree though, ACES are probably as much in the dark as we are, even though they designed the sucker. Still though, coming from the worlds longest running computer software product line, you would expect nothing but world class commitment from them. They have chimed in, but far from being any help really. It would be nice to know whether they are going to release a performance enhancing fix in the near future or if we have to wait for those fixes to be rolled into the DX10 update.Still tho, wonderful simulator, far beyond expectations as far as featureset. Just need to hammer out a few bugs is all :)Kev

It's an A8V Deluxe.Jim Karn

""PS: As far as stutters go, I now think a lot of the problems are in the OS (XP) rather than in MSFS itself. And OS is typically used to run non-realtime apps, a half second pause now and then is no problem.""One XP tweak that seems to work WRT page files is to set the minimum file size equal to the max file size.In FS9 I set both to 2048 with 1 GB of memory. I then noticed when switching to spot view on the ground ( or elsewhere )my aircraft no longer had a half second lag paint wise, it comes up fully painted!

Blurries are all related to video memory. My blurries all but went away with the purchase of an 8800gts which has 640mb of texture memory. Even the rare times that i get them now they draw back in to being sharp within 10 seconds and usually don't come back. I'm reading a lot of speculation in this thread that doesn't seem to have any basis in fact as far as i can tell. My 8800gts might have given me 1-2 fps more but it did smooth out the game greatly and increase the visuals. The bottom line is the game runs slow on all hardware which is a problem with the game. I remember back in the mid 90's 3drealms first build engine game witchaven ran dog slow no matter what processor was used. Even years later on the latest hardware it still ran the same...

>> This should be less of a problem when one has a lot of RAM,>however, people with 2 to 3 GB ram still report stutters.>As some have good FSX performance with target fps set at unlimited, this setting gives my system stutters. Started with running the target rate at 30 fps & now 25 fps which is totally stutter free.A week ago, after installing mesh addon's, stutters appeared, which is a big dissapointment. After shutdown and re-start the next day, stutters were completely gone, and have not re-appeared since. As to why?L.Adamson-- Athlon64 3700/2Gig/Geforce7600GS 256mb/1600*1200*32

>""PS: As far as stutters go, I now think a lot of the>problems are in the OS (XP) rather than in MSFS itself. And OS>is typically used to run non-realtime apps, a half second>pause now and then is no problem."">>One XP tweak that seems to work WRT page files is to set the>minimum file size equal to the max file size.>In FS9 I set both to 2048 with 1 GB of memory. I then noticed>when switching to spot view on the ground ( or elsewhere )my>aircraft no longer had a half second lag paint wise, it comes>up fully painted! Hmm, that doesn't make sense. I set something like 750/1300 MB for my page file. The lower limit is always present, and defragmented. If the file grows beyond the lower limit it may fragment, but probably not that much. If needed, the pagefile can grow, but shrinks again when not needed. Regardless, there is little problem with a 2 GB page file, considering the size of HD's nowadays. Only if one is nearly filled would there be much reason to limit the size. I have my pagefile on 'the other' drive. That way, access doesn't slow access to FS scenery on the FS drive. Further, one HD is EIDE, the other SATA. So, there is no buss sharing. Checking the MS KB, I noted than no application can be assigned more than 2 GB of memory. I think that includes any memory that swaps out. The OS doesn't take much memory, much is swapped out anyway. So, it would seem there is little value in having more than 2 GB of RAM. About what users have reported. RAF

You do understand that cache miss is very different from page fault, right? I did some test with code that I wrote back in the early 90. My code does non-native thread context switching a.k.a. fiber. I make sure each context has more that 256K of stack space and I stuff allocation of memory and de-allocation of memory of 1024KB for each context. When I test the code with 200 contexts (fibters), performance only drop less than 3% vis running the same code without the fibers. Why 256K? Because that's the page size in the PII and up.

Yeah I mentioned that the page fault/cache fault values in those graphs had nothing to do with the hardware cache on the processor.Would you be interested in sharing that code in order to come up with an executable we can all share and test on our own rigs to see if the performance drop is different on different processors?

My lawyers are going to block this as the code is used in our company's products and some of our clients actually has escrow on it. I can create something simular with real NT fibers, but until then, I am affraid the answer is no.

No worries :)