Stress-test SW, Windows 7 and "BSOD"

[BonzaiDuck]

After I got a reasonable, tentative over-clock based on what ASUS' "OC-Tuner" and related resources just "gave" me, I've started stress-testing to reduce my load voltages -- hopefully with a reduction in the peak voltage while my I7-2600K is still running at the top "turbo" speed.

In the process -- first while running PRIME95 (latest version I could get) -- I discovered that PRIME isn't trapping core failures within itself [turning "green" to "red"] -- but results in a BSOD if the VCORE is insufficient.

Earlier today, while running IBT at a lower voltage setting, I got a similar BSOD.

I had previously (temporarily) been running VISTA-64 with this system, but failing to keep notes, I cannot remember if PRIME in VISTA gave me any errors to stop a thread -- with this Z68 Sandy-Bridge hardware.

Now I'm running PRIME under Windows 7. I'm guessing that this is either an issue with Windows 7, or the way Windows 7 responds to some of the more obscure power-saving tweaks in BIOS.

Soliciting remarks: Has anyone else observed this? Is your PRIME95 behaving with Win 7 and new chipsets like P67 and Z68 as it did with older hardware and OS's?? Got any ideas if this is fixable? Something I need to configure in PRIME? In Windows? ET-cetera?

 

[sm625]

I've had some computers crash under prime95, others that just stop the thread. I never bothered to look into why I got BSODs, I just assumed it was something that went wrong when the kernel steps on the prime95 code. If a failure occurs while prime95 code is running, then it can safely terminate the bad thread. But if you get a failure when the kernel is doing something, then I dont see how prime95 can do anything about it.

 

[Kenmitch]

In my sandy bridge overclocking adventure prime95 and intel burn test seemed to work just like they did on my p55 platform. Error out if vcore too low. Freeze if vcore way too low. But inwas running windows 7 with it also.

Running at 4.6ghz currently. Was at 4.7 but had random bsod's once in awhile at desktop or surfing web. Passed all stress testing tho. I use the offset voltage as it works best for me.

 

[BonzaiDuck]

In my sandy bridge overclocking adventure prime95 and intel burn test seemed to work just like they did on my p55 platform. Error out if vcore too low. Freeze if vcore way too low. But inwas running windows 7 with it also.

Running at 4.6ghz currently. Was at 4.7 but had random bsod's once in awhile at desktop or surfing web. Passed all stress testing tho. I use the offset voltage as it works best for me.

Thanks, guys. Are you OC'ing with VCORE on "Auto" and the EIST/C1E stuff turned "on?" That's a departure from my past practice, as it might be for several Z68 and Sandy Bridge OC'ers. It would be good to isolate this, and possibly even fix it. With older hardware using VISTA-64, I never BSOD'd in either PRIME or IBT.

So if it isn't a Windows 7 problem, then it's either a hardware setting or something else.

All I can say is this: I'm soooo close to getting a handle on that "instability threshold" at this clock-speed. After getting the voltage down without the crashes, I decided I just had to find out where it fails.

Here's my current approach. Kenmitch spoke to using the "vOffset" settings to temper voltage. This had also been demonstrated on the "ROG" Republic-of-Gamers web-site. I used that to a certain extent, then decided to find out just how "Auto" for the offset scales with OC speed.

Finally, I just decided to reset everything to 3.4 Ghz/3.8 Turbo and see if I could pin it down. It appeared to me -- I won't bother with the details unless necessary that default speed was getting 0.010V (+) from the Offset item set to "Auto," so I fixed it at that level.

By this time, I had discovered another voltage setting nobody seems to have mentioned thus far. In my ASUS Z68 (P8Z68-V-Pro) UEFI-BIOS, it is "Additional Turbo Voltage" which defaults to "Auto." It is easily missed, and one would wonder if it shouldn't have been included in the main "AI Tweaker" menu page. It is instead an item on a sub-menu of that page, or "CPU Power Management."

Since the conceptual abstraction "vOffset" is a factor in vDrop and vDroop, I'm thinking that the Offset adjustment in BIOS sets a "floor" on "Auto" VCORE. This other "Additional Turbo Voltage" seems to set a ratcheted "ceiling" on the same thing. For instance, VCORE can rise to the needed level plus the additional "Additional Turbo voltage." Changing this latter to a fixed value might then limit how much voltage would be applied.

I've proven this by keeping a log and a table of reported voltages. I have two choices: Either boost "Additional Turbo V" to a level that sustains the overclock, or use LLC to trim any "vDroop." I've currently set LLC to "Medium 25%."

By adjusting "Additional Turbo Voltage," I've been able to get the LOAD, reported VCORE down to 1.28V while running PRIME95 and IBT. At this point, it's right on the edge, and I'm about to find the "instability threshold" -- or I just did, having bumped it up another 0.004V.

But the BSOD's are a nuisance. I also noticed that I had entered the title-bar menu of my HW Monitor while running IBT and "cleared" the maximum recorded settings. Not long after that, IBT stalled and the system BSOD'd.

It would be nicer if these software installations would just trap the failures and behave as I had previously known them to. Of course, if you work with some other software while the stress-test is running, you'd expect to see any failure like that as indication of the sort of thing IBT and PRIME95 are supposed to tell you without crashing the system.

 

[Kenmitch]

Thanks, guys. Are you OC'ing with VCORE on "Auto" and the EIST/C1E stuff turned "on?" That's a departure from my past practice, as it might be for several Z68 and Sandy Bridge OC'ers. It would be good to isolate this, and possibly even fix it. With older hardware using VISTA-64, I never BSOD'd in either PRIME or IBT.

I have all energy stuff enabled on mine. Using auto voltage for vcore. Manual offset voltage also. Other voltages on auto. My cores are all set at 46x with not adjustable in OS option. My chip idles at 1.6ghz 1.004v's under load 4.6ghz 1.37-1.38v's I'm using some llc I think it's on medium but would have to check.

I don't know about you but I only upgraded to satisfy my lust for playing with new technology. When I first read about sandy bridge overclocking it seemed kinda like intel took the fun out of it. I'm kinda happy that small issues do pop up when trying to find the best overclock vs voltages

 

[BonzaiDuck]

I have all energy stuff enabled on mine. Using auto voltage for vcore. Manual offset voltage also. Other voltages on auto. My cores are all set at 46x with not adjustable in OS option. My chip idles at 1.6ghz 1.004v's under load 4.6ghz 1.37-1.38v's I'm using some llc I think it's on medium but would have to check.

I don't know about you but I only upgraded to satisfy my lust for playing with new technology. When I first read about sandy bridge overclocking it seemed kinda like intel took the fun out of it. I'm kinda happy that small issues do pop up when trying to find the best overclock vs voltages

Yeah! :thumbsup: This is the sort of stuff I saw during the old LGA_775 days, but "nobody's talkin'" now . . . .

I still have this suspicion that some are either fixing their VCOREs as we used to and volting to needless levels, or doing everything on "Auto" which would then give more voltage than needed.

I KNOW this myself -- even for lower OC's at 4.4 or 4.5 . . . The Auto settings would go as high as 1.35V to 1.37 as reported in Windows. I think I saw an "OC Tuner" result in a review for 4.4 Ghz showing in BIOS a value of 1.28V on the AI Tweaker screen.

Playing with the ancillary voltage settings has now got my load voltage down below 1.30. Simple logic would tell us why the mobo-makers always give a little more voltage than necessary. But I'm pretty sure that the "Auto" values are scaled -- probably a linear scale -- because that's what I'd found by checking VCORE reported in BIOS against various settings until I was able to find how the "Turbo" load voltages matched fixed offset and "Additional Turbo V" values.

Basically everything YOU reported about your approach is nearly identical to what I've been doing -- I get the same speed-step idle V and I've got the same LLC setting. But in my setup, I left the bCLK of 103 as determined by "OC Tuner" and raised my Multi to 45 instead of 46.

Still want to get this green-light, red-light" PRIME95 thing cleared up. Also wonder, with what you report as your load VCORE, if you could "get it down" some more. But all the CPUs are different, . . . . too . . .. If you're going to "set it and forget it" with those stress-test results, you're certainly not volted excessively . . .

 

[Voo]

You're talking about two different things. Prime will just make primality tests of well known numbers. If your results deviate from the correct results you'll get an error, NOT a bluescreen (now that'd be a bit ridiculous wouldn't it?).

What you're experiencing is therefore not an error in prime (no user application on a modern OS should be capable of creating a BSOD) but an error somewhere in kernel mode.

 

[BonzaiDuck]

You're talking about two different things. Prime will just make primality tests of well known numbers. If your results deviate from the correct results you'll get an error, NOT a bluescreen (now that'd be a bit ridiculous wouldn't it?).

What you're experiencing is therefore not an error in prime (no user application on a modern OS should be capable of creating a BSOD) but an error somewhere in kernel mode.

Well, it was totally uneventful, easy Windows 7 installation with uneventful driver installations. The Win 7 install seemed to take about ten minutes.

So I'm wondering if -- with the load and stress of running PRIME or IBT -- that Windows itself would crash. And I was using HW Monitor to get my sensor data. All I can say is it happened when I was constraining voltages a bit more to find that "instability" point. And it didn't happen when those voltages were looser and higher . . . . It had happened earlier at a lower over-clock, when I was doing the same thing, trying to keep the voltages too low. Or -- leaving the voltage settings as I'd had them, and raising the multiplier without changing those voltages . . . .

Maybe it was something other than VCORE. Maybe the RAM needs more; maybe the QPI needs more. . . . I fixed those voltages to specified -- took them off "Auto" -- before I got started on this business . . . Was there ever a case you remember when you might get BSOD's with vDIMM set too low while running PRIME?

EDIT 20 MINUTES LATER:

It just occurs to me, Voo.

We had posted links to the ROG website (ASUS Z68 boards) and other reviews to the P8Z68-V-Pro etc. boards. The ASUS AI SUITE II, which includes monitoring and over-clocking tools, is observed to cause BSOD's when you "cut the horses loose from the corral" and it reaches an unstable OC. Then it reboots and resets itself to the last stable OC.

