9.1 Proposal: Power Management (Power++)

2008-10-27 Thread Richard A. Smith
Chris Ball wrote:

 We made an incremental step in 8.2, offering automatic power management
 that is disabled by default, and I propose a talk covering what needs
 to happen for us to be comfortable taking the next step to enable it
 by default in 9.1.

+1.  I'm going to expand on this further below.  I'm willing to help
research and give the talk.  BUT, I have back-to-back competitions on
the 7-9th and 13th-17th plus a fellow dancer from the UK
staying/traveling with me on the 6th-18th.  So I'll be pretty scarce
during that period. :)

So any research has to be done prior to that and I won't be available to
help talk unless its held on the 19th.

- Measurement and Tracking tools.

The XO needs to be able to track its own power usage and report back.
This way we can aggregate it all for  analysis.  Brief discussions in
the 1cc garden have covered a sort of framework for sending arbitrary
data back to the mothership.  For this to be effective in most of our
current deployments it also needs to be usable off-line.  Ether by
saving up some N number of past logfiles for manual copy and/or
by shipping them off to a school server for later relay.

The data that needs to be tracked can start with the current info that
is tracked by olpc-pwr-log but with less frequency. That will provide
enough information to make general statements of better or worse for
power use and runtime if larger enough sample is gathered.  Improving
these measurements to also include things like logging transitions
to/from suspend and various metrics on how much time we we spend in hlt
(C1) vs run (C0) will also be useful.  Information on what activities
were running at the time will also be very useful for things like 
workflow analysis

- CPUIdle

CPUIdle is our proposed future method on determining when the system is
idle and thus when we can go into suspend.  Right now we are using a
pretty simplistic metric which is easily fooled.  We need to enable
cpuidle and start using it for our idle detection and start fixing the
cases where its wrong.  As of 8.2 cpuidle has make it into the kernel
but unfortunately the code that makes cpuidle work appears to be woven
into the ACPI code which is disabled.  So cpuidle does not curretnly 
work.  Someone needs to investigate this further.

- Workload analysis

The running workload has a pretty large effect on how much power we can 
save while the machine is in use.  Activities like write and paint have 
  lots of opportunity for in-use power savings where as activities like 
TamTam and Record do not.  But there may be things inside of each 
activity that can help reduce its runtime needs.
Feedback from the recent presentations of the in-the-field folk say that 
popular or highly used apps are Write, Paint, Memorize and Scratch. 
These would be good places to start.

- Battery life estimation

Battery life estimation in the face of large power fluctuations is going
to be tricky.  While this is not strictly about saving power accurate 
representation of what power you have left is desirable.  Logs of the 
battery life under various scenarios need to be analyzed and models 
developed that can be used to estimate how much juice is left based on 
previous and current use + some future estimate.

* setting up multicast groups for wakeup during collaboration

* exposing a wakeup-timer API in Sugar to allow scheduled wakeups

While I see the usefulness of this I rather see the effort go into 
making this not necessary.  A dedicated API means that all the apps have 
to be modified to take advantage of it.  Not sure its fully achievable 
since we want to be able to stomp on things like a timer going off every 
100mS and suspend anyway if our idle conditions are met.

* faster resume

This of course is the most crucial part.  Very little of the above will 
help if we don't speed up suspend/resume to a point where it can happen 
transparently below the user at a tolerable level.
As far as I know nobody has yet gone through the process of discovering 
just how fast we can go if we do evil hacks with zero regard for kernel 
upstream or USB specifications.  I propose this is step one.  Then try 
to  figure out how to make it happen so that it plays well with the rest 
of the world.  IMHO to get where we need to go we will always have to 
carry some custom hacks to the USB stack that are outside the standards 
but perhaps I'll be pleasantly  surprised.

-- 
Richard Smith  [EMAIL PROTECTED]
One Laptop Per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-25 Thread John Gilmore
 awake.  The current scheme is already at its lowest it can be.  Jump to 
 the lowest setting and then put the cpu to sleep.  Any deviation from 
 that will use more juice.  If you wake up the CPU to do something you 
 have taken a large step backwards.

Actually, there's more we can do to save juice.  Currently, if you
turn on automatic power management, the CPU gets turned off while the
screen is still on -- and it never wakes up 20 minutes later to turn
off the screen.  The screen stays on til the battery dies.  That's bug
#8094.

Fixing #6053 (suspend makes kernel slip against realtime) and
#4606 (XO can't resume from a timer) before the next major release
would enable the next batch of low-hanging power saving fruit, including
#8094.

John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-24 Thread Richard A. Smith
Nate Ridderman wrote:

 Do we have the ability to pulse width modulate the backlight LEDs? What 
 is the resolution on the PWM? It's hard to know if this is feasible 
 without a hardware schematic and specs on the backlight driver. The CL1 
 spec mentions a PWM signal, but maybe it only has four bits of resolution?

The DCON drives a 200Hz PWM to the feeback loop of the DC/DC converter 
that produces the LED's supply voltage.  The lo-side driver transistors 
for each of the 3 LED chains (12 LEDS, 3 chains of 4) are not connected 
to anything you can PWM.

   I could be talking nonsense, and perhaps this would consume more
 power
   than it saves, but if you were able to slowly dim the backlight over
   the course of a minute or so, instead of waiting a minute and then
   dropping it suddenly, we could prevent the sudden change which causes
   a break in concentration.  (As long as the screen is bright enough to
   be usable when dim, of course.)

It not possible to save power by doing this unless you ramped the 
backlight down during the period when the CPU whould have normally been 
awake.  The current scheme is already at its lowest it can be.  Jump to 
the lowest setting and then put the cpu to sleep.  Any deviation from 
that will use more juice.  If you wake up the CPU to do something you 
have taken a large step backwards.

-- 
Richard Smith  [EMAIL PROTECTED]
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-24 Thread david
On Sat, 25 Oct 2008, Gary C Martin wrote:

 Not sure if this helps the original feedback (that the sudden screen
 dimming is annoying when trying to read), but the effect is at least
 more pleasing than a sudden sharp drop in brightness.

what I would really like to see is a reading mode, where the CPU goes to 
sleep fairly quickly (the faster the wake-up when a button is pressed the 
more quickly it can go to sleep), but the screen doesn't change. only if 
the system is idle for a long time (tens of min) should the cpu wake up 
and decide to dim/blank the screen.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-23 Thread Eben Eliason
I could be talking nonsense, and perhaps this would consume more power
than it saves, but if you were able to slowly dim the backlight over
the course of a minute or so, instead of waiting a minute and then
dropping it suddenly, we could prevent the sudden change which causes
a break in concentration.  (As long as the screen is bright enough to
be usable when dim, of course.)

- Eben


On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote:
 Hi,

When running on battery with Energy Saver set to Better Battery
Life (which sets Automatically reduce the brightness of the
display before display sleep) the backlight dims after 30 seconds.
On AC with the equivalent setting it's 2 minutes, 30 seconds.  In
each case the dimming time seems to be 50% of the time until the
screen is turned off.  1 minute is the minimum time before display
sleep.

 Thanks!  I was hoping someone would have numbers.  Our backlight dim
 currently happens fifty seconds after idleness starts, so we're
 definitely less aggressive than OS X already..

 - Chris.
 --
 Chris Ball   [EMAIL PROTECTED]
 ___
 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


Re: 9.1 Proposal: Power.

2008-10-23 Thread Jim Gettys
How well we can do that isn't clear.

We have 16 brightness levels, but we didn't think about making them
logarithmic in response to correspond to the eye's behavior, so there
are really fewer than that that are useful.

Please experiment and see if it is helpful, of course...
  - Jim

On Thu, 2008-10-23 at 10:14 -0400, Eben Eliason wrote:
 I could be talking nonsense, and perhaps this would consume more power
 than it saves, but if you were able to slowly dim the backlight over
 the course of a minute or so, instead of waiting a minute and then
 dropping it suddenly, we could prevent the sudden change which causes
 a break in concentration.  (As long as the screen is bright enough to
 be usable when dim, of course.)
 
 - Eben
 
 
 On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote:
  Hi,
 
 When running on battery with Energy Saver set to Better Battery
 Life (which sets Automatically reduce the brightness of the
 display before display sleep) the backlight dims after 30 seconds.
 On AC with the equivalent setting it's 2 minutes, 30 seconds.  In
 each case the dimming time seems to be 50% of the time until the
 screen is turned off.  1 minute is the minimum time before display
 sleep.
 
  Thanks!  I was hoping someone would have numbers.  Our backlight dim
  currently happens fifty seconds after idleness starts, so we're
  definitely less aggressive than OS X already..
 
  - Chris.
  --
  Chris Ball   [EMAIL PROTECTED]
  ___
  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
-- 
Jim Gettys [EMAIL PROTECTED]
One Laptop Per Child

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-23 Thread Ian Daniher
Hello all,
This is somewhat on-topic, as this code can be used to test the smoothness
of diming the backlight by editing SLP in the included code.
I originally wrote this as I'm planning on using an XO motherboard/screen as
an alarm clock, and will have the brightness set via some fancy HR=$(date
+%H) magic.

Questions and comments are appreciated.

CODE

FILE=/sys/class/backlight/dcon-bl/brightness
VAL=0
SLP=.1
while [ $VAL -lt 15 ]
do
echo $VAL  $FILE
echo $VAL
VAL=`expr $VAL + 1`
sleep $SLP
done
while [ $VAL -gt 0 ]
do
echo $VAL  $FILE
echo $VAL
VAL=`expr $VAL - 1`
sleep $SLP
done
echo done

CODE /

Best,
-- 
Ian Daniher
--
OLPC Support Volunteer
OLPCinci Repair Center Coordinator

On Thu, Oct 23, 2008 at 4:45 PM, Jim Gettys [EMAIL PROTECTED] wrote:

 How well we can do that isn't clear.

 We have 16 brightness levels, but we didn't think about making them
 logarithmic in response to correspond to the eye's behavior, so there
 are really fewer than that that are useful.

 Please experiment and see if it is helpful, of course...
  - Jim

 On Thu, 2008-10-23 at 10:14 -0400, Eben Eliason wrote:
  I could be talking nonsense, and perhaps this would consume more power
  than it saves, but if you were able to slowly dim the backlight over
  the course of a minute or so, instead of waiting a minute and then
  dropping it suddenly, we could prevent the sudden change which causes
  a break in concentration.  (As long as the screen is bright enough to
  be usable when dim, of course.)
 
  - Eben
 
 
  On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote:
   Hi,
  
  When running on battery with Energy Saver set to Better Battery
  Life (which sets Automatically reduce the brightness of the
  display before display sleep) the backlight dims after 30 seconds.
  On AC with the equivalent setting it's 2 minutes, 30 seconds.  In
  each case the dimming time seems to be 50% of the time until the
  screen is turned off.  1 minute is the minimum time before display
  sleep.
  
   Thanks!  I was hoping someone would have numbers.  Our backlight dim
   currently happens fifty seconds after idleness starts, so we're
   definitely less aggressive than OS X already..
  
   - Chris.
   --
   Chris Ball   [EMAIL PROTECTED]
   ___
   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
 --
 Jim Gettys [EMAIL PROTECTED]
 One Laptop Per Child

 ___
 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


Re: 9.1 Proposal: Power.

2008-10-23 Thread Nate Ridderman
Do we have the ability to pulse width modulate the backlight LEDs? What is
the resolution on the PWM? It's hard to know if this is feasible without a
hardware schematic and specs on the backlight driver. The CL1 spec mentions
a PWM signal, but maybe it only has four bits of resolution?

In the cell phone world, PWM is used pretty regularly as an approach to dim
backlights. It's much cheaper than having a bunch of analog current sensing
circuitry. I believe 100 Hz or greater is required to reduce flickering, but
this might be higher on a larger screen. Sometimes using PWM on LEDs can
create spectral noise, especially if there is no soft start mechanism in the
LED driver, so the antenna desensitivity would probably need to be tested
against this approach.

Thanks,
Nate

On Thu, Oct 23, 2008 at 4:45 PM, Jim Gettys [EMAIL PROTECTED] wrote:

 How well we can do that isn't clear.

 We have 16 brightness levels, but we didn't think about making them
 logarithmic in response to correspond to the eye's behavior, so there
 are really fewer than that that are useful.

 Please experiment and see if it is helpful, of course...
  - Jim

 On Thu, 2008-10-23 at 10:14 -0400, Eben Eliason wrote:
  I could be talking nonsense, and perhaps this would consume more power
  than it saves, but if you were able to slowly dim the backlight over
  the course of a minute or so, instead of waiting a minute and then
  dropping it suddenly, we could prevent the sudden change which causes
  a break in concentration.  (As long as the screen is bright enough to
  be usable when dim, of course.)
 
  - Eben
 
 
  On Wed, Oct 22, 2008 at 4:21 PM, Chris Ball [EMAIL PROTECTED] wrote:
   Hi,
  
  When running on battery with Energy Saver set to Better Battery
  Life (which sets Automatically reduce the brightness of the
  display before display sleep) the backlight dims after 30 seconds.
  On AC with the equivalent setting it's 2 minutes, 30 seconds.  In
  each case the dimming time seems to be 50% of the time until the
  screen is turned off.  1 minute is the minimum time before display
  sleep.
  
   Thanks!  I was hoping someone would have numbers.  Our backlight dim
   currently happens fifty seconds after idleness starts, so we're
   definitely less aggressive than OS X already..
  
   - Chris.
   --
   Chris Ball   [EMAIL PROTECTED]
   ___
   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
 --
 Jim Gettys [EMAIL PROTECTED]
 One Laptop Per Child

 ___
 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


9.1 Proposal: Power.

2008-10-22 Thread Chris Ball
Hi,

We made an incremental step in 8.2, offering automatic power management
that is disabled by default, and I propose a talk covering what needs
to happen for us to be comfortable taking the next step to enable it
by default in 9.1.  Topics will likely include:

   * setting up multicast groups for wakeup during collaboration
   * exposing a wakeup-timer API in Sugar to allow scheduled wakeups
   * faster resume

