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. 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 Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel