Q6600 3.0 @ 1.24v stable but can't get higher.

[California Roll]

I read the entire OC FAQ sticky and can get to 3.0 (9x333) easy enough. Was even able to drop voltage down to 1.24v for 57C load temps (Prime, large).

I haven't been able to get to 3.2 (8x400 or 9x355) even raising voltage to 1.4. My MCH and ICH are both set to AUTO, which are 1.1v each. I'm guessing this is the prob? I was hoping I wouldn't have to mess with these settings but I should have a lot more room to OC.

My system is in my sig, any tips from the pros here?

 

[Drsignguy]

Your Ram might be holding you back if you haven't set it to 1:1. If you have a higher ratio set, then lower it and make sure it is set to default settings and not worry about over clocking the ram until later when you have a stable system.

 

[Gillbot]

My old G0 did 400fsb no problem without touching anything but core voltage. Be sure to manually set your voltages instead of leaving them on auto. If stock is 1.1v, set it to 1.1v instead of auto and try from there.

 

[Idontcare]

On the DS3L, not sure how different it is from the UD3R, fails in large prime are more indicative of FSB/MCH undervoltage and not too telling of Vcc CPU instability.

To find peak CPU temps with prime and to determine whether Vcore is too low you really should run small FFT.

Also to determine whether you are FSB, ram, or CPU limited you can eliminate 2 of the 3 (FSB and ram) by lowering your CPU's multiplier to 6x and then ramp up the FSB and explore your stability issues while knowing when you find some that it is not your CPU. Large FFT's will serve you best to determine if FSB voltage or DIMM voltage is needed to get past the instability.

You should do this with your ram set to as slow as possible as allowed by the BIOS - usually this is called "synch mode" in the bios or sometimes it is 1:1. On my DS3L it is labeled "2.0 system ratio" or something similiar.

Now leave your Vdimm and FSB voltage at the values you know deliver you a FSB/ram stability up to the limits you found while your chip was at 6x multi.

Then take your CPU up to 9x multi and drop the FSB way down, say to 333. Now work your way your FSB up incrementally using small FFT as your stability test to uncover CPU temp/Vcore issues knowing that any errors you uncover are going to be related to the CPU and not your FSB/ram until you reach that max FSB value you previously explored.

 

[California Roll]

Thanks guys, I'll give some of your suggestions a shot. I have all my memory timing off Auto and manually set to 5-5-5-15, 1.8v per spec.

I'll try changing my NB and SB from Auto to 1.1v. For some reason, Gigabyte's EasyTune6 shows NB at 1.2 while BIOS shows 1.1 Auto.

Originally posted by: Idontcare
On the DS3L, not sure how different it is from the UD3R, fails in large prime are more indicative of FSB/MCH undervoltage and not too telling of Vcc CPU instability.

I was always a bit confused about this. Running small shows definitely higher temps, but I can run stable for several hours at small, and then immediately try it at large and have it blue screen in 10 seconds. For this reason I just stuck with large to save time.

 

[Idontcare]

Originally posted by: California Roll
I was always a bit confused about this. Running small shows definitely higher temps, but I can run stable for several hours at small, and then immediately try it at large and have it blue screen in 10 seconds. For this reason I just stuck with large to save time.

Just stating the obvious here, but which one causes your system to be instable (small or large) solely depends on which component in your system is instable.

If large is failing, but you are trying to overclock the CPU then it suggests the CPU is not really the cause of the prime 95 errors but rather the memory or the NB which was also overclocked in the process of overclocking the CPU.

They aren't entirely independent either. Its just a rule of thumb. Its all using the same hardware so you can't expect the results to always be binary in terms of flagging the limiting peice of hardware.

But the easy way to determine what is happening with large FFT for your specific situation is when you see a large FFT failure then go into the bios and only change your CPU multiplier to be lower by one unit (say from 9x -> 8x)...leave everything else including voltages the same. Now run large FFT again. If it fails again then you know it isn't CPU (because you just underclocked it by nearly 12%)...which leaves you with memory or NB.

Just ideas, these things are rarely so straightforward.

 

[AiponGkooja]

Don't mean to hijack the thread at all, but thank you for the tips, Idontcare. I was unaware of those trends.

 

[California Roll]

Originally posted by: Idontcare

Originally posted by: California Roll
I was always a bit confused about this. Running small shows definitely higher temps, but I can run stable for several hours at small, and then immediately try it at large and have it blue screen in 10 seconds. For this reason I just stuck with large to save time.

Just stating the obvious here, but which one causes your system to be instable (small or large) solely depends on which component in your system is instable.

If large is failing, but you are trying to overclock the CPU then it suggests the CPU is not really the cause of the prime 95 errors but rather the memory or the NB which was also overclocked in the process of overclocking the CPU.

They aren't entirely independent either. Its just a rule of thumb. Its all using the same hardware so you can't expect the results to always be binary in terms of flagging the limiting peice of hardware.

But the easy way to determine what is happening with large FFT for your specific situation is when you see a large FFT failure then go into the bios and only change your CPU multiplier to be lower by one unit (say from 9x -> 8x)...leave everything else including voltages the same. Now run large FFT again. If it fails again then you know it isn't CPU (because you just underclocked it by nearly 12%)...which leaves you with memory or NB.

Just ideas, these things are rarely so straightforward.

Wow, I just had a light bulb go off. Thanks for the great explanation.

It's pretty obvious now. Prime/small is pretty stable so Vcore should be ok. As soon as I go Prime/large, almost instant blue screen which means my NB voltage is too low?

I'm stressing 8x400 now as I type this. Bumped voltage to 1.29v and NB to 1.2v. I'll bump NB voltage up if it doesn't stay stable. Once it is, I'll see how low I can get Vcore.

 

[Idontcare]

Originally posted by: California Roll
As soon as I go Prime/large, almost instant blue screen which means my NB voltage is too low?

That or your ram is under-volted/over-clocked too much. You should run memtest+86 from a bootable thumb-drive or CD just to confirm your ram is not having problems.

At 400FSB the ram is operating at a minimum speed of DDR2-800 which can really push 2GB sticks or 4x1GB configs.

 

[California Roll]

So far 1.3v Vcore and 1.3v MCH(NB) looks stable after 1 hour both small and large Prime. Going to start running overnight tests now. This is at 8x400. Bumping up the MCH voltage helped out quite a bit. Thanks guys!

 

[California Roll]

Gah, for some reason 8x400 isn't very stable while 9x356 is. /headdesk.

 

[Tempered81]

higher fsb is tougher to keep stable, sometimes requires more volts.

 

[Idontcare]

Originally posted by: California Roll
Gah, for some reason 8x400 isn't very stable while 9x356 is. /headdesk.

My DS3L's (I have 5) aren't stable at 400 either. They all run 9x367 just fine and dandy.

Have you determined which component doesn't like the 400FSB? Is it the ram, the NB, MCH, FSB termination?

FWIW have you checked to see if you really lose much performance by going with the slower FSB? For my applications the difference between 8x vs 9x at the same net CPU clockspeed was <0.2%.

 

[California Roll]

I don't have an option in my mobo for FSB Termination. Is CPU Termination the same?

 

[rbk123]

I would try putting your NB voltage back to normal and bump your memory voltage to 2.1 and see if it runs more stable. If it doesn't, you've ruled out memory; if it does, you've found your culprit.