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.

<br><br><div class="gmail_quote">On Jan 16, 2008 7:06 PM, Ricardo Carrano <<a href="mailto:carrano@ricardocarrano.com">carrano@ricardocarrano.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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.

<br><font color="#888888"><br>-- RC</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Jan 16, 2008 4:51 PM, Dan Williams <<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>

> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>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.

<br>> Have you experienced otherwise?  The transfer should continue after<br>> the wakeup without any disconnection.<br><br></div>Does that still happen if the machine suspends right after it gets the<br>ACK for the last packet, but before it sends out the next packet?  Or

<br>does some sort of TCP keepalive come into play here?<br><font color="#888888"><br>Dan<br></font><div><div></div><div><br>>    > (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?

<br>><br>> As above, I think this should be harmless.  If you disagree, as the<br>> olpc-update script does, you can "touch/rm /etc/ohm/inhibit-suspend"<br>> before/after a transfer.<br>><br>> Note that if the transfer uses non-trivial CPU (for example, rsync)

<br>> it should inhibit suspend automatically by virtue of the CPU use.<br>><br>> - Chris.<br><br></div></div></blockquote></div><br>

</div></div></blockquote></div><br>