Re: Major power concern
On Tue, Oct 07, 2008 at 09:56:10AM +0200, Marco Pesenti Gritti wrote:
> On Tue, Oct 7, 2008 at 6:02 AM, John Gilmore <[EMAIL PROTECTED]> wrote:
> > /usr/share/sugar/shell/view/devices/battery.py
> >
> >#TODO: make this less of an wild/educated guess
> >minutes_remaining = int(current_level / 0.59)
> >remaining_hourpart = minutes_remaining / 60
> >remaining_minpart = minutes_remaining % 60
> >secondary_text = _('%(hour)d:%(min).2d remaining'
> > % { 'hour': remaining_hourpart,
> > 'min': remaining_minpart})
> >
> > How, uh, unusual to slip this into a release at the last minute!
> >
> > The battery code has moved all around in the last two weeks (I think
> > it's been in three different places in the Sugar tree), so I found
> > it too hard to track who put this change in, and why.
>
> It's not hard at all, just use gitweb to look at the history of the
> file in the sucrose-0.82 branch. And it's not a last minute change.
>
> http://dev.laptop.org/git?p=sugar;a=commitdiff;h=cf6bd9384004cb47cf5a0f77c31049624cff7dd0
It was I, basically, and a better solution is harder than dividing by
0.59[1]. Anyone wishing to improve the situation[2] might find trac
#4204 interesting:
http://dev.laptop.org/ticket/4204#comment:6
> Marco
Martin
1. This approximates the process I found myself and heard others doing
all the time to estimate battery power minutes remaining from the
percentage remaining value reported by HAL.
2. You'll note from the comment and the commit
comment and my email to devel@ pre-commit I set pretty modest
expectations for the code:
http://lists.laptop.org/pipermail/devel/2008-April/012759.html
I think the issue is that doing it right is hard:
http://lists.laptop.org/pipermail/devel/2008-April/012839.html
...and the issue isn't unknown to this list (ibid.) and
pgpvfvsmND4mp.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Major power concern
On Tue, Oct 7, 2008 at 6:02 AM, John Gilmore <[EMAIL PROTECTED]> wrote:
> /usr/share/sugar/shell/view/devices/battery.py
>
>#TODO: make this less of an wild/educated guess
>minutes_remaining = int(current_level / 0.59)
>remaining_hourpart = minutes_remaining / 60
>remaining_minpart = minutes_remaining % 60
>secondary_text = _('%(hour)d:%(min).2d remaining'
> % { 'hour': remaining_hourpart,
> 'min': remaining_minpart})
>
> How, uh, unusual to slip this into a release at the last minute!
>
> The battery code has moved all around in the last two weeks (I think
> it's been in three different places in the Sugar tree), so I found
> it too hard to track who put this change in, and why.
It's not hard at all, just use gitweb to look at the history of the
file in the sucrose-0.82 branch. And it's not a last minute change.
http://dev.laptop.org/git?p=sugar;a=commitdiff;h=cf6bd9384004cb47cf5a0f77c31049624cff7dd0
Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Major power concern
Hi, > I recall some free code that tracks battery performance over time, > and produces increasingly accurate predictions of when your battery > will run out, after watching your particular battery and your > particular system for a few full power cycles. But a bit of > searching didn't turn it up for me today. gnome-power-manager does this. (Perhaps it should move into HAL.) - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Major power concern
> I've just noticed that release candidate 765 when fully charged tells me I
> have 2 1/2 hours of usage. This is a major concern, and something we really
What exactly is your concern?
* That the power display includes a time remaining?
* That the time remaining is wrong?
* That the time remaining is right, but should be longer?
* That an earlier software release lasted longer on battery?
* or some combination of the above?
I'm poking around to figure out where Sugar gets that number for the
time remaining. Aha, it's in this code:
/usr/share/sugar/shell/view/devices/battery.py
#TODO: make this less of an wild/educated guess
minutes_remaining = int(current_level / 0.59)
remaining_hourpart = minutes_remaining / 60
remaining_minpart = minutes_remaining % 60
secondary_text = _('%(hour)d:%(min).2d remaining'
% { 'hour': remaining_hourpart,
'min': remaining_minpart})
How, uh, unusual to slip this into a release at the last minute!
The battery code has moved all around in the last two weeks (I think
it's been in three different places in the Sugar tree), so I found
it too hard to track who put this change in, and why.
I recall some free code that tracks battery performance over time, and
produces increasingly accurate predictions of when your battery will
run out, after watching your particular battery and your particular
system for a few full power cycles. But a bit of searching didn't
turn it up for me today.
John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Techteam] Major power concern
C. Scott Ananian wrote: > I'm not convinced that the testing methodology is sound: the machines > should be fully charged, with the same battery, and times taken until > fully discharged (until poweroff). A 10 minute olpc-pwr-log using a delay 30 should be a reasonably accurate measurement. If the Wh readings kicked out by the process-pwr_log.py are similar then the time can be increased. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Major power concern
greebo wrote: > >> To determine if it is a battery problem follow the instructions for >> using opc-pwr-log. (This should be pre-installed on 757). >> The instructions are at: >> >> http://wiki.laptop.org/go/XO_LiFePO4_Recovery_Procedure > > Will do and will post results. You may want to modify this script a bit. The delay method I uses the clock and a sleep 2 loop rather than just a sleep x command for the delay. The reason is so I can delay properly across an idle-suspend. The sleep(2) loop may not be the best for this sort of measurement. Each reading involved lots of EC commands. Its probably a good idea to replace the 'wallclock_delay' with 'sleep'. Idle-suspend is off in those builds so the wallclock feature is not needed. By default DELAY is set to 10 seconds but if you really wanted a sense of the idle power you can increase that to 60 or even longer. The ACR reading will track the over all power used accurately regardless of the delay time. Smaller delays are good if you want to try and catch some peaks. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] Major power concern
On Thu, Oct 2, 2008 at 7:58 PM, Chris Ball <[EMAIL PROTECTED]> wrote: > From devel@: > > Test 1 - default 765 image > > Estimated time = ~2 1/2 - 3hrs > > > Test 3 - default 711 image > > Estimated time = 4-5 hrs > > We'll need to set up tests with 765/767/711 tomorrow to see whether this > is true. We should suspect #8711, but Pia says she didn't launch any > activities. I'm not convinced that the testing methodology is sound: the machines should be fully charged, with the same battery, and times taken until fully discharged (until poweroff). Trusting the battery's charge monitor circuit's percentage is just Wrong, and extrapolating that to a run time is Doubly Wrong. You're just compounding estimates, which are based on the battery's own rough knowledge of previous performance. Also, there was some suspicion that hovering over the battery icon in 767 could itself be leading to greater battery consumption -- the popup menu for the battery is not present in 711; it would be best to eliminate that uncertainty as well. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Major power concern
Hi all, On Thu, 2 Oct 2008 20:41:15 -0700, Robert Howard <[EMAIL PROTECTED]> wrote: > From my reading of your description you ran the 765 and 711 test on > 2 different machines and did not swap the battery between machines. > Is this correct? > If so there is a flaw in the methodology. You should ideally run all > tests on the same machine with the same battery or at least use the > same battery in both machines for the test. I did the same test for 765 on two new machines with almost identical results. The 765p and 711 tests were for comparison and I know I need to do further testing but wanted to raise the flag asap considering the image is to be released soon and his could be a big issue. This was advised on #olpc. > To determine if it is a battery problem follow the instructions for > using opc-pwr-log. (This should be pre-installed on 757). > The instructions are at: > > http://wiki.laptop.org/go/XO_LiFePO4_Recovery_Procedure Will do and will post results. Cheers, Pia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Major power concern
Pia, From my reading of your description you ran the 765 and 711 test on 2 different machines and did not swap the battery between machines. Is this correct? If so there is a flaw in the methodology. You should ideally run all tests on the same machine with the same battery or at least use the same battery in both machines for the test. To determine if it is a battery problem follow the instructions for using opc-pwr-log. (This should be pre-installed on 757). The instructions are at: http://wiki.laptop.org/go/XO_LiFePO4_Recovery_Procedure /Robert H. On Oct 2, 2008, at 3:53 PM, Pia Waugh wrote: > Hi all, > > I've just noticed that release candidate 765 when fully charged > tells me I > have 2 1/2 hours of usage. This is a major concern, and something > we really > need to fix for this release. As I tested it, it appeared to get > about a > minute or two to each percentage of battery. Below are some initial > results > as I know people want them sooner rather than later :) > > I was asked in #olpc to see if ohmd is running. It is. Anything > else I can > check for? I found that by default the "power savings" option was > turned > off. I turned it on for one of the test laptops below. > > All laptops were simply turned on and the mouse hovered over the > battery > symbol for status, no apps were run nor other activity run. > > The % is the indicated remaining battery time. > > Test 1 - default 765 image > > 765 started at (98%) fully charged > 64% 1.48hrs remaining @ 65 mins running time > 50% 1.24hrs remaining @ 98 mins running time > 45% 1.16hrs remaining @ 108 mins running time > > Estiamted time = ~2 1/2 - 3hrs > > Test 2 - default 765 image but with power savings on > > 765 started at (93%) mostly charged with power savings turned on > and rebooted > 93% @ 0 mins running time > 92% @ 2.35 10 mins running time > 90% @ 2.32 35 mins running time > 90% @ 2.32 41 mins running time > 90% @ 2.32 50 mins running time > > Estimated full time = ~10hrs+ > > Test 3 - default 711 image > > 711 build started at (97%) fully charged (no percentage available) > 94% @ 10 mins running time > 89% @ 23 mins running time > 84% @ 35 mins running time > 73% @ 68 mins running time > > Estimated time = 4-5 hrs > > Please note these are initial results and I won't know for sure until > another few hours for the first round, and a few repeats, but at > least this > gets other able to start testing :) > > This issue could be a major problem for this new release and if > unfixed > would seriously undermine the awesome efforts of all involved in > the great > changes for 8.2.0. > > Just for reference I've seen trials for primary schools with other > devices > and one of the main benefits of the XO over them was better power, > so we > need to maintain that :) If you are interested the other main > reasons were > screen size, the ease of prepacking a full suite of apps/content, the > relative cost of the wireless infrastructure needed, and the community > around OLPC. > > Cheers, > Pia > > -- > Linux Australia http:// > linux.org.au/ > Open Source Industry Australia http:// > osia.net.au/ > Software Freedom Day http:// > softwarefreedomday.org/ > >"He who loves the world as his body may be entrusted with the > empire." > - Lao-tzu > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Major power concern
Hi all, I've just noticed that release candidate 765 when fully charged tells me I have 2 1/2 hours of usage. This is a major concern, and something we really need to fix for this release. As I tested it, it appeared to get about a minute or two to each percentage of battery. Below are some initial results as I know people want them sooner rather than later :) I was asked in #olpc to see if ohmd is running. It is. Anything else I can check for? I found that by default the "power savings" option was turned off. I turned it on for one of the test laptops below. All laptops were simply turned on and the mouse hovered over the battery symbol for status, no apps were run nor other activity run. The % is the indicated remaining battery time. Test 1 - default 765 image 765 started at (98%) fully charged 64% 1.48hrs remaining @ 65 mins running time 50% 1.24hrs remaining @ 98 mins running time 45% 1.16hrs remaining @ 108 mins running time Estiamted time = ~2 1/2 - 3hrs Test 2 - default 765 image but with power savings on 765 started at (93%) mostly charged with power savings turned on and rebooted 93% @ 0 mins running time 92% @ 2.35 10 mins running time 90% @ 2.32 35 mins running time 90% @ 2.32 41 mins running time 90% @ 2.32 50 mins running time Estimated full time = ~10hrs+ Test 3 - default 711 image 711 build started at (97%) fully charged (no percentage available) 94% @ 10 mins running time 89% @ 23 mins running time 84% @ 35 mins running time 73% @ 68 mins running time Estimated time = 4-5 hrs Please note these are initial results and I won't know for sure until another few hours for the first round, and a few repeats, but at least this gets other able to start testing :) This issue could be a major problem for this new release and if unfixed would seriously undermine the awesome efforts of all involved in the great changes for 8.2.0. Just for reference I've seen trials for primary schools with other devices and one of the main benefits of the XO over them was better power, so we need to maintain that :) If you are interested the other main reasons were screen size, the ease of prepacking a full suite of apps/content, the relative cost of the wireless infrastructure needed, and the community around OLPC. Cheers, Pia -- Linux Australia http://linux.org.au/ Open Source Industry Australia http://osia.net.au/ Software Freedom Day http://softwarefreedomday.org/ "He who loves the world as his body may be entrusted with the empire." - Lao-tzu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
