[IAEP] Fwd: [escuelab noticias ] OLPC: Una perspectiva europea - Charla de Christoph Derndorfer - Miercoles 25, 7:30pm

[Christoph Derndorfer]

Hi all,

thought some of you might be interested in a talk (OLPC: Una perspectiva
europea) I'm giving here in Lima's escuelab.org tomorrow evening which
will be streamed live via http://www.escuelab.org/envivo

The talk and Q&A will be Spanish and the thing should get started at
around 7:30PM local time (8:30PM EST if I'm not mistaken). Given the
thing called "Peruvian time" it's of course very possible that we'll
only get rolling at around 8PM or so;-)

Cheers,
Christoph

 Original-Nachricht 
Betreff:[escuelab noticias ] OLPC: Una perspectiva europea - Charla de
Christoph Derndorfer - Miercoles 25, 7:30pm
Datum:  Wed, 25 Aug 2010 01:00:17 -0500
Von:escuelab.org 
An: christ...@olpcnews.com



OLPC: Una perspectiva europea - Charla de Christoph Derndorfer -
Miercoles 25, 7:30pm

*también por STREAMING VÍA www.escuelab.org/envivo*

*

*

*"Una laptop por niño"*, es el nombre que recibe el despliegue de One
Laptop per Child (OLPC) en el Perú. El despliegue peruano junto con el
uruguayo, son los dos más grandes a nivel mundial. Paralelamente existe
una comunidad global de OLPC y Sugar, grupos como OLPC Alemanía, OLPC
Austria y OLPC Francia eson muy activos en contribuir a los esfuerzos
globales. n esta charla Christoph presentará proyectos que se están
realizando en Austria. Además revisará el trabajo de OLPC - Nepal donde
la ONG OLE Nepal ha estado trabajando en crear contenido interactivo
para sus escuelas que usan los XO (OLPC) desde el 2007. Al final se hará
un resumen de la gira de investigación que vien realizando Christoph en
torno de los proyectos de OLPC en Uruguay, Paraguay y el Perú.

*El evento está dirigido a: *

Todas las personas que se interesan por el proyecto "Una laptop por
nino" (OLPC) en general, y en el Perú en particular, así como el uso de
tecnologia en el contexto de aprendizaje en las naciones en vías de
desarrollo.

*Fecha: Miércoles 25 de Agosto*

*Hora: 7:30 a 9:00pm*

*Ingreso libre, sin Inscripción
*

*Lugar: Escuelab, Jr de la Unión 1044, Cercado, Lima*

*Sobre el expositor*

Christoph Derndorfer estudia computación en la Universidad Tecnica de
Viena, Austria. Empezó a contribuir a OLPC en 2007, primero
escribiendo artículos para olpcnews.com, donde ahoraocupa el cargo de
co-editor, y luego iniciando OLPC Austria, una ONG basada en Austria que
se dedica a suportar OLPC, Sugar Labs y proyectos en la área de
tecnología abierta y educación. Christoph ha contribuido en varios
proyectos, desde escribir el "Activity Handbook" para ensenar como
programar Activities para el XO, ha dado presentaciones en universidades
Austriacas y en conferencias y encuentros de la comunidad de software
libre en Europa, hasta trabajar como voluntario con el grupo OLE Nepal
en Kathmandu en 2009. Tambien esta coordinando el trabajo en el piloto
OLPC en Austria, uno de los pocos proyectos piloto de OLPC que existe en
Europa. En estos meses de invierno esta pasando por Uruguay, Paraguay y
Peru para aprender más sobre como funcionan los proyectos de OLPC en
estos paises.



___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] Congratulations OLPC-Peru!

[Cherry Withers]

OLPC-Peru is one of the 2010 WISE (World Innovation Summit for Education)
finalists. Information
about this summit and other finalists can be found here:
http://www.wise-qatar.org/en/2010-finalists