I'd STILL like to see a case where my voltages are marginal and one of the PRIME95 threads goes "red." But it is either rock-stable, or it goes BSOD on me . . . In this last case prompting me to put up this thread, the difference between stable and unstable was a voltage setting difference of 0.004V.

 

[Voo]

Well, it was totally uneventful, easy Windows 7 installation with uneventful driver installations. The Win 7 install seemed to take about ten minutes.

I'm not talking about the install. While you're running Prime you're still executing kernel mode code and if because of an unstable OC an error occurs there this can obviously result in a BSOD.

So it's basically a race condition where the first error occurs - after all the executed kernel code is under a similar strain to the prime code (most importantly you tax the whole memory subsystem). But basically it's unimportant if you get a normal error in Prime or a BSOD - the problem is in both cases an unstable OC. Sure could be a too low vDIMM or something - I'd first check the memory subsystem in this case - there are different ways to OC a CPU. I'd personally start with a stable OC and then decrease the single voltages and retest it.

 

[BonzaiDuck]

I'm not talking about the install. While you're running Prime you're still executing kernel mode code and if because of an unstable OC an error occurs there this can obviously result in a BSOD.

So it's basically a race condition where the first error occurs - after all the executed kernel code is under a similar strain to the prime code (most importantly you tax the whole memory subsystem). But basically it's unimportant if you get a normal error in Prime or a BSOD - the problem is in both cases an unstable OC. Sure could be a too low vDIMM or something - I'd first check the memory subsystem in this case - there are different ways to OC a CPU. I'd personally start with a stable OC and then decrease the single voltages and retest it.

Your input is greatly appreciated.

Something just occurred to me. I know that the hardware monitoring programs can interfere with each other. And it dawned on me that ASUS AI Suite II is set to load into the system tray at boot-up. However, I've been using HW Monitor: It's last update was in late June and some time after the release of the Z68 chipset; it's reported values -- voltage and temperature(s) -- are consistent with those of AI Suite Monitor. But I'd been fiddling with the HW Monitor just before the last crash. AI Suite was still running in system tray.

Question would be: Is AI Suite accessing sensor hardware while it's running in system tray? If so, there would be the possibility of a sort of software collision . . . Or so I imagine . . .

The last BSOD noted that one of the cores was waiting for either an IRQ or an interrupt. Intuitively, that sounds consistent with the sort of thing I imagine.

IF . . . this was due to the sort of conflict that I imagine, THEN it's possible my voltage was not too low for a stable overclock. I'll have to go back and re-test, and use either HW Monitor or AI Suite but not both.

And in all this -- I'm just speculating.

These stress-tests are quick and preliminary. I just completed a short 3-hour PRIME95 "0,0" a couple hours ago, and ran IBT in "Maximum" stress for 10 passes. Then I loaded TrackMania and beat myself in a race . . . .

 

[john3850]

The problem with these K chips is the vcore is all dynamically preset to the speed of the chip as op reported in the forms.
I have 2500k and at 4700 with 1.408v after dropping the offset from +.025 to +.005 the vcove still hits 1.408v on linx.
I find its almost impossible to lower vcore much as I did with any other cpu.
At a 100% load these cpu demand a certain voltage for each speed which preset and when I lower it less then the preset I get a bsod.
To get the 100% load I use prime or linx.

 

[BonzaiDuck]

The problem with these K chips is the vcore is all dynamically preset to the speed of the chip as op reported in the forms.
I have 2500k and at 4700 with 1.408v after dropping the offset from +.025 to +.005 the vcove still hits 1.408v on linx.
I find its almost impossible to lower vcore much as I did with any other cpu.
At a 100% load these cpu demand a certain voltage for each speed which preset and when I lower it less then the preset I get a bsod.
To get the 100% load I use prime or linx.

I'm thinking if I try to get another 100 Mhz out of this, the voltage requirements will go up the steep side of an exponential curve with respect to speed. I was actually hoping to do it with a lower vCORE than your OC shows.

As I told Kenmitch and Voo, there was another voltage adjustment in my ASUS UEFI_BIOS that is obscured within an arcane submenu of "Ai Tweaker" named "CPU Power Management." This voltage determines -- probably -- just the thing you mentioned: the upper limit of voltage supplied to the "cpu demand" you described. Thus, unless the "Auto" Vcore itself will dynamically respond to any voltage need, this "Voltage added to VCORE in Turbo-mode" would put a ceiling on that additional voltage. But the motherboard will typically supply more than needed -- this is almost an axiom among our over-clockers here.

I only suspect that some people haven't discovered this other voltage setting, but it works just like the "OFFSET" we've been discussing. The Offset moves the entire range of voltages -- from "EIST" idle up to the "Turbo load" -- by reducing or increasing the "vOffset" explained in a December 2007 article published by Anandtech about "Overclocking the QX9650." That was just at the time the new Wolfdale and Yorkfield LGA_775 CPUs were being released. But those voltage components discussed there were no less applicable to what we have now, even with its IMC and iGPU.

I re-ran my test with the "V_xtra_turbo" [my shorthand for it] set to only 0.020V. My tests and best guesses conclude that the stock settings -- 3.4/3.8 -- gave this voltage increment about 0.010 to 0.012V when it is set to "Auto." The test with 0.020V ran through 10 passes of IBT "Maximum-stress" without error, but when I ran PRIME95 against the same settings, I got another BSOD. Since I had a BSOD after about 90 minutes with a setting of 0.028V, I've now upped it again to 0.032V. If it's stable there, I'll bump it up again by 0.004V.

That being said -- this has enabled me to show LOAD voltages of 1.288 to 1.290V. It seems likely, since we're OC'ing with "Turbo-Boost," that there's an IDLE voltage associated with this load value that you would only see when you disable "Turbo" and take the VCORE setting off "auto" -- applying a fixed value to it. Whatever that value might be, it could only be larger than the load values I see here. My load values would be that unseen idle voltage less vDroop and vDrop. Here, of course, I've trimmed vDroop by setting LLC to a "Medium -- 25%" setting. But when running these tests and more often than not, I see a peak value that exposes itself briefly when I stop the test or it completes.

So I might see a load voltage of ~1.29V in HW Monitor (or another software), and after the tests terminates I might see a value in the HW monitor "Maximum" column of 1.34V.

Here I'm speculating that the voltage spike that we DON'T see in load-to-idle transition may be anywhere between 1.35 and higher when added to the the loaded value (plus vOffset and vDroop). That total would overshoot any ephemeral "Turbo-Boost" idle voltage that we also don't see, or only briefly see. We would never likely see that spike show up in monitoring software.

That's why I've been such a maniac about trying to keep my load voltages as low as possible.

 

[john3850]

Excellent read now I need to read more about the offsets and Power Management.
Sure must be nice to have the extra CPU Power Management bios setting.
I tried only once for 5000mhz and it loaded,problem was linx kept dropping the clocks from 50 to 46 probably do to the high temp.
I need install a cleaner ps and switch the radiator fans I have.

 

[BonzaiDuck]

Excellent read now I need to read more about the offsets and Power Management.
Sure must be nice to have the extra CPU Power Management bios setting.
I tried only once for 5000mhz and it loaded,problem was linx kept dropping the clocks from 50 to 46 probably do to the high temp.
I need install a cleaner ps and switch the radiator fans I have.

Is your motherboard the Asrock Extreme 4 [or whatever it's called]? There MUST be some similar voltage control in their BIOS. If not . . . . it MAY be a sad state of affairs . . .

I'd go to their web-site and find the "Contact" link to send them a message suggesting they update their BIOS and provide those settings if they don't exist.

When you say "radiator fans," I assume or guess that you are "water-cooled." On the PSU thing, I once put together cheap PC's for myself and bought the ubiquitous $40 power supply. When I first started OC'ing, it became apparent how inadequate those decisions were.

I've used OCZ ["PowerStream"], Antec and Seasonic. The same tech-review site [Tech Report] pointed me to the OCZ when it was released, but then turned me toward Seasonic. I've been using them ever since. Interesting, though. I understand OCZ bought out PC Power & Cooling, who in turn used re-badged Seasonics for their "Silencer" models . . .

Good PSU's have come a long way! I've been running PRIME95 now Small FFT's for 14 hours continuously. I don't feel any warmth at all coming from that Seasonic X750's exhaust. Its sheet-metal just feels . . . cool . . .

Back to BIOS talk. I'd be willing to bet that a lot people -- even veteran OC'ers -- hadn't found that item in the ASUS BIOS. Seems to me it really belongs on the same page with "VCORE," "Offset," "VCCIO," and the other voltages. Sure -- it's "Power Management," but then -- so are all the other voltages, when you think about it. . .

 

[john3850]

I built this sb as upgrade for a RFx48 c2d and still pefer 1366 over sb.
To me the wb are much easier to install then large Hsf but wb seem to trap more hot air around mosfets then hsf do.
My mb is a ASRock Z68 PRO3 which is the cheapest made mb I have ever seen.
The ASRock extreme in my 1366 is so much better made.
The ocz520adj ps that I am using has to be realy degraded after being used since 2004 and is also the hotest ps I ever owned.
Have a SeaSonic 80+ with a single 40amp line to relace it with.
My 1366 has a original 750-PC Power & Cooling Silencer great ps.
The 120 fans I use do not fully cover the width of the radiator but the 140 fans will.

If I knew these sb realy hit 5000 I would have gotten a 2600 and a better mb.

 

[BonzaiDuck]

I built this sb as upgrade for a RFx48 c2d and still pefer 1366 over sb.
To me the wb are much easier to install then large Hsf but wb seem to trap more hot air around mosfets then hsf do.
My mb is a ASRock Z68 PRO3 which is the cheapest made mb I have ever seen.
The ASRock extreme in my 1366 is so much better made.
The ocz520adj ps that I am using has to be realy degraded after being used since 2004 and is also the hotest ps I ever owned.
Have a SeaSonic 80+ with a single 40amp line to relace it with.
My 1366 has a original 750-PC Power & Cooling Silencer great ps.
The 120 fans I use do not fully cover the width of the radiator but the 140 fans will.

If I knew these sb realy hit 5000 I would have gotten a 2600 and a better mb.

Ah! You got the i5-2500K then? But that's great! You got it to 4.7!! NOW I understand your voltages!! NOW I understand!

Here's where I am . . . . My memory gets a little flaky at this age, but I've been at this since '04. Seems to me . . . that instability with Large FFT or possibly Blend would point to some other problems: RAM and [VTT]/VCCIO. And I can't completely remember . . . if a person FORGOT to run a short LFFT or Blend after adjusting VCORE settings for failure under Small FFT, that it might be possible to push VCORE too high in forgetting about that.

Right now, I'm running Large FFT at about 1.288/1.296V VCORE after a couple failures with that test. I bumped up the VCCIO -- still about 0.443V under the RAM which is about 1.53V. So . . . starting my third hour running with everything in the green . . . . Looks like I'm on the right path . . . the "quick" path, heh-heh. . .

That got me thinking -- did some web-searches to check again . . . I can get this thing up to 4.73 Ghz without much touching VCORE or the multiplier if I can bump up the bCLK just 2 more Megahertz. I have plenty of headroom with the current VCCIO -- I think . .. anyway . . . The goal is 105 Mhz. That's supposed to be almost a cakewalk . . . . I guess I'll see. . . .

I should save all the lower over-clocks in "profiles" . . . . I think this will be the last big effort, and if it goes well, I'm going to begin slowly to put this thing "in service."

Musical computers -- I have two family members queued up for upgrades and fixes. . . . Dang!! While I was typing this, the Sandy rebooted. Progress, though -- 2 hrs, 20 minutes . . . . better than last time . . .

 

[john3850]

Had the BCLK at 104 for a while but when I raised the muiltiplier from 47 to 48 bsod.
Now at 48 alone I had no problems.
You may need reset BCLK to 100 before changing muiltipliers to avoid bsod then reraise it.

Musical computers -- I have two family members queued up for upgrades and fixes. . . . Dang!! While I was typing this, the Sandy rebooted. Progress, though -- 2 hrs, 20 minutes . . . . better than last time . . .

Thats why I built the sandy just in case I need a spare pc.

 

[BonzaiDuck]

Had the BCLK at 104 for a while but when I raised the muiltiplier from 47 to 48 bsod.
Now at 48 alone I had no problems.
You may need reset BCLK to 100 before changing muiltipliers to avoid bsod then reraise it.

Musical computers -- I have two family members queued up for upgrades and fixes. . . . Dang!! While I was typing this, the Sandy rebooted. Progress, though -- 2 hrs, 20 minutes . . . . better than last time . . .

Thats why I built the sandy just in case I need a spare pc.

I have data files going back to 1987, although chances of using a lot of the older stuff is practically 0.00%. I've lost data through failing to keep an "inventory" and back up certain subdirectories (they say "folders" nowadays) before moving to a new machine. Nothing essential, and it turns out a lot of the lost files had been uploaded to my web-site back in '07. This time -- I won't miss a trick . . .

On the PRIME95 stuff, I had to refresh my memory. the Large FFT also puts the screws to the FPU, so -- it turns out -- the problem -- again -- was VCORE insufficient by a sliver.

 

[MadScientist]

BD,
Asrock’s UEFI bios settings are similar to your Asus MB just named differently. I’ve added some screen shots so you can compare Asrock’s bios settings to your MB’s.
To get UEFI screenshots on the Asrock MB insert a FAT32 flash drive into a USB2 port and hit F12.

Optimized Setting - 4.6 Ghz
I thought I’d take Zap’s suggestion and try the one stop shopping optimized settings first. It took me more than 10 seconds though to set it to 4.6 Ghz since I had to input my ram’s XMP profile. The damn thing actually worked. It defaulted to a Level 5 LLC so the load vcore voltages were lower than I expected.
All settings were left on Auto and all energy saving settings were enabled. The bios vcore was 1.360 - 1.368V, but since the LLC was on Level 5 load vcore readings (CPUZ) were 1.336V - 1.344V. Average high temps were 64C for Prime 95 (Large FFts, 20 hrs), and 74C for IBT (max ram, 50 runs), ambient temp 78F. Idle vcore was 1.024V - 1.120V, and average high temp 30C.

Edit: I've set PLL Overvoltage to Enabled, when set to Disabled the BCLK was reading 99.8 (CPUZ) when set to 100.

I tried the 4.8 Ghz setting but it hard locked before I got into Windows. The lit CMOS Reset button on the back of the case is a nice feature.

[/IMG]

[/IMG]

Vcore Fixed Voltage Mode
The Turbo Boost Power Limit is not selectable in optimized settings, but when you switch over to fixed or offset mode the settings can be seen from your last oc. The default is 118 and 95 but changed to 213, 190, and 1 when set to 4.6 Ghz optimized. Since these settings worked I used them. I’ve seen others setting this to 200, 200, 1 and higher.

Other settings:
Internal PLL Overvoltage: Enable, some say to Enable over 4.5 Ghz. Anyone know why?
Core Current Limit: 150, others setting this to 200, but 150 worked in optimized mode.
Additional Turbo Voltage: Auto, others say to set it to its lowest setting 0.004V. Their explanation: If additional turbo voltage is left on auto it'll adjust to what it thinks is needed based on VID values. I didn’t see this in fixed vcore mode when set to Auto. Is the Auto setting activated in fixed vcore mode?
Spread Spectrum: Disable
CPU Load-Line Calibration: Level 1

From a German review of this MB:
LLC-----Bios Vcore----Load Vcore
Level 1-----1.300 -------1.317
Level 2-----1.300--------1.297
Level 3-----1.300 -------1.276
Level 4-----1.300--------1.256
Level 5-----1.300--------1.238

All energy saving settings were enabled.

I left all other voltages on Auto. Others suggest lowering some of these to help lower vcore temps and be a little greener. I didn’t see any change in vcore temps when I did. If your oc’ing your ram, I’m not, it may help raising the VCCIO/VTT.

Intel Specifications
----------Min-----Typ-----Max
VCCSA---0.879---0.925---0.971
VDDQ----1.425-----1.5----1.575
VCCPLL---1.71-----1.8-----1.89
VCCIO/---1.02-----1.05----1.08
VTT

I found at 4.6 Ghz that I needed 1.330V bios to be stable. With an LLC of Level 1 this gave me a load vcore of 1.328 - 1.336V (CPUZ). These are only slightly lower than what the optimized setting gave me. Idle vcore was 1.312V - 1.320V. Average high temps were 63C for Prime 95 (Large FFts, 20 hrs), and 73C for IBT (max ram, 50 runs), ambient temp 78F.

I tried for 4.7 Ghz up to 1.45V. No go.

[/IMG]

[/IMG]

[/IMG]

[/IMG]

Vcore Offset Mode
The problem with using a fixed voltage is the high vcore in idle and at low load. Vcore Offset Mode acts like the optimized settings and increases the vcore under load. Setting it to where you want it is a balancing act between vcore, LLC levels, and Additional Turbo Voltage.

The only good thing I found about Asrock’s Extreme Tuning Utility is that it gives you the CPU Voltage offset for optimized settings. You can use that as a starting point for your vcore Offset Mode.

In my 4.6 Ghz optimized setting the CPU voltage offset is +0.075V and LLC Level 5. When I set the Offset Mode to these settings I should have gotten the same load voltages, but I didn’t. They were lower, 1.320V -1.328V (CPUZ). Low enough to make IBT BSOD after 3 runs. I suspect that in Offset Mode the Additional Turbo Voltage is not kicking in when set to Auto. Raising the Turbo Voltage to +0.027V increased the load vcore to 1.328V- 1.336V (CPUZ). Average high temps were 64C for Prime 95 (Large FFts, 20 hrs), and 73C for IBT (max ram, 50 runs), ambient temp 78F.

Increasing the Offset Mode to +0.080V, LLC Level 5, Additional Turbo Voltage set to Auto, also worked. Load vcore was 1.328V - 1.336V (CPUZ).

[/IMG]

[/IMG]

Since the 4.6 Ghz optimized setting runs great that’s what I’m currently using. The load voltages are just a tad higher compared to the fixed mode voltages but my temps are running about the same. I like that little extra voltage cush to keep it stable.

Since I can’t get my CPU over 4.6 Ghz my cheapo, paid $20. shipped, CM Hyper 212+ heat sink can handle the load temps at 1.34Vcore average (CPUZ).

 

[BonzaiDuck]

MadScientist . . . I happened to click on your profile when I was trying to click "Last post." Tell me you don't follow AMC-TV's "Breaking Bad," and snicker until your sides are sore! :biggrin:

This is extremely illuminating. The AsRock BIOS screens may be particularly useful to John3850, but helpful to me. In some ways, it is better than ASUS UEFI_BIOS. I cannot find, for instance, a setting for the System Agent voltage VCCSA, even though I can set the graphics clock speed, LLC for iGPU, Offset for iGPU, and so on.

You may have proven what has been suggested by ASUS' own people from i7-2600K chips they had tested: that for some 40-50% of the CPUs, 4.6 Ghz was about the limit.

In my case, the Vxtra [for "turbo"] voltage cannot be seen except through an arithmetic of differences from the sensors. I was able to convince myself that in "Auto" it is scaled with frequency. So at 4.5+ Ghz, I think I proved that it was about 0.055V on "Auto." As I said, it is closer to 0.010V at stock or near-stock (with bCLK 103).

I have no certain idea how -- with what sort of algorithm, schedule or formula -- these auto settings are determined, but I suspect that there is some linearity (fairly simple) that determines them. So just before I caught your most recent post, I reset my last attempted OC with an "auto" for this Vxtra, and found that my load voltages for a few IBT runs and a few minutes of PRIME95 were lower than those that occurred with my last fixed settings. So there is another reason to use it: With VCORE on "Auto" and in Offset mode with a fixed offset value, one may need to over-ride the Auto Vxtra and bump it up above what the "auto" gives you.

I've been able to boot to Windows and run PRIME and IBT with the bCLK upped to 105. But I BSOD after one hour of PRIME. I'll have to check my notes, but at bCLK 104 and some loosening of the Offset and Vxtra, I may have run through 20 iterations of IBT "Maximum" without mishap. This would have been at 4.68 Ghz -- up 45 Mhz over the 4.63 with bCLK 103 and mutiplier 45.

I'll probably keep trying to get this straight. I briefly attempted to boost the LLC to "Medium 50%" an hour ago, to discover that my load vcore was running close to 1.36V, so I stopped the stress-test and rebooted.

On the PLL Overvolt setting, one is advised to leave it off. I'll have to refresh myself by going back through some reference material, but I THINK having it on was necessary for S3 "Sleep mode" recovery. Maybe it was the opposite. But I've seen advisories to say "leave it off." Yet -- the BIOS suggests it "might help stability for high over-clocks."
I think I read there was a dilemma that you "might need" PLL_Overvolt for higher OC"s, but then you wouldn't be able to make "Sleep" mode work. Heck! I'd be happy just to leave the machine running under Speedstep . . .

Also, for upping the bCLK within the boundaries that seem prevailing in the advisories, I don't even think I need to increase RAM above 1.5V, or the VCCIO much above 1.08 to 1.10V. They haven't had an effect on getting my PRIME to run more than an hour with the 4.73 Ghz setting.

It just seems that I should be able to get the 105 x 45 = 4.73 Ghz stable, if I can run PRIME for an hour before BSOD. I had run the small-FFT for 15 hours at the 4.64 Ghz setting (bCLK=103), only to discover crashing in large-FFT, and was able to get it to run large-FFT for up to 7 hours.

EDIT: Well, my voltages are about the same for 4.64 as MadScientist's for his 4.6 Ghz settings. Rather than split hairs over keeping a low offset, I bumped it up by 0.015V to 0.025 (having kept it at 0.010V for the over-clocking move up the multiplier-ladder.

Also -- very interesting -- I see a lot of "advice" on the i7-2600K whether for P67 or Z68 chipsets: "Turn Hyper-Threading Off." They justify this with the observation that it's a marginal improvement over 4-cores/4-threads. Obviously, the temperatures are lower. I suspect also the voltages could be dialed back just a bit.

I DID get to 4.73 Ghz (HT disabled), and ran "Std," "High," "V-High" and "Max" IntelBurnTest for 5-pass and 10-pass runs -- just preliminary. Voltages seem to altnerate between 1.34 and 1.36, the higher when IBT is unloaded between iterations. And with or without Hyper-Threading, the temperatures can get up to 76C at a 78F room-ambient. I'll save it and work on it some more later.

 

[BonzaiDuck]

Folks, pardon my rudeness for "double-posting" without someone's response in between, but I thought I'd share this, since I opened this thread concerning "BSODs."

Here is an excerpt from an Sandy Bridge overclocking guide, concerning the interpretation of Blue-Screen error codes with a focus on "what needs to be done" to fix it:

BDOS CODES:
Here is a list of Common BDOS Errors and what to do to get rid of them; these suggestions are from trial and error, and many BDOSes from hundreds of hours of overclocking. I have gotten many of these BDOSes and checked them out (tried to cause them) and I have modified that list, here it is.
BSOD Codes
0x124 = add/remove vcore or QPI/VTT voltage (usually Vcore, once it was QPI/VTT)
0x101 = add more vcore
0x50 = RAM timings/Frequency add DDR3 voltage or add QPI/VTT
0x1E = add more vcore
0x3B = add more vcore
0xD1 = add QPI/VTT voltage
“0x9C = QPI/VTT most likely, but increasing vcore has helped in some instances”
0X109 = add DDR3 voltage
0x0A = add QPI/VTT voltage

As you might speculate, I suspect the author is mildly dyslexic. He calls the bCLK the bLOK or something like that. So . . . good luck managing your BDOS errors.

HEre's the link to the guide he wrote:

http://www.overclock.net/intel-general/910467-ultimate-sandy-bridge-oc-guide-p67a.html

 

[MadScientist]

On the PLL Overvolt setting, one is advised to leave it off. I'll have to refresh myself by going back through some reference material, but I THINK having it on was necessary for S3 "Sleep mode" recovery. Maybe it was the opposite. But I've seen advisories to say "leave it off." Yet -- the BIOS suggests it "might help stability for high over-clocks."
I think I read there was a dilemma that you "might need" PLL_Overvolt for higher OC"s, but then you wouldn't be able to make "Sleep" mode work. Heck! I'd be happy just to leave the machine running under Speedstep . . .

The Asus tech in this post recommends to leave PLL Overvolt enabled when oc'ing. http://hardforum.com/showthread.php?t=1578110

When I use the 4.6 Ghz optimized setting my MB sets it to Disabled. So who's right?

 

[john3850]

Thanks for cool asrock bios post madscientist
This bios stuff was so easy before Intels ME drivers for overclocking came around.
I was starting to loose my trust with these forms now new charts and info.

 

[MadScientist]

I DID get to 4.73 Ghz (HT disabled), and ran "Std," "High," "V-High" and "Max" IntelBurnTest for 5-pass and 10-pass runs -- just preliminary. Voltages seem to altnerate between 1.34 and 1.36, the higher when IBT is unloaded between iterations. And with or without Hyper-Threading, the temperatures can get up to 76C at a 78F room-ambient. I'll save it and work on it some more later.[/b]

You're getting high temps of 76C at 1.34 - 1.36V with that beast of a heat sink you have. I was going to replace my lowly cheapo CM Hyper 212+ but at 1.34V, IBT at max ram, I'm getting 74C max, same RT, so I think I'll keep her.

 

[BonzaiDuck]

You're getting high temps of 76C at 1.34 - 1.36V with that beast of a heat sink you have. I was going to replace my lowly cheapo CM Hyper 212+ but at 1.34V, IBT at max ram, I'm getting 74C max, same RT, so I think I'll keep her.

I could say I've "only" been Oc'ing my machines since 2004, or that I've been Oc'ing my machines "ever since" 2004. One thing I learned to do in my former life of work and no play -- find the info, look for contradictions and distill it. I think I've been gathering information about these processors and chipsets for the last two months. Information -- like the voltage ranges -- seems tentative or missing.

The only thing we have to go on pertaining to a safe voltage range, for instance, is the fact that these processors are 32nm silicon like the Nehalems, and would logically seem to have the same electrical limits.

Then, there's the bCLK. There are enough OC'ing guides which offer it as a limited option, and some articles -- one or more, anyway -- stating emphatically that "we have no empirical evidence over many months of data and usage suggesting that minor tweaks to bCLK can do any harm." On some forums and particularly one of them that was promulgated on others, someone stated that "Overclocking the bCLK was a definite no-no; you must not do it; set it manually to 100." At the same time, an ASUS technician on another forum echoed what I'd seen elsewhere: It's safe up to between 105-107, and you can "get to 110" -- but as you go higher, there's risk of data-corruption as you would be increasing the speed of the disks, and other equipment connected to the PCI-e. But this had been an issue a few CPU generations ago with both AGP and PCI-e overclocking, and the same recommendation prevailed: about 5% would be harmless.

Now -- with all that winded discussion -- back to your thought about temperatures. One thing of which we are reasonably certain: The thermal sensors on this latest generation of CPUs and all which preceded it are not "extremely" inaccurate, but inaccurate enough to be only of some use. One person posted here that he thought that "TCASE didn't exist anymore," but the Intel spec sheet -- omitting as they did the vcore safe range -- anchors the thermal throttling spec of 72.6C to the TCASE sensor. Then there is a story that Intel did something to take advantage of the IHS heat capacity, to allow the cores to run cooler, but allowing them to generate heat early as they ramp up to a load condition.

I also find many, many forum posts and beyond just Anandtech, with people worried about one or more core sensors which seem out of whack, and we had seen this before with LGA775 -- probably with the 1st gen i7 cores.

In specific, I have Core#1 which seems to ride 5 to 8C higher than the other three at idle, with the remaining cores all within a degree or two of each other. At load temperatures, Core#1 varies from the core with lowest temperature by between 7 and 10C. That being said, the "package temperature" in HW Monitor -- which seems to match up more or less with the single CPU temperature value reported in the ASUS AI Suite Monitor, rides along with this miscalibrated Core#1 sensor and always a couple C-degrees above the Core#1 value. With a solid grounding in statistics and probability, I can only guess that the tight grouping of the other three temperatures would suggest that Core#1 is miscalibrated.

This, in turn, would affect the actual throttling which is supposed to occur at 72.6C, and I have now either confirmed or convinced myself that I was watching that happen with my stress tests. So I disabled the "Adapative Thermal Monitoring" feature in BIOS, discovering that my attention to the temperatures all along had left me with peak temperatures only one or two degrees about the spec. As I was doing my stress tests, I kept notes about "prevailing" versus "peak" values of both the VCORE and the temperature.

So now I'm debating whether or not to turn the TM1 and related features back on in BIOS. I can truly say that my "Maximum" stress IBT runs last night on my 4.64 and 4.62 Ghz OC settings give me about 73C in the ASUS monitor. And -- yes -- I was a bit disappointed that a Noctua cooler didn't do just a little bit better. Frankly, I think I need to adjust the QFAN features of the ASUS BIOS. The fans that ship with that cooler don't spin faster than about 1,200 rpm. I believe that at loading we see under the stress-testing, they should do twice that speed.

EDIT: 5 minutes later: And just thinking -- those fans won't ever spin faster than that rpm. I think I'll replace them both with something else. One thing seems fairly evident to me, though. If I can believe the average core load temperatures of the other three sensors, then the single value I see in ASUS Monitor could be 5C higher than it should be.