cerebro in sugar (was Re: New, more realistic multi-hop network testbed)
On Sat, Jun 7, 2008 at 7:59 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: I thought I covered this scenario quite thoroughly; cerebro enabled about 70 laptops to chat in a simple mesh, even without using an access point or a school server. I got no useful comments, nor was there any significant interest to plan for sugar integration, so I think it's time to move forward with a different test. I still don't understand what's in the path to integrate cerebro into sugar. You proposed to change the API and of course you were asked to justify this. Seems to me like now everybody agrees on coding a cerebro connection manager, which would bring cerebro's benefits without having to change the API. What's the problem? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cerebro in sugar (was Re: New, more realistic multi-hop network testbed)
On Tue, Jun 10, 2008 at 11:02 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 7:59 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: I thought I covered this scenario quite thoroughly; cerebro enabled about 70 laptops to chat in a simple mesh, even without using an access point or a school server. I got no useful comments, nor was there any significant interest to plan for sugar integration, so I think it's time to move forward with a different test. I still don't understand what's in the path to integrate cerebro into sugar. You proposed to change the API and of course you were asked to justify this. Seems to me like now everybody agrees on coding a cerebro connection manager, which would bring cerebro's benefits without having to change the API. What's the problem? Yeah. There is interest to integrate cerebro. It's just very unclear (to me at least) what's the path to get there... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cerebro in sugar (was Re: New, more realistic multi-hop network testbed)
On Tue, Jun 10, 2008 at 11:06:17AM +0200, Marco Pesenti Gritti wrote: On Tue, Jun 10, 2008 at 11:02 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: I still don't understand what's in the path to integrate cerebro into sugar. You proposed to change the API and of course you were asked to justify this. Seems to me like now everybody agrees on coding a cerebro connection manager, which would bring cerebro's benefits without having to change the API. What's the problem? Yeah. There is interest to integrate cerebro. It's just very unclear (to me at least) what's the path to get there... If you want to see what needs to be done to integrate cerebro, then please examine http://dev.laptop.org/git?p=users/mstone/telepathy-cerebro;a=blob;f=tpc/service.py;hb=HEAD When someone fills in those stubs correctly, we will have a Cerebro connection manager. That ought to be enough to drive the mesh view. Then someone will need to implement D-Bus and Stream tubes (not stubbed out here). That will permit activity sharing. The basic hang-up here is that our currently shareable activities are built on Telepathy but there are few OLPC-related people who understand and enjoy the Telepathy stack. Poly, according to his perogative, has decided that building a Cerebro connection manager is not a good use of his time. The Collabora staff most familiar with Telepathy are, at my request, concentrating on Gadget for us for August. Questions? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cerebro in sugar (was Re: New, more realistic multi-hop network testbed)
On Tue, Jun 10, 2008 at 4:16 PM, Michael Stone [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 11:06:17AM +0200, Marco Pesenti Gritti wrote: On Tue, Jun 10, 2008 at 11:02 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: I still don't understand what's in the path to integrate cerebro into sugar. You proposed to change the API and of course you were asked to justify this. Seems to me like now everybody agrees on coding a cerebro connection manager, which would bring cerebro's benefits without having to change the API. What's the problem? Yeah. There is interest to integrate cerebro. It's just very unclear (to me at least) what's the path to get there... If you want to see what needs to be done to integrate cerebro, then please examine http://dev.laptop.org/git?p=users/mstone/telepathy-cerebro;a=blob;f=tpc/service.py;hb=HEAD When someone fills in those stubs correctly, we will have a Cerebro connection manager. That ought to be enough to drive the mesh view. Then someone will need to implement D-Bus and Stream tubes (not stubbed out here). That will permit activity sharing. The basic hang-up here is that our currently shareable activities are built on Telepathy but there are few OLPC-related people who understand and enjoy the Telepathy stack. Poly, according to his perogative, has decided that building a Cerebro connection manager is not a good use of his time. The Collabora staff most familiar with Telepathy are, at my request, concentrating on Gadget for us for August. Thanks for the explanation, Michael. I guess the only part I don't understand is why Poly would consider writing a connection manager not a good use of his time. Telepathy is the API used by both activities and the sugar shell. And unless someone demonstrate that it's inherently broken and provides a better alternative, I don't see it going away. Also as far as I understood Cerebro doesn't provide an API that can be used directly by activities yet (included the non-python ones). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Le dimanche 08 juin 2008 à 12:11 -0400, Michail Bletsas a écrit : b) collabora did some work to abstract out avahi, in theory the groundwork is present for a cerebro backend. That's more like wishful thinking at this point. We need to push more on that end. Latest Salut release has a new Avahi abstraction layer (see #6658). It's still unclear if Cerebro should be integrated as an Salut backend or in its own connection manager though. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Hi Kim, Kim Quirk wrote: Poly - What I can't tell from your progress reports is exactly what is needed for us to get to the next level. On the surface it sounds like you had to rebuild chat to make it work with cerebro. If so, does that mean all activities would have to be modified to a new API? No. I refactored Chat to the Xavier activity (http://dev.laptop.org/git?p=users/ypod/xavier-activity;a=summary) as a proof of concept that collaboration could be solely based on Cerebro. What else is needed? Create a connection manager for Cerebro. This would also be a great chance for OLPC to become more intimate with the internals of telepathy, which is why maybe someone from OLPC should take on this task? I think we should aim to have that implemented and tested by August. Some work has been done on this by Michael Stone already. How does the cerebro solution fit into the rest of the stack and the other technologies we are working on for 8.2.0 (August) and future releases? Cerebro should totally replace salut - the former is a superset, in terms of functionality, of the latter (eg. cerebro additionally offers network layout, distance information, more efficient file transfer etc), while it scales about an order of magnitude better than salut. Furthermore, cerebro would never black-out with broadcast storms, so if there is a jabber server present, it will always be discoverable. If the cerebro solution is still in research and there are a lot of issues that still need to be worked out before we can release it, then we need someone to help track all the issues and help resolve them through the stack in order to get something to release stage. It depends on how you define still in research. If that means not having been used by thousands of children around the world already, then yes it's still in research, but so is most of the XO's software. Realistically speaking, cerebro has been tested more extensively than the rest of the collaboration stack, not only on tens of XOs, but other platforms also. Let's work with Michail on this as he probably needs to take the lead. As a first step, I will order 10 laptops for Poly to find permanent homes for throughout the MIT campus. thank you. Kim p. -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Mon, Jun 09, 2008 at 09:55:20AM +0200, Guillaume Desmottes wrote: Latest Salut release has a new Avahi abstraction layer (see #6658). It's still unclear if Cerebro should be integrated as an Salut backend or in its own connection manager though. What lack of clarity do you observe? From the Collabora work statement: Integrating Cerebro into Telepathy framework We've spoken to Polychronis about how Cerebro works, and attended his presentation last week, and now have a better understanding of the functions provided by Cerebro, and how it could be best integrated into Telepathy framework for use by the presence service, Sugar and activities. We propose to continue work on the “telepathy-cerebro” connection manager which implements the Telepathy API by using the communications provided by Cerebro, so that we can make its functionality available to the existing software on the XOs without modification, and allow observations of the behaviour and reliability of Cerebro in our test environments. http://teach.laptop.org/~mstone/collabora.txt Michael P.S. - For hints, see http://dev.laptop.org/git/users/mstone/telepathy-cerebro ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
would it make sense to at least enter that request into the projectdb since that is what it was made for? (apart from the feature requests which will be taken care of at some time, it does hold the data and hence it can help in tracking the XOs) On a different note: in larger mesh networks (athens wireless comes to mind) you do encounter strange effects when you go to a couple of hundred of nodes. So I would not underestimate the need for a massive test. Massive means maybe 1000 ;-) After all you can reach that number of 1000 kids quite easily. a. On Jun 8, 2008, at 5:55 AM, Kim Quirk wrote: Some thoughts from a QA perspective: I consider the 100 laptops that I budgeted, ordered and help install in Peabody to be the QA collaboration testbed, which is expected to be used to recreate problems from the field and test out next release solutions. Since we had to dismantle Peabody, most of these laptops (about 70 of them) have been loaned to Poly in 1CC. Now that we have both a QA Lead and an intern, I expect we will need to refocus 20-30 laptops back to the QA testbed full time and we have signed a lease on the new test facility, which will be ready for the full 100 laptop test bed (or perhaps 200 laptops) by mid-July. Secondly, we also need to be working on the longer term solutions, such as those being investigated by Poly, Nortel, Michail, and Ricardo. If this also requires a 100 laptop test bed then we need to build one. We need to order these laptops and start making permanent homes for them. If the first step is to order 10 laptops, I will order them. Poly - What I can't tell from your progress reports is exactly what is needed for us to get to the next level. On the surface it sounds like you had to rebuild chat to make it work with cerebro. If so, does that mean all activities would have to be modified to a new API? What else is needed? How does the cerebro solution fit into the rest of the stack and the other technologies we are working on for 8.2.0 (August) and future releases? If the cerebro solution is still in research and there are a lot of issues that still need to be worked out before we can release it, then we need someone to help track all the issues and help resolve them through the stack in order to get something to release stage. Let's work with Michail on this as he probably needs to take the lead. As a first step, I will order 10 laptops for Poly to find permanent homes for throughout the MIT campus. Kim On Sat, Jun 7, 2008 at 12:02 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Honestly, I'm getting very burned out over the politicking here. Ricardo, Polychronis, and the Nortel guys seem to be the ones doing the real heavy lifting here on the mesh network. When they ask for something, I think we should give it to them. Ricardo and Polychronis agree that a sparse network testbed may be useful -- in addition to, not instead of, a dense collaboration testbed -- why can't we just say, yes, do that then. Wad is right, we still need a collaboration testbed, but as Poly points out this is currently Collabora's area of responsibility. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel --- there's no place like 127.0.0.1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
To clarify, there are at least seven different directions to follow here: a) telepathy-based collaboration on 802.11g networks b) telepathy-with-cerebro-backend collaboration on 802.11g networks c) cerebro-based collaboration in 802.11g networks. d) 802.11s meshing in dense networks e) 802.11s meshing in sparse (wide-area) networks f) 802.11s Mesh Portal Point functionality (bridging a school 802.11g network to a neighborhood 802.11s network) g) OLSRd wide-area meshing on an 802.11g sparse (wide-area) network h) plain ol' 802.11g in 100+ node schools Let me try to summarize current status on a few of these: a) what we're currently deploying. believed working for ~20 machines, but there are problem reports from the field. b) collabora did some work to abstract out avahi, in theory the groundwork is present for a cerebro backend. c) Poly has demonstrated this with 70 laptops (limited only by the size of his testbed); would require modification of activities. d) nortel and our old mesh testbed looked at this, but I believe Michalis' current opinion is that we should be using APs in this scenario. So, not important? e) No one looking at this. Poly has proposed a testbed for this. f) yanni is looking at this? No test bed yet. g) demonstrated in vienna, berlin, and athens with 600+, 800+, and ~2000 nodes. Tradeoff: we can't route w/ CPU power turned off; doesn't make progress towards getting 802.11s working for gen2, probably requires further tuning for optimal performance in dense networks. h) Ricardo looking at this? No test bed that I know of. We know that tweaks are required to get any 802.11x standard to work in a dense scenario: media access protocols, probe request/response, beacon tuning, etc. Marvell's done some of this tuning already, but we don't have any local resources validating/verifying behavior. Which should we invest in? Which should we invest in most heavily? Let the politicking commence. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Sun, 8 Jun 2008, C. Scott Ananian wrote: To clarify, there are at least seven different directions to follow here: a) telepathy-based collaboration on 802.11g networks b) telepathy-with-cerebro-backend collaboration on 802.11g networks c) cerebro-based collaboration in 802.11g networks. d) 802.11s meshing in dense networks e) 802.11s meshing in sparse (wide-area) networks f) 802.11s Mesh Portal Point functionality (bridging a school 802.11g network to a neighborhood 802.11s network) g) OLSRd wide-area meshing on an 802.11g sparse (wide-area) network h) plain ol' 802.11g in 100+ node schools one more (which may be considered a varient of d) i) 802.11s meshing in bad RF environments this is where there are a small number of XO machines (so you don't have the 802.11s traffic issues), but where there are a large number of other 802.11 devices in the area a unofficial testbed for this would be to take a half dozen XO machines to a tech conference and try to run them. David Lang Let me try to summarize current status on a few of these: a) what we're currently deploying. believed working for ~20 machines, but there are problem reports from the field. b) collabora did some work to abstract out avahi, in theory the groundwork is present for a cerebro backend. c) Poly has demonstrated this with 70 laptops (limited only by the size of his testbed); would require modification of activities. d) nortel and our old mesh testbed looked at this, but I believe Michalis' current opinion is that we should be using APs in this scenario. So, not important? e) No one looking at this. Poly has proposed a testbed for this. f) yanni is looking at this? No test bed yet. g) demonstrated in vienna, berlin, and athens with 600+, 800+, and ~2000 nodes. Tradeoff: we can't route w/ CPU power turned off; doesn't make progress towards getting 802.11s working for gen2, probably requires further tuning for optimal performance in dense networks. h) Ricardo looking at this? No test bed that I know of. We know that tweaks are required to get any 802.11x standard to work in a dense scenario: media access protocols, probe request/response, beacon tuning, etc. Marvell's done some of this tuning already, but we don't have any local resources validating/verifying behavior. Which should we invest in? Which should we invest in most heavily? Let the politicking commence. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
[EMAIL PROTECTED] wrote on 06/08/2008 11:33:15 AM: To clarify, there are at least seven different directions to follow here: a) telepathy-based collaboration on 802.11g networks b) telepathy-with-cerebro-backend collaboration on 802.11g networks c) cerebro-based collaboration in 802.11g networks. d) 802.11s meshing in dense networks e) 802.11s meshing in sparse (wide-area) networks f) 802.11s Mesh Portal Point functionality (bridging a school 802.11g network to a neighborhood 802.11s network) g) OLSRd wide-area meshing on an 802.11g sparse (wide-area) network h) plain ol' 802.11g in 100+ node schools Let me try to summarize current status on a few of these: a) what we're currently deploying. believed working for ~20 machines, but there are problem reports from the field. The number depends on the traffic paterns of the specific applications. Chat will scale to much higher numbers than write for example. Careful optimization and debugging is the short term action path. APs that support high rate multicasts can also help here. b) collabora did some work to abstract out avahi, in theory the groundwork is present for a cerebro backend. That's more like wishful thinking at this point. We need to push more on that end. c) Poly has demonstrated this with 70 laptops (limited only by the size of his testbed); would require modification of activities. Cerebro will work just fine over a mesh transport also. It uses nearest neighbor broadcast only. We need to settle on a solution for #6211 soon and we need to get some form of Cerebro into Joyride (not-necessarily integrated with Telepathy - just a simple D-BUS/UI integration with some Cerebr-ized apps like chat and file tranfer) d) nortel and our old mesh testbed looked at this, but I believe Michalis' current opinion is that we should be using APs in this scenario. So, not important? The bottom line is that there is no need to use a multi-hop transport with all of its associated overhead, when everybody can talk to everybody else. We could also be using simple ad-hoc mode, however we don't support that from a UI perspective. So, for the moment, we suggest that people use APs. In the long term we should be able to address the intermediate cases (between sparse and dense) via better broadcast support on the mesh (ex: Scalable Broadcast Algorithm, Ad-Hoc Broadacast Protocol) Marvell will be working on this one. It is not clear if we have the necessary memory/cpu resources on the 8388 but it seems a lot more feasible on the 8682. e) No one looking at this. Poly has proposed a testbed for this. I wouldn't call that Wide Area since it involves mobile devices. It's more of a MANET and less of a WMN (Wireless Mesh Network) We have done testing in the past and Polychronis' has been doing it in various forms for a long time now. f) yanni is looking at this? No test bed yet. Ricardo and Yanni (whose last day was Thursday) looked at that, there is the original scheme adapted so that it doesn't take much memory and it awaits integration in the builds and (more importantly on the UI) And given that we have the Active Antenna to think under the same context as well as an Ethernet adapter and that it operates at layer-3, lets stop calling it MPP and call it Internet Sharing from now on. I will submit a functional spec. g) demonstrated in vienna, berlin, and athens with 600+, 800+, and ~2000 nodes. Tradeoff: we can't route w/ CPU power turned off; doesn't make progress towards getting 802.11s working for gen2, probably requires further tuning for optimal performance in dense networks. Again, we are interested in a MANET scenario much more than a WMN. We are doing the work so that code like that can run on the XO (in the form of the thin mac driver). I am sure that given the proper tools present on the XO, people will come up with interesting ways to use them. I don't see us putting a lot of resources in WMN operation though. h) Ricardo looking at this? No test bed that I know of. We know that tweaks are required to get any 802.11x standard to work in a dense scenario: media access protocols, probe request/response, beacon tuning, etc. Marvell's done some of this tuning already, but we don't have any local resources validating/verifying behavior. Why is that different from a) ? Will it be really hard to make spectrum out of thin air ? (OLPC's form of Alchemy I guess ;-). Setting aside the fact that we still leak packets/frames occasionaly in the layer-2 stack, this is more about layer-7 than layer-2 Which should we invest in? Which should we invest in most heavily? Let the politicking commence. And let common sense prevail --scott M___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
[EMAIL PROTECTED] wrote on 06/08/2008 12:00:30 PM: one more (which may be considered a varient of d) i) 802.11s meshing in bad RF environments this is where there are a small number of XO machines (so you don't have the 802.11s traffic issues), but where there are a large number of other 802.11 devices in the area a unofficial testbed for this would be to take a half dozen XO machines to a tech conference and try to run them. What you are describing is nt far away from the wireless environment at 1CC... M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Quoting Michail Bletsas [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote on 06/08/2008 12:00:30 PM: one more (which may be considered a varient of d) i) 802.11s meshing in bad RF environments this is where there are a small number of XO machines (so you don't have the 802.11s traffic issues), but where there are a large number of other 802.11 devices in the area a unofficial testbed for this would be to take a half dozen XO machines to a tech conference and try to run them. What you are describing is nt far away from the wireless environment at 1CC... M. Exactly. RF noise is not the problem in a mesh network, or at least not anymore. The 70-node test at 1CC showed that what is important is _how_ you use the network, not how much noise you have. p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
While we're talking about networking: From discussions with the OLSRd guys, one way they made their protocols work well in dense networks was to aggressively use *all* the 802.11*a* as well as g channels. 802.11a has 24+ non-overlapping channels (in some regulatory environments) which could go a long way towards keeping the number of nodes on any given slice of spectrum below the 40-node 802.11 MAC limits. It appears that our wireless chipset supports 802.11a, although our frontend and antennas are apparently tuned for 802.11b/g. That could be an advantage: in dense scenarios we actually *want* to keep tx power and rx sensitivity low (at the expense of some multihop routes). Michalis, does exploring 802.11a operation in some school environments seem reasonable to you? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Quoting C. Scott Ananian [EMAIL PROTECTED]: While we're talking about networking: From discussions with the OLSRd guys, one way they made their protocols work well in dense networks was to aggressively use *all* the 802.11*a* as well as g channels. 802.11a has 24+ non-overlapping channels (in some regulatory environments) which could go a long way towards keeping the number of nodes on any given slice of spectrum below the 40-node 802.11 MAC limits. It appears that our wireless chipset supports 802.11a, although our frontend and antennas are apparently tuned for 802.11b/g. That could be an advantage: in dense scenarios we actually *want* to keep tx power and rx sensitivity low (at the expense of some multihop routes). Michalis, does exploring 802.11a operation in some school environments seem reasonable to you? --scott Are there going to be 24 different access points too? Don't forget that you will then need to allow users to communicate across different channels, so you will need a bridge at radio level. I thought the point with having three distinct channels (1,6,11) was that it provides some sort of scalability at radio level, while the cost of connecting the three channels was relatively low. p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
[EMAIL PROTECTED] wrote on 06/08/2008 12:25:13 PM: While we're talking about networking: From discussions with the OLSRd guys, one way they made their protocols work well in dense networks was to aggressively use *all* the 802.11*a* as well as g channels. 802.11a has 24+ non-overlapping channels (in some regulatory environments) which could go a long way towards keeping the number of nodes on any given slice of spectrum below the 40-node 802.11 MAC limits. It appears that our wireless chipset supports 802.11a, although our frontend and antennas are apparently tuned for 802.11b/g. That could be an advantage: in dense scenarios we actually *want* to keep tx power and rx sensitivity low (at the expense of some multihop routes). Michalis, does exploring 802.11a operation in some school environments seem reasonable to you? The R.F. power amplifier on our current radio doesn't support 5Ghz. M.___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
C. Scott Ananian wrote: Last I checked, Poly wasn't an employee of OLPC. I don't think this is a valid argument either: Not being an employee of OLPC does not mean I 'm willing to waste my time on something OLPC has no interest in. Like most other volunteers, work at OLPC is interesting because it's technically challenging and globally significant. If the work is not in OLPC's radar of interest, then something's wrong and it should be discussed. Being an employee of OLPC does not mean your technical solution is better than mine either (me being a volunteer). Please don't take this personally or literally. Having such a large pool of volunteers means you may have to assess your software stack more often against what volunteers can offer you. I don't think we can or should make him fix our dense network problems, or run our mesh testbed. Heh, I think I actually offered a solution on the first and volunteered for the second, but was put off until OLPC figures out what how to proceed with the mesh testbed. We should, however, give him all the support he needs (and he's only asking for ~10 laptops) to create the sparse network testbed he's interested in, since we will need that after 8.2, and if it's to be ready then someone needs to start working on it now. The 8.2 release is the one that Peru will be using next year (2009). It is very important that any MPP functionality that is added back to the build be very well tested in the dense school wifi scenario by 8.2 freeze to ensure happy customers. Yes, continued wireless testing is important. We also need to be willing to act on the results of that testing. I must admit that it is rather hard for OLPC to act on such results. It may be for lack of resources, but I'm speaking for myself when I say that OLPC has a hard time trusting developers unless they're on its payroll, especially for core parts of its software (with the exception of Marco? ;-). I think commitment, communication and roadmaps is the answer to this problem. p. -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Sat, Jun 7, 2008 at 2:31 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: C. Scott Ananian wrote: Last I checked, Poly wasn't an employee of OLPC. I don't think this is a valid argument either: Not being an employee of OLPC does not mean I 'm willing to waste my time on something OLPC has no interest in. Like most other volunteers, work at OLPC is interesting because it's technically challenging and globally significant. If the work is not in OLPC's radar of interest, then something's wrong and it should be discussed. I'm glad you said this; I was going to chime in with the same thought. Providing a global sense of significance and priority -- through accurate and complete transmission of feedback, and through review of all ideas being offered or tested -- is one of the most valuable things OLPC can offer its contributors and supporters. SJ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Jun 7, 2008, at 2:31 AM, Polychronis Ypodimatopoulos wrote: C. Scott Ananian wrote: Last I checked, Poly wasn't an employee of OLPC. I don't think this is a valid argument either: Not being an employee of OLPC does not mean I 'm willing to waste my time on something OLPC has no interest in. Like most other volunteers, work at OLPC is interesting because it's technically challenging and globally significant. If the work is not in OLPC's radar of interest, then something's wrong and it should be discussed. And I didn't mean that OLPC isn't interested in making the mesh work. The opposite is the truth.But we HAVE to prioritize the testing being done to the scenarios we are deploying into. Being an employee of OLPC does not mean your technical solution is better than mine either (me being a volunteer). Please don't take this personally or literally. Having such a large pool of volunteers means you may have to assess your software stack more often against what volunteers can offer you. Companies that aren't resource starved frequently fund different approaches. Volunteers can make that possible even in resource starved companies. I don't think we can or should make him fix our dense network problems, or run our mesh testbed. Heh, I think I actually offered a solution on the first and volunteered for the second, but was put off until OLPC figures out what how to proceed with the mesh testbed. What I am saying is that I don't believe a mesh testbed addresses OLPC's customer's immediate needs.A collaboration testbed does. We should, however, give him all the support he needs (and he's only asking for ~10 laptops) to create the sparse network testbed he's interested in, since we will need that after 8.2, and if it's to be ready then someone needs to start working on it now. I read more than ten. Ten laptops aren't worth the time already spent on this thread. I would like to point out that both Marvell and Nortel have mesh testbeds (100 and 50 nodes, respectedly).Our problem has been that no-one has a collaboration testbed. The 8.2 release is the one that Peru will be using next year (2009). It is very important that any MPP functionality that is added back to the build be very well tested in the dense school wifi scenario by 8.2 freeze to ensure happy customers. Yes, continued wireless testing is important. We also need to be willing to act on the results of that testing. I must admit that it is rather hard for OLPC to act on such results. It may be for lack of resources, but I'm speaking for myself when I say that OLPC has a hard time trusting developers unless they're on its payroll, especially for core parts of its software (with the exception of Marco? ;-). I think commitment, communication and roadmaps is the answer to this problem. Lack of resources and QA testing. As Martin put it, we can't take Linus' approach of putting stuff into our build and letting the customer test it.If we put it in our build, it should have been tested, tested, tested. I'm sorry, but I've spent too much time in the last week being told what doesn't work. If the laptops can't communicate well in a school, OLPC fails. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Some thoughts from a QA perspective: I consider the 100 laptops that I budgeted, ordered and help install in Peabody to be the QA collaboration testbed, which is expected to be used to recreate problems from the field and test out next release solutions. Since we had to dismantle Peabody, most of these laptops (about 70 of them) have been loaned to Poly in 1CC. Now that we have both a QA Lead and an intern, I expect we will need to refocus 20-30 laptops back to the QA testbed full time and we have signed a lease on the new test facility, which will be ready for the full 100 laptop test bed (or perhaps 200 laptops) by mid-July. Secondly, we also need to be working on the longer term solutions, such as those being investigated by Poly, Nortel, Michail, and Ricardo. If this also requires a 100 laptop test bed then we need to build one. We need to order these laptops and start making permanent homes for them. If the first step is to order 10 laptops, I will order them. Poly - What I can't tell from your progress reports is exactly what is needed for us to get to the next level. On the surface it sounds like you had to rebuild chat to make it work with cerebro. If so, does that mean all activities would have to be modified to a new API? What else is needed? How does the cerebro solution fit into the rest of the stack and the other technologies we are working on for 8.2.0 (August) and future releases? If the cerebro solution is still in research and there are a lot of issues that still need to be worked out before we can release it, then we need someone to help track all the issues and help resolve them through the stack in order to get something to release stage. Let's work with Michail on this as he probably needs to take the lead. As a first step, I will order 10 laptops for Poly to find permanent homes for throughout the MIT campus. Kim On Sat, Jun 7, 2008 at 12:02 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Honestly, I'm getting very burned out over the politicking here. Ricardo, Polychronis, and the Nortel guys seem to be the ones doing the real heavy lifting here on the mesh network. When they ask for something, I think we should give it to them. Ricardo and Polychronis agree that a sparse network testbed may be useful -- in addition to, not instead of, a dense collaboration testbed -- why can't we just say, yes, do that then. Wad is right, we still need a collaboration testbed, but as Poly points out this is currently Collabora's area of responsibility. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New, more realistic multi-hop network testbed
In the spirit of escalating collaboration/communication use cases to more realistic scenarios, I 'd like to propose creating the following multihop network testbed. This testbed will involve about 70 nodes, but most are already deployed (about 50 nodes already exist at 1CC and 8 at the Media Lab). About 10-12 new XOs are necessary to form the multi-hop network: http://maps.google.com/maps/ms?hl=engl=usptab=2ie=UTF8oe=UTF8msa=0msid=116432384591811010127.00044f046ce8f6f83aae3 This testbed will be used to: 1) stress communication over the mesh network; this can be as large as a 10-hop network spanning from my apartment (Eastgate) to a friend's apartment in Ashdown. 2) Test collaboration using Cerebro on a mixture of devices including XOs, x86 machines (Linux and Windows) and mobile phones. Cerebro runs on each one of those independently (including OpenMoko Freerunner), but this testbed could be used as a backbone network for devices that would otherwise be out of range (such as a mobile phone on one side of campus and a PC on the other). Action items: 1) secure space (especially at Infinite Corridor) to house XOs. 2) setup and automate software updates over the network. 3) last but not least, get about 10-12 XOs from OLPC ;-) Comments/additions are most welcome! Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Jun 6, 2008, at 10:31 PM, Polychronis Ypodimatopoulos wrote: In the spirit of escalating collaboration/communication use cases to more realistic scenarios, I 'd like to propose creating the following multihop network testbed. This testbed will involve about 70 nodes, but most are already deployed (about 50 nodes already exist at 1CC and 8 at the Media Lab). About 10-12 new XOs are necessary to form the multi-hop network: http://maps.google.com/maps/ms? hl=engl=usptab=2ie=UTF8oe=UTF8msa=0msid=116432384591811010127.00 044f046ce8f6f83aae3 Hi Pol! outdoor or indoor? Might be a good outdoor test for XO durability :)) You might need some external directional antennas since there is so much 2.4GHz noise there. a. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Aaron Kaplan wrote: On Jun 6, 2008, at 10:31 PM, Polychronis Ypodimatopoulos wrote: In the spirit of escalating collaboration/communication use cases to more realistic scenarios, I 'd like to propose creating the following multihop network testbed. This testbed will involve about 70 nodes, but most are already deployed (about 50 nodes already exist at 1CC and 8 at the Media Lab). About 10-12 new XOs are necessary to form the multi-hop network: http://maps.google.com/maps/ms?hl=engl=usptab=2ie=UTF8oe=UTF8msa=0msid=116432384591811010127.00044f046ce8f6f83aae3 Hi Pol! outdoor or indoor? Might be a good outdoor test for XO durability :)) You might need some external directional antennas since there is so much 2.4GHz noise there. a. This is mainly an outdoor test with indoor nodes ;-) The idea is be as realistic as possible and try to replicate the actual village environment, only in its worst possible form: Including the high radio noise levels of MIT. We should not enforce connectivity by means of external antennae, but rather experiment with the reachability of the XO as it is, potentially by adding active antennae in between. Having this testbed in place, we can try a mobility test also, eg. having a mobile phone or an XO walk from end to end. p. -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
This is mainly an outdoor test with indoor nodes ;-) The idea is be as realistic as possible and try to replicate the actual village environment, only in its worst possible form: Including the high radio noise levels of MIT. We should not enforce connectivity by means of external antennae, but rather experiment with the reachability of the XO as it is, potentially by adding active antennae in between. Having this testbed in place, we can try a mobility test also, eg. having a mobile phone or an XO walk from end to end. makes sense. But I would not be surprised if you need external antennas for good thruput. Keep us updated :) Which reminds me! You do have a radome on the main building, right? Is there something with 5Ghz (radar) there? a. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Fri, Jun 6, 2008 at 5:31 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: In the spirit of escalating collaboration/communication use cases to more realistic scenarios, I 'd like to propose creating the following multihop network testbed. This testbed will involve about 70 nodes, but most are already deployed (about 50 nodes already exist at 1CC and 8 at the Media Lab). About 10-12 new XOs are necessary to form the multi-hop network: http://maps.google.com/maps/ms?hl=engl=usptab=2ie=UTF8oe=UTF8msa=0msid=116432384591811010127.00044f046ce8f6f83aae3 This testbed will be used to: 1) stress communication over the mesh network; this can be as large as a 10-hop network spanning from my apartment (Eastgate) to a friend's apartment in Ashdown. 2) Test collaboration using Cerebro on a mixture of devices including XOs, x86 machines (Linux and Windows) and mobile phones. Cerebro runs on each one of those independently (including OpenMoko Freerunner), but this testbed could be used as a backbone network for devices that would otherwise be out of range (such as a mobile phone on one side of campus and a PC on the other). Action items: 1) secure space (especially at Infinite Corridor) to house XOs. 2) setup and automate software updates over the network. 3) last but not least, get about 10-12 XOs from OLPC ;-) Comments/additions are most welcome! Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel Pol, This will be something quite useful. We really need to start setting sparse clouds. From what we've experimented back in November, you will want to put active antennas by the window. Unless you're trying to reach the neighbor next door (which is still a valid setup). In the streets around 1cc, particularly at the parking lot near the MediaLab you can decode frames from XOs sitting at 1cc. But nothing that will support any useful communication, I believe. Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Poly, In theory, your suggestion sounds good. In practice, I think it is advanced research winning out over fixing real problems. In the spirit of testing realistic scenarios where we are currently deployed and failing, I would instead strongly urge concentrating on testing 70 laptops in a small space (no larger than 1CC's devel area) with two WiFi access points. This may not help the mesh routing work immediately, but it would help us verify why teachers in Uruguay are complaining about an inability to connect. It would also allow testing of realistic methods of automatically becoming an MPP. As Michail has rightfully pointed out and Uruguay and Peru have been requesting, we need a way of extending the WiFi network in the school out to the village. I don't see us getting far enough along with changes to mesh routing, or replacing parts of salut with cerebro in time for the 8.2 release.But I do believe that Michail can figure out a decent way to gate the MPP functionality by then. The 8.2 release is the one that Peru will be using next year (2009). It is very important that any MPP functionality that is added back to the build be very well tested in the dense school wifi scenario by 8.2 freeze to ensure happy customers. wad On Jun 6, 2008, at 4:31 PM, Polychronis Ypodimatopoulos wrote: In the spirit of escalating collaboration/communication use cases to more realistic scenarios, I 'd like to propose creating the following multihop network testbed. This testbed will involve about 70 nodes, but most are already deployed (about 50 nodes already exist at 1CC and 8 at the Media Lab). About 10-12 new XOs are necessary to form the multi-hop network: http://maps.google.com/maps/ms? hl=engl=usptab=2ie=UTF8oe=UTF8msa=0msid=116432384591811010127.00 044f046ce8f6f83aae3 This testbed will be used to: 1) stress communication over the mesh network; this can be as large as a 10-hop network spanning from my apartment (Eastgate) to a friend's apartment in Ashdown. 2) Test collaboration using Cerebro on a mixture of devices including XOs, x86 machines (Linux and Windows) and mobile phones. Cerebro runs on each one of those independently (including OpenMoko Freerunner), but this testbed could be used as a backbone network for devices that would otherwise be out of range (such as a mobile phone on one side of campus and a PC on the other). Action items: 1) secure space (especially at Infinite Corridor) to house XOs. 2) setup and automate software updates over the network. 3) last but not least, get about 10-12 XOs from OLPC ;-) Comments/additions are most welcome! Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Sat, Jun 7, 2008 at 12:37 AM, John Watlington [EMAIL PROTECTED] wrote: In theory, your suggestion sounds good. In practice, I think it is advanced research winning out over fixing real problems. Last I checked, Poly wasn't an employee of OLPC. I don't think we can or should make him fix our dense network problems, or run our mesh testbed. We should, however, give him all the support he needs (and he's only asking for ~10 laptops) to create the sparse network testbed he's interested in, since we will need that after 8.2, and if it's to be ready then someone needs to start working on it now. The 8.2 release is the one that Peru will be using next year (2009). It is very important that any MPP functionality that is added back to the build be very well tested in the dense school wifi scenario by 8.2 freeze to ensure happy customers. Yes, continued wireless testing is important. We also need to be willing to act on the results of that testing. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Hi Wad, John Watlington wrote: Poly, In theory, your suggestion sounds good. In practice, I think it is advanced research winning out over fixing real problems. Heh as you know, research is usually done based on simulations, not by deploying such cumbersome, large area networks ;-) In the spirit of testing realistic scenarios where we are currently deployed and failing, I would instead strongly urge concentrating on testing 70 laptops in a small space (no larger than 1CC's devel area) with two WiFi access points. I thought I covered this scenario quite thoroughly; cerebro enabled about 70 laptops to chat in a simple mesh, even without using an access point or a school server. I got no useful comments, nor was there any significant interest to plan for sugar integration, so I think it's time to move forward with a different test. This may not help the mesh routing work immediately, but it would help us verify why teachers in Uruguay are complaining about an inability to connect. I was not presented with any specific scenarios from Uruguay to test with cerebro, which I would be very willing to test. Again, I insist on continuing to develop cerebro instead of testing the regular XO's collaboration stack because the performance of the former is at least an order of magnitude better. It would also allow testing of realistic methods of automatically becoming an MPP. As Michail has rightfully pointed out and Uruguay and Peru have been requesting, we need a way of extending the WiFi network in the school out to the village. This is exactly one of the goals of this test - extend the network outside the classroom, into the village. I don't see us getting far enough along with changes to mesh routing, There never was any intent on changing mesh routing. or replacing parts of salut with cerebro in time for the 8.2 release. I believe there is no comparison between salut and cerebro (please correct me if I'm wrong). As for the 8.2 release, I was never asked for an integration plan. We will never make it into any release, unless we start planning. But I do believe that Michail can figure out a decent way to gate the MPP functionality by then. The 8.2 release is the one that Peru will be using next year (2009). It is very important that any MPP functionality that is added back to the build be very well tested in the dense school wifi scenario by 8.2 freeze to ensure happy customers. I don't really see how this relates to the proposed test. MPP is not, currently, the objective. p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