Congratulations!
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] Sugar Camp

[Holt]

Walter Bender wrote:
> One topic only touched upon briefly was the need for a Sugar Camp. We
> have two offers of venues: Bolzano the week of November 6 and Miami
> during a time to be determined. If you would be interested in
> attending a Sugar camp sometime in the November/early December time
> frame, please contact me and also, if you have a preference of venue,
> please voice it.
>   

Oct 21/22 - 24 in San Francisco makes the most sense to me, given it 
will be the largest gathering of OLPC/Sugar/Realness implementors ever: 
(well over 30 RSVP'd so far, from 4+ continents, even before broad 
announcement!)
http://olpcsf.org/CommunitySummit2010

Sameer Verma who arranged great hosting with SF State Univ here says we 
can accommodate 100 people.  Mike Lee's been working hard on beautiful 
artistic announcements appearing here shortly, eg:
http://flickr.com/photos/curiouslee

The barcamp-style agenda already shows great Edu, Tech, Depl & Outreach 
tracks, growing fast after we all promote this in coming weeks :)
http://wiki.laptop.org/go/OLPC_SanFranciscoBayArea/OLPCSF_Community_Summit_2010#Possible_Topics

In fact those volunteers who've been working hard putting this together 
have drawn heavily upon prior Sugar/XO/Realness Camps and Book Sprints, eg:
http://wiki.sugarlabs.org/go/Marketing_Team/Events/MiniCamp_Paris_2009 
May 2009
http://wiki.laptop.org/go/ClassActs Sep 2009
http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009 
Nov 2009
http://wiki.laptop.org/go/OLPC_SanFranciscoBayArea/OLPCSF_Community_Summit_2009 
Nov 2009
http://realness.org May/June 2010

The group is considering a very small (perhaps $30) charge to help with 
T Shirts and potentially some partial funding of travel scholarships for 
those from outside North America.  Not yet finalized, but remote access 
will also be strongly encouraged.  Plz join the Very Awesome volunteer 
organizers here if you can!!
http://lists.laptop.org/listinfo/olpc-sf
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] [SLOBS] meeting minutes

[Christoph Derndorfer]

Am 24.08.2010 13:32, schrieb Walter Bender:
> One topic only touched upon briefly was the need for a Sugar Camp. We
> have two offers of venues: Bolzano the week of November 6 and Miami
> during a time to be determined. If you would be interested in
> attending a Sugar camp sometime in the November/early December time
> frame, please contact me and also, if you have a preference of venue,
> please voice it.

I'm definitely up for another Sugar Camp, it's been too long since Sugar
Camp Paris (since I unfortunately missed the last one in Bolzano).

In terms of timing be advised that some of the people who might be
interested in attending Sugar Camp will just come out of the grand
meeting that OLPC-SF is organizing in late October. So that first week
of November might be a bit too close for some of them.

Anyway, I'll keep a close eye on this and hope to be able to make it to
the Camp if indeed takes place in Europe:-)

Cheers,
Christoph

-- 
Christoph Derndorfer
co-editor, www.olpcnews.com
e-mail: christ...@olpcnews.com
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] [SLOBS] meeting minutes

[Walter Bender]

The Sugar oversight board (SLOBs) returned from its northern
hemisphere summer recess  to meet today. We discussed two topics: how
to ensure that we have sufficient numbers and quality of maintainers
for Sugar and the upcoming elections.

Regarding the election, we will be holding it in October (tentatively
from Oct 3 to Oct 16) in order to fill three board positions that have
terms expiring: cjb, seandaly, and canoeberry.

In the run up to the election, we need to:

   1. update our membership list (lfaraone has agreed to do this);
   2. solicit candidates;
   3. prepare the ballot; and
   4. run the election.

