9.1 Proposal: Power Management (Power++)
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.
> 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.
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.
On 24 Oct 2008, at 23:40, Richard A. Smith wrote: > 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. I just tried some simple shell scripts stepping through the LED brightness to simulate a 15 to 7 drop, a pause and back again, also 15 to 1 cycle (think .1sec step seemed fair place to start). The effect seems to add a good touch of polish to a potential screen dimming cycle, if it's not too complicated to implement reliably for real. The steps between brightness values are certainly not linear to my eye (1-2 is a much larger step than 14-15), but used as a fade transition effect it didn't seem an issue. I also tried some rough PWM between 7 & 8, via the shell, but couldn't get anything that didn't make me feel nauseous after a few moments use. 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. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
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.
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
Re: 9.1 Proposal: Power.
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. 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" 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.
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.
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.
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
Re: 9.1 Proposal: Power.
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.
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.
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.
> 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. > > > +1 I did not try 767 but I have found it very irritating in 763. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Power.
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
9.1 Proposal: Power.
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
