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 > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc =--------------------- paul fox, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel