TR Forums

diasflacog wrote:

What happens if I leave it at manual? I know I get the same voltage 24/7 with this option. What I'm asking is are there any harmful side effects of this? My guess is heat, but as long as I keep my temps down I should be ok?

I haven't gone over 65c while gaming.

That depends on what your bios actually does with these settings. What Jon1984 means is that depending on that setting, the CPU could be fed 1.18V all the time regardless of whether it's idle or not. That is pretty wasteful, as the CPU will clock down to somewhere below 2GHz when it's idle. For example, my 2500K runs at 1.6GHz at the moment at 0.96V. If you somehow force a constant voltage, your CPU would consume a lot more power when it's idle than otherwise, wasting a lot of electricity for 0 benefit. The only reason why you can force the voltage to be fixed is that some extreme overclocks might gain some stability from that. But for your garden variety overclock, it's completely unnecessary and entirely wasteful.

We are still not in the full tilt of summer yet. Unless you are going to have airconditioning the whole time, your maximum temps during the hot days of summer will be higher. Keep an eye on things and be prepared to dial back if instability appears. It is nice to have a "summer setting" for your OC, or you can just run at stock when summer hits.

A lot of us have secondary computers to do the regular stuff while the "new machine" is undergoing testing. That's how we get away with long testing times. We run it like an actual IT business. While we still have our old machines humming along doing their thing, we assemble new builds, test them thoroughly; and only until we are satisfy we will "put them in production". Nothing secret or special, just methodical and time consuming (mostly set, run, check results in a few hours though) work.

Flying Fox wrote:

A lot of us have secondary computers to do the regular stuff while the "new machine" is undergoing testing. That's how we get away with long testing times. We run it like an actual IT business. While we still have our old machines humming along doing their thing, we assemble new builds, test them thoroughly; and only until we are satisfy we will "put them in production". Nothing secret or special, just methodical and time consuming (mostly set, run, check results in a few hours though) work.

Indeed. When I build a new system, I don't start using it until it has undergone a minimum of several days of burn-in tests. Even after that, I typically run the new and old systems in parallel for days or weeks, logging in to the new one but mounting the old one's hard drive over the network. That way I can easily fall back if problems arise with the new build.

Understood

I will set it to adaptive mode then which is what is recommended by asus when OC.

Also I understand that we don't have that real summer heat yet so my temps can def go up during those times. If I notice any weird stuff during summer I will reset the bios back to stock settings. keeping my PC alive is more important than a small OC boost of course.

diasflacog wrote:

Understood

I will set it to adaptive mode then which is what is recommended by asus when OC.

Also I understand that we don't have that real summer heat yet so my temps can def go up during those times. If I notice any weird stuff during summer I will reset the bios back to stock settings. keeping my PC alive is more important than a small OC boost of course.

What you want to do with haswell is set it to a specific voltage when overclocking, then when you finish you switch to adaptive voltage, especially if you are testing with prime.

My chip 4770k is stable at 4.6ghz @ 1.3v, so I have it set to adaptive +0.100v on turbo.

Prime uses AVX, which haswell looks for, and if it see avx code, it pumps up the voltage +.1v only on prime (or anything with avx), this means you might be prime stable but not game stable as when you game you voltage will be much lower. How you turn this off is to set your voltage to a manual absolute setting.

Another way to avoid this is to not use prime, OCCT has a linpack stress test that you can uncheck AVX.

Interesting. I didn't realize that they fiddled with the voltage based on what instruction sets you are using. Crazy stuff.

ColeLT1 wrote:

Prime uses AVX, which haswell looks for, and if it see avx code, it pumps up the voltage +.1v only on prime (or anything with avx), this means you might be prime stable but not game stable as when you game you voltage will be much lower. How you turn this off is to set your voltage to a manual absolute setting.

Cite?

Overvolting that much that during something as intense as Prime95 means that the IC is just about guaranteed to exceed maximum voltage the moment you turn Prime95 off and the voltage spikes.

In fact, a proper voltage control scheme does the exact opposite of what you suggest, by adding an offset (or a more finely graduated dynamically determined set of steps) to make idle voltages even higher (to ensure stability by minimizing voltage dips during sudden load onset) and load voltages even lower (to prevent frying via voltage spikes when load disappears).

Even without it, vdroop occurs because of a physical reality. Without actual citations I'm going to assume this is another overclocking old wives tale, because a lot of them still can't get around the idea that a static Vcore isn't actually a good idea, let alone even possible.

If that behavior in Prime95 is even real, it's only because the chip is throttling.

Not necessarily +.1V, but the increased Vcore may be needed to counter the Vdroop going too low that break stability? I remember having to sacrifice idle Vcore with a larger Vcore offset so that at load, the Vdroop is not enough to affect stability (then I just make sure I Fold on the thing most of the time to not let idle set in).

Flying Fox wrote:

Not necessarily +.1V, but the increased Vcore may be needed to counter the Vdroop going too low that break stability?

By making it higher than the idle voltage? Because that's what he's saying. It's not +.1V relative to Vdroop, but +.1V relative to normal voltage. Again, that's not a good idea, you're going to fry whenever you turn off Prime95.

Also, it wouldn't even help. Vdroop isn't a big a problem as the transitional dip right before it, when you go from idle to load. That dip only exists because VRMs aren't instantaneous in the first place. The whole problem is that VRMs can neither detect nor respond fast enough to these changes, and thus if we could successfully "counter" these changes like that none of this would even matter in the first place.

As I (unsuccessfully) tried to ninja-edit in, if this voltage increase is truly occurring during prime95, it's because of thermal throttling. That is, the chip is being throttled to reduce load and so the voltage correspondingly increases. I can fully believe that tightly written code with AVX puts more stress on the chip than anything else, because it's supposed to be the most efficient(and thus power-using) way of getting that sort of work done. I mean, we already know what kind of power-monsters massive SIMD machines can be: just look at the power draw of GPUs!

I just get frustrated because it seems like a lot of overclockers are fixated on the idea of "One True Voltage" or "One Adjustable Slider to Rule Them All" and thus they come up with more and more elaborate canards to explain things they can't be bothered to try and properly understand. Voltage is a classic example, and unless ColeLT1 can provide citations I'm saying the same about this.

ColeLT1 wrote:

Prime uses AVX, which haswell looks for, and if it see avx code, it pumps up the voltage +.1v only on prime (or anything with avx), this means you might be prime stable but not game stable as when you game you voltage will be much lower. How you turn this off is to set your voltage to a manual absolute setting.

Just to re-iterate, this is a little hard to believe. For one thing, how is this mechanism even supposed to work? If it immediately slams on the voltage the second it decodes an AVX instruction, that means you're talking about instantaneously trying to increase the voltage by 8-9% even though you don't really know how long the program is going to continue using the instructions or even continue to run. It might be a somewhat safe assumption, but that's actually kind of crazy, isn't it? Even if you peek at the entire decode buffer, it isn't THAT big, and thus you are making a drastic change to the operating parameters of the IC based on, what? A hunch? There isn't enough information to make a reasonable determination about what to do, and anything else becomes drastically more complicated for little conceivable reason.

Even then, what's the point? I don't know the structure of Haswell very well or anything, but the general principle is that the entire x86 ISA is microcoded so that all the various instructions are using the same execution units behind the scenes. There aren't, for instance, like 3-4 different types of ALU for each instruction set extension that uses integers. Just however many of the same sort that used by the different instructions. So while AVX instructions might be more tightly integrated/directly-related to the execution units and thus more efficiently load them, it's all the same sort of stuff. So why would they even key off of AVX usage?

If I had a haswell I could write a program that shows that this little tidbit is untrue, but I don't. So unless ColeLT1 has some citations, can we consider this to be provisionally untrue?

Glorious wrote:

Flying Fox wrote:

Not necessarily +.1V, but the increased Vcore may be needed to counter the Vdroop going too low that break stability?

By making it higher than the idle voltage? Because that's what he's saying. It's not +.1V relative to Vdroop, but +.1V relative to normal voltage. Again, that's not a good idea, you're going to fry whenever you turn off Prime95.

Also, it wouldn't even help. Vdroop isn't a big a problem as the transitional dip right before it, when you go from idle to load. That dip only exists because VRMs aren't instantaneous in the first place. The whole problem is that VRMs can neither detect nor respond fast enough to these changes, and thus if we could successfully "counter" these changes like that none of this would even matter in the first place.

Don't really care about AVX or what not. What I saw on my last system was that I can put in a constant Vcore offset for everything, SpeedStep'ed or not. On idle, the Vcore was lowered of course, and I found that I could get away with it being "stable" with a lower offset. However, on load, I found that the lower offset did not suffice, even with the increased stock Vcore. So I ended up needing to increase that Vcore offset across the board. That's why I said I sacrificed a bit for idle Vcore, since most of the time my system will be under load from Folding anyway.

These observations aside, the point to the OP is still the same: I did a lot of testing, tweaking, recording, and retesting, retweaking, and re-recording. A few times until a point I put a stop to that and settle with the settings that I like and can accept (thermals and Vcore wise).

Glorious wrote:

ColeLT1 wrote:

Prime uses AVX, which haswell looks for, and if it see avx code, it pumps up the voltage +.1v only on prime (or anything with avx), this means you might be prime stable but not game stable as when you game you voltage will be much lower. How you turn this off is to set your voltage to a manual absolute setting.

Cite?

Overvolting that much that during something as intense as Prime95 means that the IC is just about guaranteed to exceed maximum voltage the moment you turn Prime95 off and the voltage spikes.

In fact, a proper voltage control scheme does the exact opposite of what you suggest, by adding an offset (or a more finely graduated dynamically determined set of steps) to make idle voltages even higher (to ensure stability by minimizing voltage dips during sudden load onset) and load voltages even lower (to prevent frying via voltage spikes when load disappears).

Even without it, vdroop occurs because of a physical reality. Without actual citations I'm going to assume this is another overclocking old wives tale, because a lot of them still can't get around the idea that a static Vcore isn't actually a good idea, let alone even possible.

If that behavior in Prime95 is even real, it's only because the chip is throttling.

With on-chip VRMs, vdroop is pretty much out of the picture with Haswell, you don't need to worry about it or touch it if you are not a LN2 OCer, it used to directly affect the Vcore, now it affects the VRIN (CPU Input Voltage), which you can pump on its own if you are needing more power to the VRMs.

On my system I have it set to 1.3v (+0.1adaptive) and if I run a prime stress test, I will see 1.4v in cpuz.

Google "haswell avx voltage" and you will see tons of forum post and such. Anyone here with a haswell K chip can confirm if they want to back me up on this, just set to stock speed, set voltage to adaptive and +.001, open OCCT linpack with no AVX and you will see 1.2v, fire off prime and you will see 1.3v. The avx boost is "up to .1v" but in my experience, with prime, it IS .1v this is why I suggest if you use prime for stability testing to not use adaptive, simply use a set voltage, then when you are finished, switch it to adaptive (or just linpack non-avx).

http://www.techpowerup.com/reviews/Inte ... ide/9.html
One of the biggest changes Haswell stability testing brings with it is the behavior Haswell exhibits under certain workloads. If you use an application with AVX-based instructions, Haswell CPUs will boost voltage by as much as 0.100 V when using normal offset voltage values, which can significantly increase power consumption and heat output at both the board's CPU and VRM

Don't really care about AVX or what not. What I saw on my last system was that I can put in a constant Vcore offset for everything, SpeedStep'ed or not. On idle, the Vcore was lowered of course, and I found that I could get away with it being "stable" with a lower offset. However, on load, I found that the lower offset did not suffice, even with the increased stock Vcore. So I ended up needing to increase that Vcore offset across the board. That's why I said I sacrificed a bit for idle Vcore, since most of the time my system will be under load from Folding anyway.

This is correct, with ivybridge, my offset voltage of .1v added it across the board, so even at idle, if the old voltage was supposed to idle at 0.8v, it would idle at 0.9v not horrible but not optimal. Haswell has this option too (also called offset voltage), but has the additional option of "adaptive voltage" which only offsets the voltage when the chip is in turbo mode.

ColeLT1 wrote:

With on-chip VRMs, vdroop is pretty much out of the picture with Haswell, you don't need to worry about it or touch it if you are not a LN2 OCer, it used to directly affect the Vcore, now it affects the VRIN (CPU Input Voltage), which you can pump on its own if you are needing more power to the VRMs.

In other words, it's no longer one of those "Adjustable Sliders To Rule Them All" and thus, hey, we (especially not Intel anyway) don't need to worry about it anymore. Once motherboard manufacturers weren't able to make ill-advised and even more poorly understand mechanisms to allow overclockers to mess with it because of haswell's on-die VRM, it's like it just, disappeared, huh?

To repeat, droop occurs because of physical relationship that didn't just disappear from reality like it did your bios.

coleLT1 wrote:

