Opinions on this DDR3 1600 for P5E3 Premium

[Mace 1,902]

>>>This stuff is about $390:>>Model >Brand Patriot >Series Viper >Model PVS34G1600LLK I have these exact Patriot sticks you mention.All I can say is, FSX is awesome on my new box.I am now running at 3.8 (9.5 x 400) with stock voltage and zero tweaking done yet. That means, a no-brainer overclock that I could do in my sleep, that's 100% stable. That ram is running right at its spec there and so that's the least o/c I would expect.Keep in mind as of April 08, those Patriot sticks were not on the ASUS "certified" list for the P5E3 Premium. In fact only the Corsairs were, and I was not going to spend $750 on memory at that time.I expect as time passes, more memory sticks to appear on the certified list for the P5E3 Premium...I took a chance on the Patriots building this system, but so far, no compat problems.RhettFS box: E8500 (@ 3.16 ghz), AC Freezer 7 Pro, ASUS P5E3 Premium, BFG 8800GTX 756 (nVidia 169 WHQL), 4gb DDR3 1600 Patriot Cas7 7-7-7-20 (2T), PC Power 750, WD 150gb 10000rpm Raptor, Seagate 500gb, Silverstone TJ09 case, Vista Ultimate 64ASX Client: AMD 3700+ (@ 2.6 ghz), 7800GT

[Noel 4,486]

I think the latency numbers reflect that various wait times in every step of the data request and fetch pathway. One factor that affects wait time is how ready the various components are at the precise moment a request or delivery is potentially available. It seems to follow that components involving an operating frequency, will be generally more available when operating at a faster frequency, BUT, because of syncronization needs, a slightly slower freq could actually translate into more ready states when requests come along. I think this is why the FSB STRAP does what it does, out of respect for syncronization needs that must be considered.So, I would agree, latency is what is important to eliminate. I have to believe though, operating at a faster DRAM frequency, for example, may actually translate into reduced wait states as well. Moreover, faster FSB frequency will, provided syncronization is maintained in the required transaction partners (which it generally must be, ie that's what all the timing controls and strap etc are for), translate into better "system performance."Now what is system performance. I think it's when there are the least wait states . . . ANYWHERE in teh system, provided sync is maintained. Your specific system is "optimized", when latencies are maximally reduced: be it between HDD & memory, CPU>FSB>NB, or MCH>Memory and back again. I look at it this way: in a one hertz FSB, the bus is available to send and receive data once on either end every one second. That means the devices on either side can send or receive, limited by that one/sec availability. Amp that up, and you increase the readiness OF THE BUS to do it's job. Same same for DRAM frequency. Memory that is oscillating faster is that much more ready for the next task.So, in some way, BANDWIDTH is actually partly a function of latency: a higher bandwidth accomdates more IN PART because of lower latency. I think the physical bus hardware must have a maximum theoretical bandwidth or carrying capacity, and I would think what would be hugely over what the practical bandwidth becomes as a result of latencies between every component in the stream.All this is affected also by caches and engineering features that offset the system-retarding effects of latencies in all the transation points. So, Greg's point is very well taken. Sam I am keeping my QX for many years. I have about a 5y turnover rate on PCs. Since I'm in this long, I might as well reduce latencies as much as possible. I think Nick had it right when he said DDR2 is just a little harder to tighten up into the low 50ns latency level, and I def did see improvement to near perfection. Problem is it didn't stand. I think tho, it could have should I have been sharper on keeping the NB healthy.I have 4 x 1GB of OCZ, hardly used, that ran 4-4-4-15 @1050Mhz, for a latency of 52ns or so, at stock vDIMM. I'm going to try for a trade in on some other OCZ, or sell it. I hardly used it. The platform died when I tried to go 1200Mhz on the mushkins, since they had done over 1100Mhz without a whimper. I'll keep the 2x2GB Mushkins with this mainboard.

[Guest D17S]

Excellent, now we're talking tech. This most recient science project seems to prove out the tRD function. Try it. Fire up memset and the Everest memory benchmarker. Run one and note your latency. Now calculate your FSB cycle latency. For instance a 400mhz FSB can only get a data bit on "each end" (well visualized. I like it) of each cycle. Each cycle on at 400Mhz is 2.5ns long. (1 second divided by 400 million is 2.5ns). Now change the tRD (Performance Level) by one (up or down) with memset. Apply. Run Everest again. Note your latency increased (or decreased) almost Exactly one cycle (in my case with the 400Mhz FSB, 2.5ns). It's the first latency change I've been able to understand and thereby directly control . . . and calculate. Too cool! As we all observed, wait states occur throughout the system. We've nailed down one of them. Hacking off latency at 2.5ns increments with a tRD adjustment has gotta be a pretty good hunk-of-it. Only - the rest - to go~! Consider this idea: At a 266FSB, each tRD is worth 3.75ns. See where I'm going? A 266mhz FSB is still plenty to handle all the 1600Mhz DDR memory squirrel-cage spinning we can throw at it. Spool it up, Drop the CAS to -50. Go to town. The latency with a 266FSB and a 400mhz FSB will (should) be the same. However at a 266Mhz FSB, each tRD "increment is worth 3.75ns. Right? Who wants to do the experiment. Someone with an unlocked CPU maybe? Hummm.Notice too only the "Read" number changes (significantly). I believe this is data Out-bound from the ram. The decreased wait-time caused by this lower tRD allows this preexisting data to transfer more quickly because transfer opportunities are available more often (2.5ns more often, to be exact!) "Write" is (maybe) an activity that needs the ram to preform some internal ram-based function and is NoT helped by simply increasing data availability from an external source (the FSB). Da no. Maybe? I can change all the internal ram timings except CAS with memset. Bummer. Gonna have to boot, boot and reboot to check that out. We'll see if CAS has an equally definable effect. This cause and effect dynamic is probably going to be harder to correlate. We'll see."Moreover, faster FSB frequency will, provided synchronization is maintained in the required transaction partners (which it generally must be, ie that's what all the timing controls and strap etc are for), translate into better "system performance."True, but how much? At a 400Mhz FSB a cycle's interval is 2.5ns. At 500Mhz, it's 2.0. We shaved off .5ns. Every little bit helps, but if this player was going to shake up the rest of my crew - even a little bit - , I would Never even let him on the field. Dem's potatoes, but small ones.The effect is SO small that we are not seeing that a "brute force" increased in FSB speed helps anything. A speed change would only have a significant effect if this increase (or decrease) in FSB speed could help Mr. tRD with "sync," aka the Actual bottleneck, Latency. This basic concept of computer science relative to component wavelegnth timing synchronization or "Sync" is misunderstood if applied as a generic, catch-all term. That Really got me suspicious. The experiment I proposed tests this FSB limited theory, If it holds, we can discount the FSB speed as a "faster is better" factor."So, in some way, BANDWIDTH is actually partly a function of latency: a higher bandwidth accommodates more IN PART because of lower latency."I think that's backwards. Increased ram speed Allows lower latency (or is that what you said?). For instance, (so far, I'm understanding) ram speed and timings only allow the ram to (internally) process more data. They are all internal functions that occur in the ram's machinery room. Since the ram is thereby able to provide more data to the tRD "loading dock" tRD might be able to utilize additional FSB "rail cars" (CPU cycles). Ram data is not being backed-up on the loading dock because of a FSB that cannot handle the DIMM's bit-output. The ability to make transfer (latency) is the limiting factor. If tRD was 100% perfect, there would still be a latency because the ram Still cannot process bits fast enough to fully need every cycle. tRD would Then just hang around waiting for the next bit to show up. Now, Mr, tRD can only can use every X cycle, but I'll bet he's Still doing a little "just hangin' 'round" around waiting for the next bit to show up from dem DIMM-boys. "I think the physical bus hardware must have a maximum theoretical bandwidth or carrying capacity, The 400Mhz FSB's carrying capacity is exactly 400Mb/s. There's no mysterious, undefined "theoretical" about it. It is, and only is exactly that. I'm really interested to see where this "quad pumped" electrical dynamic will finally come into play (potentially 4bits per cycle), but I haven't seen it yet. But 1:1 FSB's Mhz/bps is Hard number."and I would think what would be hugely over what the practical bandwidth becomes as a result of latencies between every component in the stream."I agree. The FSB is Not a bottleneck, to anything. "All this is affected also by caches and engineering features that offset the system-retarding effects of latencies in all the transation points. So, Greg's point is very well taken."I agree. These are all going to be pieces of the latency pie . . . but I expect, not the big ones. ". . . low 50ns latency level, and I def did see improvement to near perfection." 50ns is a perfection attainment goal? (Sorry, I wasn't paying really close attention through there. It was all "top down" jabber.) So, I'm just 9ns from a (previously reported) 75% AI/AG/Traffic setting with the PMDG 744 cruzin' at 4000 ft, at 250kts hanging at 50FPS over Heathrow with crisp scenery as far as the eye can see? Really? I dano, but seems to me something else Must be going on ;) .

[Noel 4,486]

>Excellent, now we're talking tech. This most recient science>project seems to prove out the tRD function. Try it. Fire up>memset and the Everest memory benchmarker. Run one and note>your latency. Now calculate your FSB cycle latency. For>instance a 400mhz FSB can only get a data bit on "each end">(well visualized. I like it) of each cycle. Each cycle on at>400Mhz is 2.5ns long. (1 second divided by 400 million is>2.5ns). >>Now change the tRD (Performance Level) by one (up or down)>with memset. Apply. Run Everest again. Note your latency>increased (or decreased) almost Exactly one cycle (in my case>with the 400Mhz FSB, 2.5ns). It's the first latency change>I've been able to understand and thereby directly control . .>. and calculate. Too cool! That IS cool Sam. Way to stick in there and actually try to UNDERSTAND the issues. I don't have the patience! I anjusted TRANSACTION BOOSTER and noticed that, but didn't tie it to the 2.5ns at 400Mhz. Very cool Sam.>Consider this idea: At a 266FSB, each tRD is worth 3.75ns. See>where I'm going? A 266mhz FSB is still plenty to handle all>the 1600Mhz DDR memory squirrel-cage spinning we can throw at>it. Spool it up, Drop the CAS to -50. Go to town. The latency>with a 266FSB and a 400mhz FSB will (should) be the same.>However at a 266Mhz FSB, each tRD "increment is worth 3.75ns.>Right? Who wants to do the experiment. Someone with an>unlocked CPU maybe? Hummm.But FSB is only one variable. If we take the FSB and reduce it to 266, we are decreasing the potential readiness state by 33%. MCH readiness interval can be modulated with MCH read delay or, it would appear, TRANSACTION BOOSTER. Here is my P5E at 266FSB, plus one tRD via Trans Booster:http://forums.avsim.net/user_files/189327.jpghttp://forums.avsim.net/user_files/189328.jpgHere's FSB 266Mhz, but memory bus of 913Mhz, CPU ~4Ghz:http://forums.avsim.net/user_files/189331.jpgHere's FSB of 380Mhz (max this sorry RMA will do), mem bus of 900Mhz, CPU ~4Ghz:http://forums.avsim.net/user_files/189332.jpgIt would seem any time a "readiness state" is occurring more frequently, provided certain sync rules are respected, the lower the total latency between CPU and memory and other players. And then there's the GPU and it's latency of communication with the CPU and memory sub! Oy!>I can change all the internal ram timings except CAS with>memset. Bummer. Gonna have to boot, boot and reboot to check>that out. We'll see if CAS has an equally definable effect.>This cause and effect dynamic is probably going to be harder>to correlate. We'll see.>"Moreover, faster FSB frequency will, provided synchronization>is maintained in the required transaction partners (which it>generally must be, ie that's what all the timing controls and>strap etc are for), translate into better "system>performance.">>True, but how much? At a 400Mhz FSB a cycle's interval is>2.5ns. At 500Mhz, it's 2.0. We shaved off .5ns. Every little>bit helps, but if this player was going to shake up the rest>of my crew - even a little bit - , I would Never even let him>on the field. Dem's potatoes, but small ones.Yes but that is a 20% reduction, no? And you have to appreciate this also has to be a case of how often transaction occur. Put another way, .5ns doesn't sound like much, until you multiply it by a billion transactions that are impacted by it, no?>The effect is SO small that we are not seeing that a "brute>force" increased in FSB speed helps anything. A speed change>would only have a significant effect if this increase (or>decrease) in FSB speed could help Mr. tRD with "sync," aka>the Actual bottleneck, Latency. This basic concept of computer>science relative to component wavelegnth timing>synchronization or "Sync" is misunderstood if applied as a>generic, catch-all term. That Really got me suspicious. >>The experiment I proposed tests this FSB limited theory, If it>holds, we can discount the FSB speed as a "faster is better">factor.>>"So, in some way, BANDWIDTH is actually partly a function of>latency: a higher bandwidth accommodates more IN PART because>of lower latency.">>I think that's backwards. Increased ram speed Allows lower>latency (or is that what you said?). For instance, (so far,>I'm understanding) ram speed and timings only allow the ram to>(internally) process more data. They are all internal>functions that occur in the ram's machinery room. Since the>ram is thereby able to provide more data to the tRD "loading>dock" tRD might be able to utilize additional FSB "rail cars">(CPU cycles). >>Ram data is not being backed-up on the loading dock because of>a FSB that cannot handle the DIMM's bit-output. The ability to>make transfer (latency) is the limiting factor. If tRD was>100% perfect, there would still be a latency because the ram>Still cannot process bits fast enough to fully need every>cycle. tRD would Then just hang around waiting for the next>bit to show up. Now, Mr, tRD can only can use every X cycle,>but I'll bet he's Still doing a little "just hangin' 'round">around waiting for the next bit to show up from dem DIMM-boys.> >>"I think the physical bus hardware must have a maximum>theoretical bandwidth or carrying capacity, >>The 400Mhz FSB's carrying capacity is exactly 400Mb/s. There's>no mysterious, undefined "theoretical" about it. It is, and>only is exactly that. I'm really interested to see where this>"quad pumped" electrical dynamic will finally come into play>(potentially 4bits per cycle), but I haven't seen it yet. But>1:1 FSB's Mhz/bps is Hard number.>>"and I would think what would be hugely over what the>practical bandwidth becomes as a result of latencies between>every component in the stream.">>I agree. The FSB is Not a bottleneck, to anything. >>"All this is affected also by caches and engineering features>that offset the system-retarding effects of latencies in all>the transation points. So, Greg's point is very well taken.">>I agree. These are all going to be pieces of the latency pie .>. . but I expect, not the big ones. >>". . . low 50ns latency level, and I def did see improvement>to near perfection." >>50ns is a perfection attainment goal? (Sorry, I wasn't paying>really close attention through there. It was all "top down">jabber.) So, I'm just 9ns from a (previously reported) 75%>AI/AG/Traffic setting with the PMDG 744 cruzin' at 4000 ft, at>250kts hanging at 50FPS over Heathrow with crisp scenery as>far as the eye can see? Really? I dano, but seems to me>something else Must be going on ;) .Yeah, I do think so Sam. It's a def reason why I am going down this (insane) road of starting over again with a DDR3 platform. I think had I been able to comfortably maintain 52ns, I would def have been one happy camper. The 62.3ns is all that will come out of this RMA P5E. And dang, the other BRAND NEW one that arrived turned out to be DOA! SO now I'm sittin with an RMA'd P5E that is just plain crippled versus P5E #1. My first board AND BOTH sets of memory, as it turned out, were extraordinarily excellent. I wish I knew exactly how the sucker got hosed. I ran the thing at 1050Mhz, FSB 438Mz, DDR2@1060 @ CAS-4, and that translated to 51.8ns, and a racey CALWI score as well. It really was optimized, i'm convinced, despite my own scepticism. I'm struggling with the memory selection. I DO NOT want to deal with modules that just won't do SLIGHTLY overclocked performance: CAS 7 @ 1640 minimum (FSB orf 410). On the other hand, I can't see buying $650 Corsair guaranteed to do that. I really want to put it behind me, and do at least as good as 51.8ns, and I'm thinking that should be very doable with the P5E3-PQX9650 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]

"But FSB is only one variable. If we take the FSB and reduce it to 266, we are decreasing the potential readiness state by 33%. MCH readiness interval can be modulated with MCH read delay or, it would appear, TRANSACTION BOOSTER. Here is my P5E at 266FSB, plus one tRD via Trans Booster:" Note the 266 FBS is capable of generating the same performance (latency) as an 800 Mhz FSB. What we're doing is just using more of the FSB's capability at 266. This allows a good comparison.Your run is at a 266Mhz FSB with ram spinning at 800Mhz. My attached run is at a 400Mhz FSB, with ram also spinning at 800Mhz. The question becomes "Does a 266Mhz FSB have the capacity to provide the same performance as an 800Mhz FSB?" It appears the x38 allows a Good drop in tRD. (My P35 locks at a tRD of 5). That really helped demonstrate this dynamic. With the 266Mhz FSB, the AC cycles (rail cars zooming by the Newegg warehouse) are moving more slowly, but our loading dock master (tRD) is able to maintain our rate of transfer (Latency) by using more closely spaced cycles. What does this mean?What we are seeing here is a very Clear demonstration of the transfer capacity of the FSB. Even at 266Mhz, there is still Huge headroom. A tRD of 3 means we are using every 3rd cycle, right? Think about what this means. We Still are only using 1/3rd of capacity of the FSB . . . - even with a 266Mhz FSB. If we could get tRD to zero, a 100Mhz FSB would be PLenTy. Woah! Nice run.http://forums.avsim.net/user_files/189334.jpgThe second run is at a 380FSB/912Mhz memory speed/unknown tRD. Drop the tRD until it locks. if you are starting at 62ns, there still might be hope for the board. "It would seem any time a "readiness state" is occurring more frequently, provided certain sync rules are respected, the lower the total latency between CPU and memory and other players." I agree. In this order 1) tRD : 2.5ns per click at a 400Mhz FSB. Hard number. Can be calculated. Take all you can get. 2) Memory : What's gonna be worth what? Timings do what? RPM does what? This is the next frontier. 3) FSB : Each 100Mhz increase is worth .625ns. (Half of one billionth of a second. 'Bout that?) Hard number. Can be calculated. Big Yawn!"Yes but that is a 20% reduction, no? And you have to appreciate this also has to be a case of how often transaction occur. Put another way, .5ns doesn't sound like much, until you multiply it by a billion transactions that are impacted by it, no?"No. it's Not 20%. We are working on the - additive - latency number. A .5 reduction from a 60ns latency is .08%. Points is points, but at what cost? That guy had better be causing me No trouble at all . . . or he's on the bench! That 62ns latency sounds about right if the tRD is stuck somewhere high. I'm getting the feeling that we are going to find it takes Big ram clock bumps to get little tiny latency decreases. Jury's still out on that one. But that 900Mhz ram-speed likely, is not a big contributor. That 380 FSB limit is the concern. You might try warranty-ing that CPU. I believe the X38 is actually rated for the new 400 mhz CPUs. Yes? I'm thinking CPU. Let 'em try to send ya a reconditioned one a dose. Keep your power dry for a week. Comdex is on and Intel is throwing Nehalem a coming out party. If Quickpath and that onboard memory controller can get tRD to ZERO, we be rockin'. Is this fun or what?

[Guest D17S]

And speaking of a 266Mhz FSB's available headroom, check this out: http://www.nehalemnews.com/2008/06/sightin...th-nehalem.html"On our (Nehalem/x58) platform that featured triple channel DDR3, the processor multiplier was locked at 22 with a QPI bus setting of 133 to generate the 2.93Ghz CPU speed. Memory was running at DDR3-1066 with ratios available for 1333, 1600, and 1866" (Anandtech).QPI is QuickPath Interconnert, the New FSB . . . running at 133Mhz and slated to work with memory speeds of up to 1866Mhz. Looks like they got that loading dock thingie (tRD) figured out.

[Guest Nick_N]

I was not going to post anymore on this subject however I will close my involvement by saying thisand as requested, its not directed at anyone...We are thinking 2 dimensionally here. We are not taking into consideration the Intel microarchitecture or their algorithms, we are assuming strictly based on the logic of basic electronic and computer theory and are also not taking into account the application and how it addresses the systemAll these mistakes can lead to assumptions that FSB does not matter, latency is not worth going for, a Raptor is not faster than any other drive in application, and AMD memory bandwidth and latency proves its not the factor with Intel that makes a difference.The bottom line is without an intimate knowledge of how the current system works, and, how the application makes use of it, we are making suggestions based on lack of information and is just plain guessing. As I posted several times.. FSB will no longer present a factor when Nehalem is released. That platform does away with the main problem and at that point using FSB as we -now- do to tickle the current northbridge technology to work as closely in concert between the memory and the processor as possible

[Guest D17S]

So far, I am considering that the memory read/write/copy numbers are all memory module "machine room" functions that provide the memory's product , i.e., a data bit available for transfer. The more often the ram module can make a data bit available for transfer, the more often it will be able to 'catch a ride' on the FSB express. This (might be) the mechanics of how adjusting ram RPM and timings can decrease latency. These read/write/copy numbers are (might be?) just indicators of how - quickly - the memory module is able to process data . . . but we Still do not know how long it actually takes the ram module to process a bit. But consider: We - Might - surmise that, 1) Since each notch of tRD represents one FSB cycle (and is a clear and calculate-able component of latency), 2) The rest if ram based3) . . . but we don't know this. Maintaining the position that other factors are in play is prudent . . at least at this point. However it is difficult to recognize that increasing latency - in any case - can increase performance.I ran some timing and RPM comparisons. I observed that Latency is definitively effected by changes in the memory module's 'machine room' processes of timing and ram RPM (remember we already did FSB and tRD). This presents a potential opportunity to actually predict latency at any memory speed/timing/FSB/tRD combination (We'll see). But let's digest all this first. (Nick_N: Your constructive comments are More than welcome. But this tendency toward name-calling and crude retort Must stop.)

[Guest Nick_N]

I have no idea what

[Noel 4,486]

>The second run is at a 380FSB/912Mhz memory speed/unknown tRD.>Drop the tRD until it locks. if you are starting at 62ns,>there still might be hope for the board.That was it Sam. No tRD drop was doable (probably according to Anand's predictive formula). I had done it but didn't bother to post it:http://forums.avsim.net/user_files/189372.jpg>1) tRD : 2.5ns per click at a 400Mhz FSB. Hard number. Can be>calculated. Take all you can get. Sam, I'm thinking tRD (MCH Read Delay) counts cuz it's operating potentially 4 times for every fetch & deliver, no? If your machine can tolerate DECREASING by one clock cycle then it's a 4 for 1 impact. This, of course, is pure conjecture, since I only understand bits n pieces of the whole thing. >2) Memory : What's gonna be worth what? Timings do what? RPM>does what? This is the next frontier. >>3) FSB : Each 100Mhz increase is worth .625ns. (Half of one>billionth of a second. 'Bout that?) Hard number. Can be>calculated. Big Yawn!OMG Sam, but it's these numbers, x billions of transactions, no?>That 380 FSB limit is the concern. You might try warranty-ing>that CPU. Sam, the CPU can tolerate an FSB of 440 no probleme. It's this refurbed P5E that can't handle it. I ran my first P5E at FSB 438 or a little higher. I think it's really not about what the CPU can "handle." It's more about the POST read of CPU default FSB & memory SPD, the the strap & dividers available. The QX9650 runs with any FSB your mainboard & memory can work with. This is my understanding anyway.>Keep your power dry for a week. Comdex is on and Intel is>throwing Nehalem a coming out party. If Quickpath and that>onboard memory controller can get tRD to ZERO, we be rockin'.>Is this fun or what? It is, but once I have a stable platform, I will be checking out of the world of continuous upgrades. I have historically kept with about a 4-5y upgrade cycle. Despite the theory behind it, I do truly believe I saw a signficant move in FSX performance from ~86-88%% to 98% of perfection when I was doing latency of ~52ns. Don't forget, I had a chance to run those specs for several weeks before we got greedy. I think it was the NB personally. I have also clearly verified to myself, changing my current set up to latency score of 70ns makes worlds of difference versus 63.9ns which is almost the best this mainboard (and either memory set) will do. So, I'm hopeful it makes sense to move to the DDR3 board. I got some bucks tied up on my processor, which runs cool n fast.

[Guest D17S]

Each click of tRD reduces latency by exactly one FSB cycle. Major premise (as always, "?"): -- I believe the rest of this measured latency might be electricity (data) just rattling around inside the memory module. The module has gotta spin all kinds of cranks and levers to find the data. To accomplish this task, it is uses its tool box of DDR speed/CAS/RAS/ETC. Then it has to get that bit to the memory controller. The memory controller then employs its tool, tRD. The data bit is therby scheduled for the next available FSB cycle. If we drop the tRD by one cycle, the next cycle will be exactly one FSB cycle sooner. "Latency" will be (accurately) displayed as one FSB cycle quicker. -- I don't think - Any - part of the latency measured here is part of the CPU cache. That latency is included in the 2nd and 3rd row's numbers and I don't think it's included in the top-row latency number. The stopwatch starts when the request is actually issued from the CPU. The stopwatch stops when the CPU gets the requested data bit back. The time-in-transit = The Speed of light / 6 inches of mobo trace = nothing. 186K mile-sec/some darn thing? I don't think that many zeros have been invented. >2) Memory : What's gonna be worth what? Timings do what? RPM>does what? This is the next frontier.Here's how the "Control Knobs are stacking up: -- RAM Control Knobs:1) Each CL increment is worth ~ 1ns2) Each RAS/CAS Read delay increment is worth ~ 1ns3) RAS/CAS Write dalay will not adjust in memset (Maybe later). 4) RAS Precharge does nothing5) Precharge delay does nothing6) Each 100 Mhz of ram clock is worth ~ 1ns.-- tRD: 7) Each tRD increment is worth one FSB cycle-- FSB: 8) Each 100Mhz is worth .625ns. -- NotesI know the FSB and tRD are solid numbers, but I haven't 'run the numbers' against posted benchies with the Ram Control Knob numbers. But consider for just a quick look: We've got a 45ns latency at a 1800Mhz ram-buss posted above. I'm running OK at 60ns with an 800Mhz buss. That 1800Mhz stuff would get a 10ns lead on my 800 stuff (1800-800=1000. 1000/100=10ns). This would bring the latency from 60ns to 50ns. Then a couple of extra clicks of tRD gets it to 45ns. I really think this is going to be in the ball park. Geeze Louise, How hard did this have to be?!! "OMG Sam, but it's these numbers, x billions of transactions, no?"True. We are just monitoring the pump. The flow this machine can produce is virtually beyond imagination. We need to 'leave it there' for now. Personally, I'm dizzy enough as it is (ahhh, is there a good way to be dizzy? I forget). Little steps. I just got a cross-shipped P5K from Asus today for my on-board sound chip problem. Haven't changed it yet so I've been beating my old board unmercifully. Been running my NB at 1.7 volts all day. (Shame on me!) What a trooper. It was no problem at all really. Just horsing around, I ramped this little ol' P35 up to 460mhz. Booted right up. That P5E Sounds fried. But your warranty should be good up to 400mhz. "It is, but once I have a stable platform, I will be checking out of the world of continuous upgrades. I have historically kept with about a 4-5y upgrade cycle." Me too, generally. Just got caught-up in this last cycle. I generally wait for a 10X improvement. Nehalem's not going to be it, that's for sure. I've got down to ~ 55ns. But the rig's finicky down there. Although now that I have control of this thing, I should be able to dial in whatever latency I want. I'll be doing runs at various latencies. I'll let you know how it goes. Sorry 'bout the noise. I'll learn.

[Guest D17S]

Anand stole-away a Nehalem for some secret testing: http://www.anandtech.com/cpuchipsets/intel...aspx?i=3326&p=547ns. Ho hum. The 'tuneup' better do some magic. I can get ~ 56ns with DDR800 on a P35. Those 4 extra CPU threads (7-3), might just help scenery loading. There appears to be no single core breakthrough here. Come-on FS11.

[Noel 4,486]

>I've got down to ~ 55ns. 55ns is pretty dang good Sam. But this wouldn't hurt anything . . . but yer wallet:http://forums.avsim.net/user_files/189404.jpgI'm just concerned about how to run the FSB on the P5E3-Premium to 450, let alone 466. The P5E3-P is supposed to do 1800 OC or even 2000 OC, is this implying by using an FSB of 450? Can't seem to find anything on that question of exactly what the BIOS is doing in AUTO, when for example the FSB is increased, but no other manual changes. My understanding is that the BIOS will tweak timings etc to essentially loosen timings to accomodate high bus and mem frequencies."Memory Standard: DDR3 2000(OC)/1800(OC)/1600"

[Guest D17S]

Oh come-on, go somemore. Nothing's caught fire yet. Tweak down tRD and you've probably got as good as Nehalem will ever be. Too early to tell really, but that initial report was tragic. I wanted to see < 20ns. < 10ns, actually. That 1800/2000 sounds like the "Quad Pumped" number. Out in the Best Buy world, no one knows anything else. When I talk about a 266Mhz FSB, they go, "Like no way dude. It's a 1066Mhz FSB." They don't realize that 1066 is Not Mhz, but a theoretical potential to carry 4 bits per cycle. (266Mhz x 4 = 1066 bits per cycle). If anyone speaks of a 2000Mhz FSB, just smile . . . then divide by 4.In auto the bios will: 1) Set the FSB on the basis of the instruction recieved from the CPU. 2) It will then strap - or select, then set - a tRD appropriate (in its little bios brain) to that FSB. 3) It will also set ram timings based on the instructions received from the memory module. 4) Boot 'n Run. In semi-auto (if you take control of the FSB, the bios will look at whatever FSB speed you have selected and "strap" - or again, select, then set - a tRD appropriate (in its little bios brain) to that FSB. You would be driving memory too, so the Bios may receive an instruction from the ram to loosen-up. There's no need to goto 450. Don't do it. Use CPU multis and memory dividers to get the clocks, then tRD and memory timings for the rest. Remember, a 100Mhz increase in FSB is only worth .625ns of latency. Leave it at 400. Every 100Mhz of ram speed is worth 1ns. As the FSB increases, the bios will automatically use a higher and higher tRD. tRD is Exactly what WE have been manually Setting Back Down to get shave off Big chunks of latency. Ram timings and increased memory clock speed helps too (review the previous post), but tRD is the big dog. It seems that the NB can generally operate at a Much lower tRD than its Bios supervisor might apply. This ability to operate at a lower tRD is suggested as the - Real - advantage of the X38/48s (Heck, my P35 will go to 460Mhz and a tRD6, but marketing is marketing!). It might take a bit of extra NB volts to allow the NB to accomplish a lower tRD, the that's the deal. It's been called "Overclocking the NB." We are not making the FSB run faster, we are manually forcing the NB to use FSB cycles that are spaced more closely together. That's called tRD and that tRD'in is pretty hard hard work, I guess. Take control. "Memory Standard: DDR3 2000(OC)/1800(OC)/1600"Or was your question about this? (Of course, that means that this ram is rated to run at 1600Mhz (400Mhz FSB at a 4:1 ratio) or with various memory dividers (multipliers, actually) up to 2000Mhz. These are all memory speeds.)

[Noel 4,486]

I've already decided to go with some moderately priced 2x2Gb modules that appear good enough for my purposes. I've poked around and on a P5E3-P people have been able to oc these up to 1800 or more if they so choose. I plan on keeping the CAS 7 and bumping up as far as she'll go comfortably, which I'm certain (after talking with mushkin) will go to 1680 *virtually* guaranteed at that CAS rating, with an FSB of 410. Should be pretty easy to do. Anything beyond that will be bonus, but I won't be overvolting the memory. The modules I'm buying are:Model Brand mushkin Model 996601 Type 240-Pin DDR3 SDRAM Tech Spec Capacity 4GB (2 x 2GB) Speed DDR3 1600 (PC3 12800) Cas Latency 7 Timing 7-7-6-18 Voltage 1.8V - 1.9V Heat Spreader Yes I'll be amping up tRD as much as it will allow, increasing NB voltage or MCH voltage whatever the BIOS has to a safe level. I've become rather cautious, and even after a lovely fly tonight with mush at 951Mhz, FSB 380, CPU 4.07 or so, it was a very nice and smooth flight. This config only does 62.8ns tonight. It's maxed with this particular mainboard. I think the new platform will do close to 50ns, which I am certain, is good 'nuf.