mechanisms tied to mesh: "under a tree" collab

[John Gilmore]

Ricardo Carrano said:
> There are technical challenges in the way, but OLPC should keep
> pushing this for the benefits it will bring. It seems a perfect fit
> with the Mission.

Mesh and the Marvell WiFi chip have been two of the big
disappointments of the OLPC.  The mesh implementation simply doesn't
scale.  We've had to require people to turn it off to just get basic
TCP/IP to work in classrooms.  We've stopped designing mesh wireless
into school servers.  Maybe it will work someday -- in fact I'm sure
it will work *better* someday.  And the Marvell chip, as delivered,
burned something like twice the power it was spec'd to burn, reducing
the laptop's suspend time so it does not even survive one night, even
when not actively forwarding packets.  Its promised open source
firmware ended up proprietary and endlessly buggy.  Its USB interface
was almost incompatible with the laptop's power management
implementation, which is forced to turn off the USB bus, and still
requires great amounts of dancing on the head of a pin for CPU
power-off suspends to work at all (they were designed to resume
invisibly in 0.1 seconds, but cannot resume in less than 1.0 seconds).
The mesh protocol implemented is still only compatible with itself and
no other vendor; it's not a standard.

In short, among the promised "miracles" of the OLPC project, the mesh
was a failure.  We got a great screen, we got a low power fanless
flash-based laptop, we got cute and kidproof packaging, we got a low
price (almost), we got a promise of long battery life (someday), but
we didn't get automatic wireless networking that works all day in the
school and extends throughout the village all night without
infrastructure.  I don't mean to rub it in, Ricardo, but it's a fact
that anyone can see if they merely open their eyes.  To "keep pushing"
on something that did not deliver the goods for three years is not
always the best option.

If a small amount of software work would give OLPC the option to drop
mesh support in future products, I think OLPC should *definitely* do
that small amount of work.  Which is not to say they should drop the 
mesh -- just that they should keep their options open.

Martin Langhoff said (quoting me):
> > Another mechanism that only works on Mesh is sharing "under a tree".
> Ah, this is a bit of a misunderstanding :-)

Well, whether or not you asked the question ("What would we have to
change to delete Mesh from our product, since we aren't using it
much?"), you inspired me to try to answer it.  So far it looks like
only lease activation, sharing under trees, and long-distance but
thinly populated villages require mesh.  I filed bugs #8524 and #8525
for two possible enhancements (make leases and tree-sharing work
without mesh).

The decision to tie application sharing to Mesh and Sugar was a bad
design idea, one which I've been intending to explore fixing.  It
should work over any working network, which includes 802.11 adhoc
without access points, and in any GUI.  Breaking those ties would
allow anybody who runs AbiWord to do OLPC-like sharing.  And once
that's working on ordinary network hardware, in ordinary Linux
distros, for the 99.99% of Linux users who don't run Sugar, then lots
of other shareable apps would quickly follow.  The Linux programmer
community that works on Sugar activities is less than 1% of the total
Linux application programmer community.  By telling them "this shared
collaboration stuff only works if you blow away your user interface
and replace it with this extremely clunky one -- and set up a custom
school server in your house or office", they think, "I'll add shared
collab to *my* software when they have put a bit of polish on this
'feature'."

>                                      My understanding is that it
> works automagically between XOs on the same AP -- but may have
> limitations and possibly bugs as it's not something we push (and it's
> not something we test much formally ...

My naive understanding was that zeroconf works, so you can run TCP/IP,
but something about our non-mesh sharing protocol requires a "server"
somewhere.  Otherwise what's that setting in "Network" in the Control
Panel: "Mesh Server: olpc.collabora.co.um"?  Don't we switch between
two different wire protocols (theoretically seamlessly), one of which
requires a server?  Yep:  http://wiki.laptop.org/go/Collaboration_Tutorial
says we use gabble to talk to a server, and salut for link-local serverless
sharing.

> btw, the assumption you make that laptops "just can see eachother" via
> RF is not quite right when it comes to 802.11a/b/g. It's a
> misconception I had too until I sat down and read the o'reilly 802.11
> book (Thick But Worthwhile). 

Yep, many radio protocols use repeaters for many good reasons,
including hidden nodes and other channel allocation problems.  But the
ability to talk node-to-node -- without repeaters -- is a key feature
of many radio protocols.  Both capabilities are built into 802.11.

Note that when five kids are sitting under a tree using 802.11s Mesh,
their radios are talking directly node-to-node.  There is no packet
forwarding needed in such a short-distance network (though broadcasts
and multicasts are probably getting forwarded -- duplicated --
anyway).  That's the same scenario in which I suggest that plain
repeater-less adhoc 802.11 should work.

> Simple mesh does work but at a cafe I want to play with my pal *and*
> check the facebook profile of the girl I met yesterday so I know the
> bands she likes. Don't make me choose. :-p

I'm not proposing to make you choose.  

I think OLPC software, and the Linux software that OLPC shares with,
should support sharing between:

  *  Two XO's under a tree (or more).
  *  Two XO's on the same isolated access point (or more).
  *  Two XO's on the same Internet-connected access point (or more).
  *  Two XO's on the same school-server-connected access point (or more).

All using standard 802.11 (non-mesh) protocols.  In addition, in
places where a mesh is useful, sure, add that case to the four above.
But don't force users onto a mesh that they don't need (or that their
other devices don't implement) just so they can share.

Ben Schwartz said:
> My sense is that many OLPC
> developers would ideally like a relatively thin, generic 802.11 chip and a
> relatively generic, low-power processor to go with it, so that the main
> CPU can shut down, and critical network services can run on the
> coprocessor.

Next-generation system-on-chip CPUs like the OMAP3 can shut down and
wake back up the main CPU in microseconds, allowing ordinary DNA and
interrupts to bring it out of low-power mode, do whatever work is
required for milliseconds, and then go right back into low power
consumption.  See, for example, the third slide in:

  http://www.celinux.org/elc08_presentations/TI_OMAP3430_Linux_PM_reference.ppt

The red line is voltage, the blue is amperes.  Most of the time they
both sit at zero.

Trying to partition the work between a "main CPU" and very different
"coprocessors" has caused lots of the technical troubles the XO has
had (between the EC and the CPU; between the CPU and the Marvell chip;
and between the EC/CPU and the touchpad/keyboard chip).  All three
interfaces have been buggy and problematic in the extreme, burning up
MONTHS of the time of many talented senior engineers, deep hardware
probing, etc.  And gee, all of those CPUs except the main one ended
up running proprietary software.  A partitioned architecture a simple
*looking* concept, and you're forced to do it when the main CPU is
really dumb about power consumption, but I strongly hope we won't give
ourselves that problem in Gen2.

> The best architecture I can imagine is to run the Cerebro
> mesh routing and presence algorithms on that coprocessor.  Cerebro's
> performance in tests on XO's has been amazing to me, so far.

Cerebro's huge bugs and massive resource consumption have been amazing
to me, so far.  But that's off-topic for this way-too-long message.

	John