what about having network connections inhibit sleep?

[Morgan Collett]

On Thu, Jun 5, 2008 at 6:42 AM,  <david at lang.hm> wrote:
> 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.

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