Monday's Testing

[Ricardo Carrano]

Martin, David,

There is the detection of a school server _and_ there is the detection of
mesh density. Different issues (both present at Wad's testbed).
And, there is also detection of an infra-structure.

>From a high-level perspective NetworkManager keeps a state machine that
should tell us where we are.

>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.

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.

--
Ricardo Carrano

On Thu, Mar 27, 2008 at 9:14 PM, <david at lang.hm> wrote:

> On Thu, 27 Mar 2008, Martin Langhoff wrote:
>
> > 2008/3/27 Ricardo Carrano <carrano at laptop.org>:
> >> My suggestion for the Cambrige testbed is:
> >> 1 - Validade probe response driver patch submitted by Marvell and
> implement
> >> it
> >> 2 - Increase contention window from 7,31 ro 31, 1023
> >>  3 - Increase route expiration time from 10 to 20 seconds
> >> 4 - Increase mcast rate from 2 to 11 Mbps.
> >>
> >> All of the above are trade offs and should be considered in dense mesh
> >> scenarios only. Based on what I see in my own testbed, they will reduce
> the
> >> duration of bursts and also make you more resilient to them.
> >
> > Hi Ricardo,
> >
> > if this improves the behaviour in dense mesh scenarios, am I right in
> > thinking we'll be looking at - from a high-level pov - changing
> > contention window, route expiration and mcast rate dynamically on the
> > XOs when they see the school server antenna with a strong signal, and
> > then again when they lose sight of it. I am not familiar with the mesh
> > driver so this may be a stupid question - is it safe to change those
> > values on the fly?
> >
> > The switch-modes decision logic could be tricky
> >
> > -  needs data from different network layers
> > -  needs tuning to avoid having ranges where we switch back-and-forth
> >
> > still getting to grips with how the mesh works - hopefully the above
> > makes sense ;-)
>
> it may be that it's not a case of 'mode A' vs 'mode B' but is instead a
> continuous function based on how many other nodes that it sees. with small
> changes based on the number of nodes it won't matter much if it bounces
> around as the number of nodes change (as long as it doesn't waste a lot of
> power to make the change)
>
> David Lang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080328/09551a12/attachment.html>