Cerebro v3.0: File sharing and buddy management made easy!
Want to exchange files between your desktop and your XO laptop? It can't get any easier! In the latest version of Cerebro (currently 3.0.3) you will find simplified file sharing and buddy management. Just click on the buddy you want to send a file to and select a file to send! Screenshots are here: http://cerebro.mit.edu/index.php/Documentation#Example_GUI If you are a developer, there is detailed tutorial to do file sharing from Python prompt (!) here: http://cerebro.mit.edu/index.php/Documentation#Buddy_management Enjoy 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
Cerebro v3.0: File sharing and buddy management made easy!
Want to exchange files between your desktop and your XO laptop? It can't get any easier! In the latest version of Cerebro (currently 3.0.3) you will find simplified file sharing and buddy management. Just click on the buddy you want to send a file to and select a file to send! Screenshots are here: http://cerebro.mit.edu/index.php/Documentation#Example_GUI If you are a developer, there is detailed tutorial to do file sharing from Python prompt (!) here: http://cerebro.mit.edu/index.php/Documentation#Buddy_management Enjoy Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ http://www.mit.edu/%7Eypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
VGA-output on your XO?
http://arstechnica.com/journals/hardware.ars/2008/12/09/acer-releases-b223-displaylink-lcd-in-europe 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: wiki.laptop.org upgrade
Without meaning to undervalue the significance of this thread, it does not seem to pertain anymore to the subject of the devel list whose description is Software development mailing list (http://lists.laptop.org/listinfo/) :-) I refer to devel's description for the sake of completeness, not sarcasm. p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
cerebro's memory usage
I tried cerebro on two XOs running 760 while holding a chat session using Xavier for 24 hours and cerebro's memory usage is steady at 3.3Mb, so I could safely say that there no memory leaks there. Next I will investigate a way so that cerebro coordinates with extreme power management and does not wake up the system in that case. In the mean time, 760 is not using the latest version of cerebro. Is there going to be a newer stable? 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: [sugar] G1G1v2 Activities
then I'd also suggest the Xavier activity, which does: - bidding game - chat - file sharing Xavier uses cerebro directly. Tree: http://dev.laptop.org/git?p=users/ypod/Xavier-activity;a=summary Snapshots: http://lyme.media.mit.edu/cerebro/index.php/Image:Who.png http://lyme.media.mit.edu/cerebro/index.php/Image:What.png http://lyme.media.mit.edu/cerebro/index.php/Image:Bidding2.png (in Gnome) Pol Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Ball wrote: | Hi, | | Please pick up to 10 and put them in order of priority. | | We will tally the votes and use that as input to the decision. | | So, we shipped 19 activities with G1G1v1; that means the ten activities | people vote for here are likely to be a subset of that list, and we | aren't learning much about what new things we should include. People | replying might decide to give 20 suggestions instead of 10, or to omit | original G1G1 activities from their list. | Also, G1G1v1 shipped with the old Sugar interface, which made managing large numbers of installed Activities very difficult. By contrast, the new Sugar UI means that we could easily ship 100 Activities, with only 15 starred by default. Activities' average size on disk varies substantially, but many simpler ones are only about 100 KB, compressed. 100 Activities * 100 KB = 10 MB, or 1% of the disk. Each additional Activity provides more opportunity for exploration, and makes the experience more enjoyable, so I would advocate for shipping as many as possible. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSgM8ACgkQUJT6e6HFtqQ4hACfcRnjtYpakrKRa92hrsI/aIkJ m0QAmwQLe6qLvzYJBNnndfI1Wz6B8tUn =qdS2 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- 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
cerebro documentation
Hello world, The following document provides documentation on Cerebro's design, scalability properties, implementation and potential applications: http://cerebro.mit.edu/cerebro-final.pdf For the impatient, Chapter 3 provides a detailed technical and theoretical analysis of Cerebro's system architecture and design goals. Chapter 4 provides a description of Cerebro's implementation and its various modules. Chapter 5 provides an account of potential applications. This includes documentation on how the Xavier activity can be used for file-sharing, presence information, chat, etc. Chapter 6 evaluates Cerebro's performance by providing experimental results on a testbed with tens of nodes. With scalable regards, 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
analyzing memory usage of python code
Polychronis Ypodimatopoulos wrote: I filed #8128 to address the memory usage that seems excessive. I have also disabled cerebro from start-up while this is being investigated and the issue with blocking shutdown process (#8108). Should be picked up at the next version of joyride. Any suggestions on how to isolate the parts of some python code that take the most memory? It's rather impossible to start commenting out modules because of dependency issues. thx p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cerebro (was Re: Almost 50% less free memory in joyride-2302 compared with Update.1 (708))
I did the following as a basic test for memory usage of various python modules. I did the test on my computer, a 32-bit Centrino laptop running ubuntu. Let's start with the following code: import gobject mainloop = gobject.MainLoop() mainloop.run() Cost: 1.2MB of memory (1.2MB total) Add a dummy class, like the following: import dbus import dbus.service class Dummy(dbus.service.Object): pass Additional cost: 0.9MB of memory (2.1MB total) Importing some more modules, like the following: import time, sys, os, traceback from select import select from socket import * from random import random from struct import pack, unpack from optparse import OptionParser from os.path import basename Additional cost: 1.0MB of memory (3.1MB total) Running the same thing as above as root: Additional cost: 2.8MB of memory (5.9MB total) (WHY?!?!?) Nothing specific to cerebro up to this point. Running Cerebro fully-blown as root: Additional cost: 1.3MB of memory (7.2MB total) It doesn't seem to me that there's much I can do, except for writing some parts of Cerebro in C. 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: Cerebro (was Re: Almost 50% less free memory in joyride-2302 compared with Update.1 (708))
Marco Pesenti Gritti wrote: 6.5 Mib according to ps_mem You are right, it's enabled in joyride... it's failing for me because it can't find msh0 (not sure why). Marco I filed #8128 to address the memory usage that seems excessive. I have also disabled cerebro from start-up while this is being investigated and the issue with blocking shutdown process (#8108). Should be picked up at the next version of joyride. p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
where is msh0 ?
Joyride: 2331 firmware: Q2E14 machine: B4 I don't see mshX in my interfaces. Is this a known issue? Didn't find anything similar in the archives, sorry if I 'm repeating it. 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
joyride version announcements
Why are new versions of Joyride not announced? Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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: Remarks on the Work of Sugar
-level memory protection. Evidence: Sugar packs great functionality into a small number of processes and occupies only one uid. Evidence: Sugar's process-level boundaries (e.g. shell, DS, PS, telepathy CMs, rainbow, activities) seem to me to be strongly correlated with the existence of cliques of the developers who built them. 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X) to IPC techniques with superior human interfaces (HTTP, 9P, environment variables, well-known files, process arguments + status codes + man pages). Regards, Michael P.S. - Let me know if you'd like to see more such remarks in the future (perhaps on other subsystems?) or if you'd like to see more detailed exploration of any of the items noted above. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- 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
permission to add activity to joyride
Hi, I 'm asking for permission to add an activity to Joyride to be used primarily for debugging cerebro. This activity provides these features: - presence (list of users with picture (avatar) and distances) - profiles as shared by each user - file transfer - chat - a bidding game (sell that pencil!) Screenshots from a GTK-based (to be sugarized) version are here: http://lyme.media.mit.edu/cerebro/index.php/Screenshots#GTK-based_UI thanks, 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
koji vs. dropbox
This is probably meant for the release team. Is the dropbox mechanism for updating rpms in joyride still working? According to http://wiki.laptop.org/go/Build_system the dropbox should work but newer RPMs of cerebro don't get pulled into joyride. Rumors have it that this mechanism no longer works and koji must be used instead. Are there newer instructions on the wiki anywhere? Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: koji vs. dropbox
Hi Dennis, Dennis Gilmore wrote: On Monday 07 July 2008, Polychronis Ypodimatopoulos wrote: This is probably meant for the release team. Is the dropbox mechanism for updating rpms in joyride still working? According to http://wiki.laptop.org/go/Build_system the dropbox should work but newer RPMs of cerebro don't get pulled into joyride. Rumors have it that this mechanism no longer works and koji must be used instead. Are there newer instructions on the wiki anywhere? Pol It still works but is strongly discouraged. I would like to see it dropped entirely for the next release. if there not getting picked up it likely means you have not increased the EVR of your package and its not considered the latest. or its in and you just did not realised it because its the same EVR it was not tracked. Thanks for your reply. I am not familiar with the reasons behind this transition, it sounds that you feel strongly against dropbox and I believe that, at a minimum, there should be documentation on the wiki on how to do packaging using koji to make contributors' life a little easier ;-) p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
Sjoerd Simons wrote: I'm setting the ESSID on the msh0 interface indeed. But i never get an association event on it.. While i even get an association event on eth0 when it's not up (but with msh0 being up obviously) :) Seems i've got some more bugs to file Why would you set an ESSID on the mshX interface in the first place? I understand that, from a solid layering perspective, you should be able to set essids on mshX since it's treated as a wireless interface, but it would logically separate network users. It's hard enough as it is to discover nodes in different channels (although different channels do have a radio scaling advantage). 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
wiki spam!
It's becoming very annoying having to deal with spam (bots?) operating on the wiki, trying to blank wiki pages, like in the case of the following: http://wiki.laptop.org/go/Multi-hop_mesh_network_in_MIT_campus Is there a way to prevent that? Why not require user logins to make edits? 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
thread summary: On Cerebro, Telepathy, yokes and whites
This is a summary (a la Michael) of the cerebro/telepathy thread. Pol brought up the issue of how the collaboration stack is currently implemented, that there should be a dead-simple networking API for activity development and proposed someone taking the lead in implementing a connection manager for cerebro (which currently offers a D-Bus API). http://lists.laptop.org/pipermail/devel/2008-June/015238.html Ben suggested that there is no need to abstract telepathy further because it's an abstraction layer in itself. Instead, API changes should be proposed, if any exist. http://lists.laptop.org/pipermail/devel/2008-June/015239.html Ricardo suggested that there should be someone working on a cerebro connection manager in parallel with jabber. http://lists.laptop.org/pipermail/devel/2008-June/015248.html Marco and Tomeu agreed that there should be a cerebro connection manager, Marco conceded to getting cerebro in joyride, but disagreed with adding an abstraction layer between telepathy and sugar/activities on the basis that telepathy is abstraction layer in itself and we must live with what is currently available for lack of resources and because compromises are often made in large software projects. http://lists.laptop.org/pipermail/devel/2008-June/015226.html http://lists.laptop.org/pipermail/devel/2008-June/015254.html Scott brought up the issue of children invariably trying to develop a multi-player game on sugar and failing because of the complexity of the collaboration API. Marco agreed with this problem and recognized the need for a python layer above telepathy/cerebro that can be invoked without DBus, while a lower level DBus-based API will be used by non-python activities. Both Marco and Scott saw the need for extensive tutorials and examples on how to use any networking API for activity development. http://lists.laptop.org/pipermail/devel/2008-June/015255.html Kim would like to figure out how to make progress on cerebro. http://lists.laptop.org/pipermail/devel/2008-June/015261.html Robert characterized telepathy primarily as an API to a variety of functionality and different communication mechanisms, recognized some problems in the implementation and the need for cerebro as one of the plans to deal with those problems. He also went through the history of how D-Tubes and stream tubes came about and noted that the requirements were not really clear when their (D-Tubes and stream tubes) implementation started. He also recognized the need to hide some of the complexities of network programming by adding a simplifying layer on top of telepathy, or by extending the current telepathy API. http://lists.laptop.org/pipermail/devel/2008-June/015262.html http://lists.laptop.org/pipermail/devel/2008-June/015258.html Finally, Morgan went through the history of how the Presence Service was implemented, that it predates the use of telepathy and that it contains some interesting, to put it politely, design aspects. He also went through his efforts to simplify the implementation of collaboration in activities by pushing the telepathy functionality from the activities into the PS where possible and his plans to simplify further collaboration in activities. http://lists.laptop.org/pipermail/devel/2008-June/015274.html Tomeu also suggested getting this summary together (thanks!) and that it may make sense to separate discussion on the API from discussion on the current implementation. I hope I captured the most important parts of this threads, feel free to blame me if I failed in any parts. 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
On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
Tomeu and Marco, For the history, both me and another student from MIT tried to implement a connection manager back in January but gave up after a couple of weeks, even with significant help from Daf. We don't claim to be expert python programmers, but spending two weeks on something and still not even having understood what needs to be implemented (let alone implementing it) to get a connection manager going, or exactly how telepathy works was quite frustrating. What is more frustrating is that the telepathy API is no secret, but it seems that there is some distance between the API and how the presence service and telepathy really work on the laptop. Like Michael pointed out, there are few people at OLPC who understand and enjoy telepathy. I think this is an understatement. Personally, I think that Collabora was very pressed to get something working on the laptop and the resulting presence stack looks like one hack on top of another. For example, there are tons of abstraction layers, yet activities have visibility (while they shouldn't) on how telepathy works (since telepathy is only a dependency to sugar, this should not be the case). Also, the presence service needs to understand if it should switch from salut to gabble, but the broadcast storm caused by salut won't let XO get an IP address through DHCP, which would mean that there's a school server around and. you get the picture! The current plan to attack scalability problems is implementing gadget from scratch which, if I understand correctly, is a plug-in to jabber which already has many problems of its own. Are we sure we're investing our limited time in the right direction? Personally, I don't think this is entirely Collabora's fault. I also think that if you want to have distinct yoke and white, this is where you should start: Make telepathy dead-simple to understand by reading the code, not the API. I did a funny activity showing XOs and their relative distance (http://www.olpcnews.com/hardware/wireless/xo_space_where_you_are.html) almost a year ago in a couple of afternoons, when there was no hint of Sugar APIs (not even hippocanvas!) because it was dead-simple to inspect other activities' code and how sugar works. Which brings us to cerebro. Since I got stuck with telepathy, I decided to circumvent telepathy altogether, at the very least as a proof of concept for cerebro's functionality. The result is an API (http://wiki.laptop.org/go/Cerebro#Programming_API ) that offers not only presence and data sharing between activities, but is also a /complete collaboration framework/: you can share/join activities, get a list of all currently shared activities and users participating in them, invitations, out-of-band chat, interoperability with Windows, embedded Linux and OpenMoko (collaboration tested on all these platforms) and most importantly, scalability. Now, the nightmare strikes back: I have to go back to implementing a connection manager. Tomeu has a point: How many people you know that understands and enjoys any of mozilla, gtk, pygtk, abiword, X, cairo, etc?. But when did OLPC start doing compromises? And if you have to do a compromise, it's better not to do it at such a critical point like the collaboration in sugar. Here's what I propose: 1) Someone should take the lead at implementing a connection manager and I will actively participate, not just by adapting cerebro's API if necessary, but also with implementing the necessary stubs for the connection manager. But the skeleton must be well understood by the person implementing it! 2) Make provision in both sugar and activities so that there is a clear abstraction from telepathy so that _if_ a better collaboration stack comes along, telepathy won't be hardcoded in sugar. This mainly involves documenting the existing calls from sugar/activities to telepathy (and objects returned thereof) and signals provided by telepathy. 3) Get cerebro into joyride which will help a lot with the upcoming multi-hop tests: humans will be operating and updating their XO that participates in the mesh in MIT campus, so I think it is critical to have cerebro in joyride. Am I wrong? 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: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
Benjamin M. Schwartz wrote: Polychronis Ypodimatopoulos wrote: | 2) Make provision in both sugar and activities so that there is a clear | abstraction from telepathy so that _if_ a better collaboration stack | comes along, telepathy won't be hardcoded in sugar. This mainly | involves documenting the existing calls from sugar/activities to | telepathy (and objects returned thereof) and signals provided by telepathy. Telepathy _is_ that abstraction. It exists specifically so that different underlying collaboration mechanisms can be used interchangeably. For example, Telepathy can run over not only Jabber but also IRC, MSN, AIM, and other protocols. It seems perfectly reasonable to add Cerebro to this list. I thought we were talking about collaboration. MSN, IRC etc are basically chat protocols. Cerebro has little to do with such protocols; its goal is to provide efficient and scalable presence and data sharing in an ad-hoc, mobile environment where even IP addresses are a burden to maintain. I believe such functionality to be central to OLPC and should not be used interchangeably with anything else as long as you have and msh0 interface ;-) p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Networking] TCP is broken in mesh mode
nice report. Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Networking experts, I have been fighting for several months with the fact that invitations often seem not to work, when running on a serverless mesh. The symptoms are quite strange. If an invitation works once between two laptops, it continues to work between them reliably. If it fails once, it continues to fail between them consistently. Sometimes, in the same place, invitations will work on one mesh channel and not on another. The same two XOs may be reliably successful in a particular high-noise environment, and consistently fail in an area of virtual radio silence, as well as the reverse. Even when invitations fail, other presence information continues to flow correctly. Even activity sharing continues to work beautifully. With some help from Daf, we managed to get a tcpdump trace from two XOs exhibiting this behavior at 1CC. The dumps are attached to ticket #6463. ~ What we saw is bizarre, but also consistent with the behavior in the UI. ~ The invitations are unicast, implemented using TCP. When machine A sends an invitation to B, we see the following exchange: 1. A broadcasts an ARP request for B 2. B sees the ARP request and replies to A 3. A receives the ARP reply from B and sends a TCP SYN to B 4. B does not see the SYN packet (it does not appear in B's dump) 5. A retries a total of three times, but none of the SYN packets are seen by B. 3b. In parallel, A broadcasts a presence-info update with mDNS, indicating that it has shared the activity. 4b. B receives this broadcast, updates its presence-info cache, and even assigns B's XO icon a new location in the mesh view This behavior is fairly frightening. I have seen it occur in low-noise network environments with a total of 3 XOs, so I suspect a serious bug somewhere in the lowest levels of the network stack. Once this failure occurs, it is extremely reproducible. All subsequent invitations will continue to fail. I therefore suspect that the bug involves the driver or firmware reaching an invalid state and becoming stuck there. You have to keep in mind that the driver/firmware may very well have bugs, but: 1) the driver does not differentiate between different TCP/IP packets (but may wrongly differentiate between unicast and broadcast/multicast). Try establishing a separate TCP/IP connection when invitations reproducibly don't work. 2) the firmware (in terms of a route existing or not) does not differentiate between frames. Try pinging the other node when invitations reproducibly don't work. Given the variety of critical services that run over TCP, including the much-emphasized Read activity, I hope that people familiar with the driver and firmware will take a look at this bug. - --Ben Schwartz P.S. All this info is present at ticket #6463. I am writing about it here in an attempt to increase awareness. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhOz+oACgkQUJT6e6HFtqSVBQCeKPWmqeoKOzVv55JS/HTAgf1r bUYAoKCG+z1bBA+isc7Mun0VlQNGDars =4w83 -END PGP SIGNATURE- ___ Networking mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/networking -- 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
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: journal object transfer for 8.2
An OLPC intern would have actually taken up this task, but changed direction for the summer. I 'm not sure though how network robustness will improve if some networking (such as file transfer) is done in the Journal. A slightly more radical change may be necessary ;-) p. Walter Bender wrote: I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. -walter On Mon, Jun 9, 2008 at 4:12 PM, Michael Stone [EMAIL PROTECTED] wrote: Tomeu, have heard occasional requests to implement the sending and sharing of journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which polish the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Michael ___ 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 -- 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
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
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
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
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
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
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
Volunteers/help for sugar/cerebro integration
Hi, I'm looking for help/volunteers to assist with the integration process of cerebro [1] into sugar. Cerebro offers a fast and efficient data transport and collaboration mechanism between tens of XOs in simple mesh. Using cerebro we can make the simple mesh scale as well as the current limit using school server WiFi and improve the collaboration experience in many application scenarios. The integration can be done in either of these two ways: 1) Create a new telepathy connection manager that will act as interface between telepathy and cerebro. Some preliminary work already done by Michael Stone [2]. 2) Add the necessary callbacks in cerebro that will allow it to act as presence service to sugar directly [3]. Cerebro provides the necessary functionality, but lacks several dbus callbacks. Questions/comments? [1] http://wiki.laptop.org/go/Cerebro [2] http://dev.laptop.org/git?p=users/mstone/telepathy-cerebro;a=tree;hb=HEAD [3] /usr/lib/python2.5/site-packages/sugar/presence/presenceservice.py Thanks, 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: [sugar] 65-node simple mesh test (and counting... ;-)
John Watlington wrote: One interesting note is that the suggested routing algorithm for 802.11s is a combination of reactive and proactive routing (unlike our current one, which is solely reactive). Perhaps that provides the adaptation necessary for the mesh to work ? If you refer to the hybrid routing protocol, it constructs a spanning tree of the whole mesh network rooted at some node. This is meant to be used in non-homogenous meshes (eg having an MPP or access point that acts as the root). So it may help in a school environment, but not in a simple mesh environment where all nodes are equal (if you attempt to build a different tree rooted at every node, you will probably face the wrath of a proactive protocol running on a mobile network - god save us from such a day ;-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 65-node simple mesh test (and counting... ;-)
Hi Bill, Bill Mccormick wrote: The network manager could be the culprit here, although I thought you had it disabled, how did you disable it? chkconfig --del NetworkManager you'll need to pass the '--add' argument to restore it in rc5. When it's running it looks like it first looks on channel 1 for a DHCP server. Then channel 6. Then channel 11. Then it tries to connect to the last known access point. Then it does it all again. This will take a bit of time... Only then does it assume that there is no DHCP server and switches to ad hoc mode on channel 1. Does it also start looking at different intervals for a DHCP server after switching to ad-hoc mode? Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
65-node simple mesh test (and counting... ;-)
Dear devel, Here are the latest results from Cerebro's (http://cerebro.mit.edu) scaling properties. A 65-node testbed was used (703, Q2D14). The NetworkManager had to be disabled in order to stabilize the behavior of each XO's wireless interface. Unfortunately, the difficulty and time necessary to manage increasingly more nodes is linear (given that the NetoworkManager is disabled ;-), but increases steeply. ** Test plan: Cerebro was started on all 65 laptops almost at the same time. We attempted to emulate the 65 children turn on their laptops in class at the same time scenario. With Yani's help, it took about 5 seconds for both of us to press 'enter' on all laptops. Each XO would discover each other, exchange profile information and keep exchanging presence/discovery information. ** Measurements: Quantitative: According to the protocol, presence (mac address) arrives about other XOs first, then the profile for the newly arrived mac address is queried and finally the profile is cached. We assume that initially each XO has no cached information about other XOs. As a result, every XO will query everyone else. We measured the time it took for each XO to discover and exchange profile information with everyone else, bandwidth usage at all times (during profile exchange and after the network stabilized when all profiles were received everywhere) Qualitative: Collaboration was tested on all 65 nodes: one shared a chat session, everyone else joined. The chat session was based on Cerebro's collaboration model. ** Results: Discovery and profile information: The following graph shows arrival of profile information at each XO from other XOs a function of time. Each bar is a 3-second bucket representing the average number of profile arrivals during this 3-second period. The standard deviation is shown with the blue lines. http://wiki.laptop.org/images/a/af/65-arr-1.png The following graph is the cumulative distribution function. It shows that, on average, each XO has received about 95% of the profiles of the rest of the nodes within just 20 seconds. This performance boost is due to the fact that each XO queried for its profile, responds by broadcasting the profile, instead of unicasting it to the requester. As a result, the other nodes receive the profile too and the next node is queried, yielding a linear cost, instead of a quadratic one. http://wiki.laptop.org/images/7/72/65-cdf-1.png Bandwidth usage: The following wireshark snapshot shows bandwidth usage that peaks momentarily at about 60kbytes/sec. The snapshot is also in accordance with the first graph above, showing that after about 55 seconds the network stabilizes. After the network stabilizes, bandwidth usage drops to 1 packet every 3 seconds (less than 500bytes/sec), as the arrival rate adapts to the density of the network. http://wiki.laptop.org/images/5/51/Bandwidth-presence-info-1.png Chat session: Before the experiment was started, a node shared a chat session and all 64 nodes joined consistently. I sent a few chat messages from a couple of XOs and were received on all other XOs. ** Other notes After about 6.4 hours of continuous operation on all 65 nodes, Cerebro shows stable memory usage (10MB) and consistent CPU usage (83 minutes of CPU usage in 'top'). Comments/suggestions? 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: [sugar] 65-node simple mesh test (and counting... ;-)
Michael Stone wrote: Data Questions: * Are the measurements used to make the display of 'distributions of profile arrival rate vs. time' produced from timestamps of profile arrival as recorded by all the laptops or by some smaller set of 'sentinels'? All XOs got synced clocks (by means of a broadcast packet that sets the time on all machines, providing a clock skew in the neighborhood of a single second). Then, timestamps of profile arrivals were collected from all 65 nodes, each reporting arrivals for the other 64 nodes. * What was the general nature of the connectivity graph of the 65 laptops? Did it change over time? The nodes are lying in the Garden area of 1CC, and they were consistently 1-hop away from all other nodes (full mesh network) all the time. * Did you take any measurements of background network traffic? No, but I should have. However, we can all agree that 1CC is relatively noisy environment. * Do you have any new insight into how the presence of NM (or of software on top of it that depended on it) was killing your interfaces? My understanding is that the NM is trying its best to make ends meet in terms of what the user needs (connect to an AP/XS/mesh ?) and what connection is most reliable (I assume that an AP is considered more reliable than the mesh, but I honestly doubt it!). As a result, the NM may occasionally make the bold move to move from one connection type to another, breaking all existing connections (quoted because there are no TCP-like connections in my experiments), leaving stale information at various points of the software stack (eg. mesh view). At any rate, thanks for this good work! Michael P.S. - When you produce measurements like these, please include links to the raw data. The raw capture is here: http://lyme.media.mit.edu/cerebro/capture-1 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: [sugar] 65-node simple mesh test (and counting... ;-)
Bill Mccormick wrote: Hey Pol, what format is the data in, is this pcap? yes, it's libpcap. Saved from wireshark. I just tested the file and successfully loaded in wireshark ;-) Pol The raw capture is here: http://lyme.media.mit.edu/cerebro/capture-1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [sugar] 65-node simple mesh test (and counting... ;-)
Hi Greg, Greg Smith (gregmsmi) wrote: Thanks for sharing the results. Did you use a wireless AP or active antenna? No access points or active antennas were involved. This is a simple mesh network test. If you can include a few details on that it will help. Can you also include the XO build # and XS build and config if relevant? build 703 Would you say that this test passed? That is, can we recommend that schools use the chat activity with one chat session which all join? Cerebro is software under development and as such it has bugs, but I'm confident that it can easily handle 50-node, simple mesh networks (in terms of presence/profile information) and if activities use Cerebro for their data transport and sharing needs, then there is proof (http://cerebro.mit.edu/images/Comparison1.png) that Cerebro will always beat any TCP-based approach (even if access points/active antennae are used). Like Morgan said, Cerebro is not in build yet but we are examining various integration plans. The chat activity mentioned should not be mistaken for the Chat-activity on the XO. The former is an offshoot from the latter that only users Cerebro for collaboration/data exchange. Lastly, can you tell us what kind of testing time and focus you will have in the near future? I believe there is a mesh test lab coming up at Nortel in Ottawa as well. Any feedback on test capacity and plans there is appreciated too. I'm not familiar with the testbed in Ottawa. The plan is to expand the mesh test to 100 nodes and bring down the time it takes for the network to converge even further. Currently it's linear with the number of nodes and I'll experiment with some ideas on how make it completely constant and negligible! Also, I plan to make Cerebro more socially-aware (permanently cache profiles of friends, share bookmarks of friends as a friend recommendation process) and enhance its security (already collaborating with another team of MIT students on this). I ask because there is recent feedback on mesh issues from a teacher at Lambayeque, Peru http://wiki.laptop.org/go/Lambayeque#Inconvenientes and a teacher in Uruguay has asked about supported Mesh features too. The Lambayeque page says: they wish they knew in advance that Acoustic Measure Activity would not work with 6 groups of two students each. That's mostly an issue with activity design and our communication about what activities support but it does raise a good test case (6 groups of 2 sharing a single activity). As you can imagine, 6 groups of 2 kids is a pretty trivial case in terms of networking ;-) given that there is not an overwhelming amount of traffic involved. I 'll try to get in touch with Ben (author of Acoustic activity) to discuss this issue. As always, feedback from teachers and children is extremely welcomed! Unfortunately, I cannot read the 'Lambayeque' wiki page. I think both (Peru and Uruguay) teachers can help define meaningful mesh use cases which will be applicable in many schools. I want to set the right expectation on our capacity before I ask them to spend a lot of time working with us. Would you like to setup a few use cases that I could put to the test and explore our limits? I would like to shift my focus to make Cerebro more activity-friendly and examine alternative use cases. Thanks for the feedback, 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: [sugar] 65-node simple mesh test (and counting... ;-)
Bill Mccormick wrote: Pol, I forgot to ask, do you have a tool that parses the messsages and counts up etc.? Wireshark only parses the 1st mac header. Heh, you 're putting your finger on the wound now! The main reason I did not attempt a wireshark plugin for Cerebro yet is because I was heavily working on many of its protocols, but I think they 've reached a stable point now (I found no reason to change anything for more than a month now). This is definitely on the wish-list right now! Help is greatly appreciated. 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: [sugar] 65-node simple mesh test (and counting... ;-)
Bill Mccormick wrote: It does look like the NM code will select APs over mesh... I bet this plays havoc with IP changing between link local addresses and DHCP addresses. This is partly because of the scalability limitations of the existing collaboration model in a simple mesh. However, I think we can greatly improve situation in a simple mesh scenario and that may simplify the decisions that NM needs to make. Did you expect over half of the packets in your data file to be broadcasts? Specifically 11754 out of 21587 packets were sent to the broadcast address. This is true because all bulk traffic is sent over broadcast _and_ is reliable. Sounds weird? Let me provide a brief explanation. All bulk data traffic (by bulk I refer to traffic that is _potentially_ interesting to all nodes, such as profiles, files etc) is sent to the broadcast address, but the mac address of the node that originally requested the data (or the node to which this data is actually meant for) is added in the actual payload, so only one will be replying with acks to the sender (which are necessary to ensure reliability), but all other nodes will be receiving the data too because it's sent to broadcast. This actually happens anyway on your network interface, so this scheme imposes _no_ additional cost in terms of traffic, other than moving the decision of whether a frame is meant for the current host to a higher layer. This scheme allows sizeable bandwidth savings (http://lyme.media.mit.edu/cerebro/index.php/Experimental_results), especially in dense wireless networks. 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: 65-node simple mesh test (and counting... ;-)
On Fri, May 9, 2008 at 10:57 AM, Marcus Leech [EMAIL PROTECTED] wrote: I'd be *very* interested to compare the distribution on a wired network. It seems to me that given the broadcast model, everybody should see everybody else in much shorter time than the 55 seconds shown in the outlying cluster on that graph. Marcus, this is indeed an interesting idea. However it has a significant problem: wiring up more than 60 XOs onto a switch requires equipment, time and space that OLPC cannot presently provide. Such a testbed though is absolutely necessary not only as a proof of concept for your suggestion, but also for doing large scale mesh network testing in general. The common, but erroneous, assumption is often made that a wireless network is just like a wired network, but with the wires removed. So very true! On a wireless network, broadcasts are successfully received with much lower probability. RF is mysterious and magical, and all sorts of connection asymmetries, near-field effects, and radiation lobe patterns conspire to make it unlikely that *everyone* can hear you equally at once -- and then you get into remote collisions and other mechanisms that make you unaware that not everyone heard you. And there is not 'ack' mechanism for 802.11 broadcast. All these are true also, but I think we're mystifying things a little bit here. The wireless medium is unpredictable mainly because its properties are also a function of time (a non-issue in wired networks), but at least (thank God!) it [the wireless medium] does not discriminate between broadcast and unicast frames! Adding an ack scheme to broadcasts should yield equal (or even better due to lowered speed) reliability using broadcast frames. Even without the ack scheme, I noticed that, on average, some 95% of the data transmitted over broadcast are successfully received on all nodes. We are throwing this away by discarding it on our wireless interfaces. 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: 65-node simple mesh test (and counting... ;-)
Quoting Robert Withrow [EMAIL PROTECTED]: As you may know, but for the others also: Nortel is working to set up a 100 node test network of this nature (each node wired through switches with some test director automation) in a RF clean environment in a Lab in Ottawa and Marcus is one of the folks doing that. We hope it will help produce some useful results for scaling up the mesh networking. We'll keep the group updated as this project proceeds. Robert, this is great. Do you think there is any chance that we will be able to remotely use this testbed also? regards, Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Mesh testing
I 've been doing experiments on a 50-node testbed (703, Q2D14, 22.p9, simple mesh) and getting all 50 of them to communicate consistently has been hard, even in the absence no sharing or heavy workloads involved. Out of the 50 nodes (over a period of time of 6 hours), 8 nodes decided to take msh0 down, half of which did not come up again (NetworkManager?). About 18 out of 50 nodes (not including the previous 8) for some reason stopped being reachable from the rest of the network, although their network interface did not seem to have been reset. Restarting the NetworkManager seems to fix the problem. Is anyone still maintaining the NetworkManager? It seems to me that the NetworkManager chooses to restart msh0 sometimes. Is this true? Does it go so far as to reload the firmware? 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: [sugar] Ad-hoc Networking
Carl-Daniel Hailfinger wrote: Looking at trac, wireless is one of the biggest sources of bugs and the community can hardly do anything about it. Normally, somebody who complains can be told to fix the code, but with a closed wireless firmware, complaining is the only possible action. When you say Looking at trac do you mean you _really_ looked at trac? Well, I had a look at trac and found the following bug reports (includes open+closed). Of course, this is no account of what percentage are still open, or what percentage are blocking and so on, but it may just give us an idea of the situation. What users experience as network from an activity's point of view (let's call this network experience) encompasses all of the following pieces: kernel: 286 bugs* Journal: 232 bugs* wireless (firmware+driver): 189 bugs open firmware: 162 bugs* salut: 71bugs network manager: 69 bugs presence service: about 30 bugs Total bugs relating to network experience: 189+71+69+30=359 *Not necessarily part of the network experience, but was only listed here to provide perspective. So what part of the bugs that affect your network experience are _really_ related to the mesh network? Less than half! Why less? Because half (189) involve both the driver+firmware and the part that you cannot fix is a subset of those. cynicism You also said A 'feature' which is an obstacle without visible benefits to users/developers has no inherent value. Let's try to follow this rule for a moment: the kernel has 286 bug reports and journal has 232. Do you suggest abandoning the kernel and substitute with something else (say windows [just a random thought ;-)]). What about Journal? /cynicism 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: Document sharing issues
Guillaume Desmottes wrote: Le lundi 21 avril 2008 à 10:24 -0500, James Simmons a écrit : 2). Downloading a document is very slow. I distribute View Slides files on an Apache server, using the Browse activity to copy same to the Journal. This takes under a minute even for a large file (over 15mb). Then I share the document with another instance of Sugar on the same box. *That* is agonizingly slow. I know the two instances are not communicating directly, but it still seems like there is a lot of overhead going on. Can I do anything about this? Were you using Gabble or Salut? Currently Gabble stream tubes still send their data through the jabber server making transfer really slow. I'm working on implementing real p2p instead (#4047). Salut doesn't have this problem though as it already uses TCP connections. Can you elaborate more on this? Isn't TCP the underlying mechanism for Gabble also? How is Salut more efficient? p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Walter leaving and shift to XP.
Mitch Bradley wrote: No, I'm saying that giving laptops to all the world's children is a Good Thing, and worthy of being called an education project, even if they don't have the world's friendliest UI or free software. And the reason for that is because the web is so immensely valuable. The laptops are even more wonderful with a child-friendly UI, loads of fun activities, and a non-proprietary software stack. But in the steady state, the web is the high-order bit, sufficient to qualify as education in and of itself. Mitch, I completely disagree with you on this. Browsing the web is useful but doing so without being able to seamlessly communicate with people that are in your proximity is a poor goal to reach. We should be thinking bigger than just giving kids a windows box and ask them to sign up to Facebook so that they can communicate with their friends. 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
Cerebro released
(sorry for cross-postings) The first release of Cerebro is out! Cerebro basically offers scalable presence information and a simple collaboration API. Features currently include: - presence information (including distance and route) for all other users in the network - dynamic rate of updates based on density of neighborhood: No more than 1 update every 5 seconds (on average) guaranteed. - mesh network extended to regular 802.11b/g devices - extensible user profile including nickname, colors, keys, IP addreses, picture of arbitrary size, status message etc - file sharing using an efficient multicast mechanism - simple collaboration mechanism through 'share', 'join', 'leave' functions - simple programming API based on dbus (see examples) http://wiki.laptop.org/go/Cerebro Enjoy! 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: Do we ever want to bind more than 8 multicast MAC addresses?
Is it possible to associate shared activities with ethernet ports instead of whole multicast addresses? Then we would only need one single multicast address and do the filtering on the ethernet ports (eg IP is port 0x0800). At the very least, the multicast address is 6 bytes and the ethernet port is 2 bytes. Pol David Woodhouse wrote: On Fri, 2008-04-18 at 10:58 -0400, Ricardo Carrano wrote: Mmm, if the driver says it is 32 and the firmware only allows for 8, we have a problem, don't we? ;-) Indeed. Do we know which versions of firmware support which numbers of addresses? Remember, this driver handles lots of devices, some with non-mesh firmware. -- 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: Do we ever want to bind more than 8 multicast MAC addresses?
what's possible? why not? David Woodhouse wrote: On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote: Is it possible to associate shared activities with ethernet ports instead of whole multicast addresses? Then we would only need one single multicast address and do the filtering on the ethernet ports (eg IP is port 0x0800). At the very least, the multicast address is 6 bytes and the ethernet port is 2 bytes. That's possible, yes -- although you won't get the device filtering it for you then. -- 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: Do we ever want to bind more than 8 multicast MAC addresses?
David Woodhouse wrote: On Fri, 2008-04-18 at 11:50 -0400, Polychronis Ypodimatopoulos wrote: what's possible? why not? David Woodhouse wrote: On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote: Is it possible to associate shared activities with ethernet ports instead of whole multicast addresses? Then we would only need one single multicast address and do the filtering on the ethernet ports (eg IP is port 0x0800). At the very least, the multicast address is 6 bytes and the ethernet port is 2 bytes. That's possible, yes -- although you won't get the device filtering it for you then. Error. Question upside down. Please don't top-post. It's possible to do as you say -- to use different ports for different activities (although I read 'UDP ports' where you actually said 'ethernet ports' so perhaps I misunderstood). The device firmware doesn't speak IPv6 or Legacy IP, however -- and we wouldn't want it to, even if we trusted it. So it wouldn't filter for only those ports you're interested in; it'll give you all packets for that address. You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on _all_ ethernet frames. IP has nothing to do with this. Instead of looking at the first 6 bytes (destination mac) for a specific multicast address, the filter should be looking at bytes 12-14 for a specific ethernet port. Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
David Woodhouse wrote: On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote: You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on _all_ ethernet frames. IP has nothing to do with this. Instead of looking at the first 6 bytes (destination mac) for a specific multicast address, the filter should be looking at bytes 12-14 for a specific ethernet port. Ah, sorry. I read it as UDP ports. It would be hard to do this -- there's a defined mapping from IPv6 addresses to the multicast MAC addresses used, and high-level applications don't get to muck around with low-level details of the Ethernet frames. Dynamic mapping from a single 6-byte address to multiple 16-byte addresses? I'm curious how this works. I just hope you don't have to change your IPv6 address every now and then ;-) Salut is _no_ high-level application and it should _not_ be associating multicast addresses with activities. Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Devel Digest, Vol 26, Issue 65
Interesting. Does the presence information from each instance ever leave the machine's network card? Pol Tomeu Vizoso wrote: On Mon, Apr 14, 2008 at 8:30 PM, James Simmons [EMAIL PROTECTED] wrote: Morgan, I am one of those people developing activities that make use of collaboration. I'm pleased to see that someone has been charged to make that easier, especially through better documentation. My Activities are Read Etexts and View Slides. Both make use of code adapted from the Read activity, although only Read Etexts has sharing implemented in a released package. It does seem to work. View Slides has sharing code in git, but not released as that code does NOT work at this time. One thing I hope you'll address is the question of setting up a sharing test environment as simply as possible. I have been using Xubuntu with Sugar RPMs on one machine and Sugar-jhbuild on openSUSE 10.2 on another. Both use the Collabora server, and I have a G1G1 laptop pointing to that server as well. The thing is, I don't know if I have Collabora's blessing to use their server for my testing, and even if I did, it is frequently out of service. Ideally I could set up my own server. I do know that just having ejabberd installed from RPMs is not enough. (I tried that and it didn't work). So what is the simplest way for me to have my own sharing environment? You can easily use salut-based collaboration by running several instances of the xephyr-based emulator like this: http://wiki.laptop.org/go/Sugar_with_sugar-jhbuild#Running_multiple_instances Hope it helps, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- 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: networking scenarios
Dafydd Harries wrote: This is something which was not completely clear to me until I talked to Wad about it the other day, and I think other people might find it useful. It should probably go on the wiki (assuming it isn't already there somewhere). I'd like some feedback about where it belongs. The closest thing I've found is this page: http://wiki.laptop.org/go/Scenario_taxonomy Any errors are my own. There are four networking scenarios: - simple mesh - no access point - no school server - we are currently aiming to support up to 15 laptops in this case We are beyond 15 laptops in the simple mesh scenario. I am consistently testing simple mesh with 30 laptops and we are aiming for more than 50. Scaling the simple mesh somewhere between 50 - 100 laptops may have significant impact on the (potential need for) other scenarios. Pol - simple WiFi - access points - which tend not to handle multicast very well (1Mbit/s peak) - no school server - this is what G1G1 laptops will tend to encounter - typically in the developed world - school mesh - no access point - school server with Jabber server - school WiFi - access points - school server with Jabber server - only one server at a time - this is what is deployed in Peru Our current priority in terms of collaboration is to improve supprt for the fourth case, as this is the situation most of our existing laptops are deployed in, and it's likely that upcoming deployments will be similar. Our secondary priority is improving support for the second case, as this is what will tend happen when laptops are taken home from school. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
Having received a lot of publicity, the OLPC project is a great candidate for criticism, sometimes constructive, other times done in the absence of other serious academic research. Potentially weak security models in windows is no news, but in OLPC... Now this is worth taking a shot at! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
The prefix is much longer than the actual information that the name is supposed to provide ;-) p. Walter Bender wrote: True. How about OLPC-Fedora.1, ... -walter On Tue, Apr 8, 2008 at 11:21 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: hmm, Sugar aims to be available as an alternative desktop in all kinds of linux distros, so would be a bad name for an OLPC-made distro. Tomeu On Tue, Apr 8, 2008 at 5:13 PM, Walter Bender [EMAIL PROTECTED] wrote: This discussion reminds me of a favorite puzzle from Douglas Hofstadter 0, 1, 2, 3, 720!, ... That is a numbering scheme with lots of headroom. I agree that OLPC is the wrong name. There are reports that the software is now running, for example, on a Classmate PC. So any direct tie to OLPC is not necessarily appropriate. Maybe Sugar? something else? But there is not much simpler than 1,2,3... -walter On Tue, Apr 8, 2008 at 11:06 AM, Paul Fox [EMAIL PROTECTED] wrote: walter wrote: I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... as perhaps more of an outsider here, i'd say that this is not unambiguous. people with the laptops regularly refer to them as my OLPC -- perhaps encouraged by the unfortunate PC in the acronym. as for numbers: sequential is good, but starting higher than 1 might give room for adding structure later if necessary. (e.g. the 200 series of releases might be a break from the 100 series.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's degrees) ___ 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- 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: DBus - Sessionbus rights
John (J5) Palmieri wrote: Luckily all mail with DBus in the header gets filtered into a single folder ;) Yes spoofing is the answer here (it is sort of like asking why can't users create applications that run from /usr/bin though not quite exact). If we allowed users to grab names on the system bus that aren't marked as allowed to be used by users they could spoof HAL, the datastore or even the bus itself. Since applications running as root also access these services it could be used as an exploit to gain root privileges. This sounds to me like we should not allow the user to run a server on _any_ TCP port, because he may spoof an SSH/POP/DNS server. Instead, the solution was simply to not allow the user to run servers on ports lower than 1000. Even if we fixed this on the XO, my ubuntu distribution has the same security policy, so maybe a bug should be filed against DBus? In any case the session bus is what you want to use to create services other apps (in the session) can use. In my case, user processes need to have a two-way communication with a system process, like having a system process listening on a well-known port and user processes register themselves with the system process, stating on which port they are listening for data. The user processes need not necessarily use a well-known dbus name like 'org.laptop', but I could not publish a method (from a user process) on the system bus from an address like| :0-31.| thx p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
John (J5) Palmieri wrote: I can't think of a reason to want a system process invoking methods on a user process. Well, in my case, the system process is the only one having access to the network and provides network connections and events to all user processes. Sending signals to user processes is a bad choice (although this is what I'm doing right now), because it breaks the privacy between user processes. All is not lost. User processes do not necessarily have to allocate a well known name, as long as it is possible to export a method from a numeric bus address. Is this possible? Example? Thx, Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
DBus - Sessionbus rights
I've been fiddling with DBus quite a bit lately and I don't really understand its default security policy. The SystemBus is used for communication between processes that belong to different users. By default, /etc/dbus-1/system.conf says ...Deny everything then punch holes Why do we forbid the default user (olpc) by default from advertising processes under a well known name? What's wrong with user processes making their presence known on SystemBus? -- 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: [OLPC Networking] RSSI value questions
Ryan, Like Ben said, inducing the physical layout of the network from metrics such as RSSI will give you poor results for various reasons. What Space did was to average arrival rates from direct neighbors over a long period of time (anywhere between 1 and 10 seconds) to avoid highly temporal effects like multipath and noise. Even so, the result is only a rough layout of the network. If you'd like to achieve better accuracy I thing you should combine other ideas like sound measurements, as Ben suggested. Pol Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Crawford Comeaux wrote: | I'm looking to build an application through Google's Summer of Code for the | school server that uses wireless location detection methods to monitor and | approximate the physical location of all nodes within the mesh. | Unfortunately, I can't seem to find any information on whether or not the | network allows the server to poll nodes within the network for RSSI | measurements the nodes have made between themselves and all others within | their range. I was very interested in this problem as well. I was told that it was impossible for two reasons: | Is this something that the networking firmware/drivers even allow? 1. The firmware dynamically varies the transmit and receive gain to minimize power usage and interference, but this information is not available from userspace. 2. Signal intensity is a terribly inaccurate measure of distance, due to the complex interference patterns typical of 2.4GHz waves in buildings. I am no longer so sure that either of these things is true, but neither am I optimistic. I hope someone else on the networking list can provide a better answer. | If not, | is it functionality that could be requested of Marvell to provide? If so, | how accurate are the RSSI measurements and to what decimal precision are | they available? | | Also, what kind of interest within the community is there for this kind of | application, if any? I think the idea at least has interesting uses as far | as securing the network goes, but I'd really like to know what everyone | actively using and/or developing for the systems thinks. There's definitely a great deal of interest. The closest thing so far is Space: http://web.media.mit.edu/~ypod/mesh/ . Instead of the analog distance measure of RSSI, Space uses the binary measure of whether two nodes have a direct connection in the mesh. I am not sure whether Space is still working in recent builds. I have worked on http://wiki.laptop.org/go/Distance , an Activity that uses sound propagation delay to measure distance between two XOs. Distance achieves accuracy on the order of 1 cm, but it is clearly limited by its inability to measure through walls. Also, due to the complicated way in which sound propagates, it is unlikely that Distance will ever be a good tool for measuring the entire position constellation of a group of XOs. If we had control of the wireless firmware, there is perhaps a chance that we could use radio propagation delay for distance measurement. Accuracy would be limited by receive jitter, so the minimum expected error would probably be at least 3 meters. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8szwUJT6e6HFtqQRAge7AJ4i7NOqoxIA4lyiuJ8B30nJMsH4igCggJFE yFGqTzfIsyGUgrx/yATJWn8= =Zsbp -END PGP SIGNATURE- ___ Networking mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/networking -- 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: OLPC security project
Our presence algorithms should be evaluated in terms of security (impersonation, dos, mim, etc). A list of vulnerabilities should be analyzed and solutions should be proposed. More details will follow if interested. p. Jeremy Flores wrote: Hi all, Does anyone know of any security-related projects that need to be worked on for OLPC? I am taking a computer and network security class, and I was thinking that Bitfrost would be an interesting topic for a final project we have. I poked around the wiki, but I couldn't find a security todo list. Thanks! Jeremy Flores [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- 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: Call for Papers/Talks/Ideas! Update.2 Mini-Conference
I sense that this is gonna be a looong thread C. Scott Ananian wrote: On Fri, Mar 21, 2008 at 12:50 PM, Mitch Bradley [EMAIL PROTECTED] wrote: I think that Update.2 should be about 3 things: 3) Performance 2) Performance 1) Performance Mechanisms to achieve those performance goals are worthy candidates for a talk! --scott -- 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
Cerebro performance
cerebro now offers (in command-line!) - chat (just type text in the console) - file transfer (type in console: /sendfile) - view of network tree layout - information about all other nodes in the network (nickname, colors, keys, etc) Performance (remember that this is a mesh test, no servers were used): On a total of 10 XOs, I was able to share a 2MB file from one host with the remaining 9 hosts (a total of 18MB) in 30 secs (a virtual speed of about 4.8Mbits). However, the sender used the broadcast address (ff:ff:ff:ff:ff:ff) at 1Mbit! Because the file was literally broadcasted, most transmissions were successfully received at multiple receivers and the virtual speed [1] got boosted almost 5 times. The virtual speed should actually be 10Mbits (!), so there is plenty of room for improvement. A test with about 50 nodes will be attempted over the weekend. By adding more nodes to the network I expect that overall file transfer performance will actually improve even more. The chat is always available, before, during and after the file transfer. Cerebro is now ready to be fully tested in command-line. Help is still needed to connect with sugar/telepathy! [1] By virtual speed I mean the speed of a TCP-based unicast transmission. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RPM package for cerebro test
http://lyme.media.mit.edu/cerebro/images/Cerebro-24-1.olpc2.noarch.rpm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
status of project hosting?
What is the status of pending project hosting requests? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut and Suspend/Resume issues
If the time between a resume and a suspend is shorter than the time period between consecutive presence updates (which is several minutes), then the presence service should not even know that a suspend happened in between. Then why are icons disappearing? p. Sjoerd Simons wrote: It's avahi that's giving you problems. Or more precisely, it can't cope with the fact that during suspend it's essentially deaf. If we want to make presence on the local lan work in a way to allow the host CPU to sleep most of the time we need both a different presence protocol (some people are already working on this). And we need some assistence from the wireless card to keep track of presence while the host cpu is asleep.. But i don't see this happening soon. Should we be setting the wireless module to wake on multicast, so that we can respond to whatever traffic the presence service is using to see who's online? Yes please do. And if possible only to the multicast traffic the host is actually interested in. I'm pretty sure i mentioned this before, if you don't wake up on multicast traffic your completely breaking the way mdns works. And thus the notions of presence in a link-local network. Also if you don't wake up on multicast then activities in a local lan will break as they won't receive data and other metainformation from other participants. Should it be using unicast traffic instead? No What is it in Avahi's code path that causes its peer list to be emptied on resume? Given that it's long suspends that have this problem. It's probably the fact that the TTL for all contacts has run out, that is causing avahi to flush the peer list. After which it needs to rediscover all of them. Which is a valid thing to do, if you've been away for quite some time you have no idea who is still around. Sjoerd -- 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: Salut and Suspend/Resume issues
Gianni, Giannis Galanis wrote: In fact the although the requests are every 10min, the icon will hold for 30min in total until it is deleted. Bug 5501, however, will delete the entry if within the timeframe, a new host arrives. Are you saying that you can have stale icons on screen for as long as 30 minutes? If this is true, then it defeats the purpose of having a presence service in the first place. p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
hosting request: Cerebro
1. Project name : Cerebro
2. Existing website, if any : http://cerebro.mit.edu
3. One-line description : Provide scalable presence information
4. Longer description : Cerebro will be a plugin to the Presence Service.
:
:
:
5. URLs of similar projects :
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full nameSSH2 key URL
E-mail
-
--
#1 ypod Polychronis Ypodimatopoulos
http://wiki.laptop.org/go/User:Ypod [EMAIL PROTECTED]
#2 renedsRene De Santiago
[EMAIL PROTECTED]
#3
...
If any developers don't have their SSH2 keys on the web, please attach them
to the application e-mail.
7. Preferred development model
[X] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be familiar to
CVS and Subversion users, and that tends to work well for most projects.
[ ] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at one
or more of these trees, and merge changes into the maintainer-owned,
main tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a discussion tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the list
we chose to create above
[ ] A separate mailing list, projectname-git, should be created for commit
notifications
[X] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
11. Translation
[ ] Set up the laptop.org Pootle server to allow translation commits to be
made
[ ] Translation arrangements have already been made at ___
[X] No translations are necessary
12. Notes/comments:
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Salut/avahi/meshview issues
Like Michail and Ricardo said, going from a paper publication to an actual implementation and also _testing_ of that implementation is a very long way. The following factors need to be taken into account when comparing various approaches to routing and presence in MANETs: 1) scalability: I would consider broadcasting a special case of multicasting and as such I assume this is a O(n^2) approach (this means that, on average, there are n packets in the network for each of n nodes) 2) mobility: Requiring our protocol to be able to handle mobile nodes eliminates a good portion of the literature for routing in ad-hoc networks. AODV is the most widely adopted algorithm for routing in MANETs. 3) simplicity: This is more important than it sounds. This is the factor that allows theory to turn into implementation. Multicasting in the mesh network does not scale, but it is relatively simple. My approach to provides presence information for a 100 nodes with a total overhead of 120Kbps at the worst case (everybody in range with each other, like in the school scenario). For 200 nodes, it would have an overhead of up to 240Kbps in the worse case and so on. Time resolution is at 10 seconds/hop, so for 5 hops it will take 50 seconds for a change to propagate from one side to the other. By doubling the time resolution to 20 secs/hop, the overhead gets halved to 60Kbps for 100 nodes, etc. The whole implementation is about 700 lines of python code, so this should provide a hint about its simplicity. I have implemented both the protocol and a simulator that runs multiple instances of the actual implementation, just to showcase its actual scalability. The problem is that running more than 50 nodes on my Centrino 1.8MHz uses up all available processing power and packets start getting dropped. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Let's not forget the dongles that act as dumb repeaters on their own, based on their firmware. Are they gonna use a different firmware instead? p. David Woodhouse wrote: We should change the firmware so that it isn't active automatically as soon as it's loaded -- let the driver activate it when it's appropriate. Then the decision as to whether the radio is blocked can properly be handled in userspace, and the device can be left quiescent if appropriate. -- 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
Cerebro: Scalable presence information
Announcing Cerebro - http://cerebro.mit.edu Cerebro is a scalable, light-weight protocol that allows 802.11b/g devices to form a mesh network. Cerebro has the following advantages: - It provides presence information about 100 nodes using only a single frame per 10 seconds, per node. - It runs on _any_ 802.11b/g device (tested on XO, Ubuntu, Nokia N800) - It can (but not yet) provide routing information within the mesh network that is formed by regular wifi devices. Demo: http://lyme.media.mit.edu:8000/ The simulation running here shows 50 simulated nodes and a real one (shown in the center of the screen). The nodes within the same group are all in range with each other, but each group is not in range with other groups. As a result, nodes within the same group are placed close together, whereas different groups are placed as far apart as possible. All nodes have information about presence and distance for every other node. There are 50 nodes simulated in 8 groups of 5 nodes and 1 group of 10 nodes. Although the presence algorithm scales quite well, the visualization does not scale as well (yet :-). Therefore, only the first 20 nodes are displayed properly, while the rest are simply put in the list on the right. A sugarized version of the UI will follow soon! Enjoy! 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: is there space for Space for a joyride?
about 100kb. Pol Bernardo Innocenti wrote: Polychronis Ypodimatopoulos wrote: If there is still interest in the Space activity (layout of tree of neighbors according to distance) entering Joyride, do you need an .xo file or an .rpm? How big is the bundle? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
is there space for Space for a joyride?
If there is still interest in the Space activity (layout of tree of neighbors according to distance) entering Joyride, do you need an .xo file or an .rpm? Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Massive mesh view?
Representation of massive numbers of XOs in the network is definitely an interesting problem. It may be a little early to jump into providing solutions, but I dealt with the problem recently while working on my space activity, and space itself can be a scarce resource on screen, especially if you won't the layout of the icons to make some sense. Given a standard amount of space (the screen size), one approach is resize the icons in order to accommodate more icons on screen. But do we just resize all icons equally? I'd say no, because you may want to keep close friends at standard icon size and have everybody else shrink according to the level of interaction you may have with them. So, one size does not fit all. I would even go as far as to propose a Google Earth approach, where you zoom-out above ground and back in to focus on the people you're looking for. Also, providing a temperature map of human clusters may be another approach. I understand that the processing power required in both cases may also be massive and therefore prohibitive, but I just meant to layout some ideas. Pol Yoshiki Ohshima wrote: Thank you, Walter, Ah, yes. I would think that we could emphasize the openness of platform so that letting people setup their own Jabber server would be one way to go, as it is more likely that the buyers of G1G1 will have some other computers. Still an SNS system hooked up with laptops ID might be good. Customizable SNS engines like OpenPNE could be a good starting point to set up something relatively in short time... -- Yoshiki At Sat, 20 Oct 2007 07:33:09 -0400, Walter Bender wrote: Even outside of the context of the G1G1 program, many of your questions are relevant. The current neighborhood view will not scale for a large school. We have a number of enhancements to the view in the works, principally filtering. (As Philip mentioned, the friends view, to which you invite people, is in essence a filtered neighborhood view--there can be many others.) In the context of a school or community deployment, there will be multiple Jabber servers, but we will also want the Jabber servers to talk to each other at some level, so that there are bridges between islands of users. For G1G1, there will be a default Jabber server, but undoubtedly more will pop up. -walter On 10/20/07, Yoshiki Ohshima [EMAIL PROTECTED] wrote: Hello, Recently, I talked with some folks who are trying to do promotion of the give one get one program, and some issues (all are related) came up: - How many users can be shown in the mesh view? - If you limit the number of buddys on the view, how do you limit? - Are we going to have many (jabber) servers for these buyers in the US? - Are we going to have an SNS like community so that (for example) a set of friends can have a place to find each other easily? A senario was that a kid and her niece on the different coasts should be able to find each other. I don't know if there is plan for these (for the G1G1 program), but having an SNS site sounds like a good idea. The parents will feel safer if they know with whom their kids are talking. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ 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: slightly long and detailed proposal for documentation-translation workflow
heh, I totally agree, but this doesn't mean that there isn't a market for a book like that (unfortunately!). Apart from the fact that some people feel disabled without a book, there still is *not* a user-friendly introduction on how to use the laptop (let alone how it works) and I doubt that there will be one anytime soon because OLPC's primary mission is not to sell the XO in the US market. However, I'm afraid that OLPC will have to deal with user support! I hate to say this but there were already a couple of people visiting the lab, asking about where to buy the laptops and whether they're good for their needs. Pol Mitch Bradley wrote: At the current rate of XO software churn, any printed book will be obsolete/inaccurate before the ink is dry. Todd Kelsey wrote: I have been struggling with my literary agent and trying to knock someone over the head with a wet noodle into realizing that there *will* be a market for a book, and trying to suggest going with an e-book, with editorial support from a publisher, put it on amazon, develop the whole thing in a robust authoring cms so updates and multilingual versions can be easily made. one publisher responded with fear, blah blah blah, and I made an attempt to provide rationales (including insights from Wikinomics, which has helped me to be able to articulate some of the value propositions), but I'm 2 degrees away from throwing in the towel, and inviting whoever wants to join me in making a multimodal community book. then maybe when the publishers wake up they could license it and use their distribution channels to put it in stores. I don't know if the publishers realize how cool the little green xo is as a way for people to get acquainted with Linux. Ok I'm throwing in the towel. We could call it the Hitchhiker's Guide to the Laptop. I don't care what the title is. The community could name it, write it. If anyone is interested in helping learners who desire a book to get acquainted with the very wonderful work you are doing, please feel free to get in touch. Maybe the proceeds from the book could go towards a series of laptop libraries where the laptops could be checked out by kids. I guess in the same time it took to write this email I could have written a wiki page. On 10/16/07, *Steve Fullerton* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Good points. The OLPC is designed around collaboration. The model really works well where every child in a class has his/her own laptop, uses it in and out of school, and lives in close enough proximity to other class members to make the Mesh work. In class one kid discovers how to do something and teaches the other kids (and teachers as well). In an address at Harvard Law, Negroponte said something like: People ask me who is going to teach the teachers to teach the children how to use the XOs --- and I wonder what planet are they on? ... A child who gets one through G1G1 in isolation will not be able to fully benefit from collaboration and thus, along with parent/tutor, would definately benefit from user documentation in lieu of help from others in class. Likewise, the Carlos Slims approach of putting them in Mexican libraries. If G1G1 goes big-time in November, you can sure bet that there will be OLPC for Dummies books, etc. by Christmas. On 10/15/07, *Todd Kelsey * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I am amazed and inspired by all the wonderful projects and activities that have arisen from the laptop project -- and though I was skeptical at first, I have also come to appreciate the constructivist approach to education; I didn't get it until I came to appreciate the notion of allowing children to come to aha moments on their own. The fact that children do fine without manuals at the present level of interaction is a testament to the design of the computer and the philosophy behind it. As generation xo grows older, I think they will want to get deeper into the systems, and as they do, I think they will want more information, and I'd like to help make that freely available. I think a user manual or documentation will be more helpful for adult learners who will end up participating in the laptop community, and who would find it helpful to have something to refer to. Perhaps users could learn many things simply by exploring, and yet they might appreciate having something to turn to. Other people may not have personal possession of a laptop, but would be interested in learning how they could support the project. Some people who order the laptops through www.xogiving.org http://www.xogiving.org will get frustrated with the laptop if
[Fwd: [msgs] Teach anything you want!]
Not sure if this is relevant, but maybe someone would like to showcase the XO there? I may have an hour or two to spare on that weekend, but no more than that. Please forward freely and let me know. Pol Original Message Subject:[msgs] Teach anything you want! Date: Tue, 16 Oct 2007 19:10:52 -0400 (EDT) From: Catherine Havasi [EMAIL PROTECTED] To: [EMAIL PROTECTED] I know a lot of people in the lab teach for Splash - which is a one weekend program where you can teach a class on anything you want to high school and middle school students in the Boston area. It's a very low time commitment opportunity and is a lot of fun. Email me with questions. - Catherine --- Are you interested in things? Then inflict your interests on high school students by teaching Splash 2007! Splash is a weekend-long program on November 17-18 where you can teach ANYTHING you want to high school students. Quantum mechanics, speaker building, origami, duct tape design, tissue engineering...everything is fair game. Your class can be as large or as small as you want and can last anywhere from 1-5 hours. Just register your class, and you're free to delve into your favorite topics with bright high school students from all over the area. If you're not sure what to teach, come to the ESP office (W20-467) at 6pm on wednesday; we'll have a group brainstorming session. For more information, go to esp.mit.edu, then register your Splash class BY OCTOBER 20th at http://esp.mit.edu/teach/Splash/2007/teacherreg/. See you there! Stephanie Bachar ___ msgs mailing list [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless porting
Hi, What platform do you plan to port the driver to? Pol Alex Gibson wrote: To Jim , Walter, Ivan and others We (UTS) sent a proposal on doing the wireless driver porting to you a fortnight ago and we are still yet to here from you. Can you please confirm that you received it or not. If not what address/es are best to re-send it to. Thank you Alex Gibson Technical Officer Faculty of Engineering University of Technology Sydney ___ 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: [OLPC Networking] Wireless porting
Aaron, Thanks! The irony is that I only did the sugar activity to showcase my algorithm, not to design a new neighborhood interface. Actual face pictures are another add-on I have in mind (we do have a camera available ;-)). Walter Bender also suggested customized XO icons that look bored, happy, sleepy... you get the idea. For the porting part, I would like to have the driver on ARM processor. I think it makes sense for portable devices to be able to communicate with XOs over the mesh. Pol Aaron Kaplan wrote: very interested over here as well... Would it be out of the way to post the original proposal? BTW - on a side note: polychronis: great work with the mesh view! Simon Dorner mentioned that having small faces of the kids in the mesh view would be even better. Humans tend to remember faces much better than Xo signs with different colors. best, aaron. On Oct 13, 2007, at 1:12 AM, Polychronis Ypodimatopoulos wrote: Hi, What platform do you plan to port the driver to? Pol Alex Gibson wrote: To Jim , Walter, Ivan and others We (UTS) sent a proposal on doing the wireless driver porting to you a fortnight ago and we are still yet to here from you. Can you please confirm that you received it or not. If not what address/es are best to re-send it to. Thank you Alex Gibson Technical Officer Faculty of Engineering University of Technology Sydney ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Networking mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/networking --- there's no place like 127.0.0.1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Alternative neighborhood in mesh networks
Announcing Space, an activity that displays an alternative mesh network neighborhood that offers a sense of space by placing you in the center and everyone else in the mesh network at a distance proportional to link quality between you and the node that is being displayed. http://web.media.mit.edu/~ypod/mesh/ Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative neighborhood in mesh networks
Hi Cris, No it does not rely on any subsystems of the firmware or sugar (other than getting the XO's color settings). :-) Pol Chris Ball wrote: Polychronis, Announcing Space, an activity that displays an alternative mesh network neighborhood that offers a sense of space by placing you in the center and everyone else in the mesh network at a distance proportional to link quality between you and the node that is being displayed. http://web.media.mit.edu/~ypod/mesh/ Wow, this looks great. Does it rely on the mesh beacons from each laptop, though? I think we're about to turn those off -- see: https://dev.laptop.org/ticket/2750#comment:4 - Chris. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
mesh driver in ubuntu
I have Ubuntu 7.04 with 2.6.20-16 and want to use the 8388 USB module with my system. I guess I either need to jump to 2.6.22, or compile the driver for 2.6.20. I would prefer the second as the upstream version of the driver does not come with all the features I need. So, do I just get the driver and compile it? Any directions on the wiki? thanks, p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
BIOS prompt at q2c25 + B2?
How do I enter the BIOS prompt on q2c25? It seems I can no longer use ESC tryied other buttons too ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
