User: Password:
|
|
Subscribe / Log in / New account

Supporting connected standby

Supporting connected standby

Posted Jan 17, 2014 10:56 UTC (Fri) by iq-0 (subscriber, #36655)
Parent article: Supporting connected standby

I think the solution shouldn't be too tough:
- Old programs don't benefit and are all treated with indefinite slack
- Programs can explicitly set their max slack
- Include an option to "inherit" this slack
- The max slack for a program can be adjusted via /proc or something likewise (like misc priorities and affinities also can)

Now old programs don't get to run (like with suspend-to-ram) and programs that need to run can adjust it themselves. The user can always manually adjust this if/when needed and the distro can fix it by including a default "slack" for certain programs without modifying them using a "settimerslack" tool during invocation, like they can already do for nice/ionice/...) just prepend the invocation with a default maximum slack of 1 hour and your calendar app will at least every hour get to sync it's calendars...


(Log in to post comments)

Supporting connected standby

Posted Jan 17, 2014 20:28 UTC (Fri) by kleptog (subscriber, #1183) [Link]

Infinite slack is essentially what happens now with suspend. The application does a sleep/select/poll/whatever and all of a sudden it's several hours later. Any application which doesn't deal with that properly has long been fixed.

I think it's a good solution.

Supporting connected standby

Posted Jan 26, 2014 4:53 UTC (Sun) by kevinm (guest, #69913) [Link]

Not necessarily. It's no surprise if I wake my machine from standby and find that my IRC session has pinged out - but it would be a real annoyance if the same thing happens just because I haven't touched the machine for 5 minutes.

Supporting connected standby

Posted Jan 27, 2014 9:49 UTC (Mon) by iq-0 (subscriber, #36655) [Link]

That's a different case since you're talking about network interactions with an outside system. On IRC you'd timeout just if you don't respond in a timely matter to the server's ping. This should not be timer slack related.

The other case would be where you use SSH to login on a server and attach a screen session which contains your IRC client. In that case you'd probably want to enable protocol keepalive and the ssh client should be fixed to set an appropriate timer slack (or a workaround should be set in place until it's fixed). And of course data received from the server should still be handled normally since that wouldn't be subject to the infinite timer slack.

Although the timer slack could be considered infinite in most cases that means that it will probably be coalesced with another timer expiring around that time. One could even imagine a sort of master "max timer slack" setting that would ensure that the default "infinite timer slack" for a certains system would ensure that it would at still be processed in X time after the first such timer expired.
Many (unfixed) programs wouldn't necessarily degrade in functionality if they'd wake up at least within 1 minute or even after 5 minutes. This global max timer slack would thus enable the user/distribution to set an acceptable timer slack depending on the type of device and current status.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds