[sugar] 65-node simple mesh test (and counting... ;-)

John Watlington wad at laptop.org
Tue May 13 10:59:28 EDT 2008


On May 12, 2008, at 3:31 PM, Ricardo Carrano wrote:

>
> > How does the collision model/scheme change between AP mode and
> > ad-hoc/mesh modes?
>
> As far as I can tell, it doesn't.  802.11s is interoperable with
> 802.11abg, which means that the same media access algorithms are used.
>  At least part of our problem might be in the synchronized transmits
> occurring in our present 802.11s implementation of broadcast, which
> are probably killing whatever CA scheme 802.11abg dictate.  See:
>  http://wiki.laptop.org/go/ 
> Path_Discovery_Mechanism:Sanity#Question_.232_- 
> _Does_PDM_traffic_self-interfere.3F
>
> which is trying to deal with low-level path discovery requests, which
> also use the broadcast mechanism.
>  --scott
>
> Yes, it is the same 802.11 DCF for both scenarios (infra and mesh).
>
> I would like to add to this discussion that sparse and dense mesh  
> are too completely different animals. Most of the problems that we  
> are trying to address now, are associated to the latter.

Certainly an interesting question.  But is your answer really true ?
I'd argue that very little, if any, testing has been done
of the "large, yet sparse" mesh.   Certainly none by OLPC.

Our problems certainly come from "large" meshes (more than
10-15 laptops in the mesh).   What is your definition of sparse ?

> The more we dig into this, the more clear it gets that we need to  
> "adapt".
>
> Everything we do to increase coverage in a sparse mesh hurt us in a  
> dense cloud. One example: broadcasting or multicasting at 1 or 2Mbps.

> Likewise, what we do to increase reliability, might actually  
> decrease it. One example: the verbosity or redundancy of some of  
> our protocols. And that's one of the strengths of Cerebro (less is  
> more).
>
> So, as a side note: Treating the two animals as different will  
> avoid some bites and scratches. ;-)

One interesting note is that the suggested routing algorithm for  
802.11s is a combination
of reactive and proactive routing (unlike our current one, which is  
solely reactive).
Perhaps that provides the adaptation necessary for the mesh to work ?

wad



More information about the Sugar mailing list