battery plasmoid and remaining time..

[Sebastian Kügler]

On Thursday 14 May 2009 11:13:22 Aaron J. Seigo wrote:
> On Thursday 14 May 2009, Sebastian Kügler wrote:
> > > can someone provide a justification, other than idiot pacification, for
> > > r#915184
> >
> > Yes. The percentage is even less relevant, a bad battery can show 100%
> > and still go down within two minutes.
>
> if my battery is going bad, that's one thing and i deserve everything i get
> with that. nothing will save me then. but point to a defective corner case
> in hardware is not justification for anything. we're talking about
> generally working batteries, aka 99.9%+ of our use cases here.

Actually, that's not true. A battery (Li-Ion anyway) has this nasty memory 
effect that means that its capacity starts deteriorating from day one. So the 
total capacity changes all the time, if for most cases in a fairly linear 
fashion.

> > The time remaining gives at least an approximation of what the user can
> > expect, and does so in a *meaningful* way (by providing an absolute
> > number).
>
> it is not an absolute number, it's a made up number. it's a guess. you call
> it an absolute number only because it comes in cardinal digit form.

It's not made up, as far as I can see it's remaining capacity / current 
discharge rate. So it does tell you when your battery runs out if you keep 
doing what you're doing right now.

Maybe a good point is to think about how we can make this more clear to the 
user.

> > As to (a), those machines or drivers should be fixed instead of removing
> > a very popular and often useful features from the UI.
>
> ok, i give you this.
>
> > (b) is a fair point partly. Though I'm not sure it's really relevant.
> > Here's what happens in my mental model: The user checks the percentage
> > and tries to interpolate from that if he can finish reading this text,
> > writing this long email, or watching this movie.
>
> no, it's much simpler than that: i look at it and see i have 10% left and
> know i'd better find a plug sometime in the near future. there's no
> interpolating.

10% can mean anything from 5 minutes (a relatively worn out battery) to half 
an hour for most newer batteries out there. (Those are not even extreme 
cases.)

> > For all those cases, the
> > percentage isn't interesting, she needs to know the time (it'll take 40
> > minutes to finish the task, the movie lasts another 1.5 hours).
>
> yes, and that number it lies to me doesn't really help. because it's a
> _lie_. we know it isn't accurate. it's a guestimate based on the user and
> the computer not changing workload and the battery discharging at a
> reasonably predictable rate.

My point is that it's accurate given the current context. For the question 
"Will I be able to finish watching this movie?" the information is good enough 
since the activity remains the same, hence power consumption is mostly 
constant.

A relevant question here is: Can we expect users to understand that if they 
start a new task (compiling something, plug in a USB device that drags 
additional power, increase display brightness, ...) that this has influence on 
the ETA. I think we can, but then I'm more on the expert side of the scale 
here, so my assumption might be wrong.

> > Note that
> > in those cases, the activity will usually remain mostly the same, hence
> > the consumption of energy, and hence the time reported.
>
> since we're talking about something that _turns the machine off_ i don't
> think "usually" is good enough. nor do i think that activity remains mostly
> the same in many typical user work loads.

The "it turns the machine off" is a separate thing, imo. Here's why:

- battery running out does warn the user before taking an action
- it's based on the percent of battery left
- it should be non-destructive (i.e. suspend instead of shutdown, good default 
  as soon as we can actually trust suspend on our target OS to work)

> > In any case, the user does need the time, not the percentage.
>
> oh, i agree. if i could have an accurate time that'd be awesome. but the
> question is not "is having the time useful or needed", the question is "can
> we deliver that information accurately to fulfill such a need" .. answer is
> "no".

I've been using this feature for quite a while, and I've yet to see the case 
where the reported time left erred on the wrong side (i.e. telling me "you've 
got 3 minutes left, while it was only 1). Yes, I've been investigating that 
full of disbelief. :) In that regard, it actually works quite well. The 
reported time *seems* to be based on a worst case, especially once it comes 
closer to flat battery. After some fiddling, I was brave enough to suspend 
when 1% of capacity was left, and that didn't let me down.

> > I often found
> > myself trying to guess the remaining time from the percentage, and that's
> > a very complex thing to do (you have to measure over a period of time).
>
> you know, in the BR about this i suggested as an alternative showing "time
> since last charge" or something like that. that's an absolute number we can
> provide, one we can have confidence in.

I don't see how this is really relevant for the usage of time left (see those 
example I gave in my previous email). I'll have to give it some thinking.

> it's not perfect, but it's actual, real, information that can be taken as
> truth, not an ever juggling number that bobs and weaves depending on
> whether i'm reading email or watching something on cnn.com.

Thing is that it's *not* an every juggling number from my testing. I'm sure 
you're right that there are those wonky situation where it reports crap, but 
all those cases I have investigated ended up that there are also other issues 
with the hardware / BIOS. Once you use this feature on hardware that does work 
well, you'll probably be surprised by its usefulness. I was after initially 
sharing your doubts.

> > You're also talking about data loss, which I think is an invalid point.
> > The
>
> tell that to the data i lost thanks to this same feature in kde3.

I'd be interested in what happened here? Battery went flat before the machine 
could take any action? (That's why we're having this "automatic suspend" 
safety net, if the user has to monitor that, we have another reliability 
problem.)

> on fun, though non-data losing event, was a time a cron job fired up that
> spun disk madly when i purportedly had 15-20 minutes left of time (iirc i
> was just reading some text.. very much non-taxing stuff so i had time, or
> so i was lied to). imagine my surprise when the computer abruptly turned
> itself off far in advance of even the 15 minute mark.

Two points: automatic suspend is there to prevent that, also such tasks 
shouldn't be run when on battery (OSVs start understanding that updatedb  fsck 
when on battery is not helpful.)

> that was a surprise. i was betrayed by the signs on the computer. while bad
> things might happen in life, they should never come at the hand of a
> purposefully added feature that _lies_.

Well, what actually happens right now is that you get a popup: "Your computer 
is about to run out of power, I'll [suspend|shutdown] it in 20 sec if you 
don't prevent that or plug in the cable.

So let's separate this emergency case, it doesn't really relate to the 
remaining time might be inaccurate.

> > automatic suspending mechanism is still percentage-based, so the time
> > display doesn't have any influence there, the machine will warn and go to
> > sleep when the battery runs out.
>
> so the suspend is based on %, but here we go showing time.

We show both, and on hover of the battery by default the percentage.

> > Monitoring that is not something the user
> > should need to do, and that's reflected in the current implementation.
>
> we're not talking about suspend, are we?

emergency suspend when battery runs flat.

> > I'd happily welcome an approach that makes the time reported better
> > though.
>
> ... which will never happen as long as it's "close to almost broken but not
> quite". for those of us who it's broken for (regardless of drivers) we
> won't use it. the rest of you will. feature remains braindamaged.
>
> still, a long term usage heuristic would likely be more accurate, but
> unless it can predict my behaviour and what the computer will choose to do
> next .. good luck.
>
>
> let me close with an example from the world of automobiles: ever notice how
> fuel gages show "how much is left in your tank" versus "how many kilometers
> you have left to go"? think about it. this is the exact same issue. now,
> either car manufacturers are simply overlooking an obviously great feature
> that would be trivial to implement in today's cars or we're doing something
> really stupid here.

Or it's because car manufacturers have, for a long time not had the means to 
compute it -- the needle works more or less mechanically, while finding out 
the projected mileage (kilometrage?!) left is more involved. Current fuel 
usage is something that only very recently popped up in cars, I think mostly 
to environmental constraints becoming more relevant and fuel more expensive. 
Yay oil peak.

> i'm guessing car manufacturers realize that it's safer to let the user
> guess based on the readout of the fuel level, their expected use of the car
> and their experience with that vehicle than leave people stranded and
> surprised because the car said it had 10 more kliks right before hitting an
> uphill incline.

I'm not much of a car person, but knowing that with "normal usage", when the 
needle hits red I've got ~50km left is something I learned early on.
BTW, the percentage of fuel left in cars is also misleading, it's inaccurate 
as soon as you are not driving on a straight street, uphill, downhill, curves, 
or shortly after starting the car.

And note that we're actually reporting both.

I wonder if we can somehow find out if a certain piece of hard/software setup 
is unreliable and just do what's sensible then. This could solve the issues 
where the numbers are wildly off.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090514/b5ae0847/attachment-0001.sig