Re: Collaboration Requirements
Hi Edward, I have not included the case of multiple schools interacting together. This is focused on the first step which covers scale, network config and basic collaboration within a single school. I created a new page called collaboration requirements phase 2 linked from 9.1.0 page: http://wiki.laptop.org/go/9.1.0#Requirement_Definition_Phase_2 Someone can write up a definition or add other ideas there. Thanks, Greg S Edward Cherlin wrote: On Wed, Jul 30, 2008 at 2:21 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, I wrote up some collaboration requirements to help get us to a definition of collaboration support that teachers can use in schools. Thanks. It is not clear to me whether you mean to include the case of children at different schools collaborating, even in different countries. This will be vital for language learning, and important for many other educational and other functions. This is my first somewhat rigorous requirements definition for OLPC so comments on style as well as substance are welcome. I will take one round of comments then I'll find a place for it in the wiki (more comments always welcome after that). Collaboration requirements for OLPC XOs and XS Greg Smith July 30, 2008 Background: The concept of Collaboration has been around for a long time. I have used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby, Sametime, PC Anywhere, Cisco HD Video conferencing and others. Our challenge is different in three respects. - wireless - educational use - greater scale Motivation: The goal of this requirement definition is to provide all the information necessary to define tests and fix critical collaboration bugs in 8.2.0 and to set a goal for 9.1.0. The best case is that this write up motivates test cases which results in a list of detailed examples of collaboration that will be supported in 8.2.0. These examples should be deployable and usable by teachers in class. Examples of use cases generated by teachers are at: http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples Collaboration is an area where we are on the cutting edge of available technology. It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. A list of activities supposedly enabled for collaboration is at: http://wiki.laptop.org/go/Collaboration_Central Documentation on previous wireless tests is at: http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network Requirements Definition: I set a high bar but I try to balance between available technology and the desires of the teachers. I hope can at least test to this standard soon, even if we don't close all bugs found by that testing until later. Requirements beginning with must are critical to success, should are very important but can be deferred and nice to have are very useful but likely to be deferred. If a must requirement cannot be met, we should still attempt to support as much of it as possible (e.g. if we can't do 50 XOs in N9, 40 or 30 should be tested and supported). I - Network Requirements i - Supported Architectures N1 - Must support one of the four network scenarios defined at: http://wiki.laptop.org/go/Networking_scenarios The scenarios in priority order are named as follows. S1 - Simple Wifi S2 - School Wifi S3 - Simple Mesh S4 - School mesh (no need to test, just recorded here for completeness) ii - RF Environments N2 - Must support environments where there are no other RF signals beyond the APs as needed by the network scenario. N3 - Must support RF environments where up to 2 other APs are visible in the XO neighborhood. N4 - Should support environments where there are up to 4 other APs visible in the XO neighborhood. II - Scale i - Scale of XOs collaborating N5 - Must support up to 10 XOs collaborating together. See activity examples for exact steps. N6 - Should support up to 20 XOs collaborating together. N7 - Nice to support up to 30 XOs collaborating together. ii - Scale of XOs visible within range of each other N8 - In N5 above must allow up to 1500 XOs within range in the school. Can require that all other XOs aside from those collaborating have their antennas turned off. N9 - Must allow 50 (should allow 100, nice to have 300) other XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA everyone else is verbally asked to stop using the Internet and stop collaborating) but they can leave their XO radios on in scenario S1 N10 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA no collaboration and no Internet access) in scenario S2. N11 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school
Re: Collaboration Requirements
Hi Martin, OK, I can use RFC style language instead of my must and should definitions if that helps us communicate better. I'm not up to full RFC format but I can try to get as close as needed. I don't see must/should/nice to have defined in this link: ftp://ftp.isi.edu/in-notes/rfc2223.txt Did I miss it or do you have a link the definitions you want to use handy? Thanks, Greg S Martin Langhoff wrote: n Fri, Aug 1, 2008 at 2:16 AM, Greg Smith [EMAIL PROTECTED] wrote: First Michael: This feels very similar to an RFC. GS - Its not meant to be an RFC I think Michael was just suggesting a time-saving device: you defined should, must, etc, and there's a common standard for that kind of verbiage that is used in RFCs. I think it's a good timesaver - all technical ppl around here know about the RFC convention :-) We're actually on the trailing edge of collaboration technology And I think you're *both* exaggerating, and being leading edge doesn't matter that much. We want collab that is useful in education. We are trailing our own expectations, and we'd like to do better. cheers, m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
On Mon, Aug 4, 2008 at 15:43, Greg Smith [EMAIL PROTECTED] wrote: Hi Martin, OK, I can use RFC style language instead of my must and should definitions if that helps us communicate better. I'm not up to full RFC format but I can try to get as close as needed. I don't see must/should/nice to have defined in this link: ftp://ftp.isi.edu/in-notes/rfc2223.txt http://www.faqs.org/rfcs/rfc2119.html Regards Morgan Did I miss it or do you have a link the definitions you want to use handy? Thanks, Greg S Martin Langhoff wrote: n Fri, Aug 1, 2008 at 2:16 AM, Greg Smith [EMAIL PROTECTED] wrote: First Michael: This feels very similar to an RFC. GS - Its not meant to be an RFC I think Michael was just suggesting a time-saving device: you defined should, must, etc, and there's a common standard for that kind of verbiage that is used in RFCs. I think it's a good timesaver - all technical ppl around here know about the RFC convention :-) We're actually on the trailing edge of collaboration technology And I think you're *both* exaggerating, and being leading edge doesn't matter that much. We want collab that is useful in education. We are trailing our own expectations, and we'd like to do better. cheers, m ___ 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: Collaboration Requirements
On Tue, Aug 5, 2008 at 1:35 AM, Greg Smith [EMAIL PROTECTED] wrote: I have not included the case of multiple schools interacting together. This is focused on the first step which covers scale, network config and basic collaboration within a single school. To expand on this -- I had not seen Edward's question earlier -- that will be one of the key areas for post-1.0 School Server. Inter-school wishlist stuff is more appropriately tagged against the School server as that is the collaboration point. We might get some stuff in the 1.0 timeframe, specially if you can help :-), but priority for xs-1.0 is in-school. Got to walk before you run. m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- 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 Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
n Fri, Aug 1, 2008 at 2:16 AM, Greg Smith [EMAIL PROTECTED] wrote: First Michael: This feels very similar to an RFC. GS - Its not meant to be an RFC I think Michael was just suggesting a time-saving device: you defined should, must, etc, and there's a common standard for that kind of verbiage that is used in RFCs. I think it's a good timesaver - all technical ppl around here know about the RFC convention :-) We're actually on the trailing edge of collaboration technology And I think you're *both* exaggerating, and being leading edge doesn't matter that much. We want collab that is useful in education. We are trailing our own expectations, and we'd like to do better. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- 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 Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
On Wed, Jul 30, 2008 at 2:21 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, I wrote up some collaboration requirements to help get us to a definition of collaboration support that teachers can use in schools. Thanks. It is not clear to me whether you mean to include the case of children at different schools collaborating, even in different countries. This will be vital for language learning, and important for many other educational and other functions. This is my first somewhat rigorous requirements definition for OLPC so comments on style as well as substance are welcome. I will take one round of comments then I'll find a place for it in the wiki (more comments always welcome after that). Collaboration requirements for OLPC XOs and XS Greg Smith July 30, 2008 Background: The concept of Collaboration has been around for a long time. I have used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby, Sametime, PC Anywhere, Cisco HD Video conferencing and others. Our challenge is different in three respects. - wireless - educational use - greater scale Motivation: The goal of this requirement definition is to provide all the information necessary to define tests and fix critical collaboration bugs in 8.2.0 and to set a goal for 9.1.0. The best case is that this write up motivates test cases which results in a list of detailed examples of collaboration that will be supported in 8.2.0. These examples should be deployable and usable by teachers in class. Examples of use cases generated by teachers are at: http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples Collaboration is an area where we are on the cutting edge of available technology. It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. A list of activities supposedly enabled for collaboration is at: http://wiki.laptop.org/go/Collaboration_Central Documentation on previous wireless tests is at: http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network Requirements Definition: I set a high bar but I try to balance between available technology and the desires of the teachers. I hope can at least test to this standard soon, even if we don't close all bugs found by that testing until later. Requirements beginning with must are critical to success, should are very important but can be deferred and nice to have are very useful but likely to be deferred. If a must requirement cannot be met, we should still attempt to support as much of it as possible (e.g. if we can't do 50 XOs in N9, 40 or 30 should be tested and supported). I - Network Requirements i - Supported Architectures N1 - Must support one of the four network scenarios defined at: http://wiki.laptop.org/go/Networking_scenarios The scenarios in priority order are named as follows. S1 - Simple Wifi S2 - School Wifi S3 - Simple Mesh S4 - School mesh (no need to test, just recorded here for completeness) ii - RF Environments N2 - Must support environments where there are no other RF signals beyond the APs as needed by the network scenario. N3 - Must support RF environments where up to 2 other APs are visible in the XO neighborhood. N4 - Should support environments where there are up to 4 other APs visible in the XO neighborhood. II - Scale i - Scale of XOs collaborating N5 - Must support up to 10 XOs collaborating together. See activity examples for exact steps. N6 - Should support up to 20 XOs collaborating together. N7 - Nice to support up to 30 XOs collaborating together. ii - Scale of XOs visible within range of each other N8 - In N5 above must allow up to 1500 XOs within range in the school. Can require that all other XOs aside from those collaborating have their antennas turned off. N9 - Must allow 50 (should allow 100, nice to have 300) other XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA everyone else is verbally asked to stop using the Internet and stop collaborating) but they can leave their XO radios on in scenario S1 N10 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA no collaboration and no Internet access) in scenario S2. N11 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are on a given Mesh channel (1,6 or 11) while all the other XOs are on different Mesh channels in scenario S3 III Types of collaboration In all cases, a single XO starts activity, then shares it, then other XOs join the shared activity. N12 - Must support up to 3 XOs using an activity and all others XOs (as allowed by the scale) watching what happens on that screen
Re: Collaboration Requirements
On Thu, Jul 31, 2008 at 03:47:19AM +0100, Gary C Martin wrote: On 31 Jul 2008, at 01:07, Michael Stone wrote: On Wed, Jul 30, 2008 at 05:21:34PM -0400, Greg Smith wrote: It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. Insofar as we make no use of our own collaborative technology as part of our daily learning and teaching, we're not able to use it successfully ourselves. I've often wondered why we (royal we) don't have a scheduled meeting where the communication is specifically attempted using Sugar only available tools (XO HW, emulation or jhbuild on whatever platforms are currently viable). That was suggested at the first gobby meeting. The stated assumption was that the meeting wouldn't be successful with Sugar-only software. --Gary Martin pgp0kZAAVXl6A.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
On Wed, Jul 30, 2008 at 10:32:47PM -0400, Polychronis Ypodimatopoulos wrote: Dear Greg and Michael, It seems to me that we spend more time discussing things, instead of implementing them. ... Even if you pick one randomly you are guaranteed to scale by a whole order of magnitude better than OLPC's current implementation. Does anyone know what person or group of people can make that decision? Pol Martin pgp7QPGblGPy7.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
Hi All, Thanks a lot for all the comments. I tie up a single response and I edit the requirement as needed. Let me know if I don't respond to something you think needs further discussion. I put the updated version in the wiki 9.1.0 Collaboration requirements section: http://wiki.laptop.org/go/9.1.0#Collaboration *** First Michael: This feels very similar to an RFC. GS - Its not meant to be an RFC (AKA a standard that multiple organizations adhere to for better interoperability). Its meant to be an explanation of what the users require to be successful. Hopefully organized in a way that is actionable by developers and QA. should really be citing collaborative systems (both digital and otherwise) from which we take our inspiration and our warnings. GS - Sounds good. I was giving my background but send over any examplars you want people to know about. no opportunity to fix critical collaboration bugs in 8.2.0 proper. GS - OK. Its a requirement for 9.1.0. I hope 8.2.0 supports one or two collaboration examples with all the relevant details down to the activity level. I'm not giving up on that yet. We're actually on the trailing edge of collaboration technology GS - I added your apps to the background section. Maybe we should call ours real time collaboration. Agreed were behind in sharing data. Now tracking that in file management section of 9.1.0. (http://wiki.laptop.org/go/9.1.0#File_Management) but could be renamed or may deserve new section. My tendency is to make it a top priority in 9.1.0. Please define support before using it here. GS - I mean tested and shown to work. Added to wiki version. I'm not sure that your priorities are correct. (re S1 - S4) GS - Quantify your position with # of schools or kids and we can change it. The key point is to support one of them. Then we can tell deployments to build it that way if we have a documented and tested solution. You need to be more precise here. (re: N2 RF environments and other comments on RF.) GS - OK. Give me new wording. Make sure its something users can measure with available tools in the field and QA can test. Cover physical space, traffic on other radios or whatever you think is relevant. Is N10 different from N9 only in that in N9, non-collaborating users have been explicitly asked to avoid intentional network actions? (and N8 - 10 comments) GS - N10 v N9 refer to the same steps by kids but different network architectures (S1 v S2). May not need both. N8 is intentionally easy. Worst case we tell everyone to shut down and then it works for 10 kids. I wanted to throw in one freebie :-) Allowable scale is conditioned on parameters that you are not fixing in your requirements. You need to specify those parameters. GS - Scale is defined in the scale section. Let me know if that is not precise enough or propose new wording. Beware of collaboration scenarios which give access to state that is larger than the capacity of any single XO. (and chat question) GS - Not part of this requirement, maybe next time. Chat refers to the activity we ship now. You're not aiming high enough. GS - When can you support this? Give me a date and I'll consider something more ambitious next. ** On Poly and Martin D's comments re: how to get agreement on a new architecture. GS - I chatted with Michailis about this. He suggested we try to reach a consensus on a design or on specific components (start a wiki page and/or work it out on the list). If this community is in a agreement that will move the ball forward. HTHs. Try again if that doesn't address your questions. * On Gary and Martin D's comments re: eat your own dog food (harsh saying we had at Cisco meaning use your own product) GS - Good idea if it helps us build something useful more quickly. ** On Ricardos comments: Sounds good to me. Looks like you are proposing some design and test strategies. That's great! My only comment is that in the end it has to become a set of instructions that the user can execute. e.g. chat with 10 XOs, in a low noise environment (can be specified precisely) and it will work great! If it doesn't work we say: you have too much noise, check your neighborhood view and if there are any APs there, find them and turn them off. In short it has to be deployable! My third favorite e-mail of the year (after gun-toting bit heads and Alan Kay on the early days) is this one from a teacher trying to use collaboration in a second grade class: http://lists.laptop.org/pipermail/olpc-sur/2008-May/000118.html Todos visualizaban a medida que escribían un cuento y les encantaba, les parecía mágico. Everyone watched while they wrote a story [together] and they loved it, it seemed like magic Then se cerró EL PROGRAMA SORPRESIVAMENTE ,¡QUË DESILUSIÖN due to #7444. Which is why I put in a section about saving files. I want to get
Collaboration Requirements
Hi All, I wrote up some collaboration requirements to help get us to a definition of collaboration support that teachers can use in schools. This is my first somewhat rigorous requirements definition for OLPC so comments on style as well as substance are welcome. I will take one round of comments then I'll find a place for it in the wiki (more comments always welcome after that). Collaboration requirements for OLPC XOs and XS Greg Smith July 30, 2008 Background: The concept of Collaboration has been around for a long time. I have used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby, Sametime, PC Anywhere, Cisco HD Video conferencing and others. Our challenge is different in three respects. - wireless - educational use - greater scale Motivation: The goal of this requirement definition is to provide all the information necessary to define tests and fix critical collaboration bugs in 8.2.0 and to set a goal for 9.1.0. The best case is that this write up motivates test cases which results in a list of detailed examples of collaboration that will be supported in 8.2.0. These examples should be deployable and usable by teachers in class. Examples of use cases generated by teachers are at: http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples Collaboration is an area where we are on the cutting edge of available technology. It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. A list of activities supposedly enabled for collaboration is at: http://wiki.laptop.org/go/Collaboration_Central Documentation on previous wireless tests is at: http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network Requirements Definition: I set a high bar but I try to balance between available technology and the desires of the teachers. I hope can at least test to this standard soon, even if we don't close all bugs found by that testing until later. Requirements beginning with must are critical to success, should are very important but can be deferred and nice to have are very useful but likely to be deferred. If a must requirement cannot be met, we should still attempt to support as much of it as possible (e.g. if we can't do 50 XOs in N9, 40 or 30 should be tested and supported). I - Network Requirements i - Supported Architectures N1 - Must support one of the four network scenarios defined at: http://wiki.laptop.org/go/Networking_scenarios The scenarios in priority order are named as follows. S1 - Simple Wifi S2 - School Wifi S3 - Simple Mesh S4 - School mesh (no need to test, just recorded here for completeness) ii - RF Environments N2 - Must support environments where there are no other RF signals beyond the APs as needed by the network scenario. N3 - Must support RF environments where up to 2 other APs are visible in the XO neighborhood. N4 - Should support environments where there are up to 4 other APs visible in the XO neighborhood. II - Scale i - Scale of XOs collaborating N5 - Must support up to 10 XOs collaborating together. See activity examples for exact steps. N6 - Should support up to 20 XOs collaborating together. N7 - Nice to support up to 30 XOs collaborating together. ii - Scale of XOs visible within range of each other N8 - In N5 above must allow up to 1500 XOs within range in the school. Can require that all other XOs aside from those collaborating have their antennas turned off. N9 - Must allow 50 (should allow 100, nice to have 300) other XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA everyone else is verbally asked to stop using the Internet and stop collaborating) but they can leave their XO radios on in scenario S1 N10 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA no collaboration and no Internet access) in scenario S2. N11 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are on a given Mesh channel (1,6 or 11) while all the other XOs are on different Mesh channels in scenario S3 III Types of collaboration In all cases, a single XO starts activity, then shares it, then other XOs join the shared activity. N12 - Must support up to 3 XOs using an activity and all others XOs (as allowed by the scale) watching what happens on that screen. N14 - Should support 10 XOs (as allowed by scale) using an activity simultaneously. N15 - Nice to have all XOs as allowed by scale using an activity simultaneously. N16 - Must support pairs of two XOs collaborating with each other up to the number of XOs supported by scale. N17 - Should support all the partitions of XOs collaborating with each other (e.g. with 6 XOs, allow 2,2,2 and 3,3
Re: Collaboration Requirements
On Wed, Jul 30, 2008 at 05:21:34PM -0400, Greg Smith wrote: This is my first somewhat rigorous requirements definition for OLPC so comments on style as well as substance are welcome. This feels very similar to an RFC. Take a look at RFC 2223 Instructions to RFC Authors and think about whether you could happily follow its guidance. The concept of Collaboration has been around for a long time. I have used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby, Sametime, PC Anywhere, Cisco HD Video conferencing and others. You cite a number of collaborative systems with which you have personal experience. I think we should really be citing collaborative systems (both digital and otherwise) from which we take our inspiration and our warnings. (I have some favorites, but I'll let you think about the issue first before sharing.) Our challenge is different in three respects. - wireless - educational use - greater scale I agree that it's different but I think you left some important things out like the existence of side-channels provided by physical proximity of the participants. Motivation: The goal of this requirement definition is to provide all the information necessary to define tests and fix critical collaboration bugs in 8.2.0 At this date, unless we decided to slip the release by several weeks, there will be essentially no opportunity to fix critical collaboration bugs in 8.2.0 proper. However, these bugs are certainly of great interest for follow-on bugfix releases made prior to 9.1.0. The best case is that this write up motivates test cases which results in a list of detailed examples of collaboration that will be supported in 8.2.0. These examples should be deployable and usable by teachers in class. Examples of use cases generated by teachers are at: http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples Collaboration is an area where we are on the cutting edge of available technology. We're actually on the trailing edge of collaboration technology and far, far behind on collaborative teaching aids. Email, free web hosting, filesharing networks, Croquet, erights.org, Alice ML, multi-pointer X, Groovy, the distributed source control movement, and the Google Apps suite seem much closer to the leading edge of technology, to name a few. It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. Insofar as we make no use of our own collaborative technology as part of our daily learning and teaching, we're not able to use it successfully ourselves. Documentation on previous wireless tests is at: http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network More relevant documentation is available at http://wiki.laptop.org/go/Collaboration_Network_Testbed Requirements Definition: I set a high bar but I try to balance between available technology and the desires of the teachers. I hope can at least test to this standard soon, even if we don't close all bugs found by that testing until later. Requirements beginning with must are critical to success, should are very important but can be deferred and nice to have are very useful but likely to be deferred. Please consider using RFC 2119's definitions instead. If a must requirement cannot be met, we should still attempt to support as much of it as possible (e.g. if we can't do 50 XOs in N9, 40 or 30 should be tested and supported). I - Network Requirements i - Supported Architectures N1 - Must support one of the four network scenarios defined at: http://wiki.laptop.org/go/Networking_scenarios Please define support before using it here. The scenarios in priority order are named as follows. S1 - Simple Wifi S2 - School Wifi S3 - Simple Mesh S4 - School mesh (no need to test, just recorded here for completeness) I'm not sure that your priorities are correct. My understanding was that I believe that School Wifi is higher-priority (for collaboration; perhaps not for networking) than Simple Wifi. ii - RF Environments Is there an N1 that I missed. N2 - Must support environments where there are no other RF signals beyond the APs as needed by the network scenario. You need to be more precise here. RF signals and visible APs are _wholly_ different measurements. In particular, I believe that I should be able to hook up a spectrum analyzer (or run some software on my XO) and be able to immediately judge whether my environment meets your criteria. Furthermore, understand that APs by themselves consume relatively little bandwidth. It's the _clients_ of those APs (and other sources of noise) which consume the bandwidth that is inherently present in the spectrum. II - Scale i - Scale of XOs collaborating N5 - Must support up to 10 XOs collaborating together. See activity examples for exact steps. Since different collaborative activities consume different amounts of bandwidth, this is not an adequately specified requirement. ii - Scale of XOs visible within
Re: Collaboration Requirements
Dear Greg and Michael, It seems to me that we spend more time discussing things, instead of implementing them. The issue of scalability in large ad-hoc networks has been around for more than a decade and some pretty descent research results have been out there for several years now. Even if you pick one randomly you are guaranteed to scale by a whole order of magnitude better than OLPC's current implementation. Just pick one and implement it. I'm afraid that it is no exaggeration if I say that, from a network engineering standpoing, the current collaboration mechanism is literally the worse one possible, scaling quadratically with the number of nodes no matter if an access point is used or not. I do not mean to sound condescending, but rather note that it is very easy to improve on our current situation. I would rather see us spending our time iterating through implementation of a viable solution, large-scale testing (anyone testing collaboration with _scale_ in mind using 2-3 XOs should just be fired) and thinking about how to build and use feedback mechanisms (that do not involve humans) from actual deployments in schools in the US (where an internet connection is dependable) wrt our collaboration technology. 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: Collaboration Requirements
On 31 Jul 2008, at 01:07, Michael Stone wrote: On Wed, Jul 30, 2008 at 05:21:34PM -0400, Greg Smith wrote: It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. Insofar as we make no use of our own collaborative technology as part of our daily learning and teaching, we're not able to use it successfully ourselves. I've often wondered why we (royal we) don't have a scheduled meeting where the communication is specifically attempted using Sugar only available tools (XO HW, emulation or jhbuild on whatever platforms are currently viable). With the main action being based in Chat, with a shared Write session for meeting minutes; Xo IRC works well for me (most reliable and open form of live collaboration on the XO so far) and could be the fallback when other things implode. It's all about developers being prepared to eat their own... so to speak, and it would send out the right signals about the expected quality and robustness of solutions. I was pretty disappointed to see gobby seemingly adopted (not anything is wrong with gobby), it just clearly shouts, we don't trust our own software to be reliable enough to use for a 1hr meeting. It might actually help making 'itches to scratch'. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
Dear Pol, Greg and Michael, There is so much going on here that it's difficult to approach. I mostly second Michael's comments. Though Greg obviously took a lot of his time to put these goals together, I think we are missing the target. It's good to have goals such as 40 XOs being able to chat on a quiet environment but right now, they seem just too arbitrary. I'm not saying that the requirements are not legitimate, or do not come from legitimate sources (deployments), I'm just saying that we're approaching the scalability problem in an unrealistic way. I'll try to explain why and them I'll propose an alternative approach (i.e. where to put our efforts) Characterization is hard = Spectrum conditions are *very* difficult to characterize. Having a spectrum analyzer will give you some idea of the conditions in a point in space (where the spectrum analyzer is) and in a certain time interval (the consolidation interval) that may be completely irrelevant or misleading. Many times it's like predicting the growth of an specific plant on Alice's garden based on the average annual temperature on the whole country. My point is that 10 nodes may be able to chat until someone opens the door or an elevator stops on the floor. What I mean is that the only quantitative measurement that's of any value is the theoretical maximum limit. What we need to know is how many nodes will be able to chat under ideal (and unreal) conditions and them clarify to all the involved that there is no way to achieve that, ever (with the current implementation, or build). That all we can do is to wait for the elevator to go away, for the microwave oven to be turned off, or for the neighbor to stop downloading an mpeg via his access point. How do we get there is the next topic. Analytical models are necessary Each application has it's own demands and expectations must be set according to these demands. Activities requirements on terms of traffic (ideally bandwidth, delay, jitter, but minimally bandwidth) should be known. This is how you determine if a given link can or cannot support, say, a VoIP conversation. We must be able to model the traffic demands of our collaboration software likewise. What is the traffic generated by a chat between 10 XOs if each participant types one message of 20 bytes at every ten seconds? Once you have that number you should take the transport into consideration. For example, by determining that each of the chat messages will be encoded in a UDP frame of 460 bytes, that will be transmitted at 2Mbps, and will consume 2ms to be transmitted. On top of that you should consider how will this frame flood the mesh, if that's the case, i.e. computing the number of retransmissions. You do that and this will give you a number. You validate this on a testbed that tries to emulate the most favorable environment. If you get anywhere near you analytical model, you're good to go. If not, understand why and try to determine if your model is flawed (monitoring the testbed will tell you) or if your testbed is too way under optimal (some experience required to say so, but basically you try to change the environment and repeat the measures to see if there was improvements). Improvements are mandatory = In parallel you do your improvements in the stack. You try to write more efficient applications, middleware and protocols to achieve the same result. You trim out unnecessary overhead, you compact, you aggregate, you wait before transmitting so maybe you don't need to. There is a lot we already know on that front that we really need to implement (I agree with Pol on that). We can send beacon and probe requests less frequently, we can raise the route expiration time, just to mention two things that do not imply any change in code. But we also need to change code, to substitute one protocol for another, etc. I don't want to start discussing this now. I am just basically trying to say that efforts to improve scalability should happen in parallel to the modeling and analysis and should be a *permanent* effort in the development of the whole stack. In short. We have a limited resource - the shared spectrum. The only effective thing to do are: * design/implement a less spectrum demanding collaboration * build analytical models of this collaboration and try to extract realistic expectations from it. Cheers! Ricardo On Wed, Jul 30, 2008 at 11:32 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Dear Greg and Michael, It seems to me that we spend more time discussing things, instead of implementing them. The issue of scalability in large ad-hoc networks has been around for more than a decade and some pretty descent research results have been out there for several years now. Even if you pick one randomly you are guaranteed to scale by a whole order of magnitude better than OLPC's current implementation. Just pick one and implement it. I'm afraid that it
