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
> 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
> 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: [IAEP] [Sugar-devel] butiá robot challenges in sumo.uy event
http://vimeo.com/33399708 Nice video of the sumo.uy 2011 event where childrens participated using olpc/sugar in sumo and in butia challenges. regards andres On Thu, Sep 22, 2011 at 9:26 PM, Steve Thomas wrote: > This is a great use of the XO. So for comparison, how much would it cost > for an arduino, with video camera, color display, speakers, speech to text > capabilites, wireless internet? > > Plus you get programming environments like Scratch, Etoys and Turtle Art. > > My guess an XO would win and it does so much more!!! > > Stephen > > > On Thu, Sep 22, 2011 at 5:30 PM, Andres Aguirre wrote: >> >> Thank you Kevin! >> There are some more pics in flickr: >> http://www.flickr.com/photos/butiarobot/sets/ >> and some videos in http://www.youtube.com/proyectobutia >> cheers >> >> -- >> /\ndrés >> >> >> On Thu, Sep 22, 2011 at 7:33 AM, Kevin Mark >> wrote: >> > On Wed, Sep 21, 2011 at 08:24:50PM -0300, Andres Aguirre wrote: >> >> Hi, I want to share with you what we was doing the last week here in >> >> Uruguay: >> >> >> >> http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Review >> > Hi Andres, >> > this looks like more excellant work about the butiabot. I was showing >> > photos of >> > the bot at the Maker Faire NYC 2011 booth to all the kids and parents as >> > your >> > project is the one that shows how the kids are learning about robotics, >> > programming and computational thinking. And also how people can derive >> > new >> > software and new educational uses with an 'open' approach in a learning >> > environment. >> > >> > -- >> > | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| >> > | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| >> > | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| >> > |___`-Unless I ask to be CCd,.assume I am subscribed._| >> > >> > The PILLSBURY DOUGHBOY is CRYING for an END to BURT REYNOLDS movies!! >> > >> ___ >> IAEP -- It's An Education Project (not a laptop project!) >> i...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/iaep > > ___ 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 wrote: > On Thu, Feb 9, 2012 at 7:33 PM, Sridhar Dhanapalan > 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
On Thu, Feb 9, 2012 at 7:33 PM, Sridhar Dhanapalan 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
