Richard Hughes ([info]hughsient) wrote,
2007-03-09 23:17:00
  • Previous
  • Memorize
  • Share
  • Next

gnome-power-manager time remaining profile code

GNOME Power manager often sucks at predicting the amount of battery time you have left. To fix this, I've been working on a new time remaining profile class for gnome-power-manager. I'm using a self-adjusting discharge and charge profile that adjusts for the specific battery and computer that's being used, and also how it is being used. Why is this important?
  • BIOS's frequently lie to us pretty badly.
  • So called "smart" battery discharge chips are often really, really dumb.
  • Batteries sometimes have old or degraded cells that really don't hold much charge.
  • Batteries discharge faster if you are typing than if the computer idle. There's no point knowing how much time you have when idle, users want how much time they have when the computer is being used like normal.
  • Some batteries (like the OLPC or N800) don't give us much useful information and we have to be a bit clever.
  • Some BIOSes from Lenovo are REALLLLLY REALLLLLY BROKEN.
  • Sometimes machines with multiple batteries discharge in series or parallel, which completely change the way we calculate total capacity, and it's often pretty random when they change over.
  • We have a lot of floating point processing power available for some fairly advanced statistics when we are in userspace, rather than in the hardware or in the kernel.
So basically I suggest ignoring the battery capacity, and just watch how long in seconds it takes to change by each percentage point. Doing some clever rate calculations, and with enough duplicate data (which only takes 2 or 3 charge discharge cycles) the time is pretty easy to get. And, wow, it works - remarkably accurately, and more and more accurate with each charge/discharge cycle.


Sub-screenshot of data-profiling
Main problem: How do we prevent collecting bad data? Lots of things break the accurate profiling.
  • The OpenGL screensaver starting
  • The laptop screen doing DPMS off
  • Beagle doing a re-index while charging (large effect)
  • Lots of CPU load (like a kernel compile)
  • Large temperature variations.
So far I'm just rejecting any data collected during a load > 10%, or when the backlight is off, or while the session is idle. Ideally what I would like is are [Profile Start] and [Profile End] buttons that turn off all the power saving stuff and beagle/trackerd cache updates just until we have some sensible data, which we only need to do once. Ideas welcome on how to integrate this with any possible UI.

All of the new stuff is already in gnome-power-manager trunk, but some bits won't work unless you have pretty similar hardware to mine - plus it's got pretty minimal testing. The time remaining in the UI is currently all still based on the old method, but this new method will probably be selectable via gconf. So things are getting better.

  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    switch

    Your reply will be screened

    Your IP address will be recorded 

     
    Help
  • 16 comments

[info]deviant_

March 10 2007, 00:56:05 UTC 5 years ago

We don't need to worry about "real load" vs "normal load". Over time (as measured in discharge cycles) load as compared to current charge converges on a norm unless the user is _deliberately_ using the machine less at some particular charge level (in which case, the smart-ass user gets the bad data that he deserves). It's not exactly an "average" per se, but that's fine -- we really don't have a way to measure it anyway, nor a need.

[info]hughsient

March 10 2007, 17:34:28 UTC 5 years ago

Sure, I think I agree with you. Let the rate converge on it's own.

Anonymous

March 10 2007, 02:15:40 UTC 5 years ago

In my opinion you really shouldn't add buttons. This would require knowledge of when to start and stop the service and extra actions are bad anyway. I think when just all data is collected on the background it should be possible to extract a 'normal usage' pattern. Possibly not as efficient as only gathering data when it should but it would be a lot more Gnomish.
All of this is just my opinion of course :) I'd like to see where this will head to.

Are you by any chance the same fellow that has a near-dead iBook battery? I read this in a blog but I can't find it anymore. I've got a pretty decent one left if you need one for testing.

Ramon. won-at-home.nl

[info]hughsient

March 10 2007, 17:27:31 UTC 5 years ago

Thanks!

Ohh, yes. My iBook battery is very dead (holds zero charge) and they are
quite expensive to replace. My iBook is actually a clamshell, something
like http://www.microdocusa.com/images/clamshell.jpg. The battery looks
like
http://www.studentcomputers.co.uk/laptop-battery/images/lma207l-big.jpg

If you have a spare, that would be great - I would really appreciate it.

Thanks

Anonymous

March 11 2007, 14:36:54 UTC 5 years ago

Re: Thanks!

Aww, too bad. I had a iBook G4 1.ghz with the square-ish battery type.

Anonymous

March 10 2007, 12:12:20 UTC 5 years ago

Thanks!

Thanks for your work on this. Just the other day I was completely deflated when my battery charge indicator went from "47 minutes remaining" to "2 minutes remaining" in about 10 minutes. It was enough time to save my work and logout, but it definitely had me worried!

[info]hughsient

March 10 2007, 17:27:54 UTC 5 years ago

Re: Thanks!

Sounds like a non-linear discharge. I can fix that :-)

[info]hughsient

March 10 2007, 21:07:54 UTC 5 years ago

Re: Thanks!

Cool, thanks for the comment. If you get a chance, it would be interesting if you could try svn and email me your discharge graph just for reference.

Anonymous

March 10 2007, 15:09:44 UTC 5 years ago

Please be more specific

Please, what are those "clever rate calculations"?

Have you considered using a Kalman filter for estimating the battery time left?

[info]hughsient

March 10 2007, 17:33:41 UTC 5 years ago

Re: Please be more specific

>Have you considered using a Kalman filter for estimating the battery time left?

No, but I would love some help if you are a maths expert. My method is based on a modified least squares regression fitting formula, and then just back-integration to get time after we've smoothed the data with a moving average with a fairly high slew rate. Or at least that's the plan.

Kalman can improve on this by not needing an ititial "seed" estimate, although my method only really needs a seed if there is no data, as the seed is disregarded if we have even one piece of experimental data.

Anonymous

March 10 2007, 20:08:18 UTC 5 years ago

Awesome. My battery detection in GNOME is really sub-par, both making any guess on what time I have left as well as auto-hibernate options very randomish.

I hope you can find a way to not need any UI for getting those ratios though... I'd really rather not have to know or think about that. A possible compromise would be a first-run wizard that asks the user to ok such a test run, with some explanations... but really, if at all possible, don't involve me (the user) at all in the process.

Great job, keep it up!

Anonymous

March 10 2007, 20:56:57 UTC 5 years ago

Can SVN Trunk replace gnome-power-manager package from Ubuntu Edgy Eft?

Hi!

Before I get my hands dirty on checking-out and building gnome-power-manager I'd like to know if I can replace a built-from-svn gnome-power-manger with my installed gnome-power-manager-2.16.1-0ubuntu3 binary package. I am very eager to try this out as I do use my notebook on a daily basis - using AC or on battery - and would like to test / give feedback!

I'll return back here, but I can be contacted at fschricker at gmail dot com, too...

regards,
Florian

[info]hughsient

March 10 2007, 21:06:52 UTC 5 years ago

Re: Can SVN Trunk replace gnome-power-manager package from Ubuntu Edgy Eft?

Yes. What I do to test is:

mkdir ~/.root
cd gnome-power-manager-trunk
./autogen --prefix=~/.root
make
make install -k
cd src
./run-gpm.sh

and then run gnome-power-* tools from the same directory. The 2.16.x tools are not compatile with 2.19.x, and probably won't work. Then play!

Richard.

Anonymous

March 11 2007, 21:35:34 UTC 5 years ago

Re: Can SVN Trunk replace gnome-power-manager package from Ubuntu Edgy Eft?

Just checking back for a short note: unfortunately GPM from SVN trunk needs HAL >= 0.5.8. Well, since my notebook is my main production thing and I guess I should better not try updating HAL on this machine I guess I can't test GPM just yet...

Damn... ;-)

regards,
Florian

Anonymous

March 10 2007, 21:59:46 UTC 5 years ago

NIH

ibam has been doing this for years ...

[info]hughsient

March 10 2007, 22:11:12 UTC 5 years ago

Re: NIH

Agree, it looks similar.

We shouldn't have to run yet another daemon just to profile a battery tho. It also looks like the graphs are not smoothed and the peakyness of the line suggests that no temporal filtering is being done. It's also very complicated to query, and not at all integrated with the system. It's using obsolete command line interfaces and it not easy to interface with from the session.
The code itself lacks structure, and is written in a fairly old c++ style in my opinion, and there are hardly any comments in the core code. It's not modular, and assumes you only have one battery IIUC. Also, by the look of the code it's doing the gradient of a 100 discrete percentage in a very odd way, which could explain the peakyness.

So yes, in concept it's similar, but totally different.
Create an Account
Forgot your login or password?
Facebook Twitter More login options
English • Español • Deutsch • Русский…