If you are not officially a member of Sugar Labs and would like to
vote in the upcoming election, please contact Luke before October 3.
(The current membership list is in the wiki at
http://wiki.sugarlabs.org/go/Sugar_Labs/Members/List).

If you are interested in becoming a candidate, please prepare a
position statement on your "User" page in the wiki and please contact
me so that I can include your name on the ballot.

If you want to help out with the election details or have suggestions
or feedback, please contact me as well.

You can read the discussion details in the log:

http://wiki.sugarlabs.org/go/Oversight_Board/Meeting_Log-2010-08-24

---

One topic only touched upon briefly was the need for a Sugar Camp. We
have two offers of venues: Bolzano the week of November 6 and Miami
during a time to be determined. If you would be interested in
attending a Sugar camp sometime in the November/early December time
frame, please contact me and also, if you have a preference of venue,
please voice it.

---

Our next meeting will be on 7 September 2010 at 15UTC in
#sugar-meeting on irc.freenode.net

Thanks.

-walter
-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[L. Aaron Kaplan]

On Aug 24, 2010, at 7:11 PM, Reuben K. Caron wrote:

> 
> On Aug 24, 2010, at 11:24 AM, Richard A. Smith wrote:
> 
>> The largest of our mesh problems did not have to do with scalability on 
>> sheer number of nodes but rather scalability in density.  Is there any 
>> information available on how these networks perform when there are 50 - 100 
>> of them next all in the same room or in adjacent rooms?
> 
> Here is a link to a paper that actually tested in a physical 49 node lab with 
> various configurations:
> 
> http://dev.laptop.org/~reuben/Elsevier2008_OLSR_compare.pdf
> 
> This differs from most other papers that I have read that use theoretical 
> simulations.
> 

Yes, IMHO you *need* the real world simulations (and even then it is very easy 
to make measurement mistakes and arrive at arbitrary conclusions [1]). I 
started to only trust big real world deployments.

Thanks for the link, still have to read it in detail. BTW: the conclusion 
section of this paper already confirms our previous discussion about reducing 
txpower: "Currently hop counts up to 5 are achievable with routing protocols in 
the full 7x7 grid when the power is set to 0dBm with 30 dB attenuators."

;-)

a.

[1] @ARTICLE{Kurkowski05manetsimulation,
author = {Stuart Kurkowski and Tracy Camp and Michael Colagrosso},
title = {Manet simulation studies: The incredibles},
journal = {ACM SIGMOBILE Mobile Computing and Communications Review},
year = {2005},
volume = {9},
pages = {50--61}
}

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.7902&rep=rep1&type=pdf



PGP.sig
Description: This is a digitally signed message part
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[Reuben K. Caron]

On Aug 24, 2010, at 11:24 AM, Richard A. Smith wrote:

> The largest of our mesh problems did not have to do with scalability  
> on sheer number of nodes but rather scalability in density.  Is  
> there any information available on how these networks perform when  
> there are 50 - 100 of them next all in the same room or in adjacent  
> rooms?

Here is a link to a paper that actually tested in a physical 49 node  
lab with various configurations:

http://dev.laptop.org/~reuben/Elsevier2008_OLSR_compare.pdf

This differs from most other papers that I have read that use  
theoretical simulations.

Reuben

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[Andrés Ambrois]

On Tuesday, August 24, 2010 11:26:23 am Chris Ball wrote:
> Hi Reuben,
> 
>> Consider the benefits of using open source software versus our
>> closed source firmware and partnering with communities like
>> Freifunk whose network is ~ 800 node, guifi.net is almost 10k
>> nodes in Barcelona, Athens Wireless is 5k nodes.
> 
> The fact that a custom mesh algorithm would have to run on the CPU --
> prohibiting any kind of idle-suspend -- makes it a non-starter for an
> XO deployment in my eyes.  Did you have any thoughts on this?

We (MontevideoLibre, a free wireless community network) have been using OLSR 
for a while now. And though the topology in a typical OLPC scenario is very 
different, we've talked about assembling an image running OLSRd for a while. 

Anyway, I dont have time for a full response to this thread right now, but I 
had a conversation with smithbone and silbe a while back that may be 
illustrative of the worse-case scenario in terms of power consumption:

silbe: I think a working PoC could gather a lot interest from 
deployments...
 aa: one thing to consider is the power draw. with libertas_tf, the 
host CPU needs to be powered on. 
yes
silbe: do you have an idea of what that means in actual numbers?
perhaps smithbone has a guesstimate 
 aa: counter-question: are you thinking of running the protocol while 
the XO is "powered off" (screen off, everything in suspend with wake-on-WLAN) 
or just during regular operation?
 for the latter case, it might not make much of a difference, 
especially if "automatic power management" (automatic suspend) is disabled.
 Running the system is going to cost you in the 5W range. 
 in the "powered off" case it's going to make a huge difference. I 
don't think it'll be able to run for more than 3h while there's any traffic.
silbe: one of the things I want to find out is the convergence time of 
the different options
 aa: i.e. the time until the network/mesh is stable?
yes
 aa: if you were in europe, you might try getting funding from the EU 
for that ;)
silbe: also, BATMAN has a layer 2 kernel module, maybe we could make 
it aware of the PM state?
 they seem to pay some pretty sums for mesh research
 * aa migrates to Europe
:P
 aa: it should just integrate into the kernel PM QoS framework I 
cuppose, see Documentation/power/pm_qos_interface.txt
silbe: will do
 aa: oh, and some recent mail from me has a link to nice slides 
explaining the PM QoS framework
silbe, smithbone: do you guys know if wol would work with libertas_tf?
silbe: to sugar-devel?
 aa: no idea, sorry.
 aa: I think to de...@l.l.o
silbe: found it, thanks!
 aa: which gen?
smithbone: XO-1
 aa: on XO-1 the wakeup is generated by strobing a signal to the 
EC. So libertas_tf would need to support strobing that signal
smithbone: thanks a lot, is this documented somewhere?
too bad the firmware is closed :(   
 aa: no. because none of the systems you are talking about have 
open documentation
smithbone: I understand 
 aa: But I can certainly tell someone what gpio on the wlan module 
to strobe and for how long.

-- 
  -Andrés


signature.asc
Description: This is a digitally signed message part.
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[L. Aaron Kaplan]

(...)

>> 
>> 
>> BTW Richard, as far as I remember the problems with 802.11s seemed to be:
>> 1) the standard is not a standard and it was intentionally crippled
>> 2) the drivers were very b0rked and broken (and Marvel did a terrible job 
>> with the driver software)
>> 
>> Scalability to less than 30 laptops in one room was the result.
>> A standard good AP and standard laptops can go to 30 in one room (with 
>> standard settings).
>> So, there was definitely something broken with the Marvel solution.
>> 
>> Fix layer 2 first, then look at layer 3.
> 
> Yes, Yes,  I'm not trying to defend the previous mesh implementation in any 
> way.  Pretend the previous OLPC "mesh" does not exist.  And in fact on a XO 
> 1.5 it does not exist.
> 

OK. Didn't know.

> I'm saying that the bulk of our rollouts are dense scenarios connected to an 
> AP.  If we can do better density than an AP with less equipment then thats 
> something to go for.

yes, you can - take the RIPE example: just reduce the txpower and have multiple 
APs.
There are also some very smart APs with a central controlling AP out there 
(Cisco has some of those).
These APs balance out the clients "magically".

>  If you can't do better than an AP then unless you are doing the 
> minimal-infra wide area part of mesh there isn't much in it that will help 
> the bulk of OLPC rollouts.
> 

Well - the issue is IMHO that OLPC always sold the public on the mesh idea. So 
it is somewhat of a bummer that the mesh is gone now.

I might add that the Funkfeuer/Freifunk -style outdoor meshes are still another 
totally cool option: you can mesh the different schools this way very cheaply.
So that is another thing to consider IMHO.

