RAM type/speed for new system

[Guest D17S]

I really think we are in the realm of only subjective, undefinable improvements in FSX by means of memory subsystem optimizations. The subjective improvement descriptions have been mainly centered around scenery loading capability. My favorite check-out run is in the PMDG 744X at 4000', starting directly over the Statue of Liberty, then proceeding up the Hudson. NYC at it's finest. My "benchmark" is to assume a view directly above and behind the 747, then watch where the scenery pops into max resolution relative to a wingtip. There's just no way to quantify that. I've been unable to acquire any improvement by any memory subsystem tweak . . . with my admittedly plebeian setup (Q@3.6/4G-O-800). I'm afraid the big picture for FSX is that mainstream hardware is just not there yet. The Nehalem/Quickpath platform is debuting this week and that promises to "mainstream" the improvements that have been achieved here by the Big Dogs. The problem is that these 'pre-released' improvements really didn't do much. We'll just have to wait and see what Nehalem/Quickpath brings.

[Noel 4,483]

>I really think we are in the realm of only subjective,>undefinable improvements in FSX by means of memory subsystem>optimizations. I think you can sort of define them, though without ascribing numberical values to subjective impressions it would be hard to measure the effect of optimizations.How do you benchmark smoothness? It's really lack of the slightest hesitancy, lack of stuttering, fluidity. These are things one can get the sense of very quickly, but again, hard to quantify.How do you benchmark visual clarity? I guess the presumption is that texture loading can negatively impact smoothness. Not sure what other things could affect smoothness. I'm guessing there are several other points along all paths . . .I think I settled this when I began to define "performance" as:1. "Adequate Frame Rate" to eliminate choppy repaints (seems to be around 25 or more)2. "Smoothness", defined as fluidity, lack of hesitation or stutters.3. "Image Clarity", defined as textures maximally detailed as far out as the game and settings will allow.In the subjective/anecdotal realm, I'm happy using "% of Perfection", in each category. 100% perfection in IQ, is just that: all textures displayed maximally within the confines of FSX.cfg or background programming. 100% Smoothness = Zero perceived stutter or hesitancy, maximum fluidity, etc.So, in this regard, the quasi quantitative approach (made much better by double-blinding the player), would be a very decent test of this entire question. Now, run something like Nick's testbenchmark. See how participants score using a percentage, with 100% = perfection.I believe the lower latency system got me a combined score of about 98%, versus 86% or so with the 62.8ns latency. Pure anecdote mind you, without the proper double blind experiment. Now THAT would be fun Sam . . .>I'm afraid the big picture for FSX is that mainstream hardware>is just not there yet. But that truly depends on the situation. If you mean by this, FSX is just not there *when one tries to run a PMDG 747X* (or perhaps another payware equally complex), then perhaps that's true I don't know since I didn't try when this thing ran as it should. I do know for certain, optimized to 52ns, 4GB of ram, 4GHz+ CPU clock, with all the typical addons but with default aircraft, the hardware was there in spades.

[Guest D17S]

I can run memory latency between ~ 56ns and 77ns just by ramping tRD with memset (Performance Level from 6 to 14 with a 400Mhz FSB). . . - while the sim is running -. Try it. Pretty cool. I tried my PMDG 744X and then the Lear (it's got an autopilot I can deal with). There is huge FPS difference between the planes. The 744 simply pegs core 0 at 100%. With the Lear, core 0 just lopes along. Cores 2-4 stay hopin', but run independently of any core 0 action. The sim is running on the 42 at 19x10, and I'm watching/running the technical action on the two, 19s. So far, I can't tell a difference in (core 0 based) FPS with the 744 with with latency changes. I always leave all of the scenery tab's - Left side sliders - full up ('cept water, a notch down) With GE/UT/Genesis, the scenery loads look the same with either airplane. It appears that's all being taken care of by cores 2-4. Again, I can't see any difference with latency changes. From an outside view ~ 50 yards above and behind the airplane, max resolution pops-in right behind/under the horizontal stab, no matter what latency adjustments I make. With the Lear, I have sooo much core 0 Horsepower left, I needed to cap the frames at 30, then turn on some traffic. At a 4000 foot cruise, GE really makes autogen obsolete, so that stays off. With the core 0 maxed out with the 744 or just loping along with the Lear, either scenery or frames, I can't see any difference. What are you looking at?

[Noel 4,483]

GE really makes autogen obsolete, so that>stays off. With the core 0 maxed out with the 744 or just>loping along with the Lear, either scenery or frames, I can't>see any difference. What are you looking at? Sam, I am using GEX. Where is you AUTOGEN slider set?I am looking at frames, smoothness, and image clarity and detail. I rate 62ns at 86% of perfect in smoothness and IQ, and when I had it running for a few weeks at 52ns, I rated the change as closer to 96-98% of perfect. I think another issue Sam is that with lower latencies, overall "performance" is going to improve. By how much, is arguably the question. This is why it would be great to do a double blind experiment looking at users rating performance scores. That would settle the discussion in a reproducable way, if it was designed well.QX9650 w/ Retail HSF|8GB Muskin PC-6400|ASUS P5E|EVGA 8800GT @700|Seagate SATA 2 x 4|Seagate Cheetah 15K.x|XP Pro|Vista 64--soon to be installed

[Guest D17S]

I with GEX, I leave AG and all traffic completely off for the 744X. 20FPS is a miracle down town, gets better up the river. With the Lear (default airplanes), 4x3.6Ghz/~ hi-50ns can handle the FSX "canned" Ultra High ('cept water down one notch) with frames bouncing through the 20s. Starts touching the 30s up the river a ways. Scenery loads at highest resolution. What's all this "crispness" stuff? Highest res is highest res. Is there something better than that? Looks Very "tight" to me. My benchie starts over the Statue of Liberty and proceeds North up the Hudson. 4000 feet at 220 knots. They're actually making an airport outa Stewart (IRL). Used to be just an old freight-port. Tried out the runway as a drag strip, once (in the ol' rental Firebird). Great HoJo's (was?)there. Driving up from JFK (Got FSGenesis?), those Hudson cliffs are For Real. That's a good destination.I agree, it's just too close to call . . . for anyone else. A turbo-charge of 20ns of reduced latency might be a bit like fueling up my car with midgrade gas after running regular for a year. I can tell, but I'd be hard pressed to convince anyone else. But for the hobbiest in us all, this is really quite interesting. I've been playing around with the ram latency control levers a bit and these observations seem pretty close: 1) Each CL is worth ~ 1ns2) Each RAS/CAS Read delay is worth ~ 1ns3) Each RAS/CAS Write delay does nothing (but I believe Everest only monitors outbound or -read- traffic). 4) RAS Precharge does nothing5) Precharge delay does nothing6) Each + 100 Mhz of ram-buss clock is worth ~ 1ns.And then the Big Dog tRD:7) Each increment is worth 1 FSB cycle (For instance 2ns @ 400Mhz) So, if someone wants to figure out what latency new sticks or settings will yield, just add (or subtract) from what a user has now.For instance, 800Mhz at 4-4-4-12 gets me better latency than ~ 980Mhz at 5-5-5-15. Here's the math (and it worked). The extra ~ 100Mhz (at ~ 980) nets me -1ns, but I net +2ns because I have to drop CL and the two tDelays. I loose 1ns. 800's more stable anyway and I can run at its rated 2.2v 44412. The O/C meant nothing. Now, I get 1066 that can run at 44412 and I get the keep that 1ns (or I drop to 667 ram and loose 1ns?) Stop the madness! I think that "HotSpot" we kept hearing 'bout might have been about getting 2ns for each CL drop. Haven't looked at that CAWLI (?) concept yet. What was it supposed to do anyway? I forget. Also notice the ram is using the same "tool" for internal data transfer as the Northbrige. The Northbridge calls it: "FSB to RAM Read Delay" (or tRD). The Ram Module just calls it: "RAS to CAS Read Delay," "RAS to CAS Write Delay." I'm sure these numbers represent cycles too, only ram-buss cycles. What'dya know.

[Noel 4,483]

>I think that "HotSpot" we kept hearing 'bout might have been>about getting 2ns for each CL drop. Haven't looked at that>CAWLI (?) concept yet. What was it supposed to do anyway? I>forget.The CAS Access Latency Window of Interest is the range of latency where Nirvana in FSX is possible Sammy. 980Mhz at CAS 5 gets you CALWI value of 10.2. This is a sad place in Existance where there is nothing but constant pain and wanting, frustration and despair, even though it may SEEM like true happiness abounds, especially in FS9. With my awesome and cheap OCZ DDR2 800 running at CAS 4 @ 1050Mhz, I was in the hallowed CALWI zone of 7.6ns. I saw the Buddha clearly (somewhere while flying over New York I think) while I had this dialed in. No more reincarnation! Yes! Here is the read about this again, sans illustrations. In the end, CALWI appears mainly to be a concern for those wanting to get a good balance between memory performance and locked-cpu overclocking performance:The Effect of Memory Frequency on CAS LatencyFigure 1 provides a graphical representation of how CAS latency, represented in nanoseconds (ns), changes as memory frequency is varied. Of course, the location of the jump discontinuities (vertical step increases in CAS latency) are entirely dependent on the minimum CAS latency of interest. Calculating CAS latency is in fact, simple - the formula is shown below - be sure to use DDR memory speed (MHz) and not base memory speed. Study has shown that that regardless of memory speed and CAS latency specification that Value Series memory is usually binned for 10.5 - 12.0 ns of CAS latency, Mainstream memory is often about 8.0 - 10.5 ns and Performance Series memory can be found to be as low as 7.0 - 8.0 ns. Knowing this, it can be surprising to realize that what may appear to be an insignificant decrease of as little as 2.5 ns of Column Address Strobe (CAS) access latency can end up costing the consumer as much as an 80% premium per GB!Mathematically, calculating CAS latency from CAS selection and memory frequency (remember, use the DDR specification frequency, not the base memory speed) is easy. This simple expression, Equation 1, is all that's needed to form graphs like those of Figure 1 and Figure 2.In Figure 1 shown below, the minimum CAS latency of interest is established at 7.5 ns (with a maximum of 8.5 ns) - meaning that whenever CAS latency reaches this value the CAS is increased by one (instantaneously and dramatically increasing the true CAS latency). We then investigate values from 7.5 to 8.5 ns - this frames our target memory overclock window (shown with green arrows). The red arrows draw our attention to windows of relatively lower memory performance (with respect to access latency), or areas of memory operation where given the memory frequency and CAS data pair we would be unduely limiting the memory's performance potential. The tighter we make our "CAS Access Latency Window of Interest" (CALWI) the smaller each "Target Operation Band" becomes (and the larger each "Reduced Memory Performance Band" becomes).

[Guest Nick_N]

Now you are looking in the right directionThere are 4 major players in this type of tuning1. Memory2. Memory controller (northbridge)3. CPU microarchitectures or designs4. The application itselfTo briefly touch on each and summarize the result and whyThe main problem with FSX (and even FS9 due to the engine design) is its dependency on the CPU. We actually have all the

[Guest D17S]

OK, that's not so hard. It appears that what I observed with an optimized CL latency was - in fact - it's final result. It does make sense . . . and a difference. These CL, CAS , RAS, Etc are all just internal ram module processes that allow freight (data) to be provided to the loading dock (the northbridge) more quickly. If more freight is available on the dock (the northbridge) the loadmaster (tRD) has a better chance of getting it aboard the FSB express. That's it. The Everest latency number decreases by an additional ns or 2. ThaT'S iT.The final result of all this is CAWLI stuff is to allow a smidgeon less FSB < > Ram buss latency (and I mean a scoch, ~ 1ns? ). Great! We Hobbiests need to take 'em where we can get em, but there's nothing helpful for Flight Simmers here. (Stand clear. The range is Hot).

[Guest Nick_N]

Memory = warehouseNorthbridge = loading dockCPU = Main Office where orders are taken and then executed/filledCustomer = FSXOrdering System = Intel's hardware and software technology on one waferIf weA: Get the stock to the loading dock to and from the warehouse fasterandB. Get the loading dock to perform its job, much, much fasterandC. Main Office is giving the warehouse orders they have not even gotten from the customer yet, but will.Then the Main Office has the order all ready in their

[Guest Nick_N]

> with Nellie, that SiO2 and polysilicon property change begins. Clarification..With Nehalem they start taking true advantage of that design change because they need the memory controller moved to the CPU to kick the new program into gear correctly.. the TOCK after the TICKAMD jumped the gun on moving the NB to the CPU and that jump netted them a 'positive' result which only lasted until something came along which showed their processor was not as 'hot' as it originally looked.. that was the C2 and software like FSXAMD was riding a wave... but like all waves, it crashed.. unfortunately before they could do what Intel did and make use of the memory controller in the CPU. In that, Intel decided not to do what AMD did and put the cart before the horse and then figure out later how to make it work... Intel did that before making the move.http://www.intel.com/technology/quickpath/demo/demo.htmhttp://www.intel.com/pressroom/archive/ref...per_Nehalem.pdf

[Guest D17S]

So far, we're just trying to understand the loading process. Right stuff, wrong stuff: A box is a box and we don't care (yet). The entire discussion (so far) is focused on simply the loading function. The backroom's operation that not only gets a box on the dock quickly, but the right box, at the right time (even ahead of schedule) could be a PiVitoL component to the overall system's function . . . but it has nothing to do with "latency" (i.e., This dock loading function we are trying to optimize via this ridiculously clumsy tool in Everest's memory latency benchmarker). This performance enhancing dynamic that optimizes request events sounds like it really could be an important function, - but it will only utilize the available latency more efficiently - . We haven't left any thing out, cuz we're just not there yet. Stop criticizing we less inviolable for lagging behind. Stop jumping ahead. LITTLE STEPS.

[Guest Nick_N]

LOL!>Stop criticizing we less inviolable for lagging behind. Stop jumping ahead. LITTLE STEPS.SorryIt is never my goal to criticize Sam.. but I do get frustrated because this has been an ongoing