Sign in with
Sign up | Sign in
Your question

X-Bit Lab's Interesting Core 2 Duo Memory Report

Last response: in CPUs
Share
September 9, 2006 3:27:32 AM

Quote:
http://www.xbitlabs.com/articles/memory/display/core2du...

From the review, it can be concluded that pairing Core 2 Duo CPUs with faster memory is only useful if you overclock.


Interesting, but their conclusions are all whacked out... the data set is stellar though.

That is alot of data, that's for sure. My eyes are still trying to focus after going through all those charts.
September 9, 2006 3:34:46 AM

To me their conclusion seems right on target. You only need RAM to reach synchronous timings with the FSB, and beyond that, lower CAS timings are what help the most. But if you have RAM that is running way faster than the FSB, then despite relaxed timings it can still provide an additional boost.

That makes sense, as a 6-clock delay at DDR1067 is after all the same latency as a 3-clock delay at DDR533.
Related resources
September 9, 2006 4:28:04 AM

Idiot alert. If you've got nothing useful to contribute then STFU noob.
September 9, 2006 4:35:26 AM

Ooh, I think there may be a little misunderstanding. When Xbitlabs says that the FSB is limiting, they don't mean the CPU is necessarily waiting for RAM all the time. Some applications need more CPU power, some need more memory, and most probably alternate between one and the other, thus the reason for having cache memory. But there's no direct way around the hard cap of a fixed speed, fixed width FSB that the memory controller has to go through.

With all the FSB400 testing, the CPU was held at the same clock speed whether RAM was 600, 800, or 1000Mhz - thus the nearly uniform performance figures for Cinebench rendering. However, using the same setup, WinRAR shows that it really needs good memory access. But with DDR800 CL3 beating DDR1000 CL5 at WinRAR, it also suggests the FSB is bandwidth limited and only suffering from the increased latency when using DDR1000 at only Cas5.

I guess the litmus test is ... if Core 2 had a second bus connected to an on-die memory controller, and we could run really fast higher-latency RAM, would we see performance increases that we couldn't now. In applications like Cinebench, of course we wouldn't see much. But in WinRAR and most games, I'd expect there to be a noticeable difference from bandwidth alone.

Currently at stock FSB266, all the memory bandwidth benchmarks show lower than theoretical FSB performance, so varying the RAM speed has some effect, but a memory benchmark of course isn't designed to bottleneck at the CPU. I'm just guessing, but this effect might have to do with prioritization between the memory controller and other CPU communication.

I glanced at the Madshrimps conclusion, and it was saying basically the same thing, just focusing on the detail that Core 2's cache system is enough to feed the CPU and that low-latency synchronous memory is usually the best choice to improve performance.
September 9, 2006 4:51:16 AM

Troll and immature noob alert. Keep it up and see how long you last.

Quote:
Deleted


Deleted.
September 9, 2006 5:10:09 AM

Yeah those whole 3.6 posts a day really takes up a lot of my day. :roll: Good work troll, another step closer to being banned.
September 9, 2006 5:25:04 AM

So clever your only comeback is baseless crap. :lol:  A sign of a man beaten and just too cut to admit it. Classic stuff. If you're going to troll do a decent job of it.

Anyways why would you be interested in my mom and sister when you've admitted you're gay? Do you go both ways, bit of an each way man? Bit like BSer? He was like that. I reckon you two would get along real well.
September 9, 2006 5:39:57 AM

Holy generic batman! Did you hit up google for generic insults? I'm done with you troll.



Welcome to the club slinky. You're a complete waste of space and I'm not going to bother replying to you unless you're posting FUD but I wouldn't recommend it unless you're up for being banned.
September 9, 2006 5:49:33 AM

Only noobs don't and they're not real people.
September 9, 2006 5:57:56 AM

Thats almost as pathetic as BaronBS' I know you are but what am I. No comeback at all. :lol:  Action Man wins by knock out in the first round. :lol: 
September 9, 2006 6:13:51 AM

Quote:
There is no litmus test needed, just explain to me if the FSB is throttling the CPU then why does an X6800 out perform an E6600 using the exact same memory and timings, i.e. holding memory constant ?

You can't because, there is not bandwidth throttled for a C2D on a 1067 MHz bus running as fast as 2.93 GHz, the data is clear on this.

Your last paragraph is correct, that is the strength of a large cache with good prefetch, but if FSB was truly bottleknecking no amount of cache will save you. Cache only hides latency, prefetching helps decrease demand on BW.

And yes, ultimately on the surface their conclusion is correct --- Core 2 Duo does not crave high speed memory; however, they also masterfully conclude the completely obvious --- you need fast memory to over clock ?? What gives with that??? :)  :)  A little chuckle is in order here.


Well, if you restrict the analysis to, say the 6600 with its limited multiplier, and assume that you have some premium DDR2 sticks, then you can get a higher OC with a mobo that will run at a faster FSB. So, for example, if Anandtech's DFI Infinity review is accurate and its FSB will not go above 400MHz, then the 9X multiplier will limit you to 3.6GHz. The Asus P5B has been reported running a FSB of over 500MHz and CPU clocks of over 4GHz. I've got some links on my desktop at home but not here on my laptop. If I remember right, the best P5B OCs I saw were on XS. People that tried to run asynchronously got slower clocks or lower benchmarks compared to those running fast DDR2 synchronously. I'm not writing this as any kind of rebuttal, just rattling off some aspects of OCing C2Ds since many people here seem confused about what parts they should get, etc. I heard the other day from a friend that has a good contact at Asus that they are hard at work revising the BIOS on the 975 chipset boards and expect to be able to run the FSB up around the clocks being currently achieved on 965 mobos in the near future.
September 9, 2006 7:49:55 AM

Quote:
With SPD, 440Mhz is the new limit for DFI Infinity with the latest BIOS


Cool. Gotta find a way to wring 445 out of it!
September 9, 2006 8:34:36 AM

Can someone give me a hand in processing this info?

The tests showed that running at 1:1 provides a substantial boost in performance that is only matched by going to DDR2 800 or above with tight timings (and expensive).

I know VERY little about underclocking memory and only a little about overclocking the FSB. My questions are (and feel free to explain the logic behind your answers) :

1. What would be the benifits of getting DDR2 667 and underclocking it to 533mhz, compared to getting DDR2 533 CAS-3 chips?

2. What would be the benifits of getting DDR2 667 and overclocking the CPU FSB (about 25% according to my limited knowledge) to get it to run 1:1?

3. This ones a bit of a side track, but does anyone have any information on how the Conroe chips handle air cooled overclocking? I'm hoping better than my current prescott 8O
September 9, 2006 9:07:23 AM

Thanks for the reply!! I didn't know who I replied to, I just clicked a random reply button since I didn't see a generic one.

1. So underclocking your memory doesn't allow you to get tighter timings? In which case it makes no sense to get DDR2 667 and underclocking it to 533 instead of just getting 533?

3. Can you explain what the frequencies you gave (3.3-3.5 for stock, 3.8-4.0 for aftermarket) translate to (roughly) in terms of what the FSB would be? I'm just wondering if I can reach a 333 system clock or even 400 for 1:1 with DDR2 800 8O
September 9, 2006 1:48:27 PM

Quote:
Thanks for the reply!! I didn't know who I replied to, I just clicked a random reply button since I didn't see a generic one.

1. So underclocking your memory doesn't allow you to get tighter timings? In which case it makes no sense to get DDR2 667 and underclocking it to 533 instead of just getting 533?

3. Can you explain what the frequencies you gave (3.3-3.5 for stock, 3.8-4.0 for aftermarket) translate to (roughly) in terms of what the FSB would be? I'm just wondering if I can reach a 333 system clock or even 400 for 1:1 with DDR2 800 8O


1. This is a good question, maybe it is worth a try if it is stable then go for it. Overclocking often times requires one to loosen timings. Honestly, I am not up on the physics of DRAM enough to say why this would be the case off the top of my head. You can't damage anything by trying. However, you will get the nice 1:1 boost.

3. E6300, E6400 are 2 Meg Cache parts:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=280...
1.83, 2.13 GHz CPUs are overclocking to 2.6-2.9 easily (I am sorry, I need to correct myself --- reading Anands page I was of 1 GHz this is a big mistake, apologies). The E6600, E6700 are getting from 2.4 and 2.67 into the 3.0-3.5 GHz range pretty easily. http://www.gamepc.com/labs/view_content.asp?id=e6600&pa...
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=279...

Quote:
To provide some idea of overclocking abilities with other Core 2 Duo processors, we ran quick tests with E6700 (2.67GHz), and E6600 (2.4GHz). The test E6700 reached a stable 3.4GHz at default voltage and topped out at 3.9GHz with the Tuniq Cooler. The 2.4GHz E6600 turned out to be quite an overclocker in our tests. Even though it was hard-locked at a 9 multiplier it reached an amazing 4GHz in the overclocking tests. That represents a 67% overclock.


So to go back to Tekdragon's question #3, the 6600 at 4GHz with a 9X multiplier requires a FSB of about 445MHz. A 6700 with a 10X multilier running at 3.9GHz requires a FSB of 390MHz. Etc. 6800 has an 11X multiplier stock and is unlocked, 6400 is 8X, 6300 is 7X.
September 9, 2006 3:45:28 PM

Still can't see anything wrong with the xbitlabs report. It's not written purely for enthusiasts - for example, some readers like myself might have been wondering whether it's good for performance to get some 1067mhz RAM for a stock or moderatedly overclocked C2D (and to run it 2:1 or otherwise asynchronously). With C2D, the conclusion is no - you should pick a part that specifically excels at synchronous timings so that the theoretical RAM and FSB bandwidths are equal. With the A64, the conclusion is by contrast a resounding yes, as we've seen with SLI memory - there is no FSB limitation.

For Intel the FSB is still a hard bottleneck in all applications that stress it - I don't see a way to deny that. In reality, not many applications often bottleneck at the FSB (thus why an x6800 stock beats the others in applications) partly because of the good caching coupled with C2D not executing instructions at infinite speed. But all that caching does little for a memory bandwidth benchmark even with a sluggish CPU, so the FSB shows its signs there.

To my knowledge none of the charts compare C2D's of different clocks. All the charts compare different RAM frequencies/timings with the same FSB and CPU clocks. There's no reason to compare between charts as IIRC they used a different C2D chip as well (notice the higher Cinebench performance at stock FSB).
September 9, 2006 4:34:58 PM

Quote:
Still can't see anything wrong with the xbitlabs report. It's not written purely for enthusiasts - for example, some readers like myself might have been wondering whether it's good for performance to get some 1067mhz RAM for a stock or moderatedly overclocked C2D (and to run it 2:1 or otherwise asynchronously). With C2D, the conclusion is no - you should pick a part that specifically excels at synchronous timings so that the theoretical RAM and FSB bandwidths are equal. With the A64, the conclusion is by contrast a resounding yes, as we've seen with SLI memory - there is no FSB limitation.

For Intel the FSB is still a hard bottleneck in all applications that stress it - I don't see a way to deny that. In reality, not many applications often bottleneck at the FSB (thus why an x6800 stock beats the others in applications) partly because of the good caching coupled with C2D not executing instructions at infinite speed. But all that caching does little for a memory bandwidth benchmark even with a sluggish CPU, so the FSB shows its signs there.

To my knowledge none of the charts compare C2D's of different clocks. All the charts compare different RAM frequencies/timings with the same FSB and CPU clocks. There's no reason to compare between charts as IIRC they used a different C2D chip as well (notice the higher Cinebench performance at stock FSB).



But you can't tell these guys anything. They are always right.
September 9, 2006 6:52:51 PM

Quote:
But you can't tell these guys anything. They are always right.


And of course, the complimentary crappolla from the peanut gallery.

Let's flip it around --- Why don't you explain why I am not right. Becasue if I am wrong, then you should relish the opportunity to correct me as I so often need to correct you.


Please, play your superior idiot game with someone else. Your grammar is ofttimes atrocious and your general use of vocabulary is juvenile at best.

They showed very clearly that the FSB is 266MHz and quad pumping can only do so much. It clearly shows that there is a limit to how much data can be pushed to the chip. OF course most apps don't need the full bus bandwidth, even games as was shown.

If there are two components being varied then there maybe a problem, but they only varied the FSB. 1:1 is the best performer because above that you ARE FSB LIMITED. Why did ALL of the tests at 400FSB 1066 RAM show a decrease in speed?
September 9, 2006 7:21:18 PM

To prove that FSB can be a bottleneck is trivial as long as we trust Intel's specifications on the bit width and clock rates of a few pipelines on the Intel platform. Simply, if the processor and memory can each transfer more data than the FSB can, then the former can be left waiting for the latter.

Unless I've read wrong, I have the following figures:

FSB: 64 bits * 1067 MHz = 8.5 GB/s
L2 cache (on x6800): 256 bits * 2930 MHz = 93.8 GB/s
DDR800 dual channel: 64 bits * 2 * 800 MHz = 12.8 GB/s

We have a memory system capable of up to 12.8 GB/s, a CPU capable of 94 GB/s with the L2, and an FSB of just 8.5 GB/s to connect the L2 with the memory. That's a bottleneck.

Whether this bottleneck can be seen in testing depends on the code being run. We have an example of code which bottlenecks at the CPU's execution units (Cinebench rendering), and we have code which bottlenecks at the FSB or RAM (WinRAR and any memory benchmark). There are tons of applications out there, and I'm certain that there are applications which sometimes run like Cinebench and at other times like WinRar.

Because most code is not all uniformly bottlenecked at one component, varying the speed of a single component does not necessarily cause either a proportional scaling or no scaling of performance around that one component. That's why we have all these games which do exhibit minor performance benefits from fast RAM, but certainly they won't show linear scaling off RAM speed.

What Intel did with C2D is a gamble - hoping that programs will frequently enough use the L2 cache which is supplemented by prefetching to avoid waiting many cycles for RAM data to cross the Northbridge - but so far it seems like a very good gamble, as the bottlenecking we can see is generally so insignificant.

Quote:
Thus, the FSB is not bottlenecking simply because you increase the memory speed and you observe no change in performance.


When there is performance improvement going from DDR-600 to DDR-800, but hardly any from DDR-800 to DDR-1000, it suggests that there is some bottleneck between above 600 and slightly above 800. That must be either the CPU or the FSB (or the graphics card, but at this medium resolution on these games I doubt it's the x1900xtx). But how is the CPU coincidentally maxing out at this low clockspeed across two or three different game benchmarks (refer to page 10), out of the four tested? It is much easier to answer that it's the FSB, which happens to be running at 800 MHz.
September 9, 2006 8:19:06 PM

JJ, I get what Xbit meant when they said "the FSB is the bottleneck". They were right, but it was the Bottleneck for the RAM, NOT the CPU. The CPU shows alot of change when the proc speed is increased but not the FSB. That shows the FSB is not a bottleneck for the CPU. On the other hand the The FSB only delivers as much bandwidth as DDR2-533, so RAM operating at maximum speed above that wouldnt show much difference.

X-bits conclusion WAS right, just not worded correctly. But, almost all applications arn't RAM BW limited so its not a major problem.
!