Re: Minutes of Power in 9.1.0 meeting
On Wed, 24 Dec 2008, John Gilmore wrote: Also, who is tracking the added ability to shut off power to the radio interface and its logic when the radio is set to off in its control panel (requirement 2)? The difference between Radio Off and Extreme Power Management should become that Radio Off still leaves the USB bus functioning, though it will power-off the WiFi chip. This would allow airplane users to still use USB sticks or USB keyboards, for example. Both settings should have similar impacts on power, since I think the big power hog is the WiFi chip, not the USB bus itself). I don't think anyone has quantified how much power difference there would be, tho. I added a section to the wiki page, mentioning related tickets, and also filed a new ticket for the exact issue (#9145). I'm beginning to think that if we just fix #6995 (mesh icon in Frame that allows picking Mesh channel and disabling it), then this control panel item won't be needed, and the Frame will provide all the controls needed. If you disable the mesh and you disconnect from any access point, the WiFi will power down. Simple. It powers up when you turn on either the mesh or try to connect to an access point (enter the Network screen). We'd have to fix the Network screen so that if you go there, look at the pretty icons, maybe even try a few, then leave the page, if you aren't connected to an access point (or mesh) when you leave, it should power down the radio again. the only problem I see with this is that if the radio is off until you try to connect then when you go to the network screen it will be mostly blank for a while (until it hears the SSID broadcasts) could you do something along the lines of remembering what access points you have connected to and show them (indicating somehow that signal strength is unknown and that the network may not really be there)? this wouldn't solve all of the issues, but it would help when people are operating in 'known' areas. along similar lines an issue I have been seeing with the network screen (but haven't gotten around to reporting). my home access point is encrypted and sometimes I can reconnect to it without a problem, but sometimes it acts as if it's never been connected to before (asking me for the encryption key). I've had to resort to printing the key and keeping it with me (not convienient or good for security). is this a known issue? is there anything I can do to help track down the issue? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
along similar lines an issue I have been seeing with the network screen (but haven't gotten around to reporting). my home access point is encrypted and sometimes I can reconnect to it without a problem, but sometimes it acts as if it's never been connected to before (asking me for the encryption key). I've had to resort to printing the key and keeping it with me (not convienient or good for security). is this a known issue? is there anything I can do to help track down the issue? I see this all the time, too. There are some known bugs with encrypted access points, but I don't know if this one is clearly reported. Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Very frustrating. Access points with encryption have *never* worked reliably on the XO. I guess the programmers in Cambridge had better turn off their open access point, or it'll never be solved. Like the memory freezeups, I just assume that everyone is seeing this and nobody cares to work on it. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On 25.12.2008, at 09:19, John Gilmore wrote: along similar lines an issue I have been seeing with the network screen (but haven't gotten around to reporting). my home access point is encrypted and sometimes I can reconnect to it without a problem, but sometimes it acts as if it's never been connected to before (asking me for the encryption key). I've had to resort to printing the key and keeping it with me (not convienient or good for security). is this a known issue? is there anything I can do to help track down the issue? I see this all the time, too. There are some known bugs with encrypted access points, but I don't know if this one is clearly reported. Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Very frustrating. Access points with encryption have *never* worked reliably on the XO. I guess the programmers in Cambridge had better turn off their open access point, or it'll never be solved. Like the memory freezeups, I just assume that everyone is seeing this and nobody cares to work on it. More likely the actual deployments do not use encrypted APs so this indeed would not be top priority. It's annoying nevertheless, though I seem to have adopted a style of operation so it does happen very rarely anymore. There is at least one ticket open: http://dev.laptop.org/ticket/3554 - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
I'm sure Birmingham or other deployments in the US will be using encrypted access. No US school system would permit an open AP. On Thu, Dec 25, 2008 at 2:51 AM, Bert Freudenberg b...@freudenbergs.dewrote: On 25.12.2008, at 09:19, John Gilmore wrote: along similar lines an issue I have been seeing with the network screen (but haven't gotten around to reporting). my home access point is encrypted and sometimes I can reconnect to it without a problem, but sometimes it acts as if it's never been connected to before (asking me for the encryption key). I've had to resort to printing the key and keeping it with me (not convienient or good for security). is this a known issue? is there anything I can do to help track down the issue? I see this all the time, too. There are some known bugs with encrypted access points, but I don't know if this one is clearly reported. Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Very frustrating. Access points with encryption have *never* worked reliably on the XO. I guess the programmers in Cambridge had better turn off their open access point, or it'll never be solved. Like the memory freezeups, I just assume that everyone is seeing this and nobody cares to work on it. More likely the actual deployments do not use encrypted APs so this indeed would not be top priority. It's annoying nevertheless, though I seem to have adopted a style of operation so it does happen very rarely anymore. There is at least one ticket open: http://dev.laptop.org/ticket/3554 - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Don't think for a minute that power concedes. We have to work like our future depends on it. -- Barack Obama ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Has anybody figured out how to run tcpdump on another system? Do the radio chip sets support promiscuous mode? Access points with encryption have *never* worked reliably on the XO Mine works well enough that I don't pay much attention to it. I'm using a Linksys/Cisco WRT54GL with stock firmware and encryption. 2 or 3 of my neighbors' APs are usually visible. If bugs happen often enough, then you can debug them. If they don't happen often enough to debug, then they probably won't disrupt work very much. I just ran a few tests. I'm just rebooting and looking to see if packets start working again. I'm using ping to measure works. 1: OK 2: 171 ping packets dropped. 3: Failed. First poke at Connect failed. Second worked. 4: 170 5: 173 6: 169 7: 170 8: 173 9: 174 10: 170 11: 166 12: 178 13: 176 14: 172 15: 177 16: 174 Is there anything I/we can do to get more info? Can I turn on logging so there is something to look at in case I can get it to fail again? -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On Thu, 25 Dec 2008, Hal Murray wrote: Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Has anybody figured out how to run tcpdump on another system? Do the radio chip sets support promiscuous mode? Access points with encryption have *never* worked reliably on the XO Mine works well enough that I don't pay much attention to it. I'm using a Linksys/Cisco WRT54GL with stock firmware and encryption. 2 or 3 of my neighbors' APs are usually visible. If bugs happen often enough, then you can debug them. If they don't happen often enough to debug, then they probably won't disrupt work very much. I just ran a few tests. I'm just rebooting and looking to see if packets start working again. I'm using ping to measure works. Is there anything I/we can do to get more info? Can I turn on logging so there is something to look at in case I can get it to fail again? what I see is that when it starts up (power up, wake from sleep, etc) it sometimes pops up the window asking for the encryption key. it doesn't always do so, and it doesn't seem to make a difference if the XO never leaves my house or if I've connected to many other access points in the meantime. I haven't been able to figure out any pattern to it. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
I have recently seen this behavior with the Gnome desktop network applet, when provisioning Ubuntu Intrepid on some old laptops donated to a school near me. What fixed my problem was making pm-utils unload/reload the madwifi atheros driver on suspend and hibernate. I think the prompt for a password was a red herring, and the sign of not distinguishing different kinds of errors when reconnecting after resume. On Thu, Dec 25, 2008 at 9:43 AM, da...@lang.hm wrote: On Thu, 25 Dec 2008, Hal Murray wrote: Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Has anybody figured out how to run tcpdump on another system? Do the radio chip sets support promiscuous mode? Access points with encryption have *never* worked reliably on the XO Mine works well enough that I don't pay much attention to it. I'm using a Linksys/Cisco WRT54GL with stock firmware and encryption. 2 or 3 of my neighbors' APs are usually visible. If bugs happen often enough, then you can debug them. If they don't happen often enough to debug, then they probably won't disrupt work very much. I just ran a few tests. I'm just rebooting and looking to see if packets start working again. I'm using ping to measure works. Is there anything I/we can do to get more info? Can I turn on logging so there is something to look at in case I can get it to fail again? what I see is that when it starts up (power up, wake from sleep, etc) it sometimes pops up the window asking for the encryption key. it doesn't always do so, and it doesn't seem to make a difference if the XO never leaves my house or if I've connected to many other access points in the meantime. I haven't been able to figure out any pattern to it. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Don't think for a minute that power concedes. We have to work like our future depends on it. -- Barack Obama ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On Thu, Dec 25, 2008 at 12:19:37AM -0800, John Gilmore wrote: along similar lines an issue I have been seeing with the network screen (but haven't gotten around to reporting). my home access point is encrypted and sometimes I can reconnect to it without a problem, but sometimes it acts as if it's never been connected to before (asking me for the encryption key). I've had to resort to printing the key and keeping it with me (not convienient or good for security). is this a known issue? is there anything I can do to help track down the issue? I see this all the time, too. There are some known bugs with encrypted access points, but I don't know if this one is clearly reported. Wireless is *so* hard to debug, the programmers can never get to the location where it actually fails repeatably -- and when it's failing, the laptop is by definition off the net, so they can't login to it remotely to debug it. Very frustrating. Access points with encryption have *never* worked reliably on the XO. I guess the programmers in Cambridge had better turn off their open access point, or it'll never be solved. Like the memory freezeups, I just assume that everyone is seeing this and nobody cares to work on it. Daniel Drake has repeatedly offered (and in the past, made good on his offer) to help debug reproducible association problems involving wireless encryption. Other members of the wireless team, including Ricardo Carrano has done the same. Finally, several wireless folks have reported that direct use of wpa_supplicant with correct flags (rather than indirect use of wpa_supplicant by means of NM) results in more frequently successful association attempts [1]. Perhaps they might be interested in working to write up the outline of a logic tree for debugging failed association attempts such as the one that Tomeu and Mel created for debugging memory leaks? Regards, Michael [1]: http://lists.laptop.org/pipermail/devel/2008-October/020757.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
da...@lang.hm said: what I see is that when it starts up (power up, wake from sleep, etc) it sometimes pops up the window asking for the encryption key. it doesn't always do so, and it doesn't seem to make a difference if the XO never leaves my house or if I've connected to many other access points in the meantime. I've never seen a pop-up asking for a password. I used Wpa.sh from a message ages ago. It puts things in /home/olpc/.sugar/default/nm/networks.cfg -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On Thu, Dec 25, 2008 at 4:22 PM, Hal Murray hmur...@megapathdsl.net wrote: .. I used Wpa.sh from a message ages ago. It puts things in /home/olpc/.sugar/default/nm/networks.cfg There is a more recent implementation of the same idea in a python script: mw.py and more at http://wiki.laptop.org/go/Manual_Wireless_Association but I could not get it working with closed (hidden SSID) WPA network. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
Also, who is tracking the added ability to shut off power to the radio interface and its logic when the radio is set to off in its control panel (requirement 2)? The difference between Radio Off and Extreme Power Management should become that Radio Off still leaves the USB bus functioning, though it will power-off the WiFi chip. This would allow airplane users to still use USB sticks or USB keyboards, for example. Both settings should have similar impacts on power, since I think the big power hog is the WiFi chip, not the USB bus itself). I don't think anyone has quantified how much power difference there would be, tho. I added a section to the wiki page, mentioning related tickets, and also filed a new ticket for the exact issue (#9145). I'm beginning to think that if we just fix #6995 (mesh icon in Frame that allows picking Mesh channel and disabling it), then this control panel item won't be needed, and the Frame will provide all the controls needed. If you disable the mesh and you disconnect from any access point, the WiFi will power down. Simple. It powers up when you turn on either the mesh or try to connect to an access point (enter the Network screen). We'd have to fix the Network screen so that if you go there, look at the pretty icons, maybe even try a few, then leave the page, if you aren't connected to an access point (or mesh) when you leave, it should power down the radio again. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
Thanks Chris! Could you also mention any planned GUI changes in the specification section? Name changes to the modes and moving the radio off to Network control panel only are two that come to mind. If you can define what it will look like and help close the loop with Sugar or whoever is needed to change the GUI that would be a big help. Also, who is tracking the added ability to shut off power to the radio interface and its logic when the radio is set to off in its control panel (requirement 2)? Joe, Its over to you to write the test plan now. I added two documentation links to the top of the specification section to give you more background on how it is supposed to work. Let me know if you have any questions. I want to have a solid test plan reviewed and in place early this time as I think that was a critical missing piece in the 8.2.0 release. Thanks, Greg S Date: Wed, 17 Dec 2008 17:56:04 -0500 From: Chris Ball c...@laptop.org Subject: Re: Minutes of Power in 9.1.0 meeting To: g...@laptop.org Cc: Richard Smith rich...@laptop.org, OLPC Development devel@lists.laptop.org, Joseph A. Feinstein j...@laptop.org Message-ID: m3myeuqum3@pullcord.laptop.org Content-Type: text/plain; charset=us-ascii Hi Greg, * Chris to make some additions to requirement linking in the existing documentation, including what happens when the lid is closed. I believe Joe is waiting for Chris to update the requirements before he writes the test cases. I am waiting for the test cases so I can explain to people exactly how much longer the battery will last. I've added these new sections to the requirements (added to the end of the list in order to avoid renumbering the list). I also added a link to the most recent test plan we have for power management, which would be a fine model for the new one. http://wiki.laptop.org/go/Feature_roadmap/Improved_battery_life Thanks, - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
Hi Greg, * Chris to make some additions to requirement linking in the existing documentation, including what happens when the lid is closed. I believe Joe is waiting for Chris to update the requirements before he writes the test cases. I am waiting for the test cases so I can explain to people exactly how much longer the battery will last. I've added these new sections to the requirements (added to the end of the list in order to avoid renumbering the list). I also added a link to the most recent test plan we have for power management, which would be a fine model for the new one. http://wiki.laptop.org/go/Feature_roadmap/Improved_battery_life Thanks, - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Smith wrote: Comments and questions welcome. I think it would be good to clarify what the 9.1.0 plans are for #7958 (DCON shows old image with noise artifacts for the duration of suspend) and #8893 (image jumps vertically for a single frame during resume). These two tickets seem to have been confused on the Improve_battery_life page. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklJi68ACgkQUJT6e6HFtqSxFACfRos1S+/hlXUg63ta59EhyrOx c5EAn29HrPNZwQOec6wnUrQPSehu7MKA =S9+b -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
Hi, I think it would be good to clarify what the 9.1.0 plans are for #7958 (DCON shows old image with noise artifacts for the duration of suspend) and #8893 (image jumps vertically for a single frame during resume). These two tickets seem to have been confused on the Improve_battery_life page. Thanks. I have a feeling they're both caused by the same bug -- the kernel missing DCONLOAD at resume time. If they aren't, #8893 seems much more important than #7958 (which I don't recall seeing in the past few months) to me, so we'd start out with #8893 and move on to #7958 if it still exists and we get time. I've updated the wiki (Requirement 12 addressed by..) to say so. - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Ball wrote: Hi, I think it would be good to clarify what the 9.1.0 plans are for #7958 (DCON shows old image with noise artifacts for the duration of suspend) and #8893 (image jumps vertically for a single frame during resume). These two tickets seem to have been confused on the Improve_battery_life page. Thanks. I have a feeling they're both caused by the same bug -- the kernel missing DCONLOAD at resume time. I don't know much about the DCON, but this doesn't make sense to me. I thought DCONLOAD was only used at suspend time, not resume time. Having DCONLOAD fail or be skipped at suspend explains #7958, but for #8893 the correct image is shown during suspend, indicating that DCONLOAD succeeded. For #8893, the artifact is seen at resume time, and meshes perfectly with an explanation given to me by Ajax: the GPU is not genlocked to the DCON, so it starts displaying the frame at a totally random point in the refresh cycle, leading to the top of the image being somewhere in the middle of the screen. Ajax suggested that the software workaround would be to give the GPU a resolution of 1200x100 and then poll for the DCON's vertical-blanking-interval signal before making the switch. I am not clear as to whether this was implemented and then reverted, or never implemented. If they aren't, #8893 seems much more important than #7958 (which I don't recall seeing in the past few months) to me, so we'd start out with #8893 and move on to #7958 if it still exists and we get time. I've updated the wiki (Requirement 12 addressed by..) to say so. OK. I think your prioritization is reasonable, but #7958 definitely still exists. I've seen it recently. It's just very infrequent, and seemingly more frequent on some machines than others. I recall one user who brought in her G1G1 to our launch party at John Harvard's, showing #7958 on almost every suspend. Everybody keep your eyes open for a machine that gets weird noise on the screen during suspend. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklJk/sACgkQUJT6e6HFtqTYSQCfTlztXwiy4YI5cmOAoOgCRnuN 8K8AoKB8bA8itjzP6wp2t2tBgtk2VDx5 =KLyj -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On a different note, one test we might think about running is the closest thing the industry has to a standard battery life test. It's specified on a lot of the netbook specs. It's defined here: http://it.jeita.or.jp/mobile/e/index.html However, I'm also seeing that a lot of vendors are choosing not to use this test because it generally results in a number higher than what the typical user will actually get. I looked it over. Companies report the average of two measurements: The hours of power available when the machine is dialed down to minimum power, screen at its very dimmest (reflective mode for us), doing nothing, everything disabled. And the other measurement is when the system is playing back an MPEG movie, in a small window and with relatively standard OS and display settings. (We can't do this out of the box, but we could install an MPEG codec for the test, and run it that way. Or transcode their test movie to Ogg Theora and try that for simplified release testing, until we have to report an official number using MPEG.) It would be useful for us to measure and improve the numbers in both of those modes -- but the average will be highly misleading to everyone. Still, it would provide a comparison to netbooks and other computers. It would be nice if our runtime in the minimum power mode could in 9.1.0 be almost equal to our lid-closed suspend time, which I measured in #7879 to be 8 hours with mesh/wifi chip on, and 44+ hours with the mesh/wifi off. Actually, it won't be that good, because the test requires that the screen remain on (perhaps consuming 0.5W), though the reflective screen means we can turn off the backlight. So perhaps we'll get 16 to 20 hours in that mode. If so, averaging with perhaps 2 to 4 hours of active runtime, for a total standard number of about 10 to 12 hours would still be pretty good by comparison to typical netbook products. [First we'll have to fix a bunch of bugs...] John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On Mon, 15 Dec 2008, John Gilmore wrote: On a different note, one test we might think about running is the closest thing the industry has to a standard battery life test. It's specified on a lot of the netbook specs. It's defined here: http://it.jeita.or.jp/mobile/e/index.html However, I'm also seeing that a lot of vendors are choosing not to use this test because it generally results in a number higher than what the typical user will actually get. I looked it over. Companies report the average of two measurements: The hours of power available when the machine is dialed down to minimum power, screen at its very dimmest (reflective mode for us), doing nothing, everything disabled. And the other measurement is when the system is playing back an MPEG movie, in a small window and with relatively standard OS and display settings. (We can't do this out of the box, but we could install an MPEG codec for the test, and run it that way. Or transcode their test movie to Ogg Theora and try that for simplified release testing, until we have to report an official number using MPEG.) It would be useful for us to measure and improve the numbers in both of those modes -- but the average will be highly misleading to everyone. Still, it would provide a comparison to netbooks and other computers. It would be nice if our runtime in the minimum power mode could in 9.1.0 be almost equal to our lid-closed suspend time, which I measured in #7879 to be 8 hours with mesh/wifi chip on, and 44+ hours with the mesh/wifi off. Actually, it won't be that good, because the test requires that the screen remain on (perhaps consuming 0.5W), though the reflective screen means we can turn off the backlight. So perhaps we'll get 16 to 20 hours in that mode. If so, averaging with perhaps 2 to 4 hours of active runtime, for a total standard number of about 10 to 12 hours would still be pretty good by comparison to typical netbook products. as-is you are pretty good. I used the XO to follow presentation slides recently. with wifi and the backlight off I went from 9-5 and showed a bit more than half the battery life left (not a lot of activity, just moving the slides periodicly, but never idle enough to let it turn off the screen). so your 16 or so hours looks pretty reasonable. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
Hi Chris, Joe, Paul and Richard, How are we doing on closing these action items? * Chris to make some additions to requirement linking in the existing documentation, including what happens when the lid is closed. * Mitch and Deepak to figure out who works on requirement 12. * Joe to write test plan and get it reviewed. * Paul to write an explanation of what power button should do and update that requirement and specification. * Richard to determine how to address the no regressions requirement and how to measure the success of the feature in terms of Amps used. I believe Joe is waiting for Chris to update the requirements before he writes the test cases. I am waiting for the test cases so I can explain to people exactly how much longer the battery will last. Let's close these out so we can get this one ready early. Update the feature page here: http://wiki.laptop.org/go/Feature_roadmap/Improved_battery_life BTW each feature no has its own page and all the features under consideration are listed in a table here: http://wiki.laptop.org/go/Feature_roadmap#All_features Sort by target 9.1.0 to see the must have list. Send me a note if you think anything else needs to be on that must build in 9.1.0 list. Other edits and added detail on any feature, welcome anytime. Thanks, Greg S Greg Smith wrote: Greg, Chris, Joe, Erik, Mitch and Deepak met on Thursday 12/4. Minutes: Will use the feature roadmap for tracking: http://wiki.laptop.org/go/Feature_roadmap#Power_management We need to address the three separate high level areas on that page. We rewrote the requirement and listed all bugs and areas of work in the specification section. We integrated all of Gnu's comments (some must fix, some should fix and one should be moved to network). We wrote down who owns each of the listed requirements in the owners section. Action items: * Chris to make some additions to requirement linking in the existing documentation, including what happens when the lid is closed. * Mitch and Deepak to figure out who works on requirement 12. * Joe to write test plan and get it reviewed. * Paul to write an explanation of what power button should do and update that requirement and specification. * Richard to determine how to address the no regressions requirement and how to measure the success of the feature in terms of Amps used. Comments and questions welcome. I will check with you on status of your action items next week. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
Greg Smith wrote: * Richard to determine how to address the no regressions requirement and how to measure the success of the feature in terms of Amps used. I've been working on such tests off and on since October when the report of 8.2 regressions first popped up. And while I've learned a lot since then I still don't have a test thats feasible for short term testing on a generic grab-off-the-shelf XO. I have an idea for a 1 hour test that I think might remove enough variability to be useful but it will need some run hour testing to see. I think it makes more sense right now to invest the time in coding up tests that run in lab reading the instrumented XO. That is after all one of the reasons we got that equipment. Repeated runs of the same test for variability still need to be performed. Other issues are that some tests will need to be long runtime tests and unless we wire up a new system for the tinderbox to use It will block the tinderbox. It won't be hard to wire up a new unit for tinderbox as I think the only requirement is 1 IO hookup to strobe the power button. In whatever case, WLAN has to be disabled. The WLAN power draw varies enough in that unless you are in very quiet RF environments its very difficult to make a comparison between any given 2 runs as more or less power. Using the instrumented XO the wlan power reading could be subtracted out of the total, but repeatability tests need to be performed to see if that removes enough variability to make judgments on regressions. If so then it _might_ be possible to add some workload tests involving browsing or sharing into the mix and get meaningful results. On a different note, one test we might think about running is the closest thing the industry has to a standard battery life test. It's specified on a lot of the netbook specs. It's defined here: http://it.jeita.or.jp/mobile/e/index.html However, I'm also seeing that a lot of vendors are choosing not to use this test because it generally results in a number higher than what the typical user will actually get. -- Richard Smith rich...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Minutes of Power in 9.1.0 meeting
Greg, Chris, Joe, Erik, Mitch and Deepak met on Thursday 12/4. Minutes: Will use the feature roadmap for tracking: http://wiki.laptop.org/go/Feature_roadmap#Power_management We need to address the three separate high level areas on that page. We rewrote the requirement and listed all bugs and areas of work in the specification section. We integrated all of Gnu's comments (some must fix, some should fix and one should be moved to network). We wrote down who owns each of the listed requirements in the owners section. Action items: * Chris to make some additions to requirement linking in the existing documentation, including what happens when the lid is closed. * Mitch and Deepak to figure out who works on requirement 12. * Joe to write test plan and get it reviewed. * Paul to write an explanation of what power button should do and update that requirement and specification. * Richard to determine how to address the no regressions requirement and how to measure the success of the feature in terms of Amps used. Comments and questions welcome. I will check with you on status of your action items next week. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
