On Sun, Mar 14, 2010 at 07:34:14PM -0400, Paul Fox wrote:
i've been thinking about this problem, and i'm not sure i understand how seamless network connectivity is _supposed_ to work, in the face of suspend and wake-on-lan.
Classic Wake on LAN is an entirely different technology to what we are trying.
What we want is most of the time spent in suspend, if there is no reason to wake, and to wake if there is reason.
Reasons to wake that we are handling are: - incoming network packet, - user input.
Reasons to wake that we are not handling are: - TCP timer expiry, (e.g. a retry on an active connection, where a segment we have sent hasn't been acknowledged), - application timer expiry (e.g. a ping from the laptop to another host, or some other application level network timer),
And as you point out, we are probably not deferring a wake when a packet is ready to be sent.
don't we also need a "don't-go-to-sleep-because-i-still-might-have something-to-send" feature?
Heh.
a simple "how busy is the network?" mode won't be sufficient, i don't think.
Agreed, this could be an intractable problem. It may require more thought. You've started, let's proceed.
One workaround is to merely wake up once a minute for a second or two. This will allow TCP to emit what it should, and allow user space processes to get through their event or timing loops.