>> PS: can you forward my answer to the lists? I am not subscribed...
> 
> Sure but I'm not on iaep so I can't help there.
> 
thx!



PGP.sig
Description: This is a digitally signed message part
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[Reuben K. Caron]

On Aug 24, 2010, at 12:08 PM, Richard A. Smith wrote:

> I'm not talking about comparison to our previous mesh.

Thanks keeping me on track.

> I'm talking about comparison to an AP.  Overall we currently don't  
> have much need for "mesh" as most of our scenarios are a dense cloud  
> of children in the same space trying to network with each other.

Fo deployments that have funding for APs there is not much need for  
"mesh." I would approximate that roughly 66% of our user base are in  
deployments that do not have funding for APs.

>
> The network-without-infra feature of "mesh" is certainly useful in  
> scenarios were you want to provide access over a wider area.  Its a  
> very important feature of mesh but its just not the feature we need  
> on the ground ATM.

Yet, this is a "feature," we continue to sell and a feature often  
requested.

> However, if the same mesh smartness also gets density without using  
> AP's then that's a big win.

Agreed!

Reuben


___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[L. Aaron Kaplan]

>>> 
>>> The largest of our mesh problems did not have to do with
>>> scalability on sheer number of nodes but rather scalability in
>>> density.  Is there any information available on how these networks
>>> perform when there are 50 - 100 of them next all in the same room
>>> or in adjacent rooms?
>> 
>> Yes! And the answer is very very simple: turn down the txpower!
>> ;-)))
> 
> Can you provide me with a pointer to the numbers?  Whats the maximum number 
> of nodes can you have operated in a given area and what sort of network 
> traffic tests did you run?
> 


Well, the community wireless networks are not very much about very dense 
settings. We try to cover large areas with external (outdoor) antennas but 
still have very many nodes in one single mesh covering a whole city or so. See 
the attached current map of the Funkfeuer.at network.

BUT!! Because we don't have a mesh with 100s of laptops in one room, does not 
mean, we don't know physics ;-)


Since you asked if I know an example where there are many laptops in one room:
One example that I know that worked brilliantly well with many wireless devices 
in one room was the RIPE meeting in Amsterdam. There they regularly have many 
small APs below the desks in the meeting room and these are turned down very 
much in "volume" (txpower).
The effect is that they only cover a small area ( remember, power decreases by 
the square of the distance).
So this is a way to avoid a lot of noise of many laptops in a small room.
Another feature that you IMHO should look at is 802.11n devices (and of course 
also turn down the "volume" there!). These offer higher bandwidths in addition 
to actually using the multipath effects.
When you have many many laptops in one room and everybody "screams"/sends very 
loud then you have lots of "echos" (multipath fading) bouncing off the walls 
etc. 802.11n thrives off these multipath effects.


As I said - first solve layer 1 & 2 issues and then think about layer 3 meshing.


I hope I could help.
Best regards,
L. Aaron Kaplan
(OE1SYS)


PS: please forward my answers to the list or allow me to post to the list. I am 
not subscribed there . Thx.




PGP.sig
Description: This is a digitally signed message part
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[L. Aaron Kaplan]

On Aug 24, 2010, at 5:24 PM, Richard A. Smith wrote:

> 
> On 08/24/2010 10:13 AM, Reuben K. Caron wrote:
> 
> > Consider the benefits of using open source software versus our closed
> > source firmware and partnering with communities like Freifunk whose
> > network is ~ 800 node, guifi.net is almost 10k nodes in Barcelona,
> > Athens Wireless is 5k nodes.
> 
> The largest of our mesh problems did not have to do with scalability on sheer 
> number of nodes but 


BTW Richard, as far as I remember the problems with 802.11s seemed to be:
1) the standard is not a standard and it was intentionally crippled 
2) the drivers were very b0rked and broken (and Marvel did a terrible job with 
the driver software)

