Re: [IAEP] "Mesh" Dreams = OLSR
I'm not 100% certain we've pulled in members of the OLSR mailing lists on this thread yet. But they've actually got a number of very impressive *real world* demonstrations of OLSRd in the wild. You'll have to search the devel@ archives for 'olsr' to find the emails I sent years ago with all the details. Granted, I don't know that they've demonstrated the software scaling out to distributed notes *and* in to 100 laptops in a single room w/o any manual tweaking. They can best tell you about that themselves. But OLSR is a much more appropriate and much less "pixie dust" solution than 802.11s ever was/is/will be. I think the primary challenge is social -- isn't it always? The OLSRd guys have to get passionate about making their stuff work on XOs, and enough deployments have to be adventuresome (and desperate) enough to give them a testbed to iron out all the kinks. But I think it's a worthwhile "management" challenge for someone to attempt. Because what's needed is leadership, managing the resources, linking person A to person B, driving it to release/ship, and a little bit of inspiring the troops. The technical challenges are much less hard. (And it's probably an "outside OLPC" project, at least initially, because OLPC can't afford to devote any resources to it.) --scott ps. technical challenges: making it bulletproof and brainless, seamless scalability from lots of laptops in a tight space to a few laptops spread out, and (eventually) processor-independent operation on the marvel microcontroller to allow sustaining the mesh at very low power levels. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
Mike, Thank you for the information! To be clear, from what I understand from our discussions in the past you're topology looks like AP(802.11A + OLSRD) - AP (802.11B/G) - XO You have several AP(802.11A + OLSRD) acting as your backbone and they drop down to standard AP (802.11B/G) for connection to the XOs. Please let me know if this is correct. Out of curiosity: have you considered extending your OLSR network to the AP (802.11B/G)'s and installing the OLRSd binary on your XOs so the OLSR network can be extended beyond the school? Thanks, Reuben On Sep 2, 2010, at 6:36 PM, Mike Dawson wrote: > Hi, > > Sorry for my late reply to this. Actually we use OLSR in Afghanistan > to do our school networking like so: > > 1. An OLSR router (running openwrt Freifunk ; see freifunk.net ) > connects to the other routers in the school - that forms the backbone > on one network (e.g. channel 6) > > 2. A vanilla OpenWRT router actually connects to the XOs in the class. > We reduce the transmit power on that and run it on a different > channel (e.g. 1 or 11) > > The plus side is that you get a pure wireless system that does not > need network cabling / does not have cables getting killed by the > environment. The down side is you use more routers. I think > financially the costs are pretty similar. Also you can now use > 802.11n to get good speeds on the backbone. > > Seems to scale pretty nicely - we have 500 XOs in most schools. Note > though by design we are not using the collaboration on the school > server but rather just through the AP - teachers are not that enthused > by the prospect of kids being able to chat with anyone anytime. > > This has practically made doing the deployment in the field a bit > easier - though the firmware is not always perfect and not always > working out of the box with all hardware options. > > Regards, > > -Mike > > > > On 25/08/2010, Martin Langhoff wrote: >> On Tue, Aug 24, 2010 at 11:13 AM, Reuben K. Caron >> wrote: >>> Where Mesh != 802.11s but rather an adhoc, self healing, self >>> organizing routable network. >> >> Cerebro gave a great working demo of what you describe. Don't know >> how >> they compare. >> >> I think it is perfectly feasible to achieve what you want... >> >> - to do it seamlessly and with polish will take a ton of work >> >> - very few users will actually benefit because the "under a tree" >> scenario covers IMHO most of our interesting use cases. >> >> People do talk about having a mesh that covers their whole town, and >> it's great dream but not achievable with our current constraints >> >> - town-wide meshes are made of stationary nodes >> >> - the "mesh" approaches we're discussing burn CPU / battery... >> >> - perennially power-starved users will focus on use, not on >> maintaining the communal mesh up >> >>> Imagine a world where Sugar on a Stick machines can communicate on >>> the >>> same network as an XO laptop >> >> We have that now with ad-hoc and infra. Limited but we have it. >> >>> A world where mesh capabilities are >>> hardware agnostic allowing anyone to bring up a mesh network by >>> booting a live cd. >> >> Mesh is pixie dust for most people. Your 'imagine' lines will make >> the >> imagine things that cannot be made to work _in the way people >> imagine_. Some meshy things can be made to work in a lab. Others just >> involve tradeoffs no sane user would take on... >> >> We've had bazillion threads about this, because mesh stokes passion. >> Problem is... even if you had the magical code right now working >> seamlessly... the cost/benefit ratio isn't good. >> >> cheers, >> >> >> >> m >> -- >> martin.langh...@gmail.com >> mar...@laptop.org -- School Server Architect >> - ask interesting questions >> - don't get distracted with shiny stuff - working code first >> - http://wiki.laptop.org/go/User:Martinlanghoff >> ___ >> Devel mailing list >> de...@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Tue, Aug 24, 2010 at 11:13 AM, Reuben K. Caron wrote: > Where Mesh != 802.11s but rather an adhoc, self healing, self > organizing routable network. Cerebro gave a great working demo of what you describe. Don't know how they compare. I think it is perfectly feasible to achieve what you want... - to do it seamlessly and with polish will take a ton of work - very few users will actually benefit because the "under a tree" scenario covers IMHO most of our interesting use cases. People do talk about having a mesh that covers their whole town, and it's great dream but not achievable with our current constraints - town-wide meshes are made of stationary nodes - the "mesh" approaches we're discussing burn CPU / battery... - perennially power-starved users will focus on use, not on maintaining the communal mesh up > Imagine a world where Sugar on a Stick machines can communicate on the > same network as an XO laptop We have that now with ad-hoc and infra. Limited but we have it. > A world where mesh capabilities are > hardware agnostic allowing anyone to bring up a mesh network by > booting a live cd. Mesh is pixie dust for most people. Your 'imagine' lines will make the imagine things that cannot be made to work _in the way people imagine_. Some meshy things can be made to work in a lab. Others just involve tradeoffs no sane user would take on... We've had bazillion threads about this, because mesh stokes passion. Problem is... even if you had the magical code right now working seamlessly... the cost/benefit ratio isn't good. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Aug 24, 2010, at 7:11 PM, Reuben K. Caron wrote:
>
> On Aug 24, 2010, at 11:24 AM, Richard A. Smith wrote:
>
>> The largest of our mesh problems did not have to do with scalability on
>> sheer number of nodes but rather scalability in density. Is there any
>> information available on how these networks perform when there are 50 - 100
>> of them next all in the same room or in adjacent rooms?
>
> Here is a link to a paper that actually tested in a physical 49 node lab with
> various configurations:
>
> http://dev.laptop.org/~reuben/Elsevier2008_OLSR_compare.pdf
>
> This differs from most other papers that I have read that use theoretical
> simulations.
>
Yes, IMHO you *need* the real world simulations (and even then it is very easy
to make measurement mistakes and arrive at arbitrary conclusions [1]). I
started to only trust big real world deployments.
Thanks for the link, still have to read it in detail. BTW: the conclusion
section of this paper already confirms our previous discussion about reducing
txpower: "Currently hop counts up to 5 are achievable with routing protocols in
the full 7x7 grid when the power is set to 0dBm with 30 dB attenuators."
;-)
a.
[1] @ARTICLE{Kurkowski05manetsimulation,
author = {Stuart Kurkowski and Tracy Camp and Michael Colagrosso},
title = {Manet simulation studies: The incredibles},
journal = {ACM SIGMOBILE Mobile Computing and Communications Review},
year = {2005},
volume = {9},
pages = {50--61}
}
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.7902&rep=rep1&type=pdf
PGP.sig
Description: This is a digitally signed message part
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Aug 24, 2010, at 11:24 AM, Richard A. Smith wrote: > The largest of our mesh problems did not have to do with scalability > on sheer number of nodes but rather scalability in density. Is > there any information available on how these networks perform when > there are 50 - 100 of them next all in the same room or in adjacent > rooms? Here is a link to a paper that actually tested in a physical 49 node lab with various configurations: http://dev.laptop.org/~reuben/Elsevier2008_OLSR_compare.pdf This differs from most other papers that I have read that use theoretical simulations. Reuben ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Tuesday, August 24, 2010 11:26:23 am Chris Ball wrote: > Hi Reuben, > >> Consider the benefits of using open source software versus our >> closed source firmware and partnering with communities like >> Freifunk whose network is ~ 800 node, guifi.net is almost 10k >> nodes in Barcelona, Athens Wireless is 5k nodes. > > The fact that a custom mesh algorithm would have to run on the CPU -- > prohibiting any kind of idle-suspend -- makes it a non-starter for an > XO deployment in my eyes. Did you have any thoughts on this? We (MontevideoLibre, a free wireless community network) have been using OLSR for a while now. And though the topology in a typical OLPC scenario is very different, we've talked about assembling an image running OLSRd for a while. Anyway, I dont have time for a full response to this thread right now, but I had a conversation with smithbone and silbe a while back that may be illustrative of the worse-case scenario in terms of power consumption: silbe: I think a working PoC could gather a lot interest from deployments... aa: one thing to consider is the power draw. with libertas_tf, the host CPU needs to be powered on. yes silbe: do you have an idea of what that means in actual numbers? perhaps smithbone has a guesstimate aa: counter-question: are you thinking of running the protocol while the XO is "powered off" (screen off, everything in suspend with wake-on-WLAN) or just during regular operation? for the latter case, it might not make much of a difference, especially if "automatic power management" (automatic suspend) is disabled. Running the system is going to cost you in the 5W range. in the "powered off" case it's going to make a huge difference. I don't think it'll be able to run for more than 3h while there's any traffic. silbe: one of the things I want to find out is the convergence time of the different options aa: i.e. the time until the network/mesh is stable? yes aa: if you were in europe, you might try getting funding from the EU for that ;) silbe: also, BATMAN has a layer 2 kernel module, maybe we could make it aware of the PM state? they seem to pay some pretty sums for mesh research * aa migrates to Europe :P aa: it should just integrate into the kernel PM QoS framework I cuppose, see Documentation/power/pm_qos_interface.txt silbe: will do aa: oh, and some recent mail from me has a link to nice slides explaining the PM QoS framework silbe, smithbone: do you guys know if wol would work with libertas_tf? silbe: to sugar-devel? aa: no idea, sorry. aa: I think to de...@l.l.o silbe: found it, thanks! aa: which gen? smithbone: XO-1 aa: on XO-1 the wakeup is generated by strobing a signal to the EC. So libertas_tf would need to support strobing that signal smithbone: thanks a lot, is this documented somewhere? too bad the firmware is closed :( aa: no. because none of the systems you are talking about have open documentation smithbone: I understand aa: But I can certainly tell someone what gpio on the wlan module to strobe and for how long. -- -Andrés signature.asc Description: This is a digitally signed message part. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
(...) >> >> >> BTW Richard, as far as I remember the problems with 802.11s seemed to be: >> 1) the standard is not a standard and it was intentionally crippled >> 2) the drivers were very b0rked and broken (and Marvel did a terrible job >> with the driver software) >> >> Scalability to less than 30 laptops in one room was the result. >> A standard good AP and standard laptops can go to 30 in one room (with >> standard settings). >> So, there was definitely something broken with the Marvel solution. >> >> Fix layer 2 first, then look at layer 3. > > Yes, Yes, I'm not trying to defend the previous mesh implementation in any > way. Pretend the previous OLPC "mesh" does not exist. And in fact on a XO > 1.5 it does not exist. > OK. Didn't know. > I'm saying that the bulk of our rollouts are dense scenarios connected to an > AP. If we can do better density than an AP with less equipment then thats > something to go for. yes, you can - take the RIPE example: just reduce the txpower and have multiple APs. There are also some very smart APs with a central controlling AP out there (Cisco has some of those). These APs balance out the clients "magically". > If you can't do better than an AP then unless you are doing the > minimal-infra wide area part of mesh there isn't much in it that will help > the bulk of OLPC rollouts. > Well - the issue is IMHO that OLPC always sold the public on the mesh idea. So it is somewhat of a bummer that the mesh is gone now. I might add that the Funkfeuer/Freifunk -style outdoor meshes are still another totally cool option: you can mesh the different schools this way very cheaply. So that is another thing to consider IMHO. >> PS: can you forward my answer to the lists? I am not subscribed... > > Sure but I'm not on iaep so I can't help there. > thx! PGP.sig Description: This is a digitally signed message part ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Aug 24, 2010, at 12:08 PM, Richard A. Smith wrote: > I'm not talking about comparison to our previous mesh. Thanks keeping me on track. > I'm talking about comparison to an AP. Overall we currently don't > have much need for "mesh" as most of our scenarios are a dense cloud > of children in the same space trying to network with each other. Fo deployments that have funding for APs there is not much need for "mesh." I would approximate that roughly 66% of our user base are in deployments that do not have funding for APs. > > The network-without-infra feature of "mesh" is certainly useful in > scenarios were you want to provide access over a wider area. Its a > very important feature of mesh but its just not the feature we need > on the ground ATM. Yet, this is a "feature," we continue to sell and a feature often requested. > However, if the same mesh smartness also gets density without using > AP's then that's a big win. Agreed! Reuben ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
>>> >>> The largest of our mesh problems did not have to do with >>> scalability on sheer number of nodes but rather scalability in >>> density. Is there any information available on how these networks >>> perform when there are 50 - 100 of them next all in the same room >>> or in adjacent rooms? >> >> Yes! And the answer is very very simple: turn down the txpower! >> ;-))) > > Can you provide me with a pointer to the numbers? Whats the maximum number > of nodes can you have operated in a given area and what sort of network > traffic tests did you run? > Well, the community wireless networks are not very much about very dense settings. We try to cover large areas with external (outdoor) antennas but still have very many nodes in one single mesh covering a whole city or so. See the attached current map of the Funkfeuer.at network. BUT!! Because we don't have a mesh with 100s of laptops in one room, does not mean, we don't know physics ;-) Since you asked if I know an example where there are many laptops in one room: One example that I know that worked brilliantly well with many wireless devices in one room was the RIPE meeting in Amsterdam. There they regularly have many small APs below the desks in the meeting room and these are turned down very much in "volume" (txpower). The effect is that they only cover a small area ( remember, power decreases by the square of the distance). So this is a way to avoid a lot of noise of many laptops in a small room. Another feature that you IMHO should look at is 802.11n devices (and of course also turn down the "volume" there!). These offer higher bandwidths in addition to actually using the multipath effects. When you have many many laptops in one room and everybody "screams"/sends very loud then you have lots of "echos" (multipath fading) bouncing off the walls etc. 802.11n thrives off these multipath effects. As I said - first solve layer 1 & 2 issues and then think about layer 3 meshing. I hope I could help. Best regards, L. Aaron Kaplan (OE1SYS) PS: please forward my answers to the list or allow me to post to the list. I am not subscribed there . Thx. PGP.sig Description: This is a digitally signed message part ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Aug 24, 2010, at 5:24 PM, Richard A. Smith wrote: > > On 08/24/2010 10:13 AM, Reuben K. Caron wrote: > > > Consider the benefits of using open source software versus our closed > > source firmware and partnering with communities like Freifunk whose > > network is ~ 800 node, guifi.net is almost 10k nodes in Barcelona, > > Athens Wireless is 5k nodes. > > The largest of our mesh problems did not have to do with scalability on sheer > number of nodes but BTW Richard, as far as I remember the problems with 802.11s seemed to be: 1) the standard is not a standard and it was intentionally crippled 2) the drivers were very b0rked and broken (and Marvel did a terrible job with the driver software) Scalability to less than 30 laptops in one room was the result. A standard good AP and standard laptops can go to 30 in one room (with standard settings). So, there was definitely something broken with the Marvel solution. Fix layer 2 first, then look at layer 3. PS: can you forward my answer to the lists? I am not subscribed... PGP.sig Description: This is a digitally signed message part ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Aug 24, 2010, at 11:24 AM, Richard A. Smith wrote: > On 08/24/2010 10:13 AM, Reuben K. Caron wrote: > > > Consider the benefits of using open source software versus our > closed > > source firmware and partnering with communities like Freifunk whose > > network is ~ 800 node, guifi.net is almost 10k nodes in Barcelona, > > Athens Wireless is 5k nodes. > > The largest of our mesh problems did not have to do with scalability > on sheer number of nodes but rather scalability in density. Is > there any information available on how these networks perform when > there are 50 - 100 of them next all in the same room or in adjacent > rooms? > > In those scenarios we run into RF density issues even when using APs. From what I understand, OLSR has a better mechanism for maintaining the "mesh information." If you recall any change in mesh was previously broadcasted to all listeners. OLSR is configurable. For instance, information would only be broadcasted to two levels of one devices immediate neighbor not the whole mesh cloud. Another issue we had was maintaining mesh information in a limited memory space on the WLAN module; OLSR would now process that information. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Aug 24, 2010, at 5:24 PM, Richard A. Smith wrote: > > On 08/24/2010 10:13 AM, Reuben K. Caron wrote: > > > Consider the benefits of using open source software versus our closed > > source firmware and partnering with communities like Freifunk whose > > network is ~ 800 node, guifi.net is almost 10k nodes in Barcelona, > > Athens Wireless is 5k nodes. > > The largest of our mesh problems did not have to do with scalability on sheer > number of nodes but rather scalability in density. Is there any information > available on how these networks perform when there are 50 - 100 of them next > all in the same room or in adjacent rooms? Yes! And the answer is very very simple: turn down the txpower! ;-))) best regards, Aaron (OE1SYS) PGP.sig Description: This is a digitally signed message part ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
On Aug 24, 2010, at 10:26 AM, Chris Ball wrote: The fact that a custom mesh algorithm would have to run on the CPU -- prohibiting any kind of idle-suspend -- makes it a non-starter for an XO deployment in my eyes. Did you have any thoughts on this? Hi Chris, Great point. Thank you for bringing this up. I have given this some thought; though I'm curious to know if this is your only objection to the suggestion? I find it interesting that what you consider a non- starter, I consider a feature. I have often considered it a bit presumptuous for us to deplete one child's precious power resources to maintain the mesh network for other children. We have created a model where in essence one household is funding access to the Internet in another household through power costs. My thoughts are: we don't do this. If the XO wants to go into idle-suspend let it. The connecting XO will have to find another path or lose access to the Internet. Either way it is a better solution then what we have now. If children group together and knowingly disable idle-suspend so they can maintain a mesh network for their neighbors then that is fine and a great example of building community but doing so as a mandatory implementation IMHO and with all due respect is questionable. Some things I'd like to point out. -8.2.1 has idle-suspend disabled by default and we are considering disabling by default idle-suspend for new XO - 1 builds. In these cases OLSR would be performing fine. -The switch in WLAN chip from XO 1.0 to 1.5 forces us to re-think how we do connectivity. -The thin-firmware being built for XO 1.5 has the same CPU-prohibiting idle-suspend limitation and *does not* include a user base and support community of thousands of users and active development. Yet it relies on one closed source firmware developed by one firm based on the same "mesh" technology developed 3 years ago. It also lacks my hardware agnostic points. -On the XO 1.5 builds where idle-suspend is working (CONGRATULATIONS TEAM), I'd recommend letting it idle-suspend. Yes, it will create route-flapping but in the school scenarios there should be enough paths to maintain connectivity and in the household environment any bit more of connectivity is better then none. It also leaves children and families the ability to knowingly disable-idle suspend and provide a resource to their neighbors. Thank you for your thoughts. Reuben ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] "Mesh" Dreams = OLSR
Hi Reuben, > Consider the benefits of using open source software versus our > closed source firmware and partnering with communities like > Freifunk whose network is ~ 800 node, guifi.net is almost 10k > nodes in Barcelona, Athens Wireless is 5k nodes. The fact that a custom mesh algorithm would have to run on the CPU -- prohibiting any kind of idle-suspend -- makes it a non-starter for an XO deployment in my eyes. Did you have any thoughts on this? - Chris. -- Chris Ball One Laptop Per Child ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
