what about having network connections inhibit sleep?
morgan.collett at gmail.com
Thu Jun 5 04:34:11 EDT 2008
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
> 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
>> 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!
> 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
More information about the Devel