Scalability to less than 30 laptops in one room was the result.
A standard good AP and standard laptops can go to 30 in one room (with standard 
settings).
So, there was definitely something broken with the Marvel solution.

Fix layer 2 first, then look at layer 3.


PS: can you forward my answer to the lists? I am not subscribed...




PGP.sig
Description: This is a digitally signed message part
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[Reuben K. Caron]

On Aug 24, 2010, at 11:24 AM, Richard A. Smith wrote:

> On 08/24/2010 10:13 AM, Reuben K. Caron wrote:
>
> > Consider the benefits of using open source software versus our  
> closed
> > source firmware and partnering with communities like Freifunk whose
> > network is ~ 800 node, guifi.net is almost 10k nodes in Barcelona,
> > Athens Wireless is 5k nodes.
>
> The largest of our mesh problems did not have to do with scalability  
> on sheer number of nodes but rather scalability in density.  Is  
> there any information available on how these networks perform when  
> there are 50 - 100 of them next all in the same room or in adjacent  
> rooms?
>
> In those scenarios we run into RF density issues even when using APs.

 From what I understand, OLSR has a better mechanism for maintaining  
the "mesh information." If you recall any change in mesh was  
previously broadcasted to all listeners. OLSR is configurable. For  
instance, information would only be broadcasted to two levels of one  
devices immediate neighbor not the whole mesh cloud. Another issue we  
had was maintaining mesh information in a limited memory space on the  
WLAN module; OLSR would now process that information. 
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[L. Aaron Kaplan]

On Aug 24, 2010, at 5:24 PM, Richard A. Smith wrote:

> 
> On 08/24/2010 10:13 AM, Reuben K. Caron wrote:
> 
> > Consider the benefits of using open source software versus our closed
> > source firmware and partnering with communities like Freifunk whose
> > network is ~ 800 node, guifi.net is almost 10k nodes in Barcelona,
> > Athens Wireless is 5k nodes.
> 
> The largest of our mesh problems did not have to do with scalability on sheer 
> number of nodes but rather scalability in density.  Is there any information 
> available on how these networks perform when there are 50 - 100 of them next 
> all in the same room or in adjacent rooms?

Yes! And the answer is very very simple:
turn down the txpower! ;-)))

best regards,
Aaron
(OE1SYS)






PGP.sig
Description: This is a digitally signed message part
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[Reuben K. Caron]

On Aug 24, 2010, at 10:26 AM, Chris Ball wrote:


The fact that a custom mesh algorithm would have to run on the CPU --
prohibiting any kind of idle-suspend -- makes it a non-starter for an
XO deployment in my eyes.  Did you have any thoughts on this?



Hi Chris,

Great point. Thank you for bringing this up. I have given this some  
thought; though I'm curious to know if this is your only objection to  
the suggestion? I find it interesting that what you consider a non- 
starter, I consider a feature. I have often considered it a bit  
presumptuous for us to deplete one child's precious power resources to  
maintain the mesh network for other children. We have created a model  
where in essence one household is funding access to the Internet in  
another household through power costs. My thoughts are: we don't do  
this. If the XO wants to go into idle-suspend let it. The connecting  
XO will have to find another path or lose access to the Internet.  
Either way it is a better solution then what we have now. If children  
group together and knowingly disable idle-suspend so they can maintain  
a mesh network for their neighbors then that is fine and a great  
example of building community but doing so as a mandatory  
implementation IMHO and with all due respect is questionable.


Some things I'd like to point out.

-8.2.1 has idle-suspend disabled by default and we are considering  
disabling by default idle-suspend for new XO - 1 builds. In these  
cases OLSR would be performing fine.
-The switch in WLAN chip from XO 1.0 to 1.5 forces us to re-think how  
we do connectivity.
-The thin-firmware being built for XO 1.5 has the same CPU-prohibiting  
idle-suspend limitation and *does not* include a user base and support  
community of thousands of users and active development. Yet it relies  
on one closed source firmware developed by one firm based on the same  
"mesh" technology developed 3 years ago. It also lacks my hardware  
agnostic points.
-On the XO 1.5 builds where idle-suspend is working (CONGRATULATIONS  
TEAM), I'd recommend letting it idle-suspend. Yes, it will create  
route-flapping but in the school scenarios there should be enough  
paths to maintain connectivity and in the household environment any  
bit more of connectivity is better then none. It also leaves children  
and families the ability to knowingly disable-idle suspend and provide  
a resource to their neighbors.


Thank you for your thoughts.

Reuben




___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] "Mesh" Dreams = OLSR

[Chris Ball]

Hi Reuben,

   > Consider the benefits of using open source software versus our
   > closed source firmware and partnering with communities like
   > Freifunk whose network is ~ 800 node, guifi.net is almost 10k
   > nodes in Barcelona, Athens Wireless is 5k nodes.

The fact that a custom mesh algorithm would have to run on the CPU --
prohibiting any kind of idle-suspend -- makes it a non-starter for an
XO deployment in my eyes.  Did you have any thoughts on this?

- Chris.
-- 
Chris Ball   
One Laptop Per Child
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] Stamp $50 Android tablet prototype raises eyebrows in India and beyond (video)

[Kevin Cole]

Just another future possibility...

http://www.engadget.com/2010/08/23/stamp-50-android-tablet-prototype-raises-eyebrows-in-india-and/
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] "Mesh" Dreams = OLSR

[Reuben K. Caron]

Where Mesh != 802.11s but rather an adhoc, self healing, self  
organizing routable network.

Imagine a world where Sugar on a Stick machines can communicate on the  
same network as an XO laptop. A world where mesh capabilities are  
hardware agnostic allowing anyone to bring up a mesh network by  
booting a live cd.

Imagine a school full of XOs where some are connected to Adhoc Channel  
1, some to Channel 6, and some to Channel 11. Now think of an XO that  
has two USB Wireless Adapters each connected respectively to one of  
those channels. This central XO also has a third USB ethernet dongle  
or a 3G wireless modem attached to it. Consider how this simple setup  
could provide Internet to everyone in the school. Consider the ability  
to actually create "Mesh Portal Points," that allow one connection to  
provide an Internet connection to many hops down the line.

Consider the benefits of using open source software versus our closed  
source firmware and partnering with communities like Freifunk whose  
network is ~ 800 node, guifi.net is almost 10k nodes in Barcelona,  
Athens Wireless is 5k nodes.

These things are all almost immediately possible by using OLSRd  
software. Over the past few months, I have tested and built small  
networks around my neighborhood to consider the feasibility of such  
software. Now I realize there is a difference between small and large  
networks but I think it is something we should consider.

As I have said, please *consider * all of these things with a fresh  
perspective and try to forget about the prior mesh battles.

Let's think of solutions that will actually make this work.  Some  
things to consider from Aaron Kaplan, a member of the OLSR community,  
cc'd here:

"How to scale networks?

-The key is to have multiple channels, smart channel selection/ 
assignment, automatic txpower control and low interference between  
nodes!
-In a sense, it is funny but true: the quieter the devices become, the  
better everybody can "hear" his mesh partner.
-Summary: layer 2 is king for scalability , only then do you need to  
look at layer 3 optimizations (and with OLSR.org we already took care  
of that part"


I hope that we can come together to re-group and re-think how we OLPC  
and SugarLabs do connectivity and utilize the open opportunities  
available to create such solutions.

Regards,

Reuben

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] The value of plastic

[Lucian Branescu]

I found his approach to teaching children about plastic/oil interesting.

 http://motherboard.tv/2010/8/22/a-machine-that-turns-plastic-back-into-oil--2
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep