Martin, David,<br><br>There is the detection of a school server _and_ there is the detection of mesh density. Different issues (both present at Wad's testbed).<br>And, there is also detection of an infra-structure.<br>
<br>From a high-level perspective NetworkManager keeps a state machine that should tell us where we are.<br><br>From a layer two pov, Michalis already pointed out that this can be implemented at firmware level. So the tweakings will be transparent to upper layers.<br>
<br>An example of higher level tweak is switching from Jabber (and shutting down Salut) when possible. Here you have to be careful with the back and forth issue you mention.<br><br>--<br>Ricardo Carrano<br><br><div class="gmail_quote">
On Thu, Mar 27, 2008 at 9:14 PM,  <<a href="mailto:david@lang.hm">david@lang.hm</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 Thu, 27 Mar 2008, Martin Langhoff wrote:<br>
<br>
> 2008/3/27 Ricardo Carrano <<a href="mailto:carrano@laptop.org">carrano@laptop.org</a>>:<br>
>> My suggestion for the Cambrige testbed is:<br>
>> 1 - Validade probe response driver patch submitted by Marvell and implement<br>
>> it<br>
>> 2 - Increase contention window from 7,31 ro 31, 1023<br>
>>  3 - Increase route expiration time from 10 to 20 seconds<br>
>> 4 - Increase mcast rate from 2 to 11 Mbps.<br>
>><br>
>> All of the above are trade offs and should be considered in dense mesh<br>
>> scenarios only. Based on what I see in my own testbed, they will reduce the<br>
>> duration of bursts and also make you more resilient to them.<br>
><br>
> Hi Ricardo,<br>
><br>
> if this improves the behaviour in dense mesh scenarios, am I right in<br>
> thinking we'll be looking at - from a high-level pov - changing<br>
> contention window, route expiration and mcast rate dynamically on the<br>
> XOs when they see the school server antenna with a strong signal, and<br>
> then again when they lose sight of it. I am not familiar with the mesh<br>
> driver so this may be a stupid question - is it safe to change those<br>
> values on the fly?<br>
><br>
> The switch-modes decision logic could be tricky<br>
><br>
> -  needs data from different network layers<br>
> -  needs tuning to avoid having ranges where we switch back-and-forth<br>
><br>
> still getting to grips with how the mesh works - hopefully the above<br>
> makes sense ;-)<br>
<br>
</div>it may be that it's not a case of 'mode A' vs 'mode B' but is instead a<br>
continuous function based on how many other nodes that it sees. with small<br>
changes based on the number of nodes it won't matter much if it bounces<br>
around as the number of nodes change (as long as it doesn't waste a lot of<br>
power to make the change)<br>
<br>
David Lang<br>
</blockquote></div><br>