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