Ivy Bridge underclocking?

Warning: Long saga follows.

So I have this i7-3610qm processor. It's about 58 times more powerful than my desktop pc, which... truth be told still is useable. And when the Ivy Bridge processor is running at full burn, my battery tends to last about as long as a very small snowball in a campfire. So when I don't need that much power, I'd really like to find out how low it's possible to go. And what, exactly, is drawing the most power.

Question is - is it possible to do anything beyond the usual flags and throttling schemes, to get the processor running at lower speeds? Is it possible to single out the Ivy Bridge gpu module? Is it conceivable to adjust the bus-speeds?

For example, on my Asus (which like all other Asus laptops are completely locked in all ways, including the unnecessary ones), I can disable all leds, keyboard lights, unnecessary devices, and so on. There's no swap file on my system, I use an ssd, I've turned off most services that keep going in the background all the time. And get a power-draw while on battery+wifi that looks like this:

While fiddling around with something on the screen, the draw is around 13-14w. It idles down to 11.5w at the lowest (the scale is upside down -- the hwinfo64 graph is on the negative axis, since the battery is discharging ). Disabling wifi and closing all programs and services can allow it to idle down to 10 in a really good moment.

Using some of the throttlestop flags (see this wholly excellent thread here), I am not able to get the total package draw below 10w in the same conditions (the biggest saving is when running heavy services in bursts, since the processor idles more quickly).

Basically, as long as there's traffic on the bus, and there's io - just the keyboard, and some redraw taking place, the drain (as read by the battery discharge) goes up to about 13-14w.

And since I'm completely useless when trying to figure out things specifically, I need help here. As far as I understand, the wifi module at most pulls 2w. The screen on the lowest brightness is pretty modest as well. And the processor itself actually draws fairly little power when idling. The nvidia card isn't turned completely off - but it also does draw very little power, apparently. Meanwhile, I've seen desktop Ivy Bridge variants that drop down to as little as 6-8w on the core package.

So here's my problem - what is drawing the most power here? Thanks to Asus' boneheaded bios tweak conventions, I've yet to install these 1.35v ram sticks I have (then the laptop won't boot). And there's no way to adjust the bus-speed or the core voltage to see how that would affect the overall package draw. But those would be my first two picks - making sure the bus would be allowed to drop very low, along with the core clock and the "bridge" module. And then add lower voltage ram to match that. Question is, would that work? If anyone have tried - how much would you conceivably save by changing bus-speeds and ram?

Last part is the hd4000 graphics card. This seems to be idling relatively low as well. So where do the last 5w go? Is it essentially the locked bus-speeds that keeps any activity at all jump the watt-drain? Or is my math off, and this is as low as it can go?

I'm guessing other laptops may not be locked in this way, so I'm wondering if you could help me figure out how low it's possible to get here. Any advice on reducing power-draw in software - and any thoughts on ways to flash parts of the firmware, to indirectly affect volt/bus with tdp profiles on an "unlocked" bios, or something else that sounds at least as crazy - that would be great. Ways to achieve it more directly - is it possible to change the range of the limits for overclocks somehow? Are the limits actually programmed on the processor logic, and can't be changed? Anything people can come up with would be interesting to hear.

 

Did you take into account the power consumption of the chipset, onboard audio, NIC, and other chips that are integrated into the mobo? Some of these chips can use shockingly high amounts of power thanks to poorly-written firmware.

 

You can turn off CPU turbo in the BIOS if it has that option. That stops the CPU from running at its top frequencies.

 

i don't like cpu turbo cause it often makes the laptop overheat and frankly intel cpus are powerfull enough even withut turbo, i like low temps and silence so i always deactivate it in power management tab by setting cpu max usage at 99%. There's no way to reduce power consumption at other states since core i cpus don't allow undervolting like good old core 2 duo.

