Devel Digest, Vol 27, Issue 59
Greg Smith (gregmsmi)
gregmsmi at cisco.com
Fri May 9 09:01:06 EDT 2008
Thanks for sharing the results. Did you use a wireless AP or active
antenna? If you can include a few details on that it will help. Can you
also include the XO build # and XS build and config if relevant?
Would you say that this test passed? That is, can we recommend that
schools use the chat activity with one chat session which all join?
Lastly, can you tell us what kind of testing time and focus you will
have in the near future? I believe there is a mesh test lab coming up at
Nortel in Ottawa as well. Any feedback on test capacity and plans there
is appreciated too.
I ask because there is recent feedback on mesh issues from a teacher at
Lambayeque, Peru http://wiki.laptop.org/go/Lambayeque#Inconvenientes and
a teacher in Uruguay has asked about supported Mesh features too. The
Lambayeque page says: they wish they knew in advance that Acoustic
Measure Activity would not work with 6 groups of two students each.
That's mostly an issue with activity design and our communication about
what activities support but it does raise a good test case (6 groups of
2 sharing a single activity).
I think both (Peru and Uruguay) teachers can help define meaningful mesh
use cases which will be applicable in many schools. I want to set the
right expectation on our capacity before I ask them to spend a lot of
time working with us.
I can start by telling them that chat as you describe above will work
well, if you agree. Then we can follow up to gather more details on how
they want to use the mesh.
The good news is they are motivated to use the mesh which helps validate
one design goal of the XO. Now we just need to understand how they want
to use it :-)
It looks like you are focused on finding the maximum scale of Xos which
can be in a mesh. That's clearly important info too. I'm just checking
if you have capacity to look at a few other test scenarios as well.
Date: Fri, 09 May 2008 03:29:51 -0400
From: Polychronis Ypodimatopoulos <ypod at mit.edu>
Subject: 65-node simple mesh test (and counting... ;-)
To: OLPC Development <devel at lists.laptop.org>, Sugar ml
<sugar at laptop.org>, viral at media.mit.edu
Message-ID: <4823FD6F.9090209 at mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Here are the latest results from Cerebro's (http://cerebro.mit.edu)
scaling properties. A 65-node testbed was used (703, Q2D14). The
NetworkManager had to be disabled in order to stabilize the behavior of
each XO's wireless interface. Unfortunately, the difficulty and time
necessary to manage increasingly more nodes is linear (given that the
NetoworkManager is disabled ;-), but increases steeply.
** Test plan:
Cerebro was started on all 65 laptops almost at the same time. We
attempted to emulate the "65 children turn on their laptops in class at
the same time" scenario. With Yani's help, it took about 5 seconds for
both of us to press 'enter' on all laptops. Each XO would discover each
other, exchange profile information and keep exchanging
According to the protocol, presence (mac address) arrives about other
XOs first, then the profile for the newly arrived mac address is queried
and finally the profile is cached. We assume that initially each XO has
no cached information about other XOs. As a result, every XO will query
We measured the time it took for each XO to discover and exchange
profile information with everyone else, bandwidth usage at all times
(during profile exchange and after the network stabilized when all
profiles were received everywhere)
Collaboration was tested on all 65 nodes: one shared a chat session,
everyone else joined. The chat session was based on Cerebro's
Discovery and profile information:
The following graph shows arrival of profile information at each XO from
other XOs a function of time. Each bar is a 3-second bucket representing
the average number of profile arrivals during this 3-second period. The
standard deviation is shown with the blue lines.
The following graph is the cumulative distribution function. It shows
that, on average, each XO has received about 95% of the profiles of the
rest of the nodes within just 20 seconds. This performance boost is due
to the fact that each XO queried for its profile, responds by
broadcasting the profile, instead of unicasting it to the requester. As
a result, the other nodes receive the profile too and the next node is
queried, yielding a linear cost, instead of a quadratic one.
The following wireshark snapshot shows bandwidth usage that peaks
momentarily at about 60kbytes/sec. The snapshot is also in accordance
with the first graph above, showing that after about 55 seconds the
network stabilizes. After the network stabilizes, bandwidth usage drops
to 1 packet every 3 seconds (less than 500bytes/sec), as the arrival
rate adapts to the density of the network.
Before the experiment was started, a node shared a chat session and all
64 nodes joined consistently. I sent a few chat messages from a couple
of XOs and were received on all other XOs.
** Other notes
After about 6.4 hours of continuous operation on all 65 nodes, Cerebro
shows stable memory usage (<10MB) and consistent CPU usage (83 minutes
of CPU usage in 'top').
MIT Media Lab
Tel: +1 (617) 459-6058
More information about the Devel