On Thu, Jun 5, 2008 at 6:42 AM, <[EMAIL PROTECTED]> wrote: > On Wed, 4 Jun 2008, C. Scott Ananian wrote: > >> On Wed, Jun 4, 2008 at 7:12 PM, John Gilmore <[EMAIL PROTECTED]> wrote: >>>> what do people think about the idea of making the existance of established >>>> TCP connections inhibit sleep? >>> >>> What release are you running? Auto-suspend isn't enabled in production >>> releases. > > where do I go to discover this? > > when I handed the machines over for the project one was running a recent > (april/may right before the activities were being removed) joyride, and > the other was as shipped in december. I think they re-flashed both > machines, but I'm not sure what with.
cat /etc/issue tells you the build number. FWIW I always use verbose for olpc-update: sudo olpc-update -fvvr joyride-2013 That shows the exact progress of the rsync. (The r is for reboot after updating.) > I got one to upgrade by hitting the arrow keys every couple of min, but I > haven't done the other yet (I want to do it tomorrow, I've got a couple of > nieces I'm meeting for the weekend that I want to let loose on them) so I > can look at it and try things > >>> Joyride should be awakened from suspend by any received unicast (TCP) >>> packet, >>> so I'm not sure why you saw it hang in mid-download, if the update was one >>> long >>> continuous TCP download. But if it's rsync, maybe it's driven from the >>> client >>> end (and if the client suspends, the server never sends anything further). >> >> olpc-update should be touching /etc/inhibit-suspend before it does its >> work, so it should not be sleeping. If it does, and your build was >> not ancient, it's a bug and I'd like to know more. > > the machine had a fully charged battery and was plugged into external > power, it got to the step where it was doing the rsync, and then a few min > later the screen was off. I hit a key and it was still in the rsync and > did not recover. > >>> The real fix is to only force a suspend when the kernel knows no >>> process is scheduled to run now or soon, and ato waken in less than a >>> whole second. We're slowly working on those issues. If we keep >>> kludging things like TCP, there's never the time to put in the real fixes. >> >> Yes. Better integration of suspend and the kernel scheduler is >> discussed near the end of >> http://download.laptop.org/content/conf/20080403-olpc-mini-conf/Power/ >> but I don't think we've made any measurable progress on it since then. >> Dilinger has been resyncing us with upstream, and deepak just started >> full-time OLPC work. We could use help! >> --scott > I don't think that a TCP session waiting for data is nessasarily going to > schedule anything within any arbatrary 60 second block so the scheduling > detection isn't good enough (especially if going to sleep means that you > miss the reception of the packet and have to depend on the retry algorithm > re-sending it in one of the windows where you wake up) > > if wake-on-lan works for packets of an existing TCP session, then sleeping > (lightly) while waiting is fine. otherwise an established TCP session is a > good indication that this isn't a good time to auto-sleep. > > if activities need to override this it should be by doing something to > tell the systems that it doesn't care about the session being brokern. > that way unmodified apps won't break unexpectedly (they will prevent the > machine from sleeping too soundly and increase power useage, but I think > that's a muchmore graceful failure mode) > > David Lang _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
