Which is faster, 9x333 or 8x375 on a q6600? Results inside

[graysky]

What is a better overclock?

Good question. Most people believe that a higher FSB and lower multiplier are better since this maximizes the bandwidth on the FSB. Or is a low bus rate and higher multiplier better? Or is there no difference? I looked at three different settings on my Q6600:

9x333 = 3.0 GHz (DRAM was 667 MHz)
8x375 = 3.0 GHz (DRAM was 750 MHz)
7x428 = 3.0 GHz (DRAM was 856 MHz)

The DRAM:CPU ratio was 1:1 for each test and the voltage and timings were held constant; voltage was 2.25V and timings were 4-4-4-12-4-20-10-10-10-11.

After the same experiments, at each of these settings, I concluded that there is no difference for real world applications. If you use a synthetic benchmark, like Sandra, you will see faster memory reads/writes, etc. with the higher FSB values -- so what. These high FSB settings are great if all you do with your machine is run synthetic benchmarks. But the higher FSB values come at the cost of higher voltages for the board which equate to higher temps.

I think that FSB bandwidth is simply not the bottle neck in a modern system... at least when starting at 333. Perhaps you would see a difference if starting slower. In other words, a 333 MHz FSB quad pumped to 1333 MHz is more than sufficient for today’s applications; when I increased it to 375 MHz (1500 MHz quad pumped) I saw no real-world change; same result when I pushed it up to 428 MHz (1712 MHz quad pumped). Don’t believe me? Read this thread wherein x264.exe (a video encoder) is used at different FSB and multiplier values. Have a close look at the 3rd table in that thread and note the FPS (frames per second) numbers are nearly identical for a chip clocked at the same clockrate with different FSB speeds. This was found to be true of C2Q as well as C2D chips.

You can do a similar test for yourself with applications you commonly use on your machine. Time them with a stop watch if the application doesn’t report its own benchmarks like x264 does.

Some "Real-World" Application Based Tests

Three different 3.0 GHz settings on a Q6600 system were tested with some apps including: lameenc, super pi, x264, winrar, and the trial version of photoshop. Here are the details:

Test O/C 1: 9x333 = 3.0 GHz


Test O/C 2: 8x375 = 3.0 GHz


Test O/C 3: 7x428 = 3.0 GHz


Result: I could not measure a difference between a FSB of 333 MHz, 375 MHz, or 428 MHz using these application based, "real-world" benchmarks.

Since 428 MHz is about 28 % faster than 333 MHz, you’d think that if the FSB was indeed the bottle neck, the higher values would have given faster results. I believe that the bottleneck for most apps is the hard drive.

Description of Experiments and Raw Data

Lame version 3.97 – Encoded the same test file (about 60 MB wav) with these commandline options:

lame -V 2 --vbr-new test.wav

(which is equivalent to the old –-alt-preset fast standard) a total of 10 times and averaged play/CPU data as the benchmark.

Super Pi version 1.1 – Ran both the 1M and 2M tests and compared the reported total number of seconds to calculate as the benchmark.

x264 version 0.54.620 – Ran a 2-pass encode on the same MPEG-2 (480x480 DVD source) file twice and averaged the FPS1 and FPS2 numbers as the benchmark. In case you’re wondering, here is the commandline options for this encode, pass1:

x264 --pass 1 --bitrate 1000 --stats "C:\work\test-NEW.stats" --bframes 3 --b-pyramid --direct auto --subme 1 --analyse none --vbv-maxrate 25000 --me dia --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --output NUL "C:\work\test-NEW.avs"

And for pass2:

x264 --pass 2 --bitrate 1000 --stats "C:\work\test-NEW.stats" --ref 3 --bframes 3 --b-pyramid --weightb --direct auto --subme 6 --trellis 1 --analyse all  --8x8dct --vbv-maxrate 25000 --me umh --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --output "C:\work\test-NEW.264" "C:\work\test-NEW.avs"

The input avisynth script was:

global MeGUI_darx = 4
global MeGUI_dary = 3
DGDecode_mpeg2source("C:\work\test-new.d2v")
AssumeTFF()
Telecide(guide=1,post=2,vthresh=35) # IVTC
Decimate(quality=3) # remove dup. frames
crop( 2, 0, -10, -4)
Spline36Resize(640,480) # Spline36 (Neutral)

RAR version 2.63 – Had rar run my standard backup batch file which generated about 0.98 G of rars (1,896 files totally). Here is the commandline I used:

rar a -u -m0 -md2048 -v51200 -rv5 -msjpg;mp3;tif;avi;zip;rar;gpg;jpg  "e:\Backups\Backup.rar" @list.txt

