New XO-1.5 10.2.0 build 112

[Paul Fox]

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 at lists.fedoraproject.org
 > https://admin.fedoraproject.org/mailman/listinfo/olpc

=---------------------
 paul fox, pgf at laptop.org