9x333, 8x375, or 7x428 on a Q6600 - Which is faster?

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

[Shaggy]

Those apps are all cpu limited as far as I know. You would need a much larger gap in the fsb to see a difference, if any.


I think

[graysky]

I don't think they're CPU limited... x264.exe was the only app to peg all 4 cores @ 100 %. Most are disk limited which underscores my point that when using normal apps, the FSB is not the speed limiting factor.

[sofarfrome]

I don't think they're CPU limited... x264.exe was the only app to peg all 4 cores @ 100 %. Most are disk limited which underscores my point that when using normal apps, the FSB is not the speed limiting factor.

In this case if all 4 cores are taxed to 100% that means you are using an app that is CPU bound (primarily uses CPU functionality), not CPU limited. It doesn't matter if you have 400x9 or 450x8, the results will be the same for all intents and purposes. What you want for comparison of FSB impact is something that compares bandwidth. You should realize higher bandwidth with a 450x8 OC relative to a 400x9 OC. Try SiSoft's Sandra as it does a good job for a relative comparison.

[graysky]

What you want for comparison of FSB impact is something that compares bandwidth. You should realize higher bandwidth with a 450x8 OC relative to a 400x9 OC. Try SiSoft's Sandra as it does a good job for a relative comparison.

This is sort of my point: there are few apps that actually use 333 MHz of FSB to its full potential; the few that I know about are designed to simply benchmark a system like Sandra. Usually higher voltages are required to feed the higher FSB values. As you pointed out 450x8 will likely require more juice than 400x9. If you can't use the full 400 MHz bandwidth, why increase the voltage to feed 450 MHz bandwidth that you aren't going to use... sort of like driving semi to the store to buy your groceries when a pickup truck has more enough space to hold all the bags.

[Shaggy]

That is what I was saying. The cpu cache is already being filled up faster than the cpu can process the information. Thereforce, increasing the speed of the communication between the cpu and memory is not going to help. In those particular applications.

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

[Chewbenator]

So I guess higher multi wins by a tiny amount?

[Ace-a-Rue]

i think the other thing to consider; as you raise the FSB you could be adjusting straps upwards which raise the latency....a possibility in my mind.

[Hazzan]

try and run with 3dmark01 see the different result...........

[Leeghoofd]

Each benchmark has it's own particularities indeed, somr prefer high FSB others tight ram timings, others ram bandwith....

But on day to day basis I prefer 9 x 333 if I need to go and run 3ghz...less stress on the components besides the cpu

[HoriWanderFuLL]

Im yet to get a single benchmark to run faster on 8x than 9x on my Q6600

but as a guy just explained in previouse post i suppose how high up on the strap you are..9x400 =3600 mhz..8x450fsb = the same...can you Hold your Q6600 at 450Fsb ??..prolly benchmark the same on these 2 instances

but you can get your 9x430 Fsb will be screaming nicly are you gunna get ur Q6600 8x480 to match it ?? Doubt it.

Cheers Hori

[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 &#37;.

[LUH3417]

Now, what about the memory multiplier? Should I run my e6600 at 320 FSB with a 2.5x memory multiplier (2880Mhz), or 333 FSB with a 2.0x multiplier (3000Mhz)... and why? I still can't find a good explanation of the memory multiplier.

I have what I think is a common problem with the e6600 CPU. It will only overclock to FSB 333 x9 = 3Ghz. (stock is 266 = 2.4 Ghz). And the problem is this: if I set the memory multiplier to 2, the 800Mhz memory I bought is wasted; I could have just bought 667 memory.

Some motherboards support a multiplier of 2.4 (or arbitrarily flexible?) which would be ideal, but this Gigabyte GA-965-DQ6 only offers 2.5, which means the memory needs to run at 833 though its only rated for 800. I suppose many memory can handle that memory OC but my question still is, assuming we're "CPU bound" on the overclock and can't push the FSB over 333 (edit: I should say, push the CPU past 3Ghz, whatever CPU multiplier x FSB is used), is there any performance difference between a memory multiplier of 2.0, 2.4, or 2.5? And if so why? Does the memory race ahead and load up bytes ahead of time with the higher multiplier? Would 1066 memory be even better letting me use a multiplier of 3.0? Or, if the overclock is "CPU bound", should most e6600 users just stick to cheaper 667 memory?

[graysky]

Dunno about those dude... you wanna do some tests and post the results?

[LUH3417]

It would be more fun if people posted their theories and explanations and predictions first. Or ideas on which benchmarks to use. I should be able to get around to it before the week is out.

[graysky]

Since I'm suffering from insomnia and have nothing better to do at 2 AM, I compared 9x266 @ 1:1 (so memory was 533 MHz) and 9x266 @ 3:2 (so memory was 800 MHz) on my Q6600. All other settings were held constant; timings are 4-4-4-10.

All the apps run faster at the higher ratio:

Two synthetic benchmarks:
-Super PI mod (16 M) ran 6.2 &#37; faster (10m 3.125s vs. 9m 25.859s)
-Winrar internal benchmark (101 megs) ran 23.6 % faster (1329 KB/s vs. 1643 KB/s)

Three real-world benchmarks:
-Winrar running my backup batch (about 1.3 gigs of files and then generates 5 recovery volumes) ran 15 % faster (133 s vs. 113 s)
-x264 encoding a 720x480 mpeg-2 ran 4.3 % and 0.4 % faster on the first and second passes respectively (126.95 fps/33.92 fps vs. 132.36 fps/34.07 fps)
-Photoshop resizing 44 files (2472x3296 --> 768x1024) then applying USM ran 5.2 % faster (58 s vs. 55 s)

[LUH3417]

Cool! So actually, speed is lost when we go down to a 1:1 memory ratio. But, its often worth it, since that lets us crank the CPU faster. Further, if one's bankbook and motherboard support it, one might get some performance improvement from using 1066 memory, if the math worked out that they could then go to an even higher memory multiplier. Based on your benchmarks where you hold net CPU speed constant.

Does this result then inform your OP experiment, where you keep the memory multiplier constant? Consider: in practice there is an advantage to using 9x333 = 3.0 GHz (DRAM was 667 MHz) since that would then let you use a 2.5:2 memory multiplier, which your latest test shows helps. That is, each of our computers happens to have a CPU that has a fixed upper limit, ditto for the RAM, and by working the FSB, the CPU multiplier, and the memory multiplier we want to optimize.

In the case of the e6600, I'll need to bench it to see if I'm better off giving up some net CPU Mhz, going down to 2880Mhz in order to get 2.5x (=1.25) memory multiplier... versus sticking with 3000Mhz CPU but having to slow the memory to 2.0 (=1.0). In other words, I can bump the memory bandwidth 25&#37;, and cut the CPU 4%, or vice versa, choose my poison. I'm only in this fix because this (most?) motherboard doesn't have very granular control of the memory multiplier, otherwise I'd just choose a 2.4 multiplier and have my cake and eat it too.

I heard that forthcoming intel chipsets would unlock the multiplier (to go higher). If and when that happens, I'm thinking we'd want to use a 10x multiplier or more, in order to be sure to get higher memory multipliers. Though you'd think the total memory bandwidth is all that matters. Which is why the OP results are surprising, since net memory bandwidth (but not multiplier) varied. OK, I think I've managed to confuse myself again.

[Demo]

Hmm..

So a 370*9 = 3330 would would be faster than a 400*8 = 3200 ?

[graysky]

@demo - try both modes benchmarking them against the 5 most common apps/games you use and let us know which gave better results.

[Leeghoofd]

if you got a quadcore , these cpu's love bandwith and high FSB so it will be more worthwhile to run 8 x 450 instead off 9 x 400... second thing to note is that the strap the chipset sets, today we can choose it from the bios but with earlier boards (P5W and co and Striker too) there was less performance over a certain FSB...
Third what can ya ram do ? like for eg Superpi for me runs faster with tighter timings instead in favour of running high speed ram frequencies, aquamark too loves tight ram timings instead of latency... I know you have to compare and you keep the same timings for the ram as it could be that running it at 533 3-3-3-8 could give you equal scores... if you go higher on ram speeds many loosen the timings though this is not always beneficial in what you do...

Best way is to run the apps or such you like or use alot and then decide...