I started overclocking the QX9650 by setting its multiplier to 12, which would yield a 4GHz clock speed on a 1333MHz front-side bus (whose base clock is 333MHz). I initially raised the CPU core voltage from the default of 1.25V to 1.2625, just to help things along. The system came up and immediately began to POST, but then locked in mid-POST.
I tried several times, and the problem persisted.
After recovering to the BIOS defaults, I started cranking up the voltage in an attempt to achieve 4GHz. A little extra juice allowed the system to begin booting Windows, but it crashed before completing the boot process. Things got no better as I stepped up to 1.3V and then 1.325V. I could have gone for more voltage, but I figured backing down on the clock speed a little bit would probably be the best path to stability. After several attempts at 3.85GHz and 3.795GHz with a slightly overclocked bus, I finally settled on a stable config: 3.66GHz at 1.2875V on a stock 1333MHz bus. I then took this screenshot:
It's like a postcard. From a vacation. In megahertz-land.
This setup proved stable while running four instances of Prime95 for quite a while, so I called it good. The QX9650 also ran through a couple of benchmarks flawlessly at this speed.
I'd say that's an acceptable start for Intel's 45nm process, although the actual clock speed is only 166MHz faster than what we reached with our 65nm QX6850. If this chip is any indication, Intel easily has clock room to release some Penryn-based parts at 3.2 or 3.4GHz, at least, and it's still very early in the game for 45nm.
|Nvidia recalls Shield Tablet due to battery fire risk||37|
|Friday Night Shortbread||92|
|Mozilla CEO protests Win10's default application setup process||123|
|Deals of the week: Samsung's 850 EVO 1TB for $310 and more||52|
|Report: new Google Glass is a clip-on model for businesses||14|
|14 million have upgraded to Windows 10 in its first 24 hours||91|
|EVGA X99 Micro 2 mobo offers USB-C in a microATX package||13|
|The Tech Report Podcast is live on Twitch||6|
|Wake-from-sleep vulnerability leaves UEFIs open to attack||48|