Re: Impacts of disabling Automatic Power Management
On Thu, Feb 9, 2012 at 7:33 PM, Sridhar Dhanapalan srid...@laptop.org.au wrote: Looking for the happy middle ground that doesn't interfere with collaboration. Emphasis on collaboration stability, but we would prefer not to have massive battery drain while doing so. We understand that there are trade-offs. I think its hard to find a middle ground at the moment. Maybe it is just subjective. As John Gilmore points out, we have years of experience of applying workarounds and it hasn't brought brilliant results. Recent workarounds have already shifted us quite significantly to the stability side (sacrificing power savings) - waking up on all multicast frames, apparently even ones that wouldn't normally be sent from the hardware to the driver - but we are still left with a (IMO) substandard experience for the field. If you apply the collaboration workaround in question you just shift the problem to other areas, such as presence and web browsing. In terms of the real solution, we are making progress on some of the issues. Slowly but surely. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Sat, Feb 11, 2012 at 6:24 AM, Daniel Drake d...@laptop.org wrote: On Thu, Feb 9, 2012 at 7:33 PM, Sridhar Dhanapalan srid...@laptop.org.au wrote: Looking for the happy middle ground that doesn't interfere with collaboration. Emphasis on collaboration stability, but we would prefer not to have massive battery drain while doing so. We understand that there are trade-offs. I think its hard to find a middle ground at the moment. Maybe it is just subjective. As John Gilmore points out, we have years of experience of applying workarounds and it hasn't brought brilliant results. Recent workarounds have already shifted us quite significantly to the stability side (sacrificing power savings) - waking up on all multicast frames, apparently even ones that wouldn't normally be sent from the hardware to the driver - but we are still left with a (IMO) substandard experience for the field. If you apply the collaboration workaround in question you just shift the problem to other areas, such as presence and web browsing. In terms of the real solution, we are making progress on some of the issues. Slowly but surely. I have never really been involved in collaboration and am just getting up to speed but here are my observations as a fresh mind. Right now almost all the collaboration problems seem to exist on the client side of things. That makes a lot of sense to me as the we know there are limitations in the firmware we use for the wireless cards. The way we work around that is disabling powersavings so the card can behave normally. My suggestion is that we can make the machines/servers acting as host smarter and that can allow the best of both worlds. This will probably require reciprocal work on the clients but that will be worked out in the development process. The first problem I see is that machines don't wake on ARP. Ultimately I believe we don't want our machines to wake on ARP, we really want firmware that can handle ARP and only wake when our address is ARP'd. I don't know how unreasonable a request that is. Without that option the next best thing is to have the other machines on our network create a static ARP entry for other machines involved in collaboration. This makes it very easy for accurate unicast wakeups. Another problem appears to be lost wakup packets while collaborating. This should be able to be fixed by using an iptables queue. If we queue collaboration traffic that isn't responded to, we can quick of a script when the queue gets X long that tries various methods to wakeup the machine on the other end. Be smarter about how we track network traffic. Other than just checking if there is network traffic, we should be tracking where this network traffic is from or to. The most recent solution I have seen inhibits powerd if a collaboration session is invoked. I think a more fine grained hammer would be to register who is being colaborated with and specifically watching for network traffic with those hosts. I am most certainly missing some things, but I am quite sure that we can make all this work by stretching the rules of modern networking a bit. More and more networking code is written with the assumption the other machine is always online and accessible. That is generally a fair assumption, except in our model. To get around this we will need to make our networking model a bit more stateful, and intelligent. I think all the pieces exist we just need to pull it all together with some duct tape and bubble gum McGuyver style. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
waking up on all multicast frames, apparently even ones that wouldn't normally be sent from the hardware to the driver There's a flag for that, ifconfig wlan0 allmulti, which should NOT be set. That configuration tells the hardware that we want to receive all multicasts, not just the ones we have software listening for. (It shows up in capital letters, in the flags line of ifconfig wlan0 if set.) If that's off, waking on all multicasts is pretty unlikely. Multicast reception hardware (for every Ethernet as well as every WiFi) is designed so that it doesn't see packets unless they match the address filter, which the Linux drivers already know how to set. This is easy to test. Run ip maddr, it will tell you all the addresses that the driver is listening for, on each interface. It lists link-level (MAC) address, IPv4 addresses, and IPv6 addresses. To test it, let the laptop auto-suspend. Then from another node on the same network (AP or adhoc or ethernet), ping a multicast address that the node should NOT wake up for, e.g. the all routers on this link address in IPv6 (ff02::2): ping6 -I wlan0 ff02::2 This should NOT wake up the autosuspended laptop. You can try pinging various other multicast addresses, e.g. ff02::f, or ipv4's 224.1.2.3. After confirming that, try sending a multicast that SHOULD wake up the laptop. You have a list of them from the ip maddr output. An easy one that's always there is the all nodes on this link multicast address in IPv6 (ff02::1): ping6 -I wlan0 ff02::1 This should wake up the laptop (and get you a ping response sent back to the second node). However, old bugs like http://dev.laptop.org/ticket/6528 may prevent the ping response (packets that wake the laptop from suspend are often lost). If we're still dropping some packets that wake the laptop from suspend, then that could be one of the problems with collaboration. Four years ago, I commented: http://dev.laptop.org/ticket/6818#comment:18 Yes, the real test will be how it integrates in the whole system: With the presence service running, with ethtool -s msh0 wol uma, and with auto-suspend: Will we drop the unicast or multicast packet that wakes us up (#6528), or will it actually reach the application that's awaiting it? And, secondarily, can we stay suspended long enough to save power? Or will the application level multicast traffic be so constant that we always wake a few seconds after we suspend (in which case we need to fix the applications so they aren't so chatty)? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
The first problem I see is that machines don't wake on ARP. Ultimately I believe we don't want our machines to wake on ARP, we really want firmware that can handle ARP and only wake when our address is ARP'd. I don't know how unreasonable a request that is. It's completely reasonable, and we've put together most or all of the parts to get it working for IPv4. See: http://dev.laptop.org/ticket/3732 If we fix the wake-on-multicast problem then we'll fix IPv6 ARP as well (it uses multicast for neighbor discovery packets that replace the ARP protocol): http://dev.laptop.org/ticket/4616 Another problem appears to be lost wakup packets while collaborating. http://dev.laptop.org/ticket/6528 This should be able to be fixed by using an iptables queue. If we queue collaboration traffic that isn't responded to, we can quick of a script when the queue gets X long that tries various methods to wakeup the machine on the other end. We should fix the real problems, which are low-level, straightforward, and easy to reproduce, rather than building crazy workarounds at higher levels. Be smarter about how we track network traffic. Other than just checking if there is network traffic, we should be tracking where this network traffic is from or to. We shouldn't need to check whether there is network traffic when desiring to suspend. If no process has run in N milliseconds, the kernel should autosuspend. N should be tuned to avoid constantly suspending and then immediately reawakening, e.g. between packets in an active HTTP connection. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
We shouldn't need to check whether there is network traffic when desiring to suspend. If no process has run in N milliseconds, the kernel should autosuspend. N should be tuned to avoid constantly suspending and then immediately reawakening, e.g. between packets in an active HTTP connection. Aren't there situations where network traffic occurs without significant process involvement? I remember a couple of years back, when my XO-1 (if so enabled) would suspend while I had a 100 MB ethernet transfer ongoing - I needed to periodically press something on the keyboard to keep that XO-1 awake. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Sat, Feb 4, 2012 at 10:26 AM, Samuel Greenfeld greenf...@laptop.org wrote: Disabling suspend during collaboration was discussed a year ago, but as far as I know this has not made it into any 11.3.x build: http://dev.laptop.org/ticket/10363 There are longstanding bugs from four to five years ago, all the way back to the XO-1, that prevent collaboration from working when aggressive power management (suspend) is enabled. Most of those never got fixed, as far as I know. Lots of circumventions were attempted. Some bugs were closed despite not actually getting the right fix implemented. They're all still in trac. E.g.: http://dev.laptop.org/ticket/4616 http://dev.laptop.org/ticket/9535 http://dev.laptop.org/ticket/10878 http://dev.laptop.org/ticket/10363 http://dev.laptop.org/ticket/10207 (closed because it still fails!) http://dev.laptop.org/ticket/7128 http://dev.laptop.org/ticket/6818 http://dev.laptop.org/ticket/6684 Back then, we were barely able to do the bugfixes needed to get to minimal power when suspending the XO-1 when you close the lid. Making exotic features like collaboration work was way beyond what the team was able to do. Perhaps now is different? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Wed, Feb 8, 2012 at 10:16 PM, Sridhar Dhanapalan srid...@laptop.org.au wrote: In our next build, we will be doing two things [1]: 1. enabling the patch 2. disabling wake-on-LAN I would not do #2. Living up to its name, wake-on-LAN keeps the XOs awake whenever a network connection is active, even when you don't really need it to I think you are misunderstanding how WOL works. I can't get into this topic right now, and I can't find a good reference (http://en.wikipedia.org/wiki/Wake-on-LAN does not really fit with what we do). Powerd's code and README are perhaps a good read if you want to understand this topic. erikos reckons that the patch won't do much [2] I agree that his patch is not enough, but I'm not convinced of his argument that it's almost useless... I think he is also misunderstanding some aspects of it :-) m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Thu, 2012-02-09 at 13:24 -0500, Martin Langhoff wrote: On Wed, Feb 8, 2012 at 10:16 PM, Sridhar Dhanapalan srid...@laptop.org.au wrote: In our next build, we will be doing two things [1]: 1. enabling the patch 2. disabling wake-on-LAN I would not do #2. How would one disable waking up with multicast as suggested in dlo#10856? Living up to its name, wake-on-LAN keeps the XOs awake whenever a network connection is active, even when you don't really need it to I think you are misunderstanding how WOL works. I can't get into this topic right now, and I can't find a good reference (http://en.wikipedia.org/wiki/Wake-on-LAN does not really fit with what we do). From the log files and observations the screen never dims when connected to any network. Powerd's code and README are perhaps a good read if you want to understand this topic. I might be blind, but where is the README? I don't see it in the git source. erikos reckons that the patch won't do much [2] I agree that his patch is not enough, but I'm not convinced of his argument that it's almost useless... I think he is also misunderstanding some aspects of it :-) Well, we're testing this combination, someone has to take the lead. Without doing anything the XOs will never use the full potential of power saving that maybe available. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
jerry wrote: On Thu, 2012-02-09 at 13:24 -0500, Martin Langhoff wrote: On Wed, Feb 8, 2012 at 10:16 PM, Sridhar Dhanapalan srid...@laptop.org.au wrote: In our next build, we will be doing two things [1]: 1. enabling the patch 2. disabling wake-on-LAN I would not do #2. How would one disable waking up with multicast as suggested in dlo#10856? turn off the WAKE_ON_WLAN config setting in powerd.conf. Living up to its name, wake-on-LAN keeps the XOs awake whenever a network connection is active, even when you don't really need it to I think you are misunderstanding how WOL works. I can't get into this topic right now, and I can't find a good reference (http://en.wikipedia.org/wiki/Wake-on-LAN does not really fit with what we do). From the log files and observations the screen never dims when connected to any network. Powerd's code and README are perhaps a good read if you want to understand this topic. I might be blind, but where is the README? I don't see it in the git source. martin's just misremembering. the long-winded docs are in the powerd script itself. http://dev.laptop.org/git/users/pgf/powerd/tree/powerd or /usr/sbin/powerd . the config vars are also described in /etc/powerd/powerd.conf, so you might just want to start there. paul erikos reckons that the patch won't do much [2] I agree that his patch is not enough, but I'm not convinced of his argument that it's almost useless... I think he is also misunderstanding some aspects of it :-) Well, we're testing this combination, someone has to take the lead. Without doing anything the XOs will never use the full potential of power saving that maybe available. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Thu, Feb 9, 2012 at 5:02 PM, Jerry Vonau jvo...@shaw.ca wrote: Well, we're testing this combination, someone has to take the lead. Without doing anything the XOs will never use the full potential of power saving that maybe available. This seems like a bit of change of direction from the mail that opened this thread. Are you looking for stability (as the original mail asked), or are you looking for maximum power saving? Unfortunately the two are quite opposite in the present day, with respect to this topic. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Thu, 2012-02-09 at 17:47 -0600, Daniel Drake wrote: On Thu, Feb 9, 2012 at 5:02 PM, Jerry Vonau jvo...@shaw.ca wrote: Well, we're testing this combination, someone has to take the lead. Without doing anything the XOs will never use the full potential of power saving that maybe available. This seems like a bit of change of direction from the mail that opened this thread. Are you looking for stability (as the original mail asked), or are you looking for maximum power saving? Unfortunately the two are quite opposite in the present day, with respect to this topic. Looking for the happy middle ground that doesn't interfere with collaboration. Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 10 February 2012 10:56, Jerry Vonau jvo...@shaw.ca wrote: On Thu, 2012-02-09 at 17:47 -0600, Daniel Drake wrote: On Thu, Feb 9, 2012 at 5:02 PM, Jerry Vonau jvo...@shaw.ca wrote: Well, we're testing this combination, someone has to take the lead. Without doing anything the XOs will never use the full potential of power saving that maybe available. This seems like a bit of change of direction from the mail that opened this thread. Are you looking for stability (as the original mail asked), or are you looking for maximum power saving? Unfortunately the two are quite opposite in the present day, with respect to this topic. Looking for the happy middle ground that doesn't interfere with collaboration. Emphasis on collaboration stability, but we would prefer not to have massive battery drain while doing so. We understand that there are trade-offs. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 5 February 2012 10:12, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 5 February 2012 02:35, Martin Langhoff martin.langh...@gmail.com wrote: On Sat, Feb 4, 2012 at 10:26 AM, Samuel Greenfeld greenf...@laptop.org wrote: Disabling suspend during collaboration was discussed a year ago, but as far as I know this has not made it into any 11.3.x build: http://dev.laptop.org/ticket/10363 Thanks for that! I had forgotten ~ Sridhar, Jerry -- that bug has a patch that implements exactly the Sugar change I was proposing. We later dropped it for a change to powerd that we thought would cover all the bases by relying on using wake-on-LAN on the wlan... which we later learned is somewhat buggy. Please test with this patch and let us know whether it helps. Thanks! We'll add this to our next dev build. In our next build, we will be doing two things [1]: 1. enabling the patch 2. disabling wake-on-LAN It seems to me that this is the preferred solution. I think we only need to inhibit power management when collaboration is active, not for any LAN traffic. Living up to its name, wake-on-LAN keeps the XOs awake whenever a network connection is active, even when you don't really need it to be. Assuming that it always works as intended (which as you have explained, it does not), the patch won't be very testable when it is active. erikos reckons that the patch won't do much [2], but the testing performed so far seems to be small-scale. Hopefully we'll get some feedback on this after we put out our build. Sridhar [1] https://dev.laptop.org.au/issues/1049 [2] http://dev.laptop.org/ticket/10363#comment:21 Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
sridhar wrote: On 5 February 2012 10:12, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 5 February 2012 02:35, Martin Langhoff martin.langh...@gmail.com wrote: On Sat, Feb 4, 2012 at 10:26 AM, Samuel Greenfeld greenf...@laptop.org wrote: Disabling suspend during collaboration was discussed a year ago, but as far as I know this has not made it into any 11.3.x build: http://dev.laptop.org/ticket/10363 Thanks for that! I had forgotten ~ Sridhar, Jerry -- that bug has a patch that implements exactly the Sugar change I was proposing. We later dropped it for a change to powerd that we thought would cover all the bases by relying on using wake-on-LAN on the wlan... which we later learned is somewhat buggy. Please test with this patch and let us know whether it helps. Thanks! We'll add this to our next dev build. In our next build, we will be doing two things [1]: 1. enabling the patch 2. disabling wake-on-LAN It seems to me that this is the preferred solution. I think we only need to inhibit power management when collaboration is active, not for any LAN traffic. Living up to its name, wake-on-LAN keeps the XOs awake whenever a network connection is active, even when you don't really need it to be. Assuming that it always works as intended (which as you have explained, it does not), the patch won't be very testable when it is active. i guess you're saying that an active network connection should be keeping the laptop awake, and therefore being able to wake it up after it sleeps is a moot point. that may be true for chatty collaboration protocols -- it certainly wouldn't be true for TCP sessions (which isn't your use case -- i understand that). but in addition, without wake-on-lan, a sleeping laptop will be invisible to its peers, at least until the user wakes it up. is that okay? paul erikos reckons that the patch won't do much [2], but the testing performed so far seems to be small-scale. Hopefully we'll get some feedback on this after we put out our build. Sridhar [1] https://dev.laptop.org.au/issues/1049 [2] http://dev.laptop.org/ticket/10363#comment:21 Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 02/04/2012 12:13 AM, Sridhar Dhanapalan wrote: What build are you basing your images off of? We're building from Dextrose 3, which is in turn based on 11.3.0. This version is still in development and hence isn't used in the field. I'm not sure how useful data from the currently-deployed OS (10.1.3) would be. Its not as useful as it could be but its not useless. There is a bug in 10.1.3 where the time in suspend is not tracked correctly. So from the logs we can tell how many times is suspended per second of run time but we can't tell the exact percentage of suspend time vs runtime. Its still a place to start. If you have lots of suspends/run time then you know that turning off aggressive suspend/resume will affect your battery life. If you have few then it probably won't matter much. Of course the ASR setting may not really matter. Have you actually tested what your battery life is with the 3G modem connected up and the machine idle with ASR disabled? I've heard that 3G modems suck quite a bit of power and USB itself sucks power. With that extra load the savings you get from anything but a _lot_ of idleness may not really amount to much. If you run a base line test then we can estimate what your life would be if for say you added 20% of idle suspend on top of that. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 02/04/2012 12:28 AM, Sridhar Dhanapalan wrote: Let's _not_ include it in the development builds, so developers and testers suffer (and fix). end users need not suffer. +1 for this. This is negatively impacting classrooms. Teachers are shying away from using collaboration. We don't have time to wait for a 'perfect' solution. I wasn't suggesting that we don't come up with a workaround for your current problem. I was commenting that adding a hook into sugars API that globally disables suspend while collaboration is active is headed in the wrong direction. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
Disabling suspend during collaboration was discussed a year ago, but as far as I know this has not made it into any 11.3.x build: http://dev.laptop.org/ticket/10363 There might be a few 10.x.x builds with this change but I would have to research this to confirm one way or another. I could easily see USB GSM modems being unhappy about repeatedly losing power, as my USB CDMA modem resets itself every time that happens. This then requires it to reacquire a connection to the tower, reset the computer's PPP link to the modem, etc. This may require the XO to stay powered on via a usb-inhibits rule, network manager script, or Sugar's GSM/NM monitor whenever the connection is active. But unless the GSM/3G connection is being used to contact a school or other collaboration server I think these are two independent problems. On Sat, Feb 4, 2012 at 7:45 AM, Richard A. Smith rich...@laptop.org wrote: On 02/04/2012 12:28 AM, Sridhar Dhanapalan wrote: Let's _not_ include it in the development builds, so developers and testers suffer (and fix). end users need not suffer. +1 for this. This is negatively impacting classrooms. Teachers are shying away from using collaboration. We don't have time to wait for a 'perfect' solution. I wasn't suggesting that we don't come up with a workaround for your current problem. I was commenting that adding a hook into sugars API that globally disables suspend while collaboration is active is headed in the wrong direction. -- Richard A. Smith rich...@laptop.org One Laptop per Child __**_ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/**listinfo/develhttp://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 2 February 2012 09:09, Richard A. Smith rich...@laptop.org wrote: Sirdhar: Unfortunately theres no way we can answer your question ( or even make a SWAG) without known how much idleness is in your normal workload. Automatic Power Management only makes a big difference if there is a lot of time spent idle. If you are running Tam-Tam the entire time then turning off aggressive suspend/resume will make zero difference. powerd tracks this though so if you can collect some powerd logs from some of your users then we can make a guess at figuring out what your impact will be. powerd logs are located in the ~olcp/power-logs directory. Copy all the files in there off of several machines that have been used in the classroom and send them to me and we can take a look at what sort of profile you have. What build are you basing your images off of? We're building from Dextrose 3, which is in turn based on 11.3.0. This version is still in development and hence isn't used in the field. I'm not sure how useful data from the currently-deployed OS (10.1.3) would be. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 2 February 2012 14:42, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Feb 1, 2012 at 9:11 PM, Richard A. Smith rich...@laptop.org wrote: While I understand the frustration, this is going to wrong direction. We need to hunt down the problems and fix them. I think we have the root problem well isolated -- dsd has done a good job of that. Getting it fixed is taking longer than we thought, and it got better, but not fixed, in the 11.x.y cycle. Our next stab at fixed is in the 12.1.0 timeframe, mid-2012. A workaround of this kind _is_ the right thing now for the 11.x.y platform. Let's _not_ include it in the development builds, so developers and testers suffer (and fix). end users need not suffer. +1 for this. This is negatively impacting classrooms. Teachers are shying away from using collaboration. We don't have time to wait for a 'perfect' solution. 3G is a separate problem. We don't know yet what USB modems we'll be using, so we can't inhibit their USB IDs. Doing it through NM would be preferable. I've updated the tracker: http://dev.laptop.org/ticket/10708 Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Sat, Feb 4, 2012 at 12:28 AM, Sridhar Dhanapalan srid...@laptop.org.au wrote: 3G is a separate problem. We don't know yet what USB modems we'll be using, so we can't inhibit their USB IDs. Doing it through NM would be preferable. I've updated the tracker: http://dev.laptop.org/ticket/10708 In that case, I can suggest that you implement a local NM hook. When a network is brought up, or down, NM will execute scripts placed in /etc/NetworkManager/dispatcher.d/ with parameters indicating device and up/down. A snippet of shell that adds/removes a powerd inhibit file 3g connections are established/torn down will DTRT. You can add this trivially locally, and if it's done nice and clean we can include it in our next OS release :-) m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
martin wrote: On Thu, Feb 2, 2012 at 12:17 AM, Jerry Vonau jvo...@shaw.ca wrote: I like to keep OOB as close to upstream as possible, having OOB already has a module to do this: powerd. Take a peek at the XO-1 configs provided, which already disable this. but really, disabling automatic power management entirely is an awfully big hammer. please consider instead adding your 3G devices to usb-inhibits -- this is documented in the powerd script itself (where all of powerd is documented). we could also consider adding a new config file, called, perhaps, program-inhibits, which would cause powerd to inhibit automatic suspend when it detects a listed named program is running, via ps. as richard said, we'd much rather take baby steps forward than giant steps backward. :-/ paul cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Thu, Feb 2, 2012 at 10:18 AM, Paul Fox p...@laptop.org wrote: we could also consider adding a new config file, called, perhaps, program-inhibits, which would cause powerd to inhibit automatic suspend when it detects a listed named program is running, via ps. Actually, it's about whether programs are using collaboration sessions, and AIUI we have python codepaths controlling that, so we should be able to get an inhibits file touched in the right place, with minimal effort. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 01/31/2012 11:43 PM, Paul Fox wrote: sridhar wrote: We are considering disabling Automatic Power Management because of its impact on collaboration and 3G connectivity. What kind of battery life can we expect from an XO-1.5 with Automatic Power Management disabled as opposed to enabled? I understand that this can vary wildly with usage, but is there an average estimate? he's on a very long plane flight, but i'll try and channel richard: it depends. how did i do? :-) You have learned well. Sirdhar: Unfortunately theres no way we can answer your question ( or even make a SWAG) without known how much idleness is in your normal workload. Automatic Power Management only makes a big difference if there is a lot of time spent idle. If you are running Tam-Tam the entire time then turning off aggressive suspend/resume will make zero difference. powerd tracks this though so if you can collect some powerd logs from some of your users then we can make a guess at figuring out what your impact will be. powerd logs are located in the ~olcp/power-logs directory. Copy all the files in there off of several machines that have been used in the classroom and send them to me and we can take a look at what sort of profile you have. What build are you basing your images off of? -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 1 February 2012 16:09, Gary Martin garycmar...@googlemail.com wrote: On 1 Feb 2012, at 04:43, Paul Fox wrote: would it help to disable automatic power management only when specific Activities are running? only when certain kinds of collaboration are in effect? only when certain drivers are active? Thanks Paul, yes excellent point. With my Activity Team hat on, Sridhar if you could please expand a little on the test cases you are hitting Activity collaboration issues with, so that we can try and resolve or minimise issue from Automatic Power Management kicking in. There are already a number of Activities that programatically keep the machine awake – a simple example is Clock, who wants the clock display to continuously keep stopping as if there's sand stuck in the gears ;) We've found it really difficult to diagnose and replicate reliably - the problems can be random. I made an OLPC bug report [1], which is also in our tracker [2]. The workaround for us (and several other deployments, I hear) is to disable automatic power management. I didn't realise that activities could suspend power management. How does this work, and which activities use it? We see problems with just about any activity that engages in collaboration. Maybe it should be standard to suspend power management for any collaboration session? That would be smarter than turning it off entirely. Sridhar [1] http://dev.laptop.org/ticket/10878 [2] https://dev.laptop.org.au/issues/636 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Wed, Feb 1, 2012 at 6:08 PM, Sridhar Dhanapalan srid...@laptop.org.au wrote: Maybe it should be standard to suspend power management for any collaboration session? That would be smarter than turning it off entirely. I'd be supportive of a patch that does that. Simon, given the collaboration API in 11.2.x, would it be possible to keep a file in existence all the while that a collaboration session exists? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 02/01/2012 08:32 PM, Martin Langhoff wrote: On Wed, Feb 1, 2012 at 6:08 PM, Sridhar Dhanapalan srid...@laptop.org.au wrote: Maybe it should be standard to suspend power management for any collaboration session? That would be smarter than turning it off entirely. I'd be supportive of a patch that does that. Simon, given the collaboration API in 11.2.x, would it be possible to keep a file in existence all the while that a collaboration session exists? While I understand the frustration, this is going to wrong direction. We need to hunt down the problems and fix them. Its a good short term fix to be enabled on a per-deployment basis but if this becomes the default then I worry all our work on making aggressive suspend/resume work will begin to fade away because its never active. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
Sridhar - I agree with Richard's concern about finding the problem. Have you tried to differentiate between problems with collaboration and problems with networking in general? Have you tried different 3G modems and seen different results? I'm just a little skeptical about assuming we know where the problems lie when we haven't actually identified them yet. - Ed On Feb 1, 2012, at 6:08 PM, Sridhar Dhanapalan wrote: On 1 February 2012 16:09, Gary Martin garycmar...@googlemail.com wrote: On 1 Feb 2012, at 04:43, Paul Fox wrote: would it help to disable automatic power management only when specific Activities are running? only when certain kinds of collaboration are in effect? only when certain drivers are active? Thanks Paul, yes excellent point. With my Activity Team hat on, Sridhar if you could please expand a little on the test cases you are hitting Activity collaboration issues with, so that we can try and resolve or minimise issue from Automatic Power Management kicking in. There are already a number of Activities that programatically keep the machine awake – a simple example is Clock, who wants the clock display to continuously keep stopping as if there's sand stuck in the gears ;) We've found it really difficult to diagnose and replicate reliably - the problems can be random. I made an OLPC bug report [1], which is also in our tracker [2]. The workaround for us (and several other deployments, I hear) is to disable automatic power management. I didn't realise that activities could suspend power management. How does this work, and which activities use it? We see problems with just about any activity that engages in collaboration. Maybe it should be standard to suspend power management for any collaboration session? That would be smarter than turning it off entirely. Sridhar [1] http://dev.laptop.org/ticket/10878 [2] https://dev.laptop.org.au/issues/636 ___ 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: Impacts of disabling Automatic Power Management
On Wed, Feb 1, 2012 at 9:11 PM, Richard A. Smith rich...@laptop.org wrote: While I understand the frustration, this is going to wrong direction. We need to hunt down the problems and fix them. I think we have the root problem well isolated -- dsd has done a good job of that. Getting it fixed is taking longer than we thought, and it got better, but not fixed, in the 11.x.y cycle. Our next stab at fixed is in the 12.1.0 timeframe, mid-2012. A workaround of this kind _is_ the right thing now for the 11.x.y platform. Let's _not_ include it in the development builds, so developers and testers suffer (and fix). end users need not suffer. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Wed, 2012-02-01 at 22:42 -0500, Martin Langhoff wrote: On Wed, Feb 1, 2012 at 9:11 PM, Richard A. Smith rich...@laptop.org wrote: While I understand the frustration, this is going to wrong direction. We need to hunt down the problems and fix them. I think we have the root problem well isolated -- dsd has done a good job of that. Getting it fixed is taking longer than we thought, and it got better, but not fixed, in the 11.x.y cycle. Our next stab at fixed is in the 12.1.0 timeframe, mid-2012. A workaround of this kind _is_ the right thing now for the 11.x.y platform. I like to keep OOB as close to upstream as possible, having customizations contained in separate files within OOB. I take it the correct way to disable this is to add a powered stanza to the OOB's ini file to override what is in powerd/defaults.ini? Or do I have to toggle the defaults.ini file? Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On Thu, Feb 2, 2012 at 12:17 AM, Jerry Vonau jvo...@shaw.ca wrote: I like to keep OOB as close to upstream as possible, having OOB already has a module to do this: powerd. Take a peek at the XO-1 configs provided, which already disable this. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Impacts of disabling Automatic Power Management
We are considering disabling Automatic Power Management because of its impact on collaboration and 3G connectivity. What kind of battery life can we expect from an XO-1.5 with Automatic Power Management disabled as opposed to enabled? I understand that this can vary wildly with usage, but is there an average estimate? Thanks, Sridhar Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
sridhar wrote: We are considering disabling Automatic Power Management because of its impact on collaboration and 3G connectivity. What kind of battery life can we expect from an XO-1.5 with Automatic Power Management disabled as opposed to enabled? I understand that this can vary wildly with usage, but is there an average estimate? he's on a very long plane flight, but i'll try and channel richard: it depends. how did i do? :-) you're probably in as good a position to answer this as we are, since you have a better idea of your system activity load. with automatic power management turned off, a 1.5 is good for several hours of use, where several is intentionally vague. backlight on full? wireless on? continuous cpu activity? etc. would it help to disable automatic power management only when specific Activities are running? only when certain kinds of collaboration are in effect? only when certain drivers are active? paul Thanks, Sridhar Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 1 February 2012 15:43, Paul Fox p...@laptop.org wrote: sridhar wrote: We are considering disabling Automatic Power Management because of its impact on collaboration and 3G connectivity. What kind of battery life can we expect from an XO-1.5 with Automatic Power Management disabled as opposed to enabled? I understand that this can vary wildly with usage, but is there an average estimate? he's on a very long plane flight, but i'll try and channel richard: it depends. how did i do? :-) I was trying to head that off with my I understand that... statement :) you're probably in as good a position to answer this as we are, since you have a better idea of your system activity load. with automatic power management turned off, a 1.5 is good for several hours of use, where several is intentionally vague. backlight on full? wireless on? continuous cpu activity? etc. would it help to disable automatic power management only when specific Activities are running? only when certain kinds of collaboration are in effect? only when certain drivers are active? We've been thinking of doing this for when 3G connections are active [1]. It might be interesting to also tie this into Sugar's collaboration mechanism and disable power management when a session is active. Sridhar [1] https://dev.laptop.org.au/issues/1029 Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impacts of disabling Automatic Power Management
On 1 Feb 2012, at 04:43, Paul Fox wrote: sridhar wrote: We are considering disabling Automatic Power Management because of its impact on collaboration and 3G connectivity. What kind of battery life can we expect from an XO-1.5 with Automatic Power Management disabled as opposed to enabled? I understand that this can vary wildly with usage, but is there an average estimate? he's on a very long plane flight, but i'll try and channel richard: it depends. how did i do? :-) you're probably in as good a position to answer this as we are, since you have a better idea of your system activity load. with automatic power management turned off, a 1.5 is good for several hours of use, where several is intentionally vague. backlight on full? wireless on? continuous cpu activity? etc. would it help to disable automatic power management only when specific Activities are running? only when certain kinds of collaboration are in effect? only when certain drivers are active? Thanks Paul, yes excellent point. With my Activity Team hat on, Sridhar if you could please expand a little on the test cases you are hitting Activity collaboration issues with, so that we can try and resolve or minimise issue from Automatic Power Management kicking in. There are already a number of Activities that programatically keep the machine awake – a simple example is Clock, who wants the clock display to continuously keep stopping as if there's sand stuck in the gears ;) Regards, --Gary paul Thanks, Sridhar Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ 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
