power savings will stop transfers

[Ricardo Carrano]

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 <dcbw at redhat.com> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080116/adef5112/attachment.html>