Slashdot Mirror

http://www.lesswatts.org/projects/applications-power-management/race-to-idle.php suggests that it's better to run faster for a short time than to run slowly.

I'm not quite sure what you mean when you say "None of what Intel did to Linux with Moblin has any repercussions for anyone not using an x86-compatible Intel processor." For now I will interpret that as "they did nothing of interest for machines with CPUs from AMD/ARM etc.

Arjan van de van's work on asynchronous initialization of kernel subsystems means you will spend less time waiting for the kernel to finishon all sorts of CPUs - not just x86s. Powertop works on CPUs other than Intel's and has been used to help monitor power consumption of various program running on Linux.

Surely the fact that much of this work has gone upstream/mainline is a positive thing rather than a negative one? It's hard to tell which way you view this from your comment...

http://lesswatts.org/

Tune your system as per http://lesswatts.org/tips/graphics.php
And move along.

How is it different from http://lesswatts.org/tips/ethernet.php

http://lesswatts.org/tips/disks.php

Not really. A CPU running at half speed uses something like 70% of the power that it does at full speed. So it's better to run at full speed for a short time, then go into power saving mode than to run at slow speed for a long time. This has been called "race to idle", and reminds me of the de facto motto of my old military school, "hurry up so we can wait".

That said, Tom's Hardware did make a pretty big blunder on SSDs and battery life before, even having the gall to start that article with "Could Tom’s Hardware be Wrong? No, our results are definitely correct.". I haven't RTFA, but I'd be quite hesitant to take their word on anything to do with power consumption without carefully examining the methodology of their tests.

http://www.thinkwiki.org/wiki/How_to_reduce_power_consumption http://www.lesswatts.org/projects/powertop

Mod parent up, this is very true.

I have a Vaio and Sony basically don't care about respecting ACPI standards... That lead to an annoying and long-lasting screen backlight problem.
So devs have to guess and reimplement quirks that were designed for Windows while all along everything should just be following standards.

Anyway, the http://www.lesswatts.org/ site has interesting things about reducing power usage on linux, including PowerTop which will tell you what is using up most cycles/power on your box.

It's incredibly hard to say because the summary doesn't provide enough detail in and of itself to diagnose the problem (e.g. which graphics card, which chipset, which drivers are being used, which version of Ubuntu and so on). The most likely explanation is that hardware is being left on in Linux that other OSes are powering down when on battery. Examples of this:

• Wired ethernet ports that are often put into some off state under Windows such that they will no longer work until the laptop is plugged into the mains but saving power while not in use while on the battery.
• Similarly if the poster is using a particular graphics drivers (free or closed - depends on the hardware) they may not be powering the hardware down as aggressively as the drivers on another operating system. I've seen Intel graphics cards on Windows that reduce display quality presumably to increase compression (you can visibly see the artifacts) when on battery to decrease power draw.
• Hard disks might not be spun down as often (or at all) under Linux.
• USB sockets may not be auto suspending depending on the version of the distro/hardware.
• The tickless kernel may not be working effectively (or at all depending on kernel version) - there might be a program that is preventing the kernel from idling for a long period of time because it is doing some unnecessary program (this may tie back into graphics drivers again).
• The SATA controller might not be powering down as it does on other OSes.
• The screen might not be as dim as it is on other OSes.
• The sound hardware might not be powering itself off properly/completely.
• The wifi might be be being put into a low power mode/being turned off on other OSes.
• There could be bugs in a driver under Linux.
• Other OSes might have a program monitoring temperature sensors and scaling hardware functions appropriately (e.g. slowing down fans if the machine is cool).
• And so on...

As you can a myriad of reasons and not nearly enough information to whittle down the cause. Further how do you know each OS is using the same defaults? It could be that Windows says you are running out of battery later than Linux does (I'd imagine that this sort of thing could only account for 10 minutes difference to actual empty battery though) or the display is defaulting to a different brightness - it could be that lots of little things are adding up to the major difference.

A few years ago I had access to a Thinkpad T60 and it would draw two watts less power under Windows XP than under Ubuntu Gutsy. That doesn't mean things don't change over time but nor does it mean that people aren't seeing real problems now. If you know how to constructively help, things can get progressively better on your system but it can take some time and you need to know how to track these things down. Tools like powertop help and developers have been putting together good power management practices for Linux guides. However in all honesty posting to Slashdot is unlikely to help you obtain a solution (and indeed there is no guarantee of a solution even over a long period of time).

It's incredibly hard to say because the summary doesn't provide enough detail in and of itself to diagnose the problem (e.g. which graphics card, which chipset, which drivers are being used, which version of Ubuntu and so on). The most likely explanation is that hardware is being left on in Linux that other OSes are powering down when on battery. Examples of this:

• Wired ethernet ports that are often put into some off state under Windows such that they will no longer work until the laptop is plugged into the mains but saving power while not in use while on the battery.
• Similarly if the poster is using a particular graphics drivers (free or closed - depends on the hardware) they may not be powering the hardware down as aggressively as the drivers on another operating system. I've seen Intel graphics cards on Windows that reduce display quality presumably to increase compression (you can visibly see the artifacts) when on battery to decrease power draw.
• Hard disks might not be spun down as often (or at all) under Linux.
• USB sockets may not be auto suspending depending on the version of the distro/hardware.
• The tickless kernel may not be working effectively (or at all depending on kernel version) - there might be a program that is preventing the kernel from idling for a long period of time because it is doing some unnecessary program (this may tie back into graphics drivers again).
• The SATA controller might not be powering down as it does on other OSes.
• The screen might not be as dim as it is on other OSes.
• The sound hardware might not be powering itself off properly/completely.
• The wifi might be be being put into a low power mode/being turned off on other OSes.
• There could be bugs in a driver under Linux.
• Other OSes might have a program monitoring temperature sensors and scaling hardware functions appropriately (e.g. slowing down fans if the machine is cool).
• And so on...

As you can a myriad of reasons and not nearly enough information to whittle down the cause. Further how do you know each OS is using the same defaults? It could be that Windows says you are running out of battery later than Linux does (I'd imagine that this sort of thing could only account for 10 minutes difference to actual empty battery though) or the display is defaulting to a different brightness - it could be that lots of little things are adding up to the major difference.

A few years ago I had access to a Thinkpad T60 and it would draw two watts less power under Windows XP than under Ubuntu Gutsy. That doesn't mean things don't change over time but nor does it mean that people aren't seeing real problems now. If you know how to constructively help, things can get progressively better on your system but it can take some time and you need to know how to track these things down. Tools like powertop help and developers have been putting together good power management practices for Linux guides. However in all honesty posting to Slashdot is unlikely to help you obtain a solution (and indeed there is no guarantee of a solution even over a long period of time).

your wlan scans the surroundings

Windows has better ACPI stuff because most of the drivers are 3rd party, so while its not scanning the card sleeps, eventually NM+well supported cards will catch up, e.g ath5k now handles me turning the card on/off, this is a big improvement from custom rmmod scripts (if you want it sooner, go do it)

it has tons of background stuff active

The background stuff isn't "linux's" fault, its down to whatever distro/setup you have, e.g if doubt slackware/arch users bitch about battery life. For example, i run crap loads of background stuff that requires a net connection, it can't magically know that I've decided to watch a film on batteries without a net connection.

you have a colorful UI with FX

I think a lean KDE3 install might compete with XP, running fluxbox wasn't because the DE is particular efficient (which it is), it's because it didn't suit my setup.
Perhaps KDE4 might compete with Vista, but i don't know i ran vista once and it ate my batteries.

and full brightness,

Again changing brightness affects both OSes equally or do you think linux has some allergy to light?

you use the mouse

While the linux touchpad drivers probably aren't as good as the windows driver, my advice stands for windows too, using keyboard/button inputs uses much less cpu than a touchpad.

So what was the point of your post? To bitch about how the background processes and drivers in linux arn't as efficient as those in windows? How about you go fireup powertop and file some bug reports. If you'd understood the point of my post (which ill go out on a limb and say you had no fucking clue), it was that the problem doesn't lie in the kernel (although for the wlan scanning it may), but rather in the background processes (looks at pulseadudio, though it saves audio card power im sure it wastes more in CPU wakeups) and Desktop environment, which over time do actually improve (firefox is still a bad offender but its gone from ~100 wakeups/s to ~40 in 3.5), however if you want to see battery life improve quicker then do something (just filing bugreports helps [1] bitching about it on slashdot does not!)

If you're running on an Intel platform, try running powertop. I can easily gain over an hour of battery life by disabling the services it recommends and reducing the screen brightness.

embedded

First of all, modern Javascript is fast. Even if it weren't, this isn't your grandmother's Intel 8080. Modern cell phones have processors that would beat the pants off a desktop machine from a scant few years ago while using a reasonable amount of power. (Counter-intuitively, using a faster processor saves power because you spend less time running code and more in low-power sleep.)

Pretty much the only things a VM buys you are architecture independence and a certain measure of protection against exploits.

Don't forget cleaner, smaller code and a certain insulation from API changes. Have you so quickly forgotten the pain of the Great Symbian ABI break? With Javascript, there is no ABI to break, which gives the platform developers far more flexibility in improving the platform.

And in the case of WebOS it's not even a bytecode VM (or is it?) - it's interpreting textual program code...

You clearly have no idea how modern Javascript runtime systems work. They're compiled to bytecode for ages, and modern Javascript engines compile down to machine code. Like I said, modern Javascript is fast as hell.

stuff like non-executable memory pages - that would provide a lot of the same protection as interpreted code

There are more vulnerabilities in heaven and earth than are dreamt of in your philosophy. Non-executable pages provide some protection against some attacks, but they're not a panacea.

At least it seems this time they are going to follow through with some good native code options...

They are already there if you really need them. You can write a browser plugin (using NSAPI, the API that's been stable for 15 years) or you can write a normal, boring Linux process in whatever language you want, and have your Javascript front-end communicate with it over dbus. (That's how WebOS reuses libpurple, the same library that Pidgin uses.) But chances are, you don't need to write native code.

5) It's almost not worth it to put the hard disk to sleep. Modern laptop drives you might save .2-.4w over just idle, but spin up might take 5w. So telling hd to spin down every 3 min for instance might actually use more power.

Power savings isn't always about the direct savings. Putting the disk to sleep and keeping it that way (which is admittedly difficult in linux) generates less heat. That in turn causes the fans to spin less and saves more power.

As for power savings between linux and XP, for most hardware linux is much better at power savings but much harder to configure to get that savings. A good starting point is Intels excellent site: http://www.lesswatts.org/. The Ubuntu forums also have some good information. For example: http://ubuntuforums.org/showthread.php?t=847773

When it comes to reads you can't really postpone them - if someone wants to play that music file now and you don't have it already in cache (and Linux already uses unused memory as cache) then you have to hit the disk.

When it comes to writes you you can often delay them so long as no one is waiting on you telling them that you have written the data to the disk (in which case you have to no choice but to hit the disk). This is already tunable via /proc/sys/vm/dirty_writeback_centisecs . Further there are things like /proc/sys/vm/laptop_mode that will try and batch writes when other I/O was going to happen (e.g. when you play that music file all the writes can happen too). Of course, in the event of a crash you lose much more data (as it wasn't on the disk) and you create more disk contention. See the Lesswatts disk tips page for more details.

Anyways, I imaged the drive and blew out the XP install to install ubuntu... other than losing the wifi switch function it's 100% and I found an article in ubuntu forums that talks about how to make that switch function again...

Also try powertop... I was able to get about 4 to 4.5 hours of battery life out of the T60 I was using for work, and pretty close to that with the T61.

Let me introduce you to PowerTOP. Come back after you try it.

O'Reilly News recently interviewed Arjan van de Ven about his efforts to improve Linux performance and reduce power consumption. Arjan works for Intel in the Open Source Technology Center. This interview is approximately 30 minutes.

One of the projects you're probably most known for in the past couple of years is the PowerTOP utility, which I found very fascinating. Looking at some of the gains you've made over the past 18 months, it seems like Linux-based devices are saving a lot more power than they used to. What do you consider the big successes in the past year and a half?

To be honest we fixed effectively the entire Linux desktop space. It's not--PowerTOP is more--it's not just what we fixed with PowerTOP is not individual pieces. We fixed everything. For me that was a success.

Is that everything in terms of not just desktop but servers as well?

Yeah; we fixed not just Evolution. We fixed Firefox; the thing with Firefox was that it wasn't one thing that was broken. Everything had problems and we had to fix all of it. So for me the success was how quickly everything got fixed; it was just amazing.

In this context you consider fixed--everything is no longer broken in the same way or--?

Everything is no longer keeping the CPU out of idle basically.

Do you have a reference machine? I guess I'm asking what's your benchmark for this, a particular software configuration stack or particular type of machine, or are you willing to say it's pretty much every Linux based machine out there?

I'm looking at several machines--my own laptop but to be honest, what runs on my own laptop is what I care about most. At least that's where I got more battery life, this is where I see the changes. I tend to run a quite rich environment on my laptop but I also look at service. We look at all kinds of machines and we see the same trend everywhere in that all the various pieces of it--never polling or keeping the CPU up. They all got fixed.

In fixing this, is there a component of education, for example, saying "Instead of doing a busy wait on a select loop or continually polling you should set a kernel timer and wait for that to call you"?

That's part of it but the biggest thing is that you had no visibility. Just two days ago at IDF I spoke with a developer of the GNOME desktop and he said, yeah; when I saw it happen I fixed it in 10 minutes, but you don't know it's there until you see it from PowerTOP. Adding the visibility turns out to be enough for people to start fixing it. They know how to fix--how to not poll most of the time.

You can't fix something you can't measure.

If you don't see that it happens you don't know it happens and you can't fix it.

Are you getting the same sort of results from other projects you run into?

GNOME was there but it's almost everybody goes oh yeah; we should have not done that; either they fix it themselves or some--a lot of people give them the fix and in general it's like oh yeah; we shouldn't have done that. Unless you see what's happening you don't know what to fix, so the biggest thing that PowerTOP did was add visibility. We can see under the hood what's going on and then we can fix it. And quite often the fix is very simple.

It sounds then, maybe I should be able to say that just about everybody is happy to see this. Is that the case?

Yes; people--all the developers I've worked with--and that's quite a few--they all go oh yeah. Thank you for the fix; we should have no problems in the first place. We didn't know this; it's fixed now. In the beginning I did most of the fixing when PowerTOP was very new and now days the people do it themselves. The developers learn

No, you can easily use PowerTop to optimize your powerusage by disabling/poweringdown Wifi, ethernet, sound and applications. So you can get your computer down from 14 Watt to 7 Watt, of course it all depends on what you need. You will see that what draws the most power is usually software not the hardware, if you run less it will draw less. It's not a price everyone is ready to pay, on the size of your computer and on functionality.

On my 12" laptop there is a 3W difference between a fully lit screen to a turned off screen. Not alot... Read the tips and trick on lesserwatts or Pavels guide to better battery time to get real experiences e.g. IDE controllers..

No, you can easily use PowerTop to optimize your powerusage by disabling/poweringdown Wifi, ethernet, sound and applications. So you can get your computer down from 14 Watt to 7 Watt, of course it all depends on what you need. You will see that what draws the most power is usually software not the hardware, if you run less it will draw less. It's not a price everyone is ready to pay, on the size of your computer and on functionality.

On my 12" laptop there is a 3W difference between a fully lit screen to a turned off screen. Not alot... Read the tips and trick on lesserwatts or Pavels guide to better battery time to get real experiences e.g. IDE controllers..

Linux is known to be more power-hungry than Windows; I noticed the same on my computers.

Windows XP works about 40min longer than openSuse11 on the same machine, using default settings.

Here is some reading material:
- http://www.lesswatts.org/projects/powertop/
- there was a white paper written by folk from Intel, I don't remember where I found it, but it could be somewhere here: http://oss.intel.com/en-us/casestudies/

You need to switch to a tickless kernel, and tinker with powertop - that should improve things.

Note that in my case, none of the powertop tricks had any impact - I was surprised to see that no matter what I did, the estimated time would always be 1h45min. This is still an experiment in progress, so don't count this feedback as 100% certain.

Your right, the BIOS doesn't specifically look at the hard drives and say X is installed on the computer. What it does is reports that ACPI is enabled and if the OS is able to, it can use it. When the OS attempts to use it (which all moder OS's do) it presents the BIOS with an Identification string then the BIOS reterns any specific values it has for that OS if it has used the DSDT portion of the APCI 2.0 spec. In the case of Foxxcon, it didn't return anything or returned errors because it didn't know how to handle linux. Some main boards don't even use that so it would be a default return regardless.

They did not "write some program into the bios" that checked is Linux was installed and then purposely screw it up. What they did was fail to handle linux properly on the return. They could have sent a default windows back or they could specifically write for linux but instead, they did nothing. The ACPI part of the BIOS is "an abstraction layer between the OS and platform firmware and hardware. This abstraction allows the OS and the platform to evolve independently. Not only should a new OS be able to handle old hardware, but an old OS should be able to handle new hardware." When Foxxcon decided to implement the Differentiated System Description Table (DSDT) for their boards, they didn't provide a default fall back or Linux specific information which caused the faults.

Now it is entirely possible that it was some other part that failed to return properly as the spec is quite large. But this problem wasn't the result of malice.

I haven't really paid much attention to Vista DRM one way or another. But even an objective observer would at least actually try the things he Gutmann says can't be done. Rather than spend the money and try, the author cites a sales website, and a clearly photoshopped "example use" on the second page. Of course salesmen are going to say everything's possible. As the recent Vista-capable suit shows, you can't rely on such claims to be accurate.

And on the final page, we see a few interesting bits of history. People have noticed stuttering on playback, due to scheduling priorities between network and realtime playback on Vista. But more interestingly, we have a guy who's talking about how If I was trying to engineer a system with long battery life, this would be unwelcome news. And the less said about that amusing analysis of clock cycles the better.

AMD has started open-sourcing their documentation which is great, but don't forget about the competition:

Intel has built some great tools and is becoming more open-source friendly all the time. Think PowerTop and their whole LessWatts stuff, think their linux drivers.

nVidia hasn't produced any open source drivers. However, their blob drivers have always worked like a charm for me. This may be somewhat of a clash between ideology and practicability here, but I prefer the nVidia/Linus/"DO STUFF" approach to the AMD/RMS/"Ideology is important" one. While not being completely open, nVidia graphics hardware has enjoyed great linux support for quite some time and that's what counts to me.

for i in `find /sys -name "rf_kill" ; do echo 1 > $i ; done

for i in `find /sys -name "rf_kill"` ; do echo 1 > $i ; done