what about having network connections inhibit sleep?

[david at lang.hm]

On Wed, 4 Jun 2008, C. Scott Ananian wrote:

> On Wed, Jun 4, 2008 at 7:12 PM, John Gilmore <gnu at toad.com> 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