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

[Bill Mccormick]

The network manager could be the culprit here, although I thought you
had it disabled, how did you disable it?

When it's running it looks like it first looks on channel 1 for a DHCP
server.   Then channel 6.   Then channel 11.  Then it tries to connect
to the last known access point.   Then it does it all again.   This will
take a bit of time...

Only then does it assume that there is no DHCP server and switches to ad
hoc mode on channel 1.

Bill

-----Original Message-----
From: devel-bounces at lists.laptop.org
[mailto:devel-bounces at lists.laptop.org] On Behalf Of Polychronis
Ypodimatopoulos
Sent: Friday, May 09, 2008 6:04 PM
To: C. Scott Ananian
Cc: OLPC Development; viral at media.mit.edu; Sugar ml
Subject: Re: 65-node simple mesh test (and counting... ;-)

On Fri, May 9, 2008 at 10:57 AM, Marcus Leech <mleech at nortel.com> wrote:
>> I'd be *very* interested to compare the distribution on a wired
network.
>> It seems to me that given
>>  the broadcast model, everybody should see everybody else in much 
>> shorter time than the 55 seconds  shown in the outlying cluster on 
>> that graph.

Marcus, this is indeed an interesting idea. However it has a significant
problem: wiring up more than 60 XOs onto a switch requires equipment,
time and space that OLPC cannot presently provide. Such a testbed though
is absolutely necessary not only as a proof of concept for your
suggestion, but also for doing large scale mesh network testing in
general.

>
> The common, but erroneous, assumption is often made that a wireless 
> network is just like a wired network, but with the wires removed.
>   

So very true!

> On a wireless network, broadcasts are successfully received with much 
> lower probability.  RF is mysterious and magical, and all sorts of 
> connection asymmetries, near-field effects, and radiation lobe 
> patterns conspire to make it unlikely that *everyone* can hear you 
> equally at once -- and then you get into remote collisions and other 
> mechanisms that make you unaware that not everyone heard you.  And 
> there is not 'ack' mechanism for 802.11 broadcast.
>   

All these are true also, but I think we're mystifying things a little
bit here. The wireless medium is unpredictable mainly because its
properties are also a function of time (a non-issue in wired networks),
but at least (thank God!) it [the wireless medium] does not discriminate
between broadcast and unicast frames! Adding an ack scheme to broadcasts
should yield equal (or even better due to lowered speed) reliability
using broadcast frames. Even without the ack scheme, I noticed that, on
average, some 95% of the data transmitted over broadcast are
successfully received on all nodes. We are throwing this away by
discarding it on our wireless interfaces.

Pol



--
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/

_______________________________________________
Devel mailing list
Devel at lists.laptop.org
http://lists.laptop.org/listinfo/devel