Google "haswell avx voltage" and you will see tons of forum post and such.

Ah, so Intel supposedly built this REALLY STRANGE and entirely counter-productive mechanism into their shiny new chip, but the only evidence you have is a bunch of overclocking forums where overclockers repeat the same hoary canards with no empiric rigor whatsoever, just rumor and hearsay?

It's not like Intel publishes documentation or anything, I suppose this is hidden away with Appendix H, huh?

Glorious wrote:

ColeLT1 wrote:

With on-chip VRMs, vdroop is pretty much out of the picture with Haswell, you don't need to worry about it or touch it if you are not a LN2 OCer, it used to directly affect the Vcore, now it affects the VRIN (CPU Input Voltage), which you can pump on its own if you are needing more power to the VRMs.

In other words, it's no longer one of those "Adjustable Sliders To Rule Them All" and thus, hey, we (especially not Intel anyway) don't need to worry about it anymore. Once motherboard manufacturers weren't able to make ill-advised and even more poorly understand mechanisms to allow overclockers to mess with it because of haswell's on-die VRM, it's like it just, disappeared, huh?

To repeat, droop occurs because of physical relationship that didn't just disappear from reality like it did your bios.

The Vdroop setting still exists on Haswell board's bios. Vdroop affects the VRIN on haswell which is what feeds the on die VRMs, which feed vCPU.

Glorious wrote:

coleLT1 wrote:

Google "haswell avx voltage" and you will see tons of forum post and such.

Ah, so Intel supposedly built this REALLY STRANGE and entirely counter-productive mechanism into their shiny new chip, but the only evidence you have is a bunch of overclocking forums where overclockers repeat the same hoary canards with no empiric rigor whatsoever, just rumor and hearsay?

It's not like Intel publishes documentation or anything, I suppose this is hidden away with Appendix H, huh?

This is not a forum:
http://www.techpowerup.com/reviews/Inte ... ide/9.html
One of the biggest changes Haswell stability testing brings with it is the behavior Haswell exhibits under certain workloads. If you use an application with AVX-based instructions, Haswell CPUs will boost voltage by as much as 0.100 V when using normal offset voltage values, which can significantly increase power consumption and heat output at both the board's CPU and VRM

My evidence is though building and overclocking a few haswell builds, they all do this in adaptive mode, sorry I don't have a whitepaper, sorry.

Anyone here with a haswell K chip can confirm if they want to back me up on this, just set to stock speed, set voltage to adaptive and +.001, open OCCT linpack with no AVX and you will see 1.2v, fire off prime and you will see 1.3v. *note, you will see the voltage jump .1 when you see prime using AVX, see my pictures below, the non-beta prime will not be running avx code, but it switches around, give it some time and you will see AVX in the results line (like in my pictures) and the voltage will jump.

Here is my proof on my work computer, which is a 4670k @ 4.2ghz (3.9ghz uncore/cache) on stock voltage, just took these pictures now:
Prime 95 no avx (if I saw avx I restarted the torture test to get non-avx) vs Prime95 v273 (both I just did the standard torture test, all defaults).

No AVX = 1.202 cpuz and 1.219 coretemp
AVX = 1.274 cpuz and 1.276 coretemp

This computer bumps it up .075 or so, not quite .100 but I have it at stock voltage, my home computer will jump 1.3 to 1.4 if I start prime.

No AVX:
http://i.imgur.com/aYJ5fb3.png
http://imgur.com/Sa6meeF

AVX:
http://i.imgur.com/xfw8ZQ1.png
http://i.imgur.com/MivHH1z.png



We are getting really off topic but the point is to make people aware of the issue with combination of Prime95 for stability testing with adaptive voltage, if you do, you will get around .1v higher than what you are expecting randomly during the test.

ColeLT1 wrote:

Vdroop still exists on Haswell board's bios, you missread. Vdroop affects the VRIN on haswell which is what feeds the on die VRMs, which feed and will trickle down to your vCPU.

Yes, but it doesn't mean the same thing, as you just explained yourself. Like you said, Vcore is not longer set by the motherboard, but rather the on-die VRM on Haswell. Instead, the VDroop on a Haswell board can only refer to the VRIN. This is a much less finely-grained mechanism, as Intel has effectively taken that level of control away from the motherboard manufacturers.

So, yes, as an overclocker, you don't quite have to worry about it in the same way. It's out of the picture for you, because you now have much coarser level of control.

