I am sure we don't want a scenario where the user will have no chance whatsoever to connect to a salut network. Right?<br><br><div class="gmail_quote">On Feb 19, 2008 12:02 PM, John Watlington <<a href="mailto:wad@laptop.org">wad@laptop.org</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;"><br>We ALWAYS have multicast traffic.   Blindly waking on each<br>received multicast packet will ensure that we only sleep for<br>
milliseconds.<br><br>wad<br><div><div></div><div class="Wj3C7c"><br>On Feb 19, 2008, at 9:13 AM, Chris Ball wrote:<br><br>> Hi,<br>><br>>> It does feel like we should turn off suspend for some of our<br>>> testing.  I've experienced similar problems.<br>
><br>>> Chris, do you recommend removing ohm? Or is there something else we<br>>> should try?<br>><br>> I recommend fixing the bug.  :)  We know that we intend to have the<br>> CPU<br>> turned off most of the time on our laptops on the mesh -- why is the<br>
> presence service incompatible with this?  Should we be setting the<br>> wireless module to wake on multicast, so that we can respond to<br>> whatever<br>> traffic the presence service is using to see who's online?  Should<br>
> it be<br>> using unicast traffic instead?  What is it in Avahi's code path that<br>> causes its peer list to be emptied on resume?<br>><br>> If we have to disable OHM to test something in particular, that's<br>
> okay,<br>> but we won't be testing what we plan on shipping if we do so.<br>><br>> Thanks,<br>><br>> - Chris.<br>> --<br>> Chris Ball   <<a href="mailto:cjb@laptop.org">cjb@laptop.org</a>><br>
</div></div><div><div></div><div class="Wj3C7c">> _______________________________________________<br>> Devel mailing list<br>> <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>> <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
<br></div></div></blockquote></div><br>