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@lists.laptop.org http://lists.laptop.org/listinfo/devel