Monday's Testing

mbletsas at mbletsas at
Thu Mar 27 22:26:03 EDT 2008

It is safe to change these values on the fly.
Marvell was discussing doing it automatically.
A simple heuristic to check if there is congestion is to check the retransmission counters. So this is a relatively simple to implement  adaptive behavior.


----- Original Message -----
From: "Martin Langhoff" [martin.langhoff at]
Sent: 03/27/2008 08:03 PM AST
To: "Ricardo Carrano" <carrano at>
Cc: John Watlington; "OLPC Developer's List" <devel at>; Michail Bletsas
Subject: Re: Monday's Testing

2008/3/27 Ricardo Carrano <carrano at>:
> 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 ;-)


 martin.langhoff at
 martin at -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first

More information about the Devel mailing list