As for lowering power consumption at idle states, the only way i see is to put only one memory stick instead of two (since 1,35V ram rarely works and won't save much power anyway) or put a ssd like samsung 840.

 

Assuming you're referring to the Asus N56vz, 12-14W is about normal for this type of setup. With modded BIOS and/or firmware (if they exist) you may likely be able to reach 10-11W at idle with no wi-fi and lowest brightness. 1.35v vs 1.5v RAM won't make a lick of difference. Single RAM stick may help slightly but you're talking about minutes difference.

Best you can do is set CPU power in power options to "power saver", set power options max/min performance to 0% (which is just minimum the chip can run), set screen to min brightness, turn off wi-fi. Another thing to do since your machine supports Optimus (I think) is to run the nVidia feature from the nVidia control panel that shows GPU activity and see if the nVidia GPU is coming on or not. Some apps/utlities poll the sensors on the GPU and will constantly wake the 650m. Also I believe Asus have a power controlling software. I would try to use that as it will likely offer best performance and battery life. I know on an Asus netbook I had it made a big difference, and also the Clevo control panel works great with my Clevo.

But in a lot of cases, the machine firmware and BIOS are not optimized. This was the case with the 11.6" Clevo I have. From initial release battery life was only 3.5-4 hours when it should have been closer to six. Firmware and BIOS updates eventually made it 6 hours. Sometimes you just don't get the support the machine needs to optimize battery life unfortunately.

 

Mm. That's what I'm wondering, see. The x86 type chipsets with north/southbridge, and now integrated bridges, and so on, have always been drawing too much power. But the thing is that both the processors and the chipsets will function perfectly well on lower voltages and bus-speeds than they typically run on.

Tested it on my old amd setup, for example. Default on that system was max bus-speeds and lower multipler - which put it over 15-16w on idle in the same conditions as the example over. When I dropped the bus speed and the clock rate down as far as it went before the system became sluggish (not unstable - just slow), down to about 300Mhz, the core package pulled about 4-5w on idle (together with screen+wifi+disk, it still was lower than my EeePC).

Seems to me that's should be doable, even on a large chipset, on one of the intel chipsets as well. Except that.. there's apparently no settings anywhere to do it with. Either in the half-way exposed bios, or the acpi functions. Is there a table of some sort that's part of the chipset package of the firmware, or something like that..? I mean, there's nothing physical that stops you from setting any random i7 to have a dram:fsb at 1:2, and run on half the normal bus-speed on the lowest states, is there.. Then let it run to full bus-speed/800x2 when it hits the higher multipler states..?

 

If the BIOS doesn't support it you can't do it. Sometimes there's features enabled in the BIOS just not accessible through the menu. Prema and I went through the BIOS for the Clevo W110ER and unlocked a lot of potential that was there just wasn't accessible through a menu. Likely something similar on your laptop, but without the tools and skills you won't know for certain. And even then likely features like RAM ratios won't be available.

 

Sandy and Ivy Bridge systems are not very happy unless they are running at a BCLK speed of 100 MHz. You can usually only go +/- a few percent before you will run into instability issues.

When a core is spending 99% of its idle time in the C6 low power state, I don't think there is much to be gained by using tricks that used to work on previous generation chips.

 

*nods* Thank you for the input. So essentially the memory bus/bridge needs to stay at that frequency for the rest of the core&low state drops, etc. to function..?

Kind of makes you appreciate things like the tegra chipset, with variable clock and differently clocked cores with power-gating, etc..

Hopefully there will be upcoming processor.. processor&memory bus cores..? that deal with thread response and processor activity in the same way as that. I mean, I'm not a processor designer, but they're already essentially restoring activity on the iCore processor cores from idle states, with a signal that begins on a 100Mhz polling, right? That's already pretty slow. So I'm imagining that the road up to using a sleep/idle scheme with an integrated memory bus.. with that bridge on the die or off the die.. where the design cuts power on all but one core on inactivity, isn't completely inconceivable...? Does it require an integrated on-die solution?

(..apologies for completely random speculation and questions^ ).

 

Everything you mentioned has already been done by Intel. We've had power gating for idle cores since Nehalem, and Ivy Bridge introduced power gating for the memory controller. IIRC the cache and the PCI Express bus are power gated as well, but I'm not 100% sure. If you look at the following Ivy Bridge die shot, you'll see there's not much else Intel can shut off:



Also, I'm not sure what an integrated memory controller has to do with power management, but that's also been on Intel chips since Nehalem.

 

I am going to throw this in the mix. Maybe you guys are beyond me but here it goes. To OP you have "Power For Gear"? If so click advanced, then a drop down shows up. If the same as mine and maybe not. Click advanced again a new window shows. That is the money. Find the CPU "TDP". Rock that and call back?

 

I see..

(And as before) please note that I really have very little specific knowledge about what I'm talking about here, and can't tie names of functions to the actual task being done by them, etc.

But the problem, I'm wondering, could be that the memory bus would essentially always need to be turned on. So if it was possible to integrate it on the die, it'd be easier to negotiate working transport at lower speeds when that would be appropriate, without losing response time. As it is now, wouldn't the only time it's actually turned off be when the computer is in a sleep-state..?

In the same way, if there's any kind of activity on the cores (which there has to be even if just screen+keyboard is active, and the cores aren't explicitly disabled), then also all the cores would be active and powered on. Making the power-gating essentially not used... right? I mean, it's practically impossible to have a windows laptop turned on and not get even some minuscule task "balanced" between all the cores..

It's just so strange to me that there's no explicit way to handle this in the firmware. What with the push for ultrabooks, and so on, where peak performance should be far down on the list of concerns.

 

I'm not sure how I can explain this in further detail without confusing you even more, so I'll just say that all the things that you seem to be thinking are problems are actually not problems at all and that you can briefly* shut off a whole lot of the computer even when the user is sitting in front of it doing something.

* Computers are fast. Very, very fast. So fast that even if some component completely turned itself off and turned itself back on again the next instant, you wouldn't even notice anything. In fact, many computer parts actually shut themselves down and turn themselves back on several million times every second. You just can't see it, which of course is the whole point.

 

..true, of course. But the idea would be to make some devices turn off more often than the others. Or for longer periods of time without causing synchronization issues.

In the same way that if you're making an event-driven IO routine, that's intended to close the stream, and then to resume again when transport continues. Very often you choose a resume-solution naturally, because you want to avoid data-loss, and because IO is slower than internal memory transport. But if you designed a file-writer for a mobile phone, you might even want to queue up events before writing back the information in a burst, periodically.

Why.. not do the same on a processor-bus? I mean, I'm saying that, but it has been done many times before. What I'm wondering about is why it's not.. you know.. a requirement that we should be able to adapt the hardware programmatically. I'm not needing access to 5Gbps bandwidth on the memory bus now, so drop down to static listen mode, etc. Save up interrupt events for 100ms for these devices, let the other wait 500ms or more.. Etc.

 

nipsen I am getting into a conversation that is very much over my head but because it is still going on here I go. I am interested/confused why exactly you have zeroed in on the system bus speed as the power saving feature you wish/hope for. If I remember correct and I concede I might not. I had an AMD with "power now" or something I forget. It I believe did use some of what you seem to want. By that I mean the RAM slowed (system bus?) also I think. I know AMD and Intel have very different strategies but if this fell by the wayside I must suspect the "Holy Grail" of power savings was not achieved.

On a further note regarding my above paragraph. If I remember correct the AMD CPU underclock was achieved by bus adjustment. It was and still is not the best. Ergo we do not have broad support.

A couple of parallels. RAM say DDR3 uses the same 1.5v or OK fine for me 1.35v. But my point is the speed of RAM if DDR3 has no effect on power draw.

Undervolting is what it is. It works because

How you have "pegged" and determined that bus is/has any relevance in your current predicament is beyond me. That in no way means you are not correct just I do not get it. But I must mention you seem to keep making an assumption that the "speed" will have some effect on the "power draw". All else being equal (V/A/W) are all that matter not your clock speed fixation. I do not fail to recognize your concept but I think you assume that a clock adjustment might have an "affect" on the V/A/W equation but I doubt in and of itself it will have an "effect".

Good luck, I am not an expert on this stuff.

 

..well, it's the ambient effect draw on intel boards. It's pretty much a constant between anything from an EeePC to a desktop board. Change processor, change bus, change ram. And you still have that 10w draw while anything's connected to the bus.

Like Peon said, though - the thing is that intel have implemented a lot of these functions on the hardware level. And I know that for example memory bus timeouts happen. This was one of intel's great new features a.. bunch of years ago. That they allowed the system to idle in those milliseconds there would be no activity.

I'm just not completely convinced they're used in the way that they give you any benefits while the system is powered on and running any programs periodically. Like you point out, amd's approach to power-saving has been different than Intel's. Extremely broadly, you could say that Intel aims for very high peak cpu-speeds, intending to complete a task as quickly as possible, so the rest of the time can be spent idling. This fits into the "boost" concept, among other things. And the idea being that you're making sure that the task has an average power-consumption level that is fairly low, even though the actual processor burst is expensive.

This is something that recurs with Intel's attempts, it seems to me, for example with the idea of putting a frontbuffer on the actual monitor, so it won't need the graphics card to update the buffer 60 times a second.

But it also reveals something fundamental about how they think, and I think this is mirrored in their available processor designs, and could very well be something sprouted from PR as much as anything - that they won't see that a "necessity" of keeping a bus active while anything happens as a need to change the way the infrastructure works.

I mean, the thing is that the actual effect draw of creating a framebuffer and sending it to a monitor is extremely small. With current tech, on either external modules, or the integrated ones on the tegra3 chipset, or on amd's controller - the actual effect-draw involved here is miniscule. What's being discussed at nvidia, amd and any arm-producing or misp-using manufacturer, is how to update the buffer and make graphics context updates in the most efficient way. How to add processing power, without increasing the idle draw, etc.

Here's to hoping intel's new buzzword is "Asynchronous". Anyway..

So the reason I'm homing in on the bus is that it seems to me that 1. it's always active with the same ambient draw, whether the other devices are idle or active. And 2. there's apparently no functionality there to control any of this in software. You could imagine for example that adding 200ms to the response time from a memory operation would allow the bus to idle at an "inoperable" level, etc. But apparently that's not how it works.

This post, and all of the other stuff I've said is basically holistic guesswork, though. I'm not claiming any of this to be correct, because I just don't know. But I'd be interested if anyone has any numbers or know about any good papers on the way the power-gating on intel chipsets works while the system is running. Could be, like I wondered about, that the ambient power-level is necessary for those time-out, c6/c7 state functions to actually work, yeah..?

The thing is that we're hearing a lot of different things about Haswell now. And the more I learn about it, I'm stuck thinking like Peon said, that "but isn't this already there?". Or else I'm wondering "then what new function is implemented to allow this to be an improvement over X?". Should I even care to try this out when it comes out? Are we going to see similar improvements on high activity on high power-draw, like we see when using the power-saving flags, and demotion functions Throttlestop gives you? Etc..

 

The more integrated a system is, the better the overall power efficiency thanks to efficiencies that can be gained by having a guaranteed chain of components (as opposed to having to work with any conceivable combination of parts, as is the case for PCs). This is why Macs have significantly better battery life than PCs and why the iPhone has significantly better battery life than any of the flagship Android phones.

 

..not exactly, but it kind of illustrates a good point. The iphones, specially the second one, essentially had all the graphics modules running on the embedded microcode. Arm-processors have a number of optional instruction sets that ARM provides to customers. This is essentially the same as the java bytecode optimization. The hardware then treats a fairly complex instruction as just a longer instruction call, that completes in no time at all at low clock-frequency. Rather than what you might have seen on the competing symbian phones at that time, where the graphics either were driven in software (this means higher cpu-frequency to complete the larger number of almost atomic instructions, to what typically ends up as less complex functions in the end anyway), or they were run on an external "graphics card module". Enabling that part, and having a soc design that wouldn't actually turn off these modules while the phone was running anything that displays a button -- and you have a higher idle draw than if you just had the arm cores active. There's no magic going on here.

The iPhones that avoided relying on that external module were the best in that sense. And the truth is that what you see on most android and iPhones now of "desktop" effects, is actually driven by embedded microcode on the arm-processor, and not the graphics card module at all. The Arm7Neon instruction set optimizations, for example, these are common across all phones using later arm soc designs.

And the only real difference between the phones is whether or not the OS, the zoom, draw, filtering/denoise/anti-aliasing filters are programmed to actually use only the embedded instruction sets or not.

In the same vein, the latest iPhones actually rely on the external modules more and more, both for graphics and picture filters, stitching photos, editing. Or they tend to keep the external modules active. And very predictably these have a higher ambient draw and lower idle time than for example the second iPhone.

All of TI's omap designs are notorious for a high idle draw in the same way, simply because they all are designed with a board where each of the parts of the soc don't communicate with each other except in terms of "on or off?". So when you could have turned devices off, or made do with a graphics card running at much lower effect, or a memory bus that could have clocked memory down, etc. - this design only either has the device switched on, or else it's switched off. The worst examples are like this: the larger antenna-module has to be operational to enable 3g or gprs transport. And this also adds wifi and gps control.

This is actually still common on the Snapdragon chipsets, along with having unoptimized 3d effect calls in android (this hasn't really been addressed completely until just the last year) which is why battery tests generally favour the system that relies on the instruction set integrated on the cpu -- or more correctly, the instruction sets embedded on the actual die, in the same pipeline as the cpu-cores. This is what saves effect, and it's completely universal across any platform. The same with the use of external modules rather than creating specific libraries for the chipset's specialized microcode -- this is significant, and you can see that effect on certain phones running certain OS-versions on android, iOS, and others.

And note that even if they keep saying they use "integrated solutions", like TI and Qualcomm do, for example, the significant part is whether the use of them actually allow you to perform more complex instructions on lower clock-speed. If you can use the byte-code to run java practically for free compared to a desktop compiled version without a hardware interpreter, etc.

But ideally, I guess what you would like to have is all of the typical multimedia type instruction sets, graphics, sound -- or simply programmable cpus that can run your custom instruction sets -- integrated on the cores. While retaining the low power-draw that "mobile type" cpu had in the first place. With an integrated graphics and memory controller, with shorter pipeline and no large interpreter or transport links.

...by the way, that chipset has already been made. (And it's not used in an iPhone In fact, Apple is going away from the integrated solutions, as I said. Typically it's because of cost - creating specialized chipsets, rather than customized soc designs, is expensive. Comparatively speaking.)

 

Integration is not a hardware-only matter. I thought it would have been clear given the context of Mac vs PC battery life, but I suppose I should have said so more explicitly.

All the effort chipmakers like Qualcomm and Nvidia put into developing a power-efficient SoC is completely wasted by the fact that the handset makers put close to zero effort into customizing Android to run as efficiently as possible on their specific handsets, instead choosing to focus their efforts on proprietary UIs like TouchWiz. The fact that you can get better battery life from a custom rom says it all.

Apple on the other hand takes the opposite approach - they completely ignore the UI and instead focus on making sure that iOS is extremely well optimized for the devices it runs on.