Dan, That's exactly the track I am trying to follow. And that's why this is difficult to reproduce. I need to shorten the cycle. Next time I won't interfere. My gues is that the connection will timeout.
-- RC On Jan 16, 2008 4:51 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Wed, 2008-01-16 at 13:10 -0500, Chris Ball wrote: > > Hi, > > > > > If you, for example, are transfering a file when the XO enters in > > > power savings mode, the transfer will halt. > > > > For how long? As soon as the XO hits suspend, the WLAN/EC will > > assert wakeup on receipt of the next unicast packet, and then OHM > > will wait another thirty seconds or more before suspending again. > > Have you experienced otherwise? The transfer should continue after > > the wakeup without any disconnection. > > Does that still happen if the machine suspends right after it gets the > ACK for the last packet, but before it sends out the next packet? Or > does some sort of TCP keepalive come into play here? > > Dan > > > > (I avoided using the term 'suspend'. I believe suspend is an user > > > action, while sleep is automatic, anyway...) > > > > Other way around; suspend is automatic and frequent, sleep is > > user-invoked. > > > > > I don't believe this is a feature. How should we deal with it? > > > > As above, I think this should be harmless. If you disagree, as the > > olpc-update script does, you can "touch/rm /etc/ohm/inhibit-suspend" > > before/after a transfer. > > > > Note that if the transfer uses non-trivial CPU (for example, rsync) > > it should inhibit suspend automatically by virtue of the CPU use. > > > > - Chris. > >
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
