date:20080219

Sulochan,

You should check your forwarding (layer two) table with : iwpriv msh0
fwt_list index (index is 0,1,2,...)

Look for an entry that forwards the frames destined to the anycast mac
address of the server (c0:27:c0:27:c0:00) via the mac address of the first
XO.

Traceroute/path will show you layer three (IP) routes.

Regards,
Ricardo Carrano

2008/2/19 sulochan acharya [EMAIL PROTECTED]:

 Folks,
 I can not hop from xo to xo to xs.
 Here is what I did:

 One XO closer to the server with active antenna.and i can ping the
 server from this laptop.

 Another XO closer to the first laptop ( i can chat with this XO) but
 further away from the server.

 Now technically i should be able to ping the server through the first
 laptop, but I cant :(

 Is there some additional things i need to (like adding packages) go
 through to get this to work?

 Or is it just out of range? If so how it is different from one laptop
 talking to another laptop?

 Is there a way i can check that the packet is being relayed (other than
 doing trace rout ) ?

 Also, can i for test purposes change the mesh DHCP to give out ipv4 and
 not ipv6? Would this make
 some other features not work?

 best,
 -Sulochan

 ___
 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

[ANNOUNCE] Compressed Cache release 0.1

2008-02-19 Thread Nitin Gupta

Hi All,

I am excited to announce first release of ccache - Compressed RAM
based swap device for Linux (2.6.x kernel).
 - Project home: http://code.google.com/p/ccache/
 - ccache-0.1: http://ccache.googlecode.com/files/ccache-0.1.tar.bz2

This is RAM based block device which acts as swap disk. Pages swapped
to this device are compressed and stored in memory itself. I think this is
very useful for OLPC systems since it has decent processor but just 256MB
RAM. Also, flash storage suffers from wear-leveling issues, slow writing speeds
- so, its very useful if we can avoid them using as swap device.

It does not require any kernel patching. All components are separate
kernel modules:
- Memory allocator (tlsf.ko)
- Compressor (lzo1x_compress.ko)
- Decompressor (lzo1x_decompress.ko)
- Main ccache module (ccache.ko)
(LZO de/compressor is already in mainline but I have included it here
since distros don't ship it by default).
README (or project home) explains compilation and usage in detail.

Some performance numbers for allocator and de/compressor can be found
on project home. Currently it is tested on Linux kernel 2.6.23.x and
2.6.25-rc2 (x86 only) and is very stable. Please mail me/mailing-list any
issues/suggestions you have.

Code reviews/tests on OLPC will be really helpful! :)

Thanks,
- Nitin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

I believe the most important issue here is that, the way it is now,
suspend/resume will make a disconnected mesh unusable.


On Feb 17, 2008 4:11 AM, Giannis Galanis [EMAIL PROTECTED] wrote:

 There are a couple of important issues/bugs regarding Salut and
 Suspend/Resume.

 FIRST, there is a sugar issue, (or at least it seems so).
 When an XO resumes after long suspends, all icons(APs, XOs, but not the
 meshes) instantly vanish*(#6467)*. Then they slowly reappear. Although
 with the APs the situation is pretty straightforward, with the XOs we have
 several cases:

- all XOs in the mesh return almost instantly
- all or some XOs return slowly one by one
- nothing returns, and avahi peer list is empty*(#6498)*

 It seems that although suspend should keep the previous situation frozen,
 in fact the avahi peer list is affected.


 SECOND, we have a network issue, which suggests a war between
 suspend/resume and avahi/salut
 Suspend will be interrupted only with unicast packets, but Salut/avahi
 rely on multicast packets.

 The result is that  when an XO that appears in the mesh view is suspended,
 avahi will treat it just as if it has left the mesh.


- When an XO is being used(not suspended), all other suspended XOs
in the mesh will start failing 1 by 1
- From the moment an XO is suspended in about 10-30min the icon will
vanish.*(#6282)*
- If within this time new XOs join the mesh than the icon will
vanish instantly!!*(#5501)*
- If gradually several removed XOs start to resume, their icons will
start returning

 *As you can see, the XOs have very little chance to even see each
 other**

 RESULT:
 A mesh of several XOs will avoid icons flashing here and there, ONLY if no
 XO has been idle for more 10min, which is rather unlikely.

 Considering the effects of the FIRST issue, you would practically have to
 restart sugar or switch channel back and forth to return to your original
 status.

 Salut/avahi are very sluggish in handling failed connections, and suspend
 resume enhaces this effect.


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Kim Quirk

It does feel like we should turn off suspend for some of our testing.
I've experienced similar problems.

Chris, do you recommend removing ohm? Or is there something else we should try?

Kim




On 2/19/08, Ricardo Carrano [EMAIL PROTECTED] wrote:
 I believe the most important issue here is that, the way it is now,
 suspend/resume will make a disconnected mesh unusable.


 On Feb 17, 2008 4:11 AM, Giannis Galanis [EMAIL PROTECTED] wrote:

  There are a couple of important issues/bugs regarding Salut and
  Suspend/Resume.
 
  FIRST, there is a sugar issue, (or at least it seems so).
  When an XO resumes after long suspends, all icons(APs, XOs, but not the
  meshes) instantly vanish*(#6467)*. Then they slowly reappear. Although
  with the APs the situation is pretty straightforward, with the XOs we have
  several cases:
 
 - all XOs in the mesh return almost instantly
 - all or some XOs return slowly one by one
 - nothing returns, and avahi peer list is empty*(#6498)*
 
  It seems that although suspend should keep the previous situation frozen,
  in fact the avahi peer list is affected.
 
 
  SECOND, we have a network issue, which suggests a war between
  suspend/resume and avahi/salut
  Suspend will be interrupted only with unicast packets, but Salut/avahi
  rely on multicast packets.
 
  The result is that  when an XO that appears in the mesh view is suspended,
  avahi will treat it just as if it has left the mesh.
 
 
 - When an XO is being used(not suspended), all other suspended XOs
 in the mesh will start failing 1 by 1
 - From the moment an XO is suspended in about 10-30min the icon will
 vanish.*(#6282)*
 - If within this time new XOs join the mesh than the icon will
 vanish instantly!!*(#5501)*
 - If gradually several removed XOs start to resume, their icons will
 start returning
 
  *As you can see, the XOs have very little chance to even see each
  other**
 
  RESULT:
  A mesh of several XOs will avoid icons flashing here and there, ONLY if no
  XO has been idle for more 10min, which is rather unlikely.
 
  Considering the effects of the FIRST issue, you would practically have to
  restart sugar or switch channel back and forth to return to your original
  status.
 
  Salut/avahi are very sluggish in handling failed connections, and suspend
  resume enhaces this effect.
 
 


-- 
Sent from Gmail for mobile | mobile.google.com
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Chris Ball

Hi,

It does feel like we should turn off suspend for some of our
testing.  I've experienced similar problems.

Chris, do you recommend removing ohm? Or is there something else we
should try?

I recommend fixing the bug.  :)  We know that we intend to have the CPU
turned off most of the time on our laptops on the mesh -- why is the
presence service incompatible with this?  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?  Should it be
using unicast traffic instead?  What is it in Avahi's code path that
causes its peer list to be emptied on resume?

If we have to disable OHM to test something in particular, that's okay,
but we won't be testing what we plan on shipping if we do so.

Thanks,

- Chris.
-- 
Chris Ball   [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Chris Ball

Hi Ricardo,

A mesh will always rely to some degree in multicast/broadcast
traffic. This is not a bug.

I was asking whether it would help to have the wireless module wake us
on multicast packets instead of only unicast.  Are you saying that it
would?

Avahi entries will expire after some time. Suspend will prevent it
to update its cache.

Yani's bug report (#6467) suggests that Avahi entries often expire
immediately upon resume:

   After the XO resumes (probably after beinng suspended for several
   minutes) all the icons in the mesh view vanish, except the mesh
   circles.

Thanks,

- Chris.
-- 
Chris Ball   [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

Chris,

A mesh will always rely to some degree in multicast/broadcast traffic. This
is not a bug.

Avahi entries will expire after some time. Suspend will prevent it to update
its cache.

On Feb 19, 2008 11:13 AM, Chris Ball [EMAIL PROTECTED] wrote:

 Hi,

It does feel like we should turn off suspend for some of our
testing.  I've experienced similar problems.

Chris, do you recommend removing ohm? Or is there something else we
should try?

 I recommend fixing the bug.  :)  We know that we intend to have the CPU
 turned off most of the time on our laptops on the mesh -- why is the
 presence service incompatible with this?  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?  Should it be
 using unicast traffic instead?  What is it in Avahi's code path that
 causes its peer list to be emptied on resume?

 If we have to disable OHM to test something in particular, that's okay,
 but we won't be testing what we plan on shipping if we do so.

 Thanks,

 - Chris.
 --
 Chris Ball   [EMAIL PROTECTED]

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread John Watlington


The partitioning we made between the network processor and the
main processor was pretty clean.  Unfortunately, it doesn't support
low power operation.   I suggest rethinking the partition for Gen2.

wad

On Feb 19, 2008, at 10:04 AM, Chris Ball wrote:

 Hi Ricardo,

 A mesh will always rely to some degree in multicast/broadcast
 traffic. This is not a bug.

 I was asking whether it would help to have the wireless module wake us
 on multicast packets instead of only unicast.  Are you saying that it
 would?

 Avahi entries will expire after some time. Suspend will prevent it
 to update its cache.

 Yani's bug report (#6467) suggests that Avahi entries often expire
 immediately upon resume:

After the XO resumes (probably after beinng suspended for several
minutes) all the icons in the mesh view vanish, except the mesh
circles.

 Thanks,

 - Chris.
 -- 
 Chris Ball   [EMAIL PROTECTED]
 ___
 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: Salut and Suspend/Resume issues

2008-02-19 Thread John Watlington


We ALWAYS have multicast traffic.   Blindly waking on each
received multicast packet will ensure that we only sleep for
milliseconds.

wad

On Feb 19, 2008, at 9:13 AM, Chris Ball wrote:

 Hi,

 It does feel like we should turn off suspend for some of our
 testing.  I've experienced similar problems.

 Chris, do you recommend removing ohm? Or is there something else we
 should try?

 I recommend fixing the bug.  :)  We know that we intend to have the  
 CPU
 turned off most of the time on our laptops on the mesh -- why is the
 presence service incompatible with this?  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?  Should  
 it be
 using unicast traffic instead?  What is it in Avahi's code path that
 causes its peer list to be emptied on resume?

 If we have to disable OHM to test something in particular, that's  
 okay,
 but we won't be testing what we plan on shipping if we do so.

 Thanks,

 - Chris.
 -- 
 Chris Ball   [EMAIL PROTECTED]
 ___
 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: Salut and Suspend/Resume issues

2008-02-19 Thread Sjoerd Simons

On Tue, Feb 19, 2008 at 09:13:29AM -0500, Chris Ball wrote:
 It does feel like we should turn off suspend for some of our
 testing.  I've experienced similar problems.
 
 Chris, do you recommend removing ohm? Or is there something else we
 should try?
 
 I recommend fixing the bug.  :)  We know that we intend to have the CPU
 turned off most of the time on our laptops on the mesh -- why is the
 presence service incompatible with this?

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
-- 
Matter cannot be created or destroyed, nor can it be returned without a receipt.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

On Feb 19, 2008 10:13 AM, Ricardo Carrano [EMAIL PROTECTED]
wrote:


 I was asking whether it would help to have the wireless module wake us
  on multicast packets instead of only unicast.  Are you saying that it
  would?


 It seems so, though it would, as John points out, make resumes far more
 constant. It seems we have to find a creative way out of this tough choice
 (automated suspend vs mesh) or face it.


 
 
 Avahi entries will expire after some time. Suspend will prevent it
 to update its cache.
 
  Yani's bug report (#6467) suggests that Avahi entries often expire
  immediately upon resume:
 
After the XO resumes (probably after beinng suspended for several
minutes) all the icons in the mesh view vanish, except the mesh
circles.


 I read this as the avahi-cache  expiring its entries.  Yanni  can  you put
 timeframes on this?
 Could check how long does it take to expiry an entry (TO) and then check
 if:
 Suspend time  TO - all entries vanish
 Suspend time  TO - no entries vanish
 Supens time ~ TO - some entries vanish


There as 2 cases where icons vanish due to suspend.

1st: The moment you resume(it generally happens after long suspends), all
icons vanish instantly(APs/XOs). This bug (#6467) suggests that sugar has a
problem with suspend resume.
The icons slowly reappear. I assume that if the avahi peer list is intact
that all XOs return.

2nd: The avahi list smtimes looses some or all of the peers at resume. This
is also under 6467, but it seems technicaly different. One possible
explanation could be that during suspend th XO resumes several times, but i
didnt notice it! And within this time frames it realized that the other
suspended XOs are gone, so it cleared its cache. Now when I resumed it
myself, I observed that the cache is clean!!

Now, regarding the timeouts of avahi. This is a 3rd thing:
When an XO leaves the channel we have 4 states:
   mm:ss
1. 00:00  XO leave the channel(manually/or ti suspended)
2. 10:00  Avahi notices teh XO left, and reports it as failed
3. 30:00  Icon dissappears in the mesh view
4. 60:00  Avahi cache is cleared
Additionally there is a bug(#5501) according to which, is a NEW XO arrives
between states 2 and 3, then instantly ALL failed avahi peers are cleared
and the corresponding icons vanish.

So, the 3rd case is the following:

Assume a mesh has e.g. 20 XOs, and I use my XO so it doesnt suspend, but the
rest 19 of them are suspended.
If in 10mins a new XO arrives, then all the 19 XOs instantly vanish from
the mesh.

So the TO time is between 10-30min... but closer to 10min if many XOs
suspend/resume
So if resume time  10min everything is fine!!



What i dont know is when an XO resumes if it sends any avahi packet no
notify tis presence/return. Because if it doesnt, then the XO wont exist int
he others cache list, so the others wont search for it.
Sjoerd, can you answer this?

This would explain why after resume some XOs take tooo long to see each
other again.
If you combine this with the 2nd case, you will see that in the natural
case that XOs will resume at random points in time by the user, they will
all clear their cache, unless they resume concurrently.
So in the end, all will have empty caches!!





 
  Thanks,
 
  - Chris.
  --
  Chris Ball   [EMAIL PROTECTED]
 


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

Yanni,

As I posted in the bug, I believe that you are observing the entries on the
avahi cache expiring.

So, your first scenario would happen when the suspend time is longer than
the time it takes for all entries to expire.
The second scenario would happen when the suspend time is not long enough to
make all cached entries to go away.
And the third scenario seems related to previous reports you've made on the
Xmas tree effect, so not related to suspend/resume.

What do you think?

On Feb 19, 2008 1:13 PM, Giannis Galanis [EMAIL PROTECTED] wrote:



 On Feb 19, 2008 10:13 AM, Ricardo Carrano [EMAIL PROTECTED]
 wrote:

 
  I was asking whether it would help to have the wireless module wake us
   on multicast packets instead of only unicast.  Are you saying that it
   would?
 
 
  It seems so, though it would, as John points out, make resumes far more
  constant. It seems we have to find a creative way out of this tough choice
  (automated suspend vs mesh) or face it.
 
 
  
  
  Avahi entries will expire after some time. Suspend will prevent it
  to update its cache.
  
   Yani's bug report (#6467) suggests that Avahi entries often expire
   immediately upon resume:
  
 After the XO resumes (probably after beinng suspended for several
 minutes) all the icons in the mesh view vanish, except the mesh
 circles.
 
 
  I read this as the avahi-cache  expiring its entries.  Yanni  can  you
  put timeframes on this?
  Could check how long does it take to expiry an entry (TO) and then check
  if:
  Suspend time  TO - all entries vanish
  Suspend time  TO - no entries vanish
  Supens time ~ TO - some entries vanish
 

 There as 2 cases where icons vanish due to suspend.

 1st: The moment you resume(it generally happens after long suspends), all
 icons vanish instantly(APs/XOs). This bug (#6467) suggests that sugar has a
 problem with suspend resume.
 The icons slowly reappear. I assume that if the avahi peer list is intact
 that all XOs return.

 2nd: The avahi list smtimes looses some or all of the peers at resume.
 This is also under 6467, but it seems technicaly different. One possible
 explanation could be that during suspend th XO resumes several times, but i
 didnt notice it! And within this time frames it realized that the other
 suspended XOs are gone, so it cleared its cache. Now when I resumed it
 myself, I observed that the cache is clean!!

 Now, regarding the timeouts of avahi. This is a 3rd thing:
 When an XO leaves the channel we have 4 states:
mm:ss
 1. 00:00  XO leave the channel(manually/or ti suspended)
 2. 10:00  Avahi notices teh XO left, and reports it as failed
 3. 30:00  Icon dissappears in the mesh view
 4. 60:00  Avahi cache is cleared
 Additionally there is a bug(#5501) according to which, is a NEW XO arrives
 between states 2 and 3, then instantly ALL failed avahi peers are cleared
 and the corresponding icons vanish.

 So, the 3rd case is the following:

 Assume a mesh has e.g. 20 XOs, and I use my XO so it doesnt suspend, but
 the rest 19 of them are suspended.
 If in 10mins a new XO arrives, then all the 19 XOs instantly vanish from
 the mesh.

 So the TO time is between 10-30min... but closer to 10min if many XOs
 suspend/resume
 So if resume time  10min everything is fine!!



 What i dont know is when an XO resumes if it sends any avahi packet no
 notify tis presence/return. Because if it doesnt, then the XO wont exist int
 he others cache list, so the others wont search for it.
 Sjoerd, can you answer this?

 This would explain why after resume some XOs take tooo long to see each
 other again.
 If you combine this with the 2nd case, you will see that in the natural
 case that XOs will resume at random points in time by the user, they will
 all clear their cache, unless they resume concurrently.
 So in the end, all will have empty caches!!




 
  
   Thanks,
  
   - Chris.
   --
   Chris Ball   [EMAIL PROTECTED]
  
 
 

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Benjamin M. Schwartz

On Tue, 2008-02-19 at 12:29 -0500, Giannis Galanis wrote:
 The avahi works is that every several minutes(a predetermined timeout)
 each host will send multicast request for all peers in its list.
 Then all peers receiving this request will send a multicast reply.
 
 The packets are multicast because the mesh is mobile/dynamic so we
 dont know where the target is, or which is the ideal route

The problem is that with a timeout of T minutes and N laptops, there is
a wakeup required every T/N minutes, on average?  Based on your
description, it sounds as if this could be fixed by a small change in
Avahi's timeout behavior.  

If I reach the timeout, I send a broadcast saying Everyone, what's your
status?.  In reply, all users send a broadcast My status is X.  All
peers receive all of these broadcasts, and reset their timers to zero.
In this way, all laptops wake up together once every T minutes.

Surely the solution is not this simple...

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: default jabber server?

2008-02-19 Thread Wilson Farrell

Morgan Collett wrote:
 On Feb 19, 2008 10:08 AM, Adrian Chadd [EMAIL PROTECTED] wrote:
 Why do the jabber servers get overwhelmed? Surely there's a jabber
 server implementation that can handle tens of thousands of concurrent
 users?

 What software are people using on the servers?
 
 ejabberd - see http://wiki.laptop.org/go/Ejabberd_Configuration. Our
 presence mechanism, a shared roster, doesn't scale well but there are
 other strange stability issues with the configuration we are running -
 consuming all memory and dying etc. Process-one are looking into that.


If anyone gets ejabberd running correctly using those instructions, 
please let me (or just the list) know.  I posted a while back with a 
list of issues and received no response.  I got busy with other things. 
  This thread brought it all back.

Here's a synopsis:
The ejabberd 1.1.4 stuff won't even start, dying with some obscure 
erlang error.
The ejabberd 2.0.0 beta stuff is a whole lot more promising.  It 
actually runs.
I believe the setting up shared roster roster is not correct, and I 
had every intention of updating the wiki as soon as I figure out what 
was wrong... that never happened.

In short, following those instructions will make it so XO's rarely see 
each other, much less share resources.  I started fooling with those 
values in the shared roster.  It seems that Displayed Groups needs to 
be set to the value of the identification (what you called it when it 
was created) not the Name, which seems to be a pretty print name.  The 
examples at:

http://www.ejabberd.im/shared-roster-all and particularly
http://www.process-one.net/docs/ejabberd/guide_en.html#htoc64

seem to indicate this.

When you do that, XO's can see each other 100% of the time, but shared 
resources do not display properly at the remote XO.  (You can invite 
others to share and the actual sharing works properly) In the end the 
closest I could get to having everything right was setting my shared 
roster as such:

Shared Group: Everybody
Name: Online
Description:  blank
Members:  @online@
Displayed Groups: Everybody

This issue is echo'd here: 
http://wiki.laptop.org/go/Talk:Ejabberd_Configuration by another user I 
commiserated with.

If anyone is interested in pursuing this, I can bump my previous post, 
but right now its not a high priority for me.

Wilson

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Benjamin M. Schwartz

On Tue, 2008-02-19 at 10:02 -0500, John Watlington wrote:
 We ALWAYS have multicast traffic.   Blindly waking on each
 received multicast packet will ensure that we only sleep for
 milliseconds.

What is all this multicast traffic?
If I am sitting idle on the network, why is there constant multicast
traffic being sent to me?

I would expect broadcasts for activity share notifications and Hi, I'm
new announcements, but those should be infrequent.

--Ben

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

startup icon blinks and disappears

2008-02-19 Thread Kaitlin Anderson

Hi all,

I'm a beginner at Python and have been trying to go through these two
tutorials that were posted on the wiki:
1) http://wiki.laptop.org/go/Activity_tutorial
2) http://wiki.laptop.org/go/PyGTK/Hello_World_Tutorial

The first tutorial was great and got me familiarized with the entire
integration with QEMU.
I successfully got that little Hello World up and running but have had some
difficulty with the second one which was an introduction to Glade.

I was able to run my class code successfully in PythonWin so I know the base
source works, which points to something wrong in the activity.py wrapper.
The symptom is when I invoke the activity from the frame, the icon gets
added to the active activity ring and starts blinking. However, it tries to
start but after a few blinks it just disappears. I ran into this issue with
the first tutorial and discovered it was an accidental indentation I had
added. I could ctrl-alt-3 over to the console to see the errors when I ran
it from the developer's console. However, when I try running the tutorial 2
code, I get an error from _init_check within gtk saying it had a Runtime
Error Could not open display. Any suggestions?

Much thanks,
Kaitlin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An Update about Speech Synthesis

2008-02-19 Thread Hemant Goyal

Hi,

I'd like to see an eSpeak literacy project written up -- Once we have
a play button, with text highlighting, we have most of the pieces to
make a great read + speak platform that can load in texts and
highlight words/sentences as they are being read. Ping had a nice
mental model for this a while back.

Great idea :). The button will soon be there :D. I had never expected this
to turn into something this big :). There are lots of things I want to get
done wrt this project and hope to accomplish them one by one.

Thanks for the info Hemant! Can you tell me more about your experiences
with speech dispatcher and which version you are using? The things I'm
interested in are stability, ease of configuration, completeness of
implementation, etc.

I'll try to tell whatever I am capable of explaining (I am not an expert
like you all :) ). Well we had initially started out with a speech-synthesis
DBUS API that directly connected to eSpeak. Those results are available on
the wiki page [http://wiki.laptop.org/go/Screen_Reader]. From that point
onwards we found out about speech-dispatcher and decided to analyze it for
our requirements primarily keeping the following things in mind:

1. An API that provided configuration control on a per-client basis.
2. a feature like printf() but for speech for developers to call, and
thats precisely how Free(b)soft described their approach to
speech-dispatcher.
3. Python Interface for speech-synthesis
4. Callbacks for developers after certain events.

At this moment I am in a position to comment about the following:

1. WRT which modules to use -I found it extremely easy to configure
speech-dispatcher to use eSpeak as a TTS engine. There are configuration
files available to simply select/unselect which TTS module needs to be used.
I have described how an older version of speech-dispatcher can be made to
run on the XO here

http://wiki.laptop.org/go/Screen_Reader#Installing_speech-dispatcher_on_the_xo
2. There were major issues of using eSpeak with the ALSA Sound system
some time back [http://dev.laptop.org/ticket/5769,
http://dev.laptop.org/ticket/4002]. This issue is resolved by using
speech-dispatcher as it supports ALSA, and OSS. So in case OLPC ever shifts
to OSS we are safe. I am guessing speech-dispatcher does not directly let a
TTS engine write to a sound device but instead accepts the audio buffer and
then routes it to the Audio Sub System.
3. Another major issue we had to tackle was providing callbacks while
providing the DBUS interface. The present implementation of
speech-dispatcher provides callbacks for various events that are important
wrt speech-synthesis. I have tested these out in python and they were
working quite nicely. In case you have not, you might be interested in
checking out their Python API [

http://cvs.freebsoft.org/repository/speechd/src/python/speechd/client.py?hideattic=0view=markup
].
4. Voice Configuration and language selection - The API provides us
options to control voice parameters such as pitch, volume, voice etc for
each client.
5. Message Priorities and Queuing - speech-dispatcher has provided
various levels of priority for speech synthesis, so we cand place a Higher
Priority to a message played by Sugar as compared to an Activity.
6. Compatibility with orca - I installed orca and used
speech-dispatcher as the speech synth engine. It worked fine. We wanted to
make sure that the speech synth server would work with orca if it was ported
to XO in the future.
7. Documentation - speech-dispatcher has a lot of documentation at the
moment, and hence its quite easy to find our way and figure out how to do
things we really want to. I had intended to explore gnome-speech as well,
however the lack of documentation and examples turned me away.

The analysis that I did was mostly from a user point of view or simple
developer requirements that we realized had to be fulfilled wrt
speech-synthesis, and it was definitely not as detailed as you probably
might expect from me.

We are presently using speech-dispatcher 0.6.6

A dedicated eSpeak module has been provided in the newer versions of
speech-dispatcher and that is a big advantage for us. In the older version
eSpeak was called and various parameters were passed as command line
arguments, it surely was not very efficient wrt XO.

Stability - I think the main point that I tested here was how well
speech-dispatcher responds to long strings. The latest release of
speech-dispatcher 0.6.6 has some
tests in which an entire story is read out [
http://cvs.freebsoft.org/repository/speechd/src/tests/long_message.c?view=markup].
However I still need to run this test on the XO. I will do so once I have
RPM packages to install on the XO.

In particular speech-dispatcher is quite customizable, easily controlled
through programming languages, provides callback support, and has

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Polychronis Ypodimatopoulos

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

For the protocol to be healthy,

not only you have to wake every 10min to send your request,
but you have to be awake to receive the others' requests.

These are again 10min, but have different offsets. Thats why I believe the
only way would be to have 10off - 10on.

Still, due to bug 5501, if you miss a single request, u are prone to be
deleted right away.

So 10ff-10on might not work either.

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.



On Feb 19, 2008 1:19 PM, Benjamin M. Schwartz [EMAIL PROTECTED]
wrote:

 On Tue, 2008-02-19 at 13:11 -0500, Giannis Galanis wrote:

 
  The wakeup required is T minutes for every T minutes.
  Actually you would need to be awake  for T  minutes
  and suspended for T minutes to be sure u are ok.
 
  So for T=10min, as in this case:
  9off, 11on, 9 off, 11on
 
  but this is not very effective in terms of suspend/resume

 I meant to imply that this would work only if the wireless hardware
 wakes up the system for every broadcast.

 --Ben



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Polychronis Ypodimatopoulos

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

Re: Salut and Suspend/Resume issues

The list expires in 10min-30min.

But we cant wait 30min before suspending, it is way too long.


On Feb 19, 2008 11:37 AM, Ricardo Carrano [EMAIL PROTECTED]
wrote:

 Yanni,

 As I posted in the bug, I believe that you are observing the entries on
 the avahi cache expiring.

 So, your first scenario would happen when the suspend time is longer than
 the time it takes for all entries to expire.
 The second scenario would happen when the suspend time is not long enough
 to make all cached entries to go away.


Oh i see that you mean. But, i think both cases are when the suspend time is
longer than time to expire.
The first is UI effect, and might have no relation to salut, but to mesh
view in general
The second is an avahi effect, that the avahi cache is chagned
Both, are in long suspends


 And the third scenario seems related to previous reports you've made on
 the Xmas tree effect, so not related to suspend/resume.


The xmas tree effect appears when XOs leave connection, while others return.
Suspend/resume enhances this effect dramatically, because in 1-2min everyone
goes away, and they return at random time according to when they resume.

In my suspend-salut tests , the xmas tree effect(although NOT related to
suspend/resume), it affects salut alot more then the other 2 scenarios

My point is that we must fix it anyway. But especially now!!



 What do you think?


I have 2 questions that will help (me) understand alot about the situation:

1. When a XO resumes, does it send any notification via avahi, that it is
back? Because if it doesnt, then other XOs that have cleared it from their
lists, they will never search for it.

2. Every scans the network every 10min, to check whether its avahi peers are
alive, in multicast packets. Do these packets include the address of the
peers/targets? I think they do, unless i am very confused. Couldn't we
awake/resume the target XO when it receives these specific packets?

we need to do some sniffing




 On Feb 19, 2008 1:13 PM, Giannis Galanis [EMAIL PROTECTED] wrote:

 
 
  On Feb 19, 2008 10:13 AM, Ricardo Carrano [EMAIL PROTECTED]
  wrote:
 
  
   I was asking whether it would help to have the wireless module wake us
on multicast packets instead of only unicast.  Are you saying that
it
would?
  
  
   It seems so, though it would, as John points out, make resumes far
   more constant. It seems we have to find a creative way out of this tough
   choice (automated suspend vs mesh) or face it.
  
  
   
   
   Avahi entries will expire after some time. Suspend will prevent
it
   to update its cache.
   
Yani's bug report (#6467) suggests that Avahi entries often expire
immediately upon resume:
   
  After the XO resumes (probably after beinng suspended for several
  minutes) all the icons in the mesh view vanish, except the mesh
  circles.
  
  
   I read this as the avahi-cache  expiring its entries.  Yanni  can  you
   put timeframes on this?
   Could check how long does it take to expiry an entry (TO) and then
   check if:
   Suspend time  TO - all entries vanish
   Suspend time  TO - no entries vanish
   Supens time ~ TO - some entries vanish
  
 
  There as 2 cases where icons vanish due to suspend.
 
  1st: The moment you resume(it generally happens after long suspends),
  all icons vanish instantly(APs/XOs). This bug (#6467) suggests that sugar
  has a problem with suspend resume.
  The icons slowly reappear. I assume that if the avahi peer list is
  intact that all XOs return.
 
  2nd: The avahi list smtimes looses some or all of the peers at resume.
  This is also under 6467, but it seems technicaly different. One possible
  explanation could be that during suspend th XO resumes several times, but i
  didnt notice it! And within this time frames it realized that the other
  suspended XOs are gone, so it cleared its cache. Now when I resumed it
  myself, I observed that the cache is clean!!
 
  Now, regarding the timeouts of avahi. This is a 3rd thing:
  When an XO leaves the channel we have 4 states:
 mm:ss
  1. 00:00  XO leave the channel(manually/or ti suspended)
  2. 10:00  Avahi notices teh XO left, and reports it as failed
  3. 30:00  Icon dissappears in the mesh view
  4. 60:00  Avahi cache is cleared
  Additionally there is a bug(#5501) according to which, is a NEW XO
  arrives between states 2 and 3, then instantly ALL failed avahi peers are
  cleared and the corresponding icons vanish.
 
  So, the 3rd case is the following:
 
  Assume a mesh has e.g. 20 XOs, and I use my XO so it doesnt suspend, but
  the rest 19 of them are suspended.
  If in 10mins a new XO arrives, then all the 19 XOs instantly vanish
  from the mesh.
 
  So the TO time is between 10-30min... but closer to 10min if many XOs
  suspend/resume
  So if resume time  10min everything is fine!!
 
 
 
  What i dont know is when an XO resumes if it sends any avahi packet no
  notify tis presence/return. Because if it doesnt, then the XO

Re: Salut and Suspend/Resume issues

On Feb 19, 2008 12:55 PM, Benjamin M. Schwartz [EMAIL PROTECTED]
wrote:

 On Tue, 2008-02-19 at 12:29 -0500, Giannis Galanis wrote:
  The avahi works is that every several minutes(a predetermined timeout)
  each host will send multicast request for all peers in its list.
  Then all peers receiving this request will send a multicast reply.
 
  The packets are multicast because the mesh is mobile/dynamic so we
  dont know where the target is, or which is the ideal route

 The problem is that with a timeout of T minutes and N laptops, there is
 a wakeup required every T/N minutes, on average?


The wakeup required is T minutes for every T minutes.
Actually you would need to be awake  for T  minutes
and suspended for T minutes to be sure u are ok.

So for T=10min, as in this case:
9off, 11on, 9 off, 11on

but this is not very effective in terms of suspend/resume

  Based on your
 description, it sounds as if this could be fixed by a small change in
 Avahi's timeout behavior.

 If I reach the timeout, I send a broadcast saying Everyone, what's your
 status?.  In reply, all users send a broadcast My status is X.  All
 peers receive all of these broadcasts, and reset their timers to zero.
 In this way, all laptops wake up together once every T minutes.

 Surely the solution is not this simple...

 The problem is that the others wont know YOUR status.
I think the confirmation of status is not announced/beaconed, but
requested first.

But someone from collabora must confirm this
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

Yanni,

Timeout is a value, not a range. The effects brought by the timeout may
manifest in a period (a range).

I believe everyone will agree that 30 minutes is a long time to wait (and
like Polychronis added) defeat the whole idea of a presence service.

But, what I want to stress is that we are dealing with different issues
here.

I don't believe this 30 minutes or the xmas tree effect is related to
suspend/resume. Those seem like bugs somewhere in the stack of software that
support presence, while the suspend/resume issues are clearly a side effect
of  the multicast traffic not being heard by a suspended XO.



On Feb 19, 2008 3:00 PM, Giannis Galanis [EMAIL PROTECTED] wrote:

 The list expires in 10min-30min.

 But we cant wait 30min before suspending, it is way too long.


 On Feb 19, 2008 11:37 AM, Ricardo Carrano [EMAIL PROTECTED]
 wrote:

  Yanni,
 
  As I posted in the bug, I believe that you are observing the entries on
  the avahi cache expiring.
 
  So, your first scenario would happen when the suspend time is longer
  than the time it takes for all entries to expire.
  The second scenario would happen when the suspend time is not long
  enough to make all cached entries to go away.


 Oh i see that you mean. But, i think both cases are when the suspend time
 is longer than time to expire.
 The first is UI effect, and might have no relation to salut, but to mesh
 view in general
 The second is an avahi effect, that the avahi cache is chagned
 Both, are in long suspends

 
  And the third scenario seems related to previous reports you've made on
  the Xmas tree effect, so not related to suspend/resume.


 The xmas tree effect appears when XOs leave connection, while others
 return.
 Suspend/resume enhances this effect dramatically, because in 1-2min
 everyone goes away, and they return at random time according to when they
 resume.

 In my suspend-salut tests , the xmas tree effect(although NOT related to
 suspend/resume), it affects salut alot more then the other 2 scenarios

 My point is that we must fix it anyway. But especially now!!


 
  What do you think?
 

 I have 2 questions that will help (me) understand alot about the
 situation:

 1. When a XO resumes, does it send any notification via avahi, that it is
 back? Because if it doesnt, then other XOs that have cleared it from their
 lists, they will never search for it.

 2. Every scans the network every 10min, to check whether its avahi peers
 are alive, in multicast packets. Do these packets include the address of the
 peers/targets? I think they do, unless i am very confused. Couldn't we
 awake/resume the target XO when it receives these specific packets?

 we need to do some sniffing



 
  On Feb 19, 2008 1:13 PM, Giannis Galanis [EMAIL PROTECTED] wrote:
 
  
  
   On Feb 19, 2008 10:13 AM, Ricardo Carrano [EMAIL PROTECTED]
   wrote:
  
   
I was asking whether it would help to have the wireless module wake
 us
 on multicast packets instead of only unicast.  Are you saying that
 it
 would?
   
   
It seems so, though it would, as John points out, make resumes far
more constant. It seems we have to find a creative way out of this tough
choice (automated suspend vs mesh) or face it.
   
   


Avahi entries will expire after some time. Suspend will
 prevent it
to update its cache.

 Yani's bug report (#6467) suggests that Avahi entries often expire
 immediately upon resume:

   After the XO resumes (probably after beinng suspended for
 several
   minutes) all the icons in the mesh view vanish, except the mesh
   circles.
   
   
I read this as the avahi-cache  expiring its entries.  Yanni  can
you put timeframes on this?
Could check how long does it take to expiry an entry (TO) and then
check if:
Suspend time  TO - all entries vanish
Suspend time  TO - no entries vanish
Supens time ~ TO - some entries vanish
   
  
   There as 2 cases where icons vanish due to suspend.
  
   1st: The moment you resume(it generally happens after long suspends),
   all icons vanish instantly(APs/XOs). This bug (#6467) suggests that sugar
   has a problem with suspend resume.
   The icons slowly reappear. I assume that if the avahi peer list is
   intact that all XOs return.
  
   2nd: The avahi list smtimes looses some or all of the peers at resume.
   This is also under 6467, but it seems technicaly different. One possible
   explanation could be that during suspend th XO resumes several times, but 
   i
   didnt notice it! And within this time frames it realized that the other
   suspended XOs are gone, so it cleared its cache. Now when I resumed it
   myself, I observed that the cache is clean!!
  
   Now, regarding the timeouts of avahi. This is a 3rd thing:
   When an XO leaves the channel we have 4 states:
  mm:ss
   1. 00:00  XO leave the channel(manually/or ti suspended)
   2. 10:00  Avahi notices teh XO left, and reports

Re: Salut and Suspend/Resume issues

On Feb 19, 2008 2:48 PM, Ricardo Carrano [EMAIL PROTECTED] wrote:

 Yanni,

 Timeout is a value, not a range. The effects brought by the timeout may
 manifest in a period (a range).


Did a use it otherwise? Because of the effects of xmas tree, the timeout for
a failed XO until it's icon is removed is 10-30min.


 I believe everyone will agree that 30 minutes is a long time to wait (and
 like Polychronis added) defeat the whole idea of a presence service.

 But, what I want to stress is that we are dealing with different issues
 here.


 I don't believe this 30 minutes or the xmas tree effect is related to
 suspend/resume. Those seem like bugs somewhere in the stack of software that
 support presence, while the suspend/resume issues are clearly a side effect
 of  the multicast traffic not being heard by a suspended XO.


There are way too many issues. Theses bugs (30min/xmas tree) enhance the
effects of suspend/resume on the mesh.
I believe that since we have the big test week coming, everyone must be
aware of them, or else noone will interpret the results properly.

The direct suspend/resume bugs are:

1. Why the mesh view  empties after a long suspend, and how this affects the
mesh view
2. Why some times the avahi cache is cleared after  resume.


Ricardo, do you have anwers to the questions I posted before? :
1. When a XO resumes, does it send any notification via avahi, that it is
back? Because if it doesnt, then other XOs that have cleared it from their
lists, they will never search for it.

2. Every scans the network every 10min, to check whether its avahi peers are
alive, in multicast packets. Do these packets include the address of the
peers/targets? I think they do, unless i am very confused. Couldn't we
awake/resume the target XO when it receives these specific packets?


On Feb 19, 2008 3:00 PM, Giannis Galanis [EMAIL PROTECTED] wrote:

 The list expires in 10min-30min.

 But we cant wait 30min before suspending, it is way too long.


 On Feb 19, 2008 11:37 AM, Ricardo Carrano [EMAIL PROTECTED]
 wrote:

  Yanni,
 
  As I posted in the bug, I believe that you are observing the entries on
  the avahi cache expiring.
 
  So, your first scenario would happen when the suspend time is longer
  than the time it takes for all entries to expire.
  The second scenario would happen when the suspend time is not long
  enough to make all cached entries to go away.


 Oh i see that you mean. But, i think both cases are when the suspend time
 is longer than time to expire.
 The first is UI effect, and might have no relation to salut, but to mesh
 view in general
 The second is an avahi effect, that the avahi cache is chagned
 Both, are in long suspends

 
  And the third scenario seems related to previous reports you've made on
  the Xmas tree effect, so not related to suspend/resume.


 The xmas tree effect appears when XOs leave connection, while others
 return.
 Suspend/resume enhances this effect dramatically, because in 1-2min
 everyone goes away, and they return at random time according to when they
 resume.

 In my suspend-salut tests , the xmas tree effect(although NOT related to
 suspend/resume), it affects salut alot more then the other 2 scenarios

 My point is that we must fix it anyway. But especially now!!


 
  What do you think?


 I have 2 questions that will help (me) understand alot about the
 situation:

 1. When a XO resumes, does it send any notification via avahi, that it is
 back? Because if it doesnt, then other XOs that have cleared it from their
 lists, they will never search for it.

 2. Every scans the network every 10min, to check whether its avahi peers
 are alive, in multicast packets. Do these packets include the address of the
 peers/targets? I think they do, unless i am very confused. Couldn't we
 awake/resume the target XO when it receives these specific packets?

 we need to do some sniffing



 
  On Feb 19, 2008 1:13 PM, Giannis Galanis [EMAIL PROTECTED] wrote:
 
  
  
   On Feb 19, 2008 10:13 AM, Ricardo Carrano [EMAIL PROTECTED]
   wrote:
  
   
I was asking whether it would help to have the wireless module wake
 us
 on multicast packets instead of only unicast.  Are you saying that
 it
 would?
   
   
It seems so, though it would, as John points out, make resumes far
more constant. It seems we have to find a creative way out of this tough
choice (automated suspend vs mesh) or face it.
   
   


Avahi entries will expire after some time. Suspend will
 prevent it
to update its cache.

 Yani's bug report (#6467) suggests that Avahi entries often expire
 immediately upon resume:

   After the XO resumes (probably after beinng suspended for
 several
   minutes) all the icons in the mesh view vanish, except the mesh
   circles.
   
   
I read this as the avahi-cache  expiring its entries.  Yanni  can
you put timeframes on this?
Could check how long does it take to expiry

A modest proposal.

2008-02-19 Thread C. Scott Ananian

I propose installing a handler for a new URI type in our browse
application.  The links will look like:
   friend:name.xxx.school.country.xs.laptop.org
where:
  name is a Punycode encoding of the XO nickname.  Technically, the
IDN ToASCII mapping operation is performed on the nickname, truncated
on the right if necessary so the result is 63 characters or less; see
http://en.wikipedia.org/wiki/Internationalized_domain_name.
  xxx is an encoded version of the the XO public key.  The number is
written in a variable base number system where the first three digits
are base 36, base 37, and base 26 and the digits are mapped into
characters starting with lowercase alphabetic, then numeric, then a
hyphen.  If I've done my math correctly
(http://en.wikipedia.org/wiki/Birthday_paradox ), this requires about
220 students to have the same name before a collision has a 50% chance
of occuring.  If the server uses an independent means to prevent
duplicate nicknames, the xxx can be replaced with 'fun'.
  'school.country.xs.laptop.org' is filled in by registration with a
school server.  If you do not have access to a school server, then you
can register with xofriends.org (or another independent service) and
use that suffix.

Clicking on a link of this form would add this person to your buddy
list.  Communicating with a this form of buddy would, in parallel, (a)
attempt to contact the IPv6 Link-Local address formed from the lower
64 bits of the SHA-256 of the complete friend domain string (not
including the URI scheme or colon) and (b) attempt to look up the
hostname and contact the IPv4 or IPv6 address returned.  (If the DNS
responds, you SHOULD use this address for further communication in
this session, since it may persist even if you roam off your current
mesh.)  A simple service at a well-known port would confirm status and
list sharable activities.

Via a network manager hook, XOs should report their current IPv4/IPv6
addresses to the 'school.country.xs.laptop.org' part of their local
domain name, which will export it via the standard dynamic DNS
mechanisms.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

Yanni,


 Did a use it otherwise? Because of the effects of xmas tree, the timeout
 for a failed XO until it's icon is removed is 10-30min.


I am talking about the time it takes for an avahi entry to expire. For what
you said, is 10 minutes.



 Ricardo, do you have anwers to the questions I posted before? :


Let's see:


 1. When a XO resumes, does it send any notification via avahi, that it is
 back? Because if it doesnt, then other XOs that have cleared it from their
 lists, they will never search for it.


I believe there is no I am back notification different than the normal way
presence information is exchanged by the protocol.



 2. Every scans the network every 10min, to check whether its avahi peers
 are alive, in multicast packets. Do these packets include the address of the
 peers/targets? I think they do, unless i am very confused. Couldn't we
 awake/resume the target XO when it receives these specific packets?


That's the point. Mdns is multicast and the XOs, when suspended, don't
listen to multicast frames.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

On Feb 19, 2008 4:10 PM, Ricardo Carrano [EMAIL PROTECTED] wrote:

 Yanni,

 
  Did a use it otherwise? Because of the effects of xmas tree, the timeout
  for a failed XO until it's icon is removed is 10-30min.
 

 I am talking about the time it takes for an avahi entry to expire. For
 what you said, is 10 minutes.


Oh ok. This is not 10min.

Avahi checks every 10min that its peers are alive.

An active entry will never expire
A failed entry will naturally expire in an additional 20min(30 in total).
BUT, it can expire instantly due to xmas tree bug(5501)




  Ricardo, do you have anwers to the questions I posted before? :
 

 Let's see:


  1. When a XO resumes, does it send any notification via avahi, that it
  is back? Because if it doesnt, then other XOs that have cleared it from
  their lists, they will never search for it.
 

 I believe there is no I am back notification different than the normal
 way presence information is exchanged by the protocol.


If not, then we have a problem. The other XOs will never know it is here, so
they will never search for it. I think the are u alive request is
destination specific.

I will do some sniffing and find out.


 
  2. Every scans the network every 10min, to check whether its avahi peers
  are alive, in multicast packets. Do these packets include the address of the
  peers/targets? I think they do, unless i am very confused. Couldn't we
  awake/resume the target XO when it receives these specific packets?
 

 That's the point. Mdns is multicast and the XOs, when suspended, don't
 listen to multicast frames.


The suspended XO can be setup to wake up by multicast packets. This is
technically possible afaik
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Salut and Suspend/Resume issues

2008-02-19 Thread Michail Bletsas

Yeah, let's drop everything and the kitchen sink on the radio!!

M.





John Watlington [EMAIL PROTECTED] 
02/19/2008 10:10 AM

To
Chris Ball [EMAIL PROTECTED]
cc
John Watlington [EMAIL PROTECTED], Ricardo Carrano 
[EMAIL PROTECTED], OLPC Devel [EMAIL PROTECTED], Michail 
Bletsas [EMAIL PROTECTED]
Subject
Re: Salut and Suspend/Resume issues







The partitioning we made between the network processor and the
main processor was pretty clean.  Unfortunately, it doesn't support
low power operation.   I suggest rethinking the partition for Gen2.

wad

On Feb 19, 2008, at 10:04 AM, Chris Ball wrote:

 Hi Ricardo,

 A mesh will always rely to some degree in multicast/broadcast
 traffic. This is not a bug.

 I was asking whether it would help to have the wireless module wake us
 on multicast packets instead of only unicast.  Are you saying that it
 would?

 Avahi entries will expire after some time. Suspend will prevent it
 to update its cache.

 Yani's bug report (#6467) suggests that Avahi entries often expire
 immediately upon resume:

After the XO resumes (probably after beinng suspended for several
minutes) all the icons in the mesh view vanish, except the mesh
circles.

 Thanks,

 - Chris.
 -- 
 Chris Ball   [EMAIL PROTECTED]
 ___
 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: A modest proposal.

Such a thing would be most excellent, indeed. :)

A similar, but more standards-compliant[1][2] proposal might look more like:
 xmpp:[EMAIL PROTECTED]

Clicking on a link of this form:
 xmpp:[EMAIL PROTECTED]
could add the individual as a friend, or a link like this:
 xmpp:[EMAIL PROTECTED]
might start a conversation with them.

The presence service already registers to an XMPP server on the school
server. If we arrange the DNS reachability for school servers, we can
use the existing XMPP network and server-to-server connections to deal
with sending communications between school servers. We just need to arrange:
 a) global naming of the school servers
 b) discovery of that name by the laptops
 c) adding the name to the generated XMPP ID

There's already a service on each school server which responds on a well
known port (5222, aka xmpp-client) and confirms people's
status/availability, and we're already working on a simple add-on
component to enumerate activities which are reachable via that school
server, it's called Gadget (see http://wiki.laptop.org/go/Gadget).

Key verification of link-locally reachable contacts can be used to
resolve these contacts on the local network too.

Also, no punycode is required. XMPP was drafted after non-ASCII speaking
countries were discovered. :)

Regards,
Rob

1: http://tools.ietf.org/html/rfc4395
2: http://tools.ietf.org/html/rfc4622

C. Scott Ananian wrote:
 I propose installing a handler for a new URI type in our browse
 application.  The links will look like:
friend:name.xxx.school.country.xs.laptop.org
 where:
   name is a Punycode encoding of the XO nickname.  Technically, the
 IDN ToASCII mapping operation is performed on the nickname, truncated
 on the right if necessary so the result is 63 characters or less; see
 http://en.wikipedia.org/wiki/Internationalized_domain_name.
   xxx is an encoded version of the the XO public key.  The number is
 written in a variable base number system where the first three digits
 are base 36, base 37, and base 26 and the digits are mapped into
 characters starting with lowercase alphabetic, then numeric, then a
 hyphen.  If I've done my math correctly
 (http://en.wikipedia.org/wiki/Birthday_paradox ), this requires about
 220 students to have the same name before a collision has a 50% chance
 of occuring.  If the server uses an independent means to prevent
 duplicate nicknames, the xxx can be replaced with 'fun'.
   'school.country.xs.laptop.org' is filled in by registration with a
 school server.  If you do not have access to a school server, then you
 can register with xofriends.org (or another independent service) and
 use that suffix.
 
 Clicking on a link of this form would add this person to your buddy
 list.  Communicating with a this form of buddy would, in parallel, (a)
 attempt to contact the IPv6 Link-Local address formed from the lower
 64 bits of the SHA-256 of the complete friend domain string (not
 including the URI scheme or colon) and (b) attempt to look up the
 hostname and contact the IPv4 or IPv6 address returned.  (If the DNS
 responds, you SHOULD use this address for further communication in
 this session, since it may persist even if you roam off your current
 mesh.)  A simple service at a well-known port would confirm status and
 list sharable activities.
 
 Via a network manager hook, XOs should report their current IPv4/IPv6
 addresses to the 'school.country.xs.laptop.org' part of their local
 domain name, which will export it via the standard dynamic DNS
 mechanisms.
  --scott
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A modest proposal.

Robert McQueen wrote:
 Key verification of link-locally reachable contacts can be used to
 resolve these contacts on the local network too.

Ah, I misread a bit of the OP, deriving local IPv6 addresses from the
contact address is actually a pretty neat tweak. :) It's orthogonal to
the addressing scheme used however, and we probably want to do key
verification when we initiate communications anyway.

Regards,
Rob
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Project hosting application

2008-02-19 Thread Nicolas Escobar J.

1. Project name : Mastergoal
2. Existing website, if any :
3. One-line description : Board strategy game inspired on soccer and chess

4. Longer description   : The mastergoal board represents the
field and the pieces represent the players and the ball. Each
: team have one or more players (depending
on the level) and the objective is to score a goal to the
: opposite team. This project involves the
implementation of the board game including rules, AI,
: multi-player feature, etc.

5. URLs of similar projects : http://www.mastergoal.com

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 name SSH2 key URLE-mail
     - --
   #1 nescobarj  Nicolas Escobar   (below)
[EMAIL PROTECTED]
   #2
   #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
   [X] Set up the laptop.org Pootle server to allow translation
commits to be made
   [ ] Translation arrangements have already been made at ___

12. Notes/comments:

ssh-dss B3NzaC1kc3MAAACBAKA8UeRiQmSK/zavI8oFri1+QKfYM0E01AuYMhVLqHoT
0eBBFNnJKbGdK2SBu4npokPF8P5grDRlJ6cOeMhfG5ABR84emSeLuGhhZGimazgJ
KzM4DLxU5ggxhzjoWU0eYU0l3pBmsLUNxB896ccd59ckPU47tUF3taFoLK9+W2u/
FQCjbbuoXrknW080O0m5NGcgCnQvSwAAAIAbLK5vecX626jiwx0b/42UkJxr
StYohcWiXFes2ujw11k7WbDcvwbCFFF5FiVUY7DLnru4BSgwH3I4TTS4qWN4yA5T
61Ea8cNppnD8UXsAswzU/SJRoxu1O3FtU5+eb/y6R6d4y7AjA/WdgjLuQnAFUhqB
T3v7FnE6NaMkA6UfjQAAAIAzEuIMbVYHAjUgtC+gK047PFyhEnpn6LG6+o1khxpZ
NOj2HvGy15WQSrHBD/ZCxrFoOEK/EiL4l681kFYHOk2nqRdnUZyEm83HXVBSnWKi
9v5IDh2HRH9wTS1RDyqLNJefhJj1pW9fC974bL5OFQO+LD7pzrIig0GtVrBXNFV2
dg==



-- 
Nicolás.-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

git admin, where are you? (was Re: Read ETexts Activity Text To Speech)

2008-02-19 Thread Edward Cherlin

On Feb 19, 2008 7:55 AM, James Simmons [EMAIL PROTECTED] wrote:
 Edward,

 I've looked at Hemant Goyal's pages on speech synthesis and it looks to
 be a great deal easier than I expected.  The karaoke highlighting looks
 doable too.  While my first priority will be getting my Activity to have
 all of the features that Read has, once I've done that I'd like to try
 adding this new feature.

All excellent news.

 The issue that I'll have with this is making
 it degrade gracefully.  Since text to speech looks like it will be
 shipped with the OS, I have to figure out a way to make this feature
 only be visible on laptops that can support it.

That sounds like a 'not' fell out somewhere. I vote for having TTS
included on every laptop.

 Maybe an extra toolbox
 tab.  I'd also have to figure out a way to test it.  I use xubuntu with
 the Sugar emulator for testing, so somehow I'd have to get Hemant's
 packages on there, probably compiling from source.

I'm sure somebody here can help.

 I submitted the form to this list to get a git repository, etc.  I
 haven't heard from anyone on that since.

Yo! Anybody home?

 I didn't expect instant turnaround on this,

*I* expect instant acknowledgment of applications. At least an
autoreply message saying how long it should take, how you will be
notified when your directory is ready for submissions, and whom to
ping if it isn't happening. I have some applications in preparation.
If I don't get satisfaction when I submit them, and I don't know whom
to ping individually, I will bother lots of people about it. At a
minimum, this entire list, as I am in fact now doing.

Why isn't management on top of these issues?

 and there is definitely no rush, but I am wondering
 what to expect.  I'd like to have my projects hosted on the OLPC
 servers, where I feel they would be most visible.  On the other hand I
 already have a project on SourceForge and it would  be simple enough to
 set up another one.

 James Simmons


 Edward Cherlin wrote:

 Will it include Text-to-Speech, for the purposes we have discussed on
 this list? If so, could we get some sort of cursor or coloring effect
 to show the illiterate or semi-literate where they are in the text?
 
 
 






-- 
Edward Cherlin
End Poverty at a Profit by teaching children business
http://www.EarthTreasury.org/
The best way to predict the future is to invent it.--Alan Kay
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Audio device capture settings at start in Kernel

2008-02-19 Thread Arjun Sarwal

Currently, when the audio capture device is opened, the kernel applies
these settings
1. The  DC mode enable setting is disabled
2. The bias voltage is enabled

Both are settings that allow the built in mic to get enabled properly.


The rationale of applying these settings is that if Activities quit
prematurely without properly closing the capture device,another
Activity that uses this device, mustn't need to do anything special to
get a default recording stream from the mic.



The flip-side of  applying these settings is that using an alsa
interface, say such as pyalsaaudio to acquire  a specified certain
number of samples makes it impossible to get these samples at anything
but the default settings. This is because when the specified call to
get samples opens the capture device, the kernel overrides with the
default settings (outlined in point 1 and 2 in the beginning of this
email)


My suggestion -- apply default settings only at close of capture
device and not while opening it


Given the current settings, I am out of ideas of how to write code
that allows one to, at-will request for _a_ sample from the ADC at a
specified set of capture settings and get it. Any suggestions ?








-- 
Arjun Sarwal
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An Update about Speech Synthesis

2008-02-19 Thread Samuel Klein

Hemant and James,

Can you write something about this at a [[spoken texts]] page on the
wiki ('hear and read'? some other more creative name... )? The
Google Literacy Project is highlighting a number of literacy efforts
for the upcoming World Book Day, and your work would be fine
suggestions for that list.

On Feb 19, 2008 1:13 PM, Hemant Goyal [EMAIL PROTECTED] wrote:

Hi,

An API that provided configuration control on a per-client basis.
a feature like printf() but for speech for developers to call, and thats
precisely how Free(b)soft described their approach to speech-dispatcher.
Python Interface for speech-synthesis
Callbacks for developers after certain events.
At this moment I am in a position to comment about the following:

WRT which modules to use -I found it extremely easy to configure
speech-dispatcher to use eSpeak as a TTS engine. There are configuration
files available to simply select/unselect which TTS module needs to be used.
I have described how an older version of speech-dispatcher can be made to
run on the XO here
http://wiki.laptop.org/go/Screen_Reader#Installing_speech-dispatcher_on_the_xo

There were major issues of using eSpeak with the ALSA Sound system some time
back [http://dev.laptop.org/ticket/5769, http://dev.laptop.org/ticket/4002].
This issue is resolved by using speech-dispatcher as it supports ALSA, and
OSS. So in case OLPC ever shifts to OSS we are safe. I am guessing
speech-dispatcher does not directly let a TTS engine write to a sound device
but instead accepts the audio buffer and then routes it to the Audio Sub
System.

Another major issue we had to tackle was providing callbacks while providing
the DBUS interface. The present implementation of speech-dispatcher provides
callbacks for various events that are important wrt speech-synthesis. I have
tested these out in python and they were working quite nicely. In case you
have not, you might be interested in checking out their Python API
[http://cvs.freebsoft.org/repository/speechd/src/python/speechd/client.py?hideattic=0view=markup].
Voice Configuration and language selection - The API provides us options to
control voice parameters such as pitch, volume, voice etc for each client.
Message Priorities and Queuing - speech-dispatcher has provided various
levels of priority for speech synthesis, so we cand place a Higher Priority
to a message played by Sugar as compared to an Activity.

Compatibility with orca - I installed orca and used speech-dispatcher as the
speech synth engine. It worked fine. We wanted to make sure that the speech
synth server would work with orca if it was ported to XO in the future.
Documentation - speech-dispatcher has a lot of documentation at the moment,
and hence its quite easy to find our way and figure out how to do things we
really want to. I had intended to explore gnome-speech as well, however the
lack of documentation and examples turned me away.
The analysis that I did was mostly from a user point of view or simple
developer requirements that we realized had to be fulfilled wrt
speech-synthesis, and it was definitely not as detailed as you probably
might expect from me.

We are presently using speech-dispatcher 0.6.6

Re: git admin, where are you? (was Re: Read ETexts Activity Text To Speech)

2008-02-19 Thread Samuel Klein

 On Feb 19, 2008 7:55 AM, James Simmons [EMAIL PROTECTED] wrote:

  The issue that I'll have with this is making
  it degrade gracefully.  Since text to speech looks like it will be
  shipped with the OS, I have to figure out a way to make this feature
  only be visible on laptops that can support it.

 That sounds like a 'not' fell out somewhere. I vote for having TTS
 included on every laptop.

That is the idea.  The basic functionality is already in the builds.

SJ
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A modest proposal.

C. Scott Ananian wrote:
 On Feb 19, 2008 5:47 PM, Robert McQueen [EMAIL PROTECTED] wrote:
 A similar, but more standards-compliant[1][2] proposal might look more like:
  xmpp:[EMAIL PROTECTED]
 
 The key part of my original proposal is that it also works in the
 (possibly temporary) absence of a school school or of network
 connectivity to the broader internet.  It can use DNS or mDNS if
 available, again without requiring connectivity to the broader
 internet or to the original schoolserver.

Indeed, but if you're able to make a mapping between the server-derived
identities and the link-local identities, this goal can still be served.
Currently we use the buddy key as this unifying key, but I very much
like the idea of providing extra information to open up the prospect of
communicating between schools, and allowing the XOs to exist in the
global XMPP namespace.

 Michael Stone suggested that the 'clever' part of the proposal, where
 the domain name is directly mapped to a link local IPv6 address, could
 actually be performed by a local DNS relay server on the XO.  So, an
 alternative might be something like:
xmpp:[EMAIL PROTECTED]
 It shouldn't be necessary to contact a server to collaborate directly
 with a peer.

Correct, but the problem here is that makes the addressing essentially
incompatible with re-using the existing (and globally-compatible)
namespace. In general, people don't run one XMPP server each. The odd
part seems to be that DNS must be involved. You don't need to mangle
things via DNS in order to allow a higher-level component to interpret
them and be able to make a mapping between identifiers (however they're
derived) and local IPv6 addresses.

   --scott

Regards,
Rob
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A modest proposal.

2008-02-19 Thread C. Scott Ananian

On Feb 19, 2008 7:57 PM, Robert McQueen [EMAIL PROTECTED] wrote:
 C. Scott Ananian wrote:
 Currently we use the buddy key as this unifying key, but I very much
 like the idea of providing extra information to open up the prospect of
 communicating between schools, and allowing the XOs to exist in the
 global XMPP namespace.

Ok, what extra information are you suggesting?  I really have no clue
what your phrase global XMPP namespace is supposed to mean.  Don't
you mean global DNS namespace, as the bits to the left of the @ sign
are supposed to be resolvable via DNS, no?  XMPP doesn't have any part
in that resolution.

 Correct, but the problem here is that makes the addressing essentially
 incompatible with re-using the existing (and globally-compatible)
 namespace.

Again, I have no idea what you're getting at here.

 In general, people don't run one XMPP server each.

Is your contention that people should run *less* than one XMPP server
each (which I strenuously disagree with), or that they typically run
*more* than one XMPP server each (and that's what the 'resource' part
of a JID is supposed to be for)?

 The odd part seems to be that DNS must be involved.

How is this odd?  DNS is the second-oldest part of the internet.

 You don't need to mangle
 things via DNS in order to allow a higher-level component to interpret
 them and be able to make a mapping between identifiers (however they're
 derived) and local IPv6 addresses.

The key point is that *no other server need be involved*.  I also
prefer to avoid mDNS as much as possible, for reasons of scalability.
And I've presented an existence proof that this can be done.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A modest proposal.