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><br>-- RC<br><br><div class="gmail_quote">On Jan 16, 2008 4:51 PM, Dan Williams <<a href="mailto:dcbw@redhat.com">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 class="Ih2E3d">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 class="Wj3C7c"><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>