<br><br><div class="gmail_quote">On Feb 19, 2008 2:48 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;">
Yanni,<br><br>Timeout is a value, not a range. The effects brought by the timeout may manifest in a period (a range).</blockquote><div> </div><div>Did a use it otherwise? Because of the effects of xmas tree, the timeout for a failed XO until it's icon is removed is 10-30min.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I believe everyone will agree that 30 minutes is a long time to wait (and like Polychronis added) defeat the whole idea of a presence service.<br>
<br>But, what I want to stress is that we are dealing with different issues here. <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>I don't believe this 30 minutes or the xmas tree effect is related to suspend/resume. Those seem like bugs somewhere in the stack of software that support presence, while the suspend/resume issues are clearly a side effect of the multicast traffic not being "heard" by a suspended XO.<div>
<div></div><div class="Wj3C7c"></div></div></blockquote><div class="Wj3C7c"><br>There are way too many issues. Theses bugs (30min/xmas tree) enhance the effects of suspend/resume on the mesh.<br>I believe that since we have the big test week coming, everyone must be aware of them, or else noone will interpret the results properly.<br>
<br>The direct suspend/resume bugs are:<br><br>1. Why the mesh view empties after a long suspend, and how this affects the mesh view<br>2. Why some times the avahi cache is cleared after resume. <br><br><br>Ricardo, do you have anwers to the questions I posted before? :<br>
1.
When a XO resumes, does it send any notification via avahi, that it is
back? Because if it doesnt, then other XOs that have cleared it from
their lists, they will never search for it.<br>
<br>2. Every scans the network every 10min, to check whether its avahi
peers are alive, in multicast packets. Do these packets include the
address of the peers/targets? I think they do, unless i am very
confused. Couldn't we awake/resume the target XO when it receives these
specific packets? <br><br><br><div class="gmail_quote">On Feb 19, 2008 3:00 PM, Giannis Galanis <<a href="mailto:galanis@laptop.org" target="_blank">galanis@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;">
The list expires in 10min-30min.<br><br>But we cant wait 30min before suspending, it is way too long.<br><br><br><div class="gmail_quote"><div>On Feb 19, 2008 11:37 AM, Ricardo Carrano <<a href="mailto:carrano@ricardocarrano.com" target="_blank">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;">Yanni,<br><br>As I posted in the bug, I believe that you are observing the entries on the avahi cache expiring.<br>
<br>So, your first scenario would happen when the suspend time is longer than the time it takes for all entries to expire.<br>
The second scenario would happen when the suspend time is not long enough to make all cached entries to go away.</blockquote></div><div><br>Oh i see that you mean. But, i think both cases are when the suspend time is longer than time to expire.<br>
The first is UI effect, and might have no relation to salut, but to mesh view in general<br>The second is an avahi effect, that the avahi cache is chagned<br>Both, are in long suspends<br></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>And the third scenario seems related to previous reports you've made on the Xmas tree effect, so not related to suspend/resume.</blockquote></div><div><br>The xmas tree effect appears when XOs leave connection, while others return.<br>
Suspend/resume enhances this effect dramatically, because in 1-2min everyone goes away, and they return at random time according to when they resume.<br><br>In my suspend-salut tests , the xmas tree effect(although NOT related to suspend/resume), it affects salut alot more then the other 2 scenarios<br>
<br>My point is that we must fix it anyway. But especially now!!<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>What do you think?</blockquote><div><br>I have 2 questions that will help (me) understand alot about the situation:<br><br>1. When a XO resumes, does it send any notification via avahi, that it is back? Because if it doesnt, then other XOs that have cleared it from their lists, they will never search for it.<br>
<br>2. Every scans the network every 10min, to check whether its avahi peers are alive, in multicast packets. Do these packets include the address of the peers/targets? I think they do, unless i am very confused. Couldn't we awake/resume the target XO when it receives these specific packets? <br>
<br>we need to do some sniffing<br><br> </div><div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div>
<br><div class="gmail_quote">
On Feb 19, 2008 1:13 PM, Giannis Galanis <<a href="mailto:galanis@laptop.org" target="_blank">galanis@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><br><div class="gmail_quote"><div><div>On Feb 19, 2008 10:13 AM, Ricardo Carrano <<a href="mailto:carrano@ricardocarrano.com" target="_blank">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;">
<br><div class="gmail_quote"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I was asking whether it would help to have the wireless module wake us<br>
on multicast packets instead of only unicast. Are you saying that it<br>would?</blockquote></div><div><br>It seems so, though it would, as John points out, make resumes far more constant. It seems we have to find a creative way out of this tough choice (automated suspend vs mesh) or face it.<br>
</div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div><br> > Avahi entries will expire after some time. Suspend will prevent it<br>
> to update its cache.<br><br></div>Yani's bug report (#6467) suggests that Avahi entries often expire<br>immediately upon resume:<br><br> After the XO resumes (probably after beinng suspended for several<br>
minutes) all the icons in the mesh view vanish, except the mesh<br>
circles.</blockquote></div><div><br>I read this as the avahi-cache expiring its entries. Yanni can you put timeframes on this?<br>Could check how long does it take to expiry an entry (TO) and then check if:<br>Suspend time > TO -> all entries vanish<br>
Suspend time << TO -> no entries vanish<br>Supens time ~ TO -> some entries vanish</div></div></blockquote></div></div><div><br>There as 2 cases where icons vanish due to suspend.<br><br>1st: The moment you resume(it generally happens after long suspends), all icons vanish instantly(APs/XOs). This bug (#6467) suggests that sugar has a problem with suspend resume. <br>
The icons slowly reappear. I assume that if the avahi peer list is intact that all XOs return.<br><br>2nd: The avahi list smtimes looses some or all of the peers at resume. This is also under 6467, but it seems technicaly different. One possible explanation could be that during suspend th XO resumes several times, but i didnt notice it! And within this time frames it realized that the other suspended XOs are gone, so it cleared its cache. Now when I resumed it myself, I observed that the cache is clean!!<br>
<br>Now, regarding the timeouts of avahi. This is a 3rd thing:<br>When an XO leaves the channel we have 4 states:<br> mm:ss<br>1. 00:00 XO leave the channel(manually/or ti suspended)<br>2. 10:00 Avahi notices teh XO left, and reports it as "failed"<br>
3. 30:00 Icon dissappears in the mesh view<br>4. 60:00 Avahi cache is cleared<br>Additionally there is a bug(#5501) according to which, is a NEW XO arrives between states 2 and 3, then instantly ALL "failed" avahi peers are cleared and the corresponding icons vanish.<br>
<br>So, the 3rd case is the following:<br><br>Assume a mesh has e.g. 20 XOs, and I use my XO so it doesnt suspend, but the rest 19 of them are suspended.<br>If in >10mins a new XO arrives, then all the 19 XOs instantly vanish from the mesh.<br>
<br>So the TO time is between 10->30min... but closer to 10min if many XOs suspend/resume<br>So if resume time << 10min everything is fine!!<br><br><br><br>What i dont know is when an XO resumes if it sends any avahi packet no notify tis presence/return. Because if it doesnt, then the XO wont exist int he others cache list, so the others wont search for it.<br>
Sjoerd, can you answer this?<br><br>This would explain why after resume some XOs take tooo long to see each other again.<br>If you combine this with the "2nd" case, you will see that in the natural case that XOs will resume at random points in time by the user, they will all clear their cache, unless they resume concurrently.<br>
So in the end, all will have empty caches!!<br><br> <br><br></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">
<div><br></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div><div><br>Thanks,<br><br>- Chris.<br>--<br>Chris Ball <<a href="mailto:cjb@laptop.org" target="_blank">cjb@laptop.org</a>><br></div></div></blockquote></div></div><br>
</blockquote></div></div><br>
</blockquote></div><br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br>
</div></div><br>