Overclocked, now chkdsk.

[Ho72]

After running my 3770K on an Asus P8 Z77-V Pro for about a year, I decided to bump the speed up to 4.4GHz via the mulitplier. Things seemed to settle in nicely at 1.224 volts (max observed using -.020 offset), temps never went above 77C under stress. No Prime errors, no WHEA events, no weirdness... except: I get random messages about once a week in Win 8's Action Center telling me a disk needs to be checked for errors.

In reviewing the Event logs, the disk in question has an unrecognizable Volume designation: (System Warning) Volume \\?\Volume{e98bebb1-7862-11e2-be65-806e6f6e6963} (\Device\HarddiskVolume1) requires an Online Scan. (Summary Page Events) Chkdsk was executed in scan mode on a volume snapshot. No errors are reported.

I never saw this before I overclocked, so what could be going on here?

 

[OCGuy]

I would back down the speed 100mhz and keep the voltage the same. Also I would find a mobo-specific OC guide (if you haven't already) to compare to your BIOS settings to make sure you are fully optimized.

Is your RAM overclocked with the CPU? RAM that is not completely stable can cause issues if it ever writes to virtual memory on your HDD.

 

[Ho72]

No, RAM is not OC'd, and I did refer to more than one guide. I tried to use the least aggressive settings that resulted in a seemingly stable OC.

 

[jkauff]

I have the same board with a 3570K running at 4400, and I'm not fully stable at less than 1.300v. FWIW.

 

[Ho72]

I have the same board with a 3570K running at 4400, and I'm not fully stable at less than 1.300v. FWIW.

Interesting. One of the guides I used recommended keeping the voltage for the 3770K at or below 1.28 for a 24/7 OC. Obviously I can bump up the volts a bit before I get there if need be. I think I'm going to stay away from anything higher for the moment, but thanks for that info.

Another recommendation was to change the CPU Voltage Frequency from Auto to a manual value of 350, which I have not done. Any thoughts on that?

 

[jkauff]

Interesting. One of the guides I used recommended keeping the voltage for the 3770K at or below 1.28 for a 24/7 OC. Obviously I can bump up the volts a bit before I get there if need be. I think I'm going to stay away from anything higher for the moment, but thanks for that info.

Another recommendation was to change the CPU Voltage Frequency from Auto to a manual value of 350, which I have not done. Any thoughts on that?

I think my chip is probably just not a great overclocker, and in the year since I've been running it at 4.4, it's slowly been requiring slight bumps in voltage to stay stable, so there's probably the wear-and-tear factor, too.

Haven't read about the Frequency tweak, but in any case I try to keep it simple. I've got the Intel insurance on the CPU, so I'm really not worried about running it into the ground with the higher voltage as long as my temps are good. Handbrake is the only program I use that really stresses it, and temps stay in the high 70s-low 80s even for a long encode.

 

[BonzaiDuck]

I can't say what Windows 8 would do or mean with its built-in reporting.

I have a list of things I'd recommend to anyone who overclocks. Among these, even if it costs a little money, I'd say get a spare HDD like a WD "Blue" drive that can hold your OS and essential monitoring software; it can be used later for imaging or cloning. But first use it while you make your overclock tweaks.

This would alleviate both the anxiety and actual risk of disk corruption through successive BSODs until you find your stable settings.

Said it enough . . . but I began to have a pattern of instability episodes that would only occur every week-and-a-half of 24/7 operation. Folks here kept urging me that it was my OC settings, but I was convinced it wasn't, and I seem to have been correct. Instead, it was a matter of buggy drivers and mis-installed drivers -- for instance, my network -- which were always generating red-bang errors in the Event Logs.

Since the resets and much less frequent BSODs seemed to occur with (1) 24/7 operation of Media Center -- disappearing during a month when I wasn't running MC, and (2) approximately consistent with the schedule of DHCP refresh on my network, I focused on one particular "distributed COM" error and solved it. Suddenly, I can measure the alacrity of my network access as improved "now" over "then."

The MC Live TV depends on my SiliconDust tuner device, which is a network device. I found other hardware problems, for instance, malfunction of my onboard USB3 controller due to insufficient resources. But whichever it was "exactly," it has been resolved.

All this time, I had mounting anxiety about disk corruption, and I'd continue to run CHKDSK with low-level repair enabled. It would always give a clean bill of health. But I also ran SFC /SCANNOW, which is supposed to detect corrupt OS components on the HDD. It would only turn up a missing DLL file (MFC80.DLL) which was part of an old, 32-bit C++ runtime library. Now I find that I have one mis-installed software package that generates a conflict between a 32-bit and 64-bit C++ runtime component -- showing as a "SideBySide" error when the software loads.

I had installed an earlier version of the software which was only Windows 7 compatible with caveats, and uninstalling it still left a PDF_file-viewer which still shows up in "Programs and Features." So it would seem that this one, last "red-bang" would only require me to uninstall the latest software version, uninstall the old residual component, and then do a reinstall.

There are complications to overclocking that arise when different causes of instability get confused with your BIOS tweaks -- leading you on wild goose chases. IN my case, the complications weren't there when I originally found my best overclock settings. But if the system is overclocked, any new or arising instability can be misattributed to the overclock when it is due to something else.

 

[Tristor]

That volume identifier isn't strange, it's expected to be referenced by a GUID. I would say if you have run a chkdsk and it hasn't reported any issues you're probably fine. It's possible though that Windows detected an issue from the SMART data on the drive. Chkdsk is not SMART aware, but Windows 8 may be (I am not certain). It may be worth investigating the SMART data on the drive. You can do this from a lot of different tools, among them is Speedfan (which is always handy to have around for a variety of reasons).

I highly doubt any disk corruption would be caused by your OC settings. If it were to occur it would be a very unusual set of circumstances. Strange behaviors from OC typically would be math errors or memory issues, both of which /might/ cause disk corruption, but would be highly unlikely to. It may be worth running a memtest on your RAM, OC or not, to see if faulty RAM may be a culprit.

You can use verified math applications like Prime95, SuperPi, etc. to check to ensure the math functionality of the CPU is fully intact and operational correctly.

 

[BonzaiDuck]

That volume identifier isn't strange, it's expected to be referenced by a GUID. I would say if you have run a chkdsk and it hasn't reported any issues you're probably fine. It's possible though that Windows detected an issue from the SMART data on the drive. Chkdsk is not SMART aware, but Windows 8 may be (I am not certain). It may be worth investigating the SMART data on the drive. You can do this from a lot of different tools, among them is Speedfan (which is always handy to have around for a variety of reasons).

I highly doubt any disk corruption would be caused by your OC settings. If it were to occur it would be a very unusual set of circumstances. Strange behaviors from OC typically would be math errors or memory issues, both of which /might/ cause disk corruption, but would be highly unlikely to. It may be worth running a memtest on your RAM, OC or not, to see if faulty RAM may be a culprit.

You can use verified math applications like Prime95, SuperPi, etc. to check to ensure the math functionality of the CPU is fully intact and operational correctly.

Yeah . . . there are a lot of other reasons besides an unstable OC to cause disk corruption. Best to do regular disk imaging.

Sometime after LGA_775, it became apparent to me that Prime95 and even the Linpack-enabled stress programs will BSOD before simply providing an error message and terminating. I might have had an exchange about it with ShintaiDK back in '11.

OC'ing then seems a "more traumatic" experience. And enough BSODs, you COULD have disk corruption, but I've yet to experience it in more than 20 years. I had a hard disk go "south" in 1987, and another around 1996, I think.

Another story -- While visiting my cousin in another state, I met this woman he employed in his home office, who was all goo-gah about day-trading. Had something like a 21" color CRT monitor with her computer at home -- this was around 2003. Computer wouldn't boot, she brought it to us -- since I was doing all the maintenance on Cuz's network. Right away, I could see "hard disk corruption," said I couldn't repair it -- and it needed a complete OS reinstall on a good HDD. She got a bit huffy with her discontent, then reached for the power switch and just . . . turned off the computer without shutting down! I asked her "Did you do that frequently?" And the answer was -- "Sure. It's the power-switch, right? Why not?"

 

[Ho72]

I had a couple of BSOD's during the OC trial and error stage. Once things appeared stable, I restored a disk image made prior to the bios tinkering. I also had some WHEA events after I thought my OC was stable, but those went away after I raised my offset voltage to -020 from -030.

I'll run memtest or whatever the current favorite utility is and see if that tells me anything. Thanks.

 

[BonzaiDuck]

I had a couple of BSOD's during the OC trial and error stage. Once things appeared stable, I restored a disk image made prior to the bios tinkering. I also had some WHEA events after I thought my OC was stable, but those went away after I raised my offset voltage to -020 from -030.

I'll run memtest or whatever the current favorite utility is and see if that tells me anything. Thanks.

I should've absorbed more details about your settings.

IB is successor to the SB cores, but I would think the same basic parameters apply, despite the TIM problem and thermal limitations.

So I am curious. Where did you get the idea to use a -20 (or -30) mV negative offset? I would find it difficult to just believe that such is recommended in IB OC'ing guides, and frankly, some guides merge OC'ing advice for SB and IB processors.

There are reasons which I understand are unfavorable for much exploration of offset "negative territory." Negative offset is not recommended because it can lead to idle-state instability.

Also, that ASUS board is the successor to my Z68 board, and my CPU is compatible with your board. So I'd suspect that there is a setting under "CPU POwer Management" or somewhere in the voltage tweaking menus for "Extra voltage for turbo mode." You can allocate your voltage settings between those two items. Did you ever try OC'ing the 3770K with an offset of +0.005V while adjusting the "Extra" setting?

 

[Ho72]

I should've absorbed more details about your settings.

IB is successor to the SB cores, but I would think the same basic parameters apply, despite the TIM problem and thermal limitations.

So I am curious. Where did you get the idea to use a -20 (or -30) mV negative offset? I would find it difficult to just believe that such is recommended in IB OC'ing guides, and frankly, some guides merge OC'ing advice for SB and IB processors.

There are reasons which I understand are unfavorable for much exploration of offset "negative territory." Negative offset is not recommended because it can lead to idle-state instability.

Also, that ASUS board is the successor to my Z68 board, and my CPU is compatible with your board. So I'd suspect that there is a setting under "CPU POwer Management" or somewhere in the voltage tweaking menus for "Extra voltage for turbo mode." You can allocate your voltage settings between those two items. Did you ever try OC'ing the 3770K with an offset of +0.005V while adjusting the "Extra" setting?

Actually, I saw the (-) offset recommended in more than one place. I read numerous forum posts as well as OC guides and I don't recall ever seeing any specific prohibition against a negative offset, except for the warning not to go too low for the reason you mentioned. At any rate, (-) seemed appropriate since I was hitting pretty far north of 1.3V early on (@4.3GHz as I recall), using mostly stock settings and just bumping the multiplier. Both of the BSODs happened under load, but that's not my issue now so maybe the chkdsk scenario occurs when it's idling and low voltage is a factor.

What's the current thinking on LLC (could that be the "Extra Voltage for Turbo" you've referred to)? I've read that it's a good thing on newer boards, other opinions say to leave it off or set at 0%.

 

[Ho72]

Regarding my question about LLC above, it appears vdroop is implemented by design. Here's what Intel has to say about it:

VCC (Vcore) and Vdroop Explained

Load line droop (or Vdroop) is an inherent part of any Intel power delivery design. A current proportional to the average current of all active channels flows through load line regulation resistor RFB. The resulting voltage drop across RFB is proportional to the output current, effectively creating an output voltage droop with a steady-state value. Equation 2 dictates the value for RFB that should be choosen to satisfy the Intel VRD specification (the source of RLL) based on a) the number of power delivery phases (N) and b) the equivalent series resistance (ESR) of the inductor used, effectively known as DCR.

The first question that may come to mind is why droop voltage at all. Truthfully, in most cases the designer may determine that a more cost-effective solution can be achieved by adding droop. Droop can help to reduce the output-voltage spike that results from fast load/current demand changes. The magnitude of the spike is proportional to the magnitude of the load swing and the ESR/ESL of the output capacitor(s) selected. By positioning the no-load voltage (VNL) level near the upper specification limit (bound by the Vccmin load line), a larger negative spike can be sustained without crossing the lower limit. By adding a well controlled output impedance (RLL), the output voltage under load can be effectively 'level shifted' down so that a larger positive spike can be sustained without crossing the upper specification limit (such as when the system suddenly leaves a heavy load condition). This makes sense as the heavier the CPU loading the smaller the potential negative spike and vice versa for lower CPU loading/positive spikes. The resulting system is one in which the system operation point is bound by Vccmin and Vccmax at all times (although short excursions above Vccmax are allowed by design).
http://www.thetechrepository.com/showthread.php?t=126

So, if I'm reading this correctly, it appears the way to stay within Intel's design parameters is to assign an offest that keeps Vcc at no load close to the Vccmax (Vid?) and let the voltage drop occur. The graphs in this post http://www.overclock.net/t/1407901/cpu-load-line-calibration-llc/10 seem to present a good argument against LLC, but might it be OK in moderate amounts like 25%?

Thoughts?

 

[ehume]

This certainly explains the source of recurrent advice on not using LLC. Nice find.

 

[BonzaiDuck]

Actually, I saw the (-) offset recommended in more than one place. I read numerous forum posts as well as OC guides and I don't recall ever seeing any specific prohibition against a negative offset, except for the warning not to go too low for the reason you mentioned. At any rate, (-) seemed appropriate since I was hitting pretty far north of 1.3V early on (@4.3GHz as I recall), using mostly stock settings and just bumping the multiplier. Both of the BSODs happened under load, but that's not my issue now so maybe the chkdsk scenario occurs when it's idling and low voltage is a factor.

What's the current thinking on LLC (could that be the "Extra Voltage for Turbo" you've referred to)? I've read that it's a good thing on newer boards, other opinions say to leave it off or set at 0%.

I see where someone else got to these issues before I answered here, so I'll keep it short.

I don't care whether you're running an old Northwood Pentium or the latest Haswell. There are certain aspects of VCORE, vOFFSET, vDROOP etc. that haven't changed so much. the new motherboards with beefy VRM parts may do a lot to eliminate certain types of voltage spikes that you never see. But the advice: try to avoid raising Load Line Calibration to a point where your load voltage is higher than the recorded VID the processor shows for that particular load Ghz speed. There are "hazards."

