I agree. Those top dog CPUs generally stay hi. The QX6850 is Still 900 bucks!http://www.newegg.com/Product/Product.aspx...N82E16819115026Don't know about ATI vs Nvidia . . . 'cept you won't be able to use that AGP Vcard in a new box. I agree, it'll still do the job. It's been way over a year and DX10 is still a total bust. I've tried it in FSX and with my new 8800GT . . . and it just breaks things. ToTally more trouble than it's worth. Too bad. actually. You'll need to get a PCI-e Vcard. That dual Nvidia Gcore is a real letdown. Sounds like it might be trouble-makin' too. They are going to use some kind of onboard SLI firmware. Boy, that's just looking for trouble, but that 1G of Vram sure looks good to me. We'll see. Right now a single 8800GT in a P35 mobo is about as good as there is for us regular folks (Google "Skulltrail").

>According to the benchmarks ATI cards are consistently slower>in FSX than Nvidia card, which is strange considering its CPU>bound. I know that is the conventional wisdom, but I have to ask you this, why is it QX9650 at 3.6GHz and Q6850 at 2.83GHz (I think) show the same frame rates at 1280x, High Quality if the sim is not now GPU bound with these processors?

As I continue to observe TM with the sim running, it appears the main (only?) task Aces was able to offload to additional cores is scenery loading. My Core 0 goes to 100% and just sits there. The other boys jump in and out as scenery loading duties come and go. After I pause the sim, then after the scenery pops into its sharpest resolution, the other 3 cores will immediately settle down to 0% usage. That might leave a single core as the primary driver of FPS. If one compares two, single CPU systems with only a 20% clock difference, a FPS comparison could seem very subjective, or even nonexistant. I'm seeing the scenery loading job keeping three Core2 CPUs at 3.6Ghz busy pretty much full time. We might be underestimating the additional work that goes on beyond maintaning FPS. With a quad, that FIBER_FRAME_TIME_FRACTION=0.33 setting might be fun to play with. It schedules the amount of time the CPU(s?) spend between scenery loading and processing. If it's only looking at the single CPU -- that appears to be FSX's soloist -- , set it to a ".001" time for loading scenery. Let the other 3 cores handle it. Let the poor guy focus on his violin. Let the crew drag in the mic cables. On the 1 gig of Vcard memory front, I'm having all kinds of wierd, FSX initial load issues with a 42/19/19, 3 monitor setup with an 8800GT/512. That 42 is really a hog at 1920x1080. When it's good, it's very, verrry good. But when it's bad . . . All that real estate has to be kept in mind by something. I'm looking for a Video memory monitor. That might tell the story, if I could find one. Any ideas?

RE: NehalemEverything I have read so far points to more than a 10-25% performance boost with nehalem.The on die memory controller will be significant if nothing else. Add this to the fact that Nehalem is a new architecture (not just a Conroe rehash) then I think we will see signifiacnt gains.Glenn

