power savings will stop transfers

[Ricardo Carrano]

Chris,

It happened two times during an scp tranfer between two XOs (I don't recall
if they were transferring via eth0 or via msh0 by the time - it is a test
that continuously switches the interfaces). It did not recover (I waited a
couple of minutes), until I brought the XO back, hitting the touch pad. It
them resumed the scp transfer.

It is not easy to reproduce this effect with the above test. How can we
reduce the time for the automatic suspend to happen? (Sorry couldn't find
this in the wiki).

[Ok. Maybe automatic and manual suspend would be more intuitive. ;-)]

On Jan 16, 2008 4:10 PM, Chris Ball <cjb at laptop.org> 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.
>
>   > (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.
> --
> Chris Ball   <cjb at laptop.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080116/2381cafb/attachment.html>