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 <[EMAIL PROTECTED]> wrote:
> Da
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 <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-01-16
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
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 unica
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 be
If you, for example, are transfering a file when the XO enters in power
savings mode, the transfer will halt.
(I avoided using the term 'suspend'. I believe suspend is an user action,
while sleep is automatic, anyway...)
I don't believe this is a feature. How should we deal with it?
-- Ricardo Ca