>As I continue to observe TM with the sim running, it appears>the main (only?) task Aces was able to offload to additional>cores is scenery loading. Yes that's what ACES said, too.>>With a quad, that FIBER_FRAME_TIME_FRACTION=0.33 setting might>be fun to play with. My understanding is that FIBER_FRAME is inactive with multi-core setups. It only works for single core. This is on one of the blogs, probably PT's, can't remember.>>On the 1 gig of Vcard memory front, I'm having all kinds of>wierd, FSX initial load issues with a 42/19/19, 3 monitor>setup with an 8800GT/512. That 42 is really a hog at>1920x1080. When it's good, it's very, verrry good. But when>it's bad . . . >Like the nice bad rabbit. When she's good, she's verry good, but when she's bad, she's very,...very bad. >All that real estate has to be kept in mind by something. I'm>looking for a Video memory monitor. That might tell the story,>if I could find one. Any ideas? MemStatus is not very accurate for showing vid mem usage, but its the only one I know of.RhettAMD 3700+ (@2585 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS A8N-E, PC Power 510 SLI, 2gb Corsair XMS 3-3-3-8 (1T), WD 150 gig 10000rpm Raptor, WD 250gig 7200rpm SATA2, Seagate 120gb 5400 rpm external HD, CoolerMaster Praetorian

I think we'll begin to see that 10-25% increases are not significant. The big gains will be adding cores. The big clock for clock increase came when Intel finally decided to abandon Netburst use AMD's short pipeline architecture. That gave us a 100% clock for clock increase and finally allowed Intel to compete with AMD. I do not see that kind of clock for clock increase happening again. The Core2 architecture will just be tweaked as we go forward. Nehalem will just be a Core2 tweak. Another 10% core for core refinement, like the penryn. All significant increases in the future will come from increasing the number of cores. 40 cores in 4 years is not pie-in-the-sky. 10-25% is hardly worth even noticing. The onboard memory controller will not help RW performance in the forseeable future. AMD has been using this technology with its Athlons/Optis for years. This is a buss issue and the current FSB is not a bottleneck. Maybe someday, but not soon. The O/Cers are already running DDR3 at staggering speeds on the current FSB. This onboard memory controller is like telling us we need PCI-e2. With luck, they figure, some will buy a new mobo to get this new (non) performance. Admittedly Vcards will eventually need this buss speed capability, but not for the forseeable future. For instance, PCI-e offers Vcards an 8GB/s capacity . . . just like AGP 8X! Even the old AGP tech is not being used yet and now we have PCI-e2. Like that onboard memory controller . . . If you sell it, some will buy.

Thanks for the tip. I'll give memtest a try. I changed that FIBER_FRAME_TIME_FRACTION=0.33 to .01. The premise was this: "Core 0 works alone to provide Frames per Second. If the other 3 Core2s @ 3.6Ghz were entirely (and only) dedicated to loading scenery, adding 33% of Core 0 to this scenery loading effort wouldn't make much difference. That 33% of Core 0's effort could be better spent in giving me some extra Frames PS." It worked. I limit at 20FSP and was getting 15FPS, tops, falling to 8 near the ground (as autogen kicked in?). The first post-tweak flight rode right up to the 20 limit and never fell below 15. The difference was immediate and obvious. Much better. It's really beginning to appear that everything official (the entire .cfg file?) is focused on core 0. The FPS benchies we've seen with the quads vs the duals show only incremental increases because the competing CPUs are All using Only One Core for most of the FPS specific duties. The other (1-3) cores are off in their own scenery loading world. This is starting to make a bit more sense.

>>I know that is the conventional wisdom, but I have to ask you>this, why is it QX9650 at 3.6GHz and Q6850 at 2.83GHz (I>think) show the same frame rates at 1280x, High Quality if the>sim is not now GPU bound with these processors?>>I'd have to see the bechmarks you are refering to. FSX scales quite well with clock speed, as seen here.http://sio.midco.net/FTP4/IMG0019166.JPGFrom this set you can see that going from two to four cores at the same clock speed gives the same frame rate.http://sio.midco.net/FTP4/IMG0021312.gifhttp://www.behardware.com

>>The onboard memory controller will not help RW performance in>the forseeable future. I disagree with this. The Athlons saw a 30% clock for clock performance leap with the on die controller. Intel has even stated the perforamcne leap when going to Nehalam will be larger than the leap from Netburst to Core.The fact the FSB is not a bottleneck doesn't have anything to do with the performance gain you get by eliminating it.

Intel connects the main memory (ram) to the CPU via a memory controller that is currently located on the Northbridge. The Front Side Buss is what connects the Northbridge (and thereby, the main memory/memory controller) to the CPU. The theoretical (and potentially very real), performance increase could come from eliminating that Buss (the Front Side one) that connects the main memory (ram) to the CPU. This is what Intel plans with Nehalem and could really, Really help performance. However, even into the forseeable future, the current FSB architecture provides no memory bandwidth limitations. An onboard memory controller (like AMD and soon Nehalem) and a FSB system will provide identical performance. This is because memory bandwidth is limited by ram's speed capability. it is NoT limited by the buss (or lack of buss) on which that data travels. Therefore eliminating a thing (any thing) that does not limit performance will not increase performance.We have a 100mph race car running on a racetrack that can safely accommodate a car traveling at 300mph. Increasing the tracks capability will not 'cause' that car to go faster. It's been the same deal with the PATA > SATA and AGP > PCI-e buss transitions. These buss transitions were Way ahead of what the users needed (Vcards/HD). And now we have Hypertransport (aka Quickpath). It too, is Way ahead of what ram needs right now. Ram will catch up, but not until beyond Nehalem. This is just the way these guys sell stuff that nobody needs. The fact the FSB is not a bottleneck is Entirely the reason we get No Gain by eliminating it.The articles I've read are saying Intel is (optimistically) predicting 10-25% clock for clock increases with Nehalem. This is nothing near the 100% we got when Intel finally adopted AMDs architecture with the Core2. I sincerely doubt we will get that again. More cores will be the big dog in performance increases.

>I'd have to see the bechmarks you are refering to. FSX scales>quite well with clock speed, as seen here.From http://www.extremetech.com/article2/0,1697,2208253,00.asphttp://forums.avsim.net/user_files/183047.jpgFrom the article:"The oddest result is the Flight Sim X result, which was identical across all CPUs. Note that we did install the Flight Sim X service pack, so we expected some variation