Intel’s quad-core processors has a relatively narrow front side bus for handling data transfers. We’ve taken a closer look at what a higher system bus can do for the performance of a Core 2 Quad processor.
It’s been less than a year since Intel launched its first quad-core processor, Kentsfield. Even though the competition may define “quad-core” differently, the fact remains that Core 2 Quad contains four processor cores, and it’s been a very successful processor for this relatively short period of time. The clock frequency has scaled from the initial 2.67 GHz to 3 GHz, but there’s a lot more to it than just frequencies. Core 2 Quad series hasn’t just been expanded to include QX6850, QX6800, Q6700 and Q6600, but thanks to a new stepping, Intel has also managed to reduce power consumption and heat significantly. The motherboards of today are getting better and better at handling high system bus frequencies of quad-core processors, which also made it possible to raise the bus from 266 MHz to 333 MHz with the QX6850 model.
We dissected the Kentsfield architecture in a previous article, basically we’re talking about two merged dual-core processors. Back then we concluded that such a solution could be bottlenecked when the processor sends data between the two pairs of cores. This information is namely sent through the common system bus, which is a lot slower than a direct path between cores in the same die. This should also mean that the performance should improve if we raise the system bus, also known as the FSB. That is precisely what we’re going to investigate in this article, and we will not settle for just comparing 266 MHz and 333 MHz FSB.
Let’s take a look at the test system.
Test system | ||
Hardware | ||
Motherboard | Abit IP35 Pro | |
Processor | Intel Core 2 Extreme QX6800 (2x4MB) | |
Memory | Corsair Dominator 8500C5DF (2048MB) | |
Graphics card | nVidia GeForce 8800GTX | |
Power supply | Silverstone Zeus 850W | |
Software | ||
Operating system | Windows XP (SP2) | |
Drivers | Intel Chipset Driver 8.3.0.1013 nVidia Forceware 158.22 | |
Benchmarks | EVEREST Ultimate Edition 4.00.976 SuperPi 1.5 wPrime 1.52 Cinebench 9.5 Lame 3.97 WinRAR 3.70 3DMark2001 3.3.0 3DMark03 3.6.0 3DMark05 1.2.0 3DMark06 1.0.2 PCMark05 1.1.0 FarCry 1.33 Doom 3 Quake 4 |
We’ve chosen to use a motherboard based on the Intel P35 chipset, namely Abit’s IP35 Pro. The motherboard manufacturers have been able to add quad-core support to older chipsets such as the i975X, but these are still not capable of any higher FSBs with Kentsfield. With P965 and the newer P35 they’ve managed to tune the reference voltages a bit and have thus been able to achieve FSB frequencies far beyond 400 MHz.
To be able to test as many FSB combinations as possible, we chose to overclock the processor just slightly. Below is a table showing the different combinations we’ve used that resulted in almost identical clock frequencies.
Processor settings |
|||
FSB
|
Multiplier
|
Clock frequency
|
Memory frequency
|
278
|
12
|
3336
|
417
|
303
|
11
|
3333
|
378
|
333
|
10
|
3330
|
400
|
370
|
9
|
3330
|
444
|
417
|
8
|
3336
|
417
|
476
|
7
|
3332
|
476
|
As you can see the memory frequency varies quite a bit, which means that the system bus isn’t completely isolated. This is because of the memory dividers implemented by the chipset. A positive side of being able to overclock the system bus is that you can find an optimal memory frequency, which is really hard to do using just memory multipliers.
First up we have a couple of synthetic benchmarks.
include_once("/public_html/dia.php"); ?>
do_diagram(1905); ?>
do_diagram(1906); ?>
do_diagram(1907); ?>
The Everest Queen benchmark shows no correlation between FSB and performance. When it comes to PhotoWorxx there are some varying results, but we can see that the system bus has an overall effect on the performance. Zlib doesn’t seem to be affected by the system bus.
We move on to the well known
SuperPi.
include_once("/public_html/dia.php"); ?>
do_diagram(1908); ?>
do_diagram(1909); ?>
do_diagram(1910); ?>
Using different FSB frequencies means we’ll also be getting different memory frequencies, which has a major impact on the longer calculations. The shortest times are achieved at the highest FSB frequency and this should come as no surprise to people used to benching SuperPi.
Next up are wPrime and Cinebench.
include_once("/public_html/dia.php"); ?>
do_diagram(1911); ?>
do_diagram(1912); ?>
do_diagram(1913); ?>
do_diagram(1914); ?>
wPrime doesn’t reveal any significant advantages of a higher FSB and the results are all well within the margin of error. The same applies to Cinebench when we only use one core, but when we use all four cores and these are forced to share the available resources we can see that a higher FSB is preferable.
Moving on to some more practical benchmarks.
include_once("/public_html/dia.php"); ?>
do_diagram(1933); ?>
do_diagram(1916); ?>
Lame is just about the clock frequency, FSB doesn’t really matter here.
WinRAR on the other hand, usually likes memory-related performance, and we can see that a high FSB together with a high memory frequency is clearly the best scenario.
Next we have 3DMark.
include_once("/public_html/dia.php"); ?>
do_diagram(1917); ?>
do_diagram(1918); ?>
do_diagram(1919); ?>
do_diagram(1920); ?>
All of the 3DMark benchmarks prefer a high FSB. There are no landslide victories, but still a couple of percent to gain, especially in 3DMark 2001.
We continue with some other benchmarks from Futuremark.