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.
two cases, involving host "H" and xo laptop "X".
case 1:
"H" "X"
ping -->
ping response <--
[ "X" sleeps ]
ping -->
[ "X" wakes ]
ping response <--
...and all is happy.
case 2:
"H" "X"
ping -->
ping response <--
ping -->
[ "X" receives ping, but before "X" replies, "X" sleeps ]
no response
... "H" is unhappy. "X" will respond, eventually, after
"X"
wakes. i.e., far too late.
failure cases similar to the above can be imagined for "real"
(i.e., non-ping) traffic -- network protocols are asymmetric
by nature -- one side requests, the other responds.
how exactly do we think this is supposed to work? as far as i
can see, "wake-on-lan" is only half the solution. don't we also
need a "don't-go-to-sleep-because-i-still-might-have
something-to-send" feature?
or, more realistically, i think at the least we need a mode like
one of the following:
- "no tcp (or ping or dns or arp or ... ) packets in the
last NN seconds means i'm idle" means it's okay to sleep
or:
- "no tcp sessions open at all" means it's okay to sleep
a simple "how busy is the network?" mode won't be sufficient, i
don't think.
paul
james wrote:
On Fri, Mar 12, 2010 at 06:23:15PM -0600, Daniel Drake wrote:
> If you continually ping an (inactive) XO with autosuspend enabled (at
> the regular ping interval) does it now survive for more than an hour?
It works until the ARP cache of the pinging host dries up, then the ARP
queries emitted are not seen by the laptop.
Laptop will also get into a mode where the wireless LED goes off at the
same time the power LED goes off; when that happens, the next keyboard
wake will reassociate with the access point within about a minute.
Here's a test with a XO-1.5 C1 with build 112, no changes to powerd
configuration, with ARP cache preloaded on the pinging host, with the
laptop booted at the same time the ping is begun:
host:~$ ping -a -n quozl-l
PING quozl-l.lan (10.0.0.164) 56(84) bytes of data.
64 bytes from 10.0.0.164: icmp_seq=75 ttl=64 time=12.2 ms
64 bytes from 10.0.0.164: icmp_seq=76 ttl=64 time=4.23 ms
64 bytes from 10.0.0.164: icmp_seq=77 ttl=64 time=2.93 ms
64 bytes from 10.0.0.164: icmp_seq=78 ttl=64 time=2.20 ms
64 bytes from 10.0.0.164: icmp_seq=79 ttl=64 time=2.32 ms
64 bytes from 10.0.0.164: icmp_seq=80 ttl=64 time=3.10 ms
64 bytes from 10.0.0.164: icmp_seq=81 ttl=64 time=2.90 ms
64 bytes from 10.0.0.164: icmp_seq=82 ttl=64 time=2.93 ms
64 bytes from 10.0.0.164: icmp_seq=83 ttl=64 time=2.36 ms
64 bytes from 10.0.0.164: icmp_seq=84 ttl=64 time=3.11 ms
64 bytes from 10.0.0.164: icmp_seq=85 ttl=64 time=2.69 ms
64 bytes from 10.0.0.164: icmp_seq=86 ttl=64 time=2.31 ms
64 bytes from 10.0.0.164: icmp_seq=87 ttl=64 time=2.29 ms
64 bytes from 10.0.0.164: icmp_seq=88 ttl=64 time=2.46 ms
(at this point the power LED flickered off briefly, an idle suspend
event followed by a wake on LAN),
64 bytes from 10.0.0.164: icmp_seq=89 ttl=64 time=344 ms
64 bytes from 10.0.0.164: icmp_seq=90 ttl=64 time=2.37 ms
64 bytes from 10.0.0.164: icmp_seq=91 ttl=64 time=2.30 ms
64 bytes from 10.0.0.164: icmp_seq=92 ttl=64 time=2.56 ms
64 bytes from 10.0.0.164: icmp_seq=93 ttl=64 time=2.13 ms
64 bytes from 10.0.0.164: icmp_seq=94 ttl=64 time=2.25 ms
64 bytes from 10.0.0.164: icmp_seq=95 ttl=64 time=2.14 ms
64 bytes from 10.0.0.164: icmp_seq=96 ttl=64 time=2.16 ms
64 bytes from 10.0.0.164: icmp_seq=97 ttl=64 time=2.12 ms
64 bytes from 10.0.0.164: icmp_seq=98 ttl=64 time=2.28 ms
64 bytes from 10.0.0.164: icmp_seq=99 ttl=64 time=2.21 ms
(at this point the wireless LED flashed a few times, a NetworkManager
access point scan event),
64 bytes from 10.0.0.164: icmp_seq=100 ttl=64 time=334 ms
64 bytes from 10.0.0.164: icmp_seq=101 ttl=64 time=45.4 ms
64 bytes from 10.0.0.164: icmp_seq=102 ttl=64 time=2.42 ms
64 bytes from 10.0.0.164: icmp_seq=103 ttl=64 time=2.29 ms
64 bytes from 10.0.0.164: icmp_seq=104 ttl=64 time=2.27 ms
64 bytes from 10.0.0.164: icmp_seq=105 ttl=64 time=2.20 ms
64 bytes from 10.0.0.164: icmp_seq=106 ttl=64 time=2.27 ms
64 bytes from 10.0.0.164: icmp_seq=107 ttl=64 time=2.19 ms
(at this point the power LED and wireless LED both went out, and the
wake on LAN is not happening ... the laptop has to be manually woken).
--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
olpc mailing list
olpc(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/olpc
=---------------------
paul fox, pgf(a)laptop.org