Archived

This topic is now archived and is closed to further replies.

Noel

Opinions on this DDR3 1600 for P5E3 Premium

Recommended Posts

Since I don't plan on more than a 410 or so Mhz FSB, what do you think of this stuff at $255? Won't be 1T, but timings are good and this would be a modest overclock.Model Brand OCZ Series Platinum Model OCZ3P16004GK Type 240-Pin DDR3 SDRAM Tech Spec Capacity 4GB (2 x 2GB) Speed DDR3 1600 (PC3 12800) Cas Latency 7 Timing 7-7-7-24 Voltage 1.9V Heat Spreader Yes Features 1.95V EVPPlatinum Z3 XTC Heatspreader Recommend Use High Performance or Gaming Memory ------This stuff is about $390:Model Brand Patriot Series Viper Model PVS34G1600LLK Type 240-Pin DDR3 SDRAM Tech Spec Capacity 4GB (2 x 2GB) Speed DDR3 1600 (PC3 12800) Cas Latency 7 Timing 7-7-7-20 Voltage 1.9V Heat Spreader Yes ---------This stuff is only $650. Since I'm not doing alot of o'c on this, probably not much point in this Corsair.Model Brand CORSAIR Model WIN3X40961600C7DHXIN Type 240-Pin DDR3 SDRAM Tech Spec Capacity 4GB (2 x 2GB) Speed DDR3 1600 (PC3 12800) Cas Latency 7 Timing Intel XMP SPD Certified Profile 7-7-7-20 Heat Spreader Yes Manufacturer Warranty Parts Lifetime limited Labor Lifetime limited Thanks in advance for your input,Noel

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Try and find some test reports on the memory your listed.

Share this post


Link to post
Share on other sites

Noel,I'm using the Patriot Viper with my P5E3 Premium. Works just fine with the motherboard no issues at all.

Share this post


Link to post
Share on other sites

Thanks Sarg. Are you able (or have you tried) to run at 1640Mhz and retain CAS 7 timing?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

Share this post


Link to post
Share on other sites

Sarg, can you run a Everest latency and read benchmark? Thanks alot in advance if you can . . .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

Share this post


Link to post
Share on other sites

Sarg, do you mind running an Everest latency and read benchmark on your rig? Much appreciated!Noel

Share this post


Link to post
Share on other sites

That's good nuf for me. I do wonder tho a few posters, I think the majority (of a small sample) said it wouldn't do CAS 7 if I recall. If it did CAS 7 I'd go for it at price.

Share this post


Link to post
Share on other sites

Sam, I have a P5E3-Premium coming, and it needs DDR3. I know, I went for it. A 4th P5E I can't stomach!Sarg's OCZ is *only* $255. The Corsair Dominator DDR3 1800 2x2 was in 3 locations yesterday at $525, and is all sold out as of this morning. Yes, it has gotten way out of hand for me. I am determined to see 1640 @ CAS 7, and tRD of 6 or whatever works. If I have to cough up $550 I will! Makes perfect sense to someone who coughed up for a QX processor, no? I still have zero clear advise on where to go with vMCH. Just vague generalities ("you have to increase vMCH when you up the FSB etc etc). I will try consulting with multiple parties at Corsair and the other memory people, and do some more reading about that. One thing I also have gotten no clear answer on is what my BIOS does when you set, for example, NB voltage to AUTO. Does it scale up with demand? Or is it the same as default? I know with vCore it doesn't scale up. Anyway, probably have to call ASUS and see.

Share this post


Link to post
Share on other sites

This is my ol' DDR2-800 about maxed out. This is 4, 1gig sticks too. My P5K-e does not allow me to directly see tRD. I can only adjust it in increments of -1, -2, -3. I found the -3 won't run, even at a Northbridge voltage of 1.7v. It would be Very handy to know what my actual tRD was. Latency is additive. If I knew what tRD number I was using, I could calculate it's contribution to the latency pie. I could then know what "the rest" was. That might be helpful in isolating other player's latency contributions. Consider: If Anand's description of tRD of 12 being typical, the tRD's crossing latency is worth 2.5ns (at a 400Mhz FSB) times 12, or 30ns. If I could get rid of the crossing delay, I could reduce my latency by 30ns. Gentlemen, that's a BuncH. 50% for me. I expect Nehalem's QuickPath is a LoT about that. This and the previous 800MHz run (at 4-4-4-12. Yes, I goofed the text) is at a setting of -2, with NB volts at 1.55v. http://forums.avsim.net/user_files/189274.jpgSo, how much difference does tRD make? Look at this: http://forums.avsim.net/user_files/189275.jpgAll I did was reset turbobuster (or whatever they call it) to Auto. What a difference. My arithmetic tells me I lost 3 FSB cycles. (2.5ns x 3 = my latency loss of ~ 7.5ns). If Anand is correct, my tRD increased by three. How about that. That tRD explanation might have just proven out. It's pretty close, actually. Does that mean that at a 400Mhz FSB (aka, 2.5ns per cycle) each notch of tRD will reduce latency by 2.5ns? That supertuned northbridge in the X48 may be worthwhile. 6 notches of tRD is worth 15ns of latency? Hummm. Try it. Now look at the tRD's effect on the rest. Read ramped, Write didn't budge and Copy only came along. What's up with that? I'm still not entirely sure what these numbers represent. 8GB/s is Lot of data . . . and those are BiG "B"s That's 64Gb/s? What's up with that? I'm almost thinking those might be ram module internal numbers. The FSB is only clocking along at pokey 400Mhz, or quad pumped for a potential transfer rate of 1.6Gb/s ('ittle "b"). Something's not tracking. Mr. Wizard. Need more data!

Share this post


Link to post
Share on other sites

I believe what you are getting you can read under PERFORMANCE in MemSet. I know with the 4 x 1Gb OCZ 800 ram I had running at 1050Mhz, CAS 4, and had Everest latency of 51.8ns at the best ever. If I recall correctly, I was able to set Transaction Booster (must be similar to directly setting tRD on an X48, tho I don't know for sure. I DO know that going +1 translates to 1 less in MemSet Performance.

Share this post


Link to post
Share on other sites

What I don't get with this whole memory optimisation thing is that a drop of main memory access latency from say 60ns to 54ns is only a 10% improvement in memory access speed. Yet main memory access latency is only a subset of instructions that a CPU performs, especially since the CPU cache handles a lot of these memory access requests, hence this 10% performance boost at the system level is likely much, much lower perhaps in the 1-2% band level. Dedicated memory performance benchmarks show this, so how does this exactly translate into phenomenal performance increases in real world applications, like a major performance boost in overall FS9/FSX texture loading performance. The cynic in me says "I don't think so".Gary

Share this post


Link to post
Share on other sites

Yea, Performance Level on Memset is tRD. The darn thing will adjust on the fly. Just locked myself up at a tRD of 5. That makes sense. My "-3" setting won't even boot. This P35 just doesn't have the chops. So a tRD of 7 means that 2.5ns x 7 or 17.5ns of my ram's latency is tRD related. On the other hand, how much more can even a super-duper NB offer. I don't think I'd spend even $3 to pick up 3 more tRDs. Nehalem's just around the corner and that may take that down a bunch. But do we really need it? Consider: 40ns are still happening somewhere else. What's going on there? Why would speeding up the ram's internal processes (timings & clock) allow faster transfers (lower latency)? Not that it couldn't, but if it does, why? If an operator is using the same tRD rate (for instance exactly every 7th cycle), how can data transfer rates increase? We can "quad pump" a cycle to load up 4 bits on a single cycle (Anand didn't address that), but that's the end of it. I have a feeling increases in performance is going to be about latency. The rest may be just a look inside the ram module's machine room.For this circumstance we are observing to occur, tRD - Must - mean that these transfer events are only Available every (for instance) 7th cycle. If we were actually using every 7th cycle, the latency would be 7 x 2.5ns or 17.5ns. At a 60ns latency, only every (60 / 2.5ns) 24th cycle is being used. It appears that ram's transfer capability is way behind the FSB's ability to carry that data. Maybe that's why a 266Mhz FSB works just fine with whatever ram you want to throw at it! High FSB speeds really are totally meaningless. I'm getting dizzy. Your turn.

Share this post


Link to post
Share on other sites

"Yet main memory access latency is only a subset of instructions"(So far) I'm arguing that Latency is not just another factor. The latency number represents the actual flow of data transfered between the ram and the CPU. The ram's internal timings and clock simply make the ram's internal data more available to transfer. For instance, with a tRD of 7 on a 400Mhz FSB, the FSB provides a data transfer opportunity every 7 cycles (7 x 2.5ns) or every 17.5ns. If they were all used, my latency would be 17.5ns . . . but it's not. Why? The ram cannot produce data that fast. So, how fast - Can - my ram produce data? My latency is 60ns. The FSB is not the bottleneck. It's provides a transfer opportunity every 17.5ns. So what's holding up production? The RAM(?!).So why does increasing the CPU's ram-Feed - Not - translate on a 1:1 basis into tangible, non-subjective increased performance. It surely doesn't and that's DefinaTelY going to be another one of our $64 questions.

Share this post


Link to post
Share on other sites

>>>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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 ;) .

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

"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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

>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.

Share this post


Link to post
Share on other sites