- Chris.
-- 
Chris Ball   [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-22 Thread david
On Wed, 22 Oct 2008, Chris Ball wrote:

 We made an incremental step in 8.2, offering automatic power management
 that is disabled by default, and I propose a talk covering what needs
 to happen for us to be comfortable taking the next step to enable it
 by default in 9.1.  Topics will likely include:

   * setting up multicast groups for wakeup during collaboration
   * exposing a wakeup-timer API in Sugar to allow scheduled wakeups
   * faster resume

as a G1G1 user one annoyance of enabling power savings is the screen 
dimming while I am reading a page. I thought this was supposed to be 
improved, but I saw the same thing when I upgraded to 767 a week ago.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-22 Thread Chris Ball
Hi,

as a G1G1 user one annoyance of enabling power savings is the
screen dimming while I am reading a page. I thought this was
supposed to be improved, but I saw the same thing when I upgraded
to 767 a week ago.

There's a way this could be improved.  We previously had to dim the
screen before CPU sleep because we weren't going to get a chance to
dim it later -- once the CPU is off, it stays off.  Now that we have
wakeup timers, we could do something like this:

   idle+30s:  CPU sleeps
   idle+2m:   wakeup to dim the backlight, back to sleep
   idle+5m:   wakeup to turn off the screen, back to sleep

I'm not yet entirely convinced that we should wait that long, though.
Anyone who has used a laptop running OS X will have noticed that it
dims the backlight after just a few (ten?) seconds of inactivity.

I'll add this topic to the talk.  Thanks!

- Chris.
-- 
Chris Ball   [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-22 Thread david
On Wed, 22 Oct 2008, Chris Ball wrote:

 Hi,

as a G1G1 user one annoyance of enabling power savings is the
screen dimming while I am reading a page. I thought this was
supposed to be improved, but I saw the same thing when I upgraded
to 767 a week ago.

 There's a way this could be improved.  We previously had to dim the
 screen before CPU sleep because we weren't going to get a chance to
 dim it later -- once the CPU is off, it stays off.  Now that we have
 wakeup timers, we could do something like this:

   idle+30s:  CPU sleeps
   idle+2m:   wakeup to dim the backlight, back to sleep
   idle+5m:   wakeup to turn off the screen, back to sleep

 I'm not yet entirely convinced that we should wait that long, though.
 Anyone who has used a laptop running OS X will have noticed that it
 dims the backlight after just a few (ten?) seconds of inactivity.

we notice that the backlight dimms immediatly, the problem is that this 
distracts us from what we are reading to hit a button to wake it up and 
get the backlight on again.

for someone playing an interactive game, this won't matter. but for 
someone studying some technical content this breaks their concentration 
and hinders them.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 9.1 Proposal: Power.

2008-10-22 Thread Ed McNierney
Chris -

The OS X dimming is more than 10 seconds, but not much more.  OK, it's  
rather lame to make that assertion on a MacBook Pro without timing  
it

When running on battery with Energy Saver set to Better Battery  
Life (which sets Automatically reduce the brightness of the display  
before display sleep) the backlight dims after 30 seconds.  On AC  
with the equivalent setting it's 2 minutes, 30 seconds.  In each case  
the dimming time seems to be 50% of the time until the screen is  
turned off.  1 minute is the minimum time before display sleep.

- Ed

On Oct 22, 2008, at 3:37 PM, Chris Ball wrote:

 Hi,

 as a G1G1 user one annoyance of enabling power savings is the
 screen dimming while I am reading a page. I thought this was
 supposed to be improved, but I saw the same thing when I upgraded
 to 767 a week ago.

 There's a way this could be improved.  We previously had to dim the
 screen before CPU sleep because we weren't going to get a chance to
 dim it later -- once the CPU is off, it stays off.  Now that we have
 wakeup timers, we could do something like this:

   idle+30s:  CPU sleeps
   idle+2m:   wakeup to dim the backlight, back to sleep
   idle+5m:   wakeup to turn off the screen, back to sleep

 I'm not yet entirely convinced that we should wait that long, though.
 Anyone who has used a laptop running OS X will have noticed that it
 dims the backlight after just a few (ten?) seconds of inactivity.

 I'll add this topic to the talk.  Thanks!

 - Chris.
 -- 
 Chris Ball   [EMAIL PROTECTED]
 ___
 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


Re: 9.1 Proposal: Power.

2008-10-22 Thread Chris Ball
Hi,

When running on battery with Energy Saver set to Better Battery
Life (which sets Automatically reduce the brightness of the
display before display sleep) the backlight dims after 30 seconds.
On AC with the equivalent setting it's 2 minutes, 30 seconds.  In
each case the dimming time seems to be 50% of the time until the
screen is turned off.  1 minute is the minimum time before display
sleep.

Thanks!  I was hoping someone would have numbers.  Our backlight dim
currently happens fifty seconds after idleness starts, so we're
definitely less aggressive than OS X already..

- Chris.
-- 
Chris Ball   [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel