power savings will stop transfers

[Ricardo Carrano]

The question, after all, seem to be: Having frames to send out will or will
not bring the XO out of automatic suspend mode?
If not, we'll halt tcp connections sometimes. Particularly if the XO in
suspend is the sending node.

On Jan 16, 2008 7:06 PM, Ricardo Carrano <carrano at ricardocarrano.com> wrote:

> 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/fb5cbf65/attachment.html>