mechanisms tied to mesh: "under a tree" collab

[Ricardo Carrano]

On Wed, Sep 17, 2008 at 1:26 AM, John Gilmore <gnu at toad.com> wrote:
> 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
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>

John,

It is true that some false expectations were created around the mesh
and some people may be disappointed because they embraced such
expectations. It is unfair to use a hammer as a screwdriver and them
drop the hammer as a worthless tool.

If you point an alternative and better way to provide communication
capabilities, with no infra-structure at all, let us know. The ad hoc
mode of 802.11 is not that alternative. Not even IEEE thinks it is
(otherwise there will be no 802.11s). It is a very limited setting, at
some point you will want multi hop capabilities.

By the way, wireless multihop networks are not only possible, they are
a reality. There are whole cities around the world, from Montain View
to Vienna that benefit from it. These solutions vary in the degree of
engineering/infra used. But it is possible to have an inexpensive
version of that also in Peru, Uruguay, Mongolia, and everywhere. All
you need is some XOs and some active antennae.  Think of the small
villages, the rural areas, and all the scenarios that can benefit from
it.

I agree with some of your arguments. Example: from an architectural
point of view modularity is desirable. But I doubt there was the
omniscient decision to "to tie application sharing to Mesh and Sugar".
But just so people don't get confused, we should focus on improving
the mesh, because AFAIK there is no intention to drop it.

And, incidentally, no one in the world is dropping the mesh. Quite the
opposite. 802.11s is in mainline Linux kernel and maybe you don't know
that OLPC was one of the supporters of it. Our mesh was not compatible
to the standard simply because there is no standard yet (802.11s is
still a draft and when OLPC started it's implementation was still a
very incipient version). And if a standard ever happens, this will be
in at least in part due to OLPC efforts too. And you'll see all kinds
of educational laptops using it.

Yes, there were mistakes. Let's do better, not give up.

And truly, take five XOs and give them to a group of kids in the
middle of nowhere. Teach them how to collaborate and observe.

Cheers!
Ricardo