What I was getting at was that it isn't out of the picture for Intel, and that's what matters. Haswell's on-die VRM is still doing VDroop per core, and for good reason.

Additionally, what I was referring to is more the general tendency of motherboard manufacturers to offer a lot of sliders to adjust various things, many of which are ill-advised and even more of which are misunderstood. When you say that, as an overclocker, you don't need to worry about droop with Haswell, that doesn't mean the problem actually went away. It's still there, behind the scenes.

What I am getting at is that this adaptive voltage thing seems to be yet another one of those ill-advised and poorly understood sliders. Why are you using it, again?

I mean, you've explicitly said that this strange behavior only occurs when it is on, but inexplicably you blame the CPU (and even stranger, the instruction extension AVX) and not the motherboard manufacturer. If you don't have it turned on, your CPU apparently doesn't get goosed with extra voltage.

ColeLT1 wrote:

This is not a forum:
http://www.techpowerup.com/reviews/Inte ... ide/9.html

It's still completely anecdotal, just like a forum. That guy didn't do a test, or even a thought experiment about how his proposed mechanism of action could even work.

And, again, if this behavior disappears when that "adaptive voltage" setting is disabled... yeah...

ColeLT1 wrote:

My evidence is though building and overclocking half a dozen haswell builds, they all do this sorry I don't have a whitepaper, deal with it or ignore it, no reason to be a sarcastic ass.

But, see, you aren't just positing an observation. You are positing causation.

I'm not disputing that you are seeing this, I am disputing that it makes any kind of sense from Intel's perspective. Because, you know, it doesn't.

However, BIOS settings that do strange and inappropriate things and the ignorant overclockers who swear by them, well, that's unfortunately nothing new.

ColeLT1 wrote:

Anyone here with a haswell K chip can confirm if they want to back me up on this, just set to stock speed, set voltage to adaptive and +.001, open OCCT linpack with no AVX and you will see 1.2v, fire off prime and you will see 1.3v. *note, you will see the voltage jump .1 when you see prime using AVX, see my pictures below, the non-beta prime will not be running avx code, but it switches around, give it some time and you will see AVX in the results line (like in my pictures) and the voltage will jump.

First off, the better test would be Prime95 version 26 versus version 27. Apples-to-Apples, as much as we can.

Second off, we're already muddled because what you are really looking at is the VID, which can be different for each individual core in Haswell but yet your tools only report one number.

Third off, if this doesn't happen without adaptive voltage enabled...

Fourth off, are you using blend? Don't do that. You want the smallest size FFT available, but your screenshots indicate sizes of 448K and 1024k That's too big. You're out of the L2 cache at that point. Only use the CPU torture test, which should give you 8-12K FFTs, that will guarantee maximal CPU usage.

I mean, I can understand why motherboard manufacturers might think that goosing the VIDs under heavy load might make sense, I'm just not sure why you think Intel has anything to do with it.

Glorious wrote:

Third off, if this doesn't happen without adaptive voltage enabled...

On the stock "auto" setting this DOES happen, adaptive not required. To block this behavior you have to manually set the voltage in bios, which keeps that full voltage all the time. Try it yourself.

If I had a Haswell I would.

I'm really not trying to dump on you, it's just that what you (or your sources anyway) are claiming as causation is rather shocking.

I guess I have two objections:

1) (Which is stronger) It is extremely unlikely that Haswell detects the usage of AVX and manipulates its VIDs accordingly. Especially since I presume this behavior (adaptive OR auto) only occurs when running a turbo multiplier (like overclocking).

2) (Which is weaker) I find it unlikely that Haswell will directly manipulate its VIDs like that even upon high loads. I wouldn't be entirely shocked to find out that I'm wrong, and the integration of the VRM certainly gives Haswell much finer control over ripple during load changes, but it just still seems so unlikely. If such behavior is occurring we would have to definitively rule out the motherboard first, because that's the kind of crap mobo manufacturers routinely do. That's who I'd initially suspect, not Intel.

Again, I don't have a haswell, but it'd be interesting to see if this behavior occurs under prime95 version 26 running strictly the CPU torture test, not blend.

Furthermore, instead of waiting randomly for the right test to occur, you can configure prime95 with prime.txt to specify exactly what you want for more control and reproducibility.

Firestarter wrote:

you can use CPU-Z to monitor the clock speed in real time:

ya that CPU-Z help me a lot...