Can't remember which motherboard you have, but the ASUS boards (that I know of -- extrapolating to the "generation after" or Z77) have an offset voltage (or "voltage offset") and the "Extra voltage for turbo-mode." Most of us starting with Sandy Bridge were overclocking "Turbo mode." I can guarantee -- if you find that setting in your BIOS, you can use it to tune your system for stability for any single vOFFSET setting. If you want higher or lower offset, you only need to compensate your offset changes by subtracting or adding the "Extra V . . Turbo". In my case, this latter setting is in increments of 0.004V, while the Offset is in increments of 0.005V. So if you wanted to make a voltage change of only a couple millivolts, you could do it by adjusting both. Want to add only a millivolt? Offset up one notch of 0.005V, Extra down one notch of 0.004 . . .

 

[Ho72]

^ After some testing, I'm running a +.030 offset with Regular (25%) LLC. This results in .984v at idle and 1.208v under full load (lowest observed running Prime, max was 1.248v). Vid is 1.256v. No errors in either Prime or WHEA, but I had that going before. Now to see if chkdsk rears its ugly head.

EDIT: To expand on the above a bit, I tried running with no LLC using +.045 offset but encountered a Prime error. I finally settled on the above config for stability and now I'm slowly stepping down the offset voltage to move my max observed Vc away from the Vid. Right now, +.020 is looking good, don't know if I can go much lower without increasing LLC and, given what I posted earlier (post 13), I'm not sure I want to do that.

I still have found no bios setting that sounds anything like "Extra Voltage for Turbo".

 

[Ho72]

If anyone's interested, here's the config I'm calling stable with relevant bios settings for the Asus P8 Z77-V Pro and 3770K:

4.4GHz
Asus Multi-Core Enhancement: Disabled
CPU voltage offset +.020v
LLC Medium, i.e., 25% (a compromise I'm OK with at the moment due to its minimal boosting of Vc under load http://linustechtips.com/main/topic/24019-load-line-calibration-why-overclockers-should-care/).
CPU PLL Voltage 1.7v
CPU Voltage Frequency: Manual, 350
CPU Power Phase Control: Optimized
CPU Current Capability: 130%

All other settings are essentially at defaults. Using XMP memory profiles but no tweaks to RAM config. C states all active, etc. Currently idling at .968v with max observed voltage hitting 1.232v which, when processor is fully loaded, drops to 1.2v @79° C. This latest iteration gets me a little farther away from the 1.256v Vid, a margin I think is important in case the software voltage readout is giving me something less than actual.

As I said earlier, I had no obvious stability issues with my old setup but the chkdsk thing was annoying and, even if it meant nothing, I still want to be free of it. I'll know in about a week or so if I've been successful.

Thanks.