where list.txt a list of all the dirs I want it to back up. I timed how long it took to complete with a stop watch. I ran the backup twice and averaged it as the benchmark.

Trial of Photoshop CS3 – I used the batch function in PSCS3 to batch bicubic resize 10.1 MP to 0.7 MP (3872x2592 --> 1024x685), then applied an unsharpen mask (60 %, 0.8 px radius, threshold 12), and finally saved as quality 8 jpg. In total, 57 jpg files were used in the batch. I timed how long it took to complete two runs, and averaged them together as the benchmark.

Here are the raw data if you care to see them:

[stargate125645]

If your RAM isn't saturating your FSB bandwidth, you aren't going to notice much of a performance difference between the two frequencies, though the one with higher FSB would be faster if you had the same divider.

[graysky]

I agree with both your statement, SG. My whole point about this experiment is to show people that they don't necessarily want to max out their FSB to hit the same final CPU frequency. I've seen some posts claiming that 8x450 is faster than 9x400 for example. These data show that statement is simply not true for application based benchmarks.

[stargate125645]

Originally Posted by graysky

I agree with both your statement, SG. My whole point about this experiment is to show people that they don't necessarily want to max out their FSB to hit the same final CPU frequency. I've seen some posts claiming that 8x450 is faster than 9x400 for example. These data show that statement is simply not true for application based benchmarks.

Understood. Very well done and comprehensive. Great job!

[graysky]

In the interest of overkill, I just completed the same benchmark @ 7x428 (edited first post in thread). Results are the same: no benefit of an even higher FSB.

[nicolasb]

I sort of half-remember seeing some gaming benchmarks somewhere (vague enough for ya?! ) which suggested that high FSB speed made more of a performance difference in games than it does in the sort of applications you're benchmarking here. I may well have remembered that wrong but perhaps you could run a few gaming benchmarks as well and see...?

[doublejack]

What kind of motherboard were these tests conducted on?

The reason I ask is because boards based on Intel chipsets, particularly the 965, scale a bit weird with fsb. The reason for this is because they have various bootstraps which are utilized depending on the fsb speed selected. Once you cross a threshold of one bootstrap, you go into the next which has looser chipset timings that allow for the higher bus speeds. For example, setting the fsb speed to 332MHz will use the 1066 strap, and starting at 333MHz the mobo automatically switches to the 1333 strap. 400MHz is another threshold, going to a theoretical 1600 strap.

Basically this is the same concept as taking cas4 DDR2-800 memory and running it @ cas5 DDR2-1066. You are gaining raw MHz, but the trade off is more latency. Which is ultimately faster depends, and they may very well be about the same.

Also, tests like a 1M superpi are a very poor method of measuring the effect of memory bandwidth and fsb. Why? Because once the data is initially loaded, it fits completely within the cache on the processor die. So you could have a C2D with a 100x multiplier with a very, very slow fsb speed of 30MHz and the result will come out about the same. That test is doing nothing more than verifying the CPU speed, and the CPU speed alone.

[graysky]

I just read the FSB1333 Intel Processors & New 2007 CPU Charts article over at TH.com and am happy to see that the testers over there have drawn the same conclusion that I have about fixed final core speeds with higher and higher FSB speeds: faster FSB speeds w/ a C2Q/C2D don't equate to faster real-world benchmarks.

Have a look at page 8 from their article comparing the "old" 1066 MHz FSB to the "new" 1333 MHz FSB chips: average gain <1 %.

[ianm2]

its good to exhaust all the variations, but if fsb doesn't matter, then just get an old cpu and mobo. a pentium 2/3?

and don't forget, lowering the multiplier sets the limit on the chipset itself as that overclocks more.

what is important is not (not directed to you) but some willy waving " i have done this speed, can you do better contest " it IS a bit geekish to simply play around trying to max out everything just for a benchmark. some of those hardcore oc's are rather sad imo, all we want is better performance in day to day stuff.

for that reason, I am simply oc'ing on air, and who cares if I can get faster with water, its too much hassle, I could just buy faster parts instead, and when I reach the limit, that's fine by me.

the computer serves me, not the other way around

all the more reason not to jump on the very latest bandwagon, and buy the older discounted stuff that's just about as good for poss 1/4 of the price.

what I would like to see, I have no idea if its poss. but surely, is independant chipset, memory, and processor speeds and latencies, its what we are all crying out for. control. anyone who did that would surely coin the market.

surely the amount of time to calculate all the interdependant relations and dividers is pretty complex.

hello intel? can/will you do it?