[Testing] [sugar] Automated testing, OLPC, code+screencasts.

Benjamin M. Schwartz bmschwar at fas.harvard.edu
Thu Mar 27 01:37:16 EDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michail Bletsas wrote:
| testing-bounces at lists.laptop.org wrote on 03/26/2008 09:19:19 PM:
|
|> 2. Many, and perhaps most, of OLPC's remaining difficult bugs are
| related
|> to the network.  They are most commonly related to the closed wireless
|> firmware, which is buggy and lacks key features regarding mesh routing
| and
|> multicast.
|
| Can you qualify your statement?
I have seen the wireless hardware silently drop all outgoing packets but
continue to route incoming packets for several minutes, until forcibly
reset by the user (about a month ago).  The firmware is so unstable that
the wireless driver even contains a mechanism to recognize when the
firmware has wedged and reset it.  This is what I mean by buggy.

| What features does it lack when it comes to mesh routing?
For me, the #1 missing feature is whitelisted wake-on-multicast.  To be
specific, it should be possible for the firmware to be told which
multicast addresses refer to this host.  The firmware would then wake up
the CPU only when a multicast packet arrives with a destination that is on
the whitelist.  Without this feature, we are forced to choose between
never waking on multicast, and missing lots of important packets, and
waking up on every single multicast packet, which essentially means never
sleeping at all.

My #2 missing feature is a control for transmit gain and receive gain.  By
decreasing gain, the range of each transmission could be reduced, turning
dense meshes in a single classroom into multihop meshes.  This might
compensate somewhat for the firmware's simplistic multicast routing.  It's
not clear that this would work, but at present we cannot even try it.

Smart multicast routing is the other obvious missing feature; I appreciate
that this is still considered an academic research problem.

| Can you point me to a better working implementation out there when it
| comes to multicast routing?
No, I cannot.

This wireless firmware may be the best mesh implementation in all of
history, in the whole world.  It's still disgustingly buggy, and has
already set the project back months.  Its multicast and wakeup behaviors
have forced us to drop critical features.  The software team has come to
regard the wireless system as so unpredictable that any task involving it
is "science, not programming".

I am also quite convinced that if OLPC developers were free to read the
source code and modify it, given access to Marvell's internal
documentation, we would be much further along.

|> 3. Almost all of OLPC's major bugs are Heisenbugs.  They often don't
|> appear at all with only one laptop, and appear rarely until one has 12
| or
|> more laptops sharing a wireless mesh.
|
| And most of them are due to the fact that our application traffic
| saturates the wireless spectrum.

Indeed.  And that is due to a mismatch between Salut, which assumes
efficient multicast routing, and the firmware, which doesn't provide it.
I know very little about the ongoing work with Cerebro, but that seems to
be a very reasonable next step.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6zKMUJT6e6HFtqQRAjYKAKCffnf5uXMdKI/OcLNNMBZVYmlgSACggq9Q
jyAWy4yzyGAO+IfIIlmM+JE=
=gamM
-----END PGP SIGNATURE-----


More information about the Testing mailing list