Re: WDS problems observed in today's testing

[Javier Cardona]

John,

On 3/1/08, John Watlington <[EMAIL PROTECTED]> wrote:
>
>  I was told that 17 laptops were associated on Friday, w. lots of
>  bandwidth left over.
>
>  Question 1:  What is "lots of bandwidth" ?   CSMC networks don't work
>  well past around 50 - 60% of available bandwidth...

What I recall is 50% duty cycle and a channel grade of 22/100.  The
channel grade takes into account not only the duty cycle but also the
noise floor.
I did not re-check those numbers after turning the AP off, but there
was a drastic improvement of the channel energy profile.

The limit of concurrent users for a low-end AP like the WRT54G is ~30.
 But in the capture we see that the AP is wasting most of its time
transmitting WDS frames at low rates.  That is very likely to be the
reason why we could not get more than 17 laptops associated.

>  Question 2:  Did this bandwidth measurement include the relayed WDS
>  frames ?

Yes it did:  the WDS frames were in the same channel.

Javier

>  On Mar 1, 2008, at 2:17 PM, Kim Quirk wrote:
>
>  > Was anyone able to get a test with a different AP?  We were only able
>  > to associate something like 20 laptops on Fri. Do we believe it should
>  > be 30 or more?
>  >
>  > Kim
>  >
>  >
>  >
>  >
>  > On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
>  >> Kim, Michail,
>  >>
>  >> The conclusion to all of this is that we should not use WRT54G in
>  >> deployments, regardless of whether mesh is used or not (in fact,
>  >> if we
>  >> *only* use mesh we don't have this problem as the AP ignores mesh
>  >> multicast traffic now).  The WRT54G will forward multicast traffic to
>  >> all other APs in the vicinity that it identifies as peers using
>  >> flawed
>  >> criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
>  >> traffic, that creates a risk of triggering the multicast storms that
>  >> we saw at OLPC.
>  >>
>  >> Javier
>  >>
>  >> PS. If we have no choice but to use that AP, then we should re-image
>  >> the AP with a distribution that allows turning WDS off.  In Tomato
>  >> (http://www.polarcloud.com/tomato) this can be achieved via Basic ->
>  >> Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'
>  >>
>  >>
>  >> On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
>  >>> Ricardo,
>  >>>
>  >>>
>   - The access point Javier mentions is the one I bought yesterday
>  >> (Linksys
>   WRT54G)
>  >>>
>  >>>
>  >>> Agreed, yes:
>  >>>  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
>  >>>
>  >>>
>   - Most of this traffic is retransmission (3606):
>   (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
>  >> ce:6e) &&
>   (wlan.fc.retry == 1)
>  >>>
>  >>>
>  >>> Agreed.
>  >>>
>  >>>
>   - It is also interesting to detect other wds peers this AP
>   identified
>  >> (one
>   is 00:0b:85:53:27:50 and got 1066 of these frames).
>   ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
>  >> ce:6e))
>   && (wlan.ra == 00:0b:85:53:27:50)
>  >>>
>  >>>
>  >>> Yes.  Note that none of the WDS peers are xo's, as was the case
>  >>> in the
>  >> past.
>  >>>
>  >>>
>   It seems that the linksys is expecting acks for this wds frames
>   (which
>  >> btw are mulcast frames). It is amazing.
>  >>>
>  >>>
>  >>> Well, even if the final destination is a multicast address, those
>  >>> WDS
>  >>>  frames are unicast, and therefore acknowledged.  What's
>  >>> troubling is
>  >>>  that the WDS links are not torn down when the link quality is so
>  >>> poor.
>  >>>   But we all know that Lazy-WDS is a flawed protocol.
>  >>>
>  >>>
>   I believe we should compare this with the previous capture from the
>   Netgear AP, just to confirm that this is (again) specific to WDS
>   issues
>   on the Linksys.
>  >>>
>  >>>
>  >>> I don't have access to that capture.  Maybe David?
>  >>>
>  >>>  Javier
>  >>>
>  >>>
>  >>>
>   On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]>
>  >> wrote:
>  
>  > Michail, Chris,
>  >
>  >
>  > This afternoon I captured some traffic while Chris was running
>  > tests
>  > for Peru.  The test setup consisted on ~25 laptops associated to a
>  > WRT54 access point.  When the laptops were on, associated and (not
>  > sure about this) idle, we observed a high volume of wireless
>  > traffic.
>  > The spectrum analyzer showed close to 50% duty cycle
>  > utilization of
>  > the channel.
>  > We also observed that a few xo's could not associate, and some
>  > seemed
>  >> to
>  > intermittently lose and recover association.
>  >
>  > Turning off the WRT54 (and therefore stopping all the infra
>  > traffic)
>  > freed up most of the bandwidth on that channel.
>  >
>  > In my 50 second capture (taken before turning off the AP) we
>  > observe:
>  >
>  > Total traffic:  15081 frames (100%)
>  > All WDS traffic (1): 

Re: storing Activity parameters

[Joshua Minor]

I implemented the save/load feature of Speak without fully  
understanding the other options.  Now that I've seen the recent  
discussion about data vs instance vs the journal I think it would make  
more sense to have Speak save its state in a different way.

On the other hand, the new frame redesign makes it much easier to  
resume an Activity, which would mean that parameters saved to the  
Journal, like Speak does now, would naturally be restored when you  
resume the Activity.

A nice "best practices" document would be very handy.

-josh

On Mar 1, 2008, at 11:23 AM, Mikus Grinbergs wrote:

> There has been discussion of the use of the Journal, versus other
> places, to store information associated with an Activity.
>
> What I've noticed is that some Activities are now storing their
> parameters in the Journal.  For instance, I prefer to change the
> shape of the eyes in 'Speak'.  If I launch 'Speak' from the menu
> frame, it shows the "default" eye shape.  If I launch 'Speak' from
> the Journal, it shows the eye shape I specified earlier.
>
> Personally, I would prefer having Activities store user-specified
> overrides someplace other than in the Journal.  Then when a new
> 'instance' of the Activity gets invoked, it can come up looking the
> way the user likes it, not just with its "built-in" appearance.
>
> mikus
>
> ___
> 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

OLPC News (2008-03-01)

[Walter Bender]

1. Learning learning: Darah Tappitake and David Cavallo are preparing
for March Learning Workshop with confirmed participations from
Thailand, Mali, and the Committee for Democracy in Information
Technology.

2. Lima: The Peru deployment continues to progress. 40K laptops
arrived in Lima this week and are being sorted by distribution
district and school in anticipation of delivery and activation. Ivan
Krstić and Scott Ananain have been working with Hernán Pachas
Magallanes on a mechanism to map CSV files into activation leases that
will be useful across all of our deployments.

The first tranch of training in Peru begins on Monday. The 143
representatives from the regional distribution centers (UGELs) and 20
ministry of education personnel will attend a 5-day workshop on all
aspects of the XO laptop, school server, and the learning models. John
Watlington and Walter Bender are heading to Lima to help with final
preparations over the weekend. In the following weeks, teachers and
university students will also be attending workshops throughout the
country.

3. Assessment: David Cavallo, Edith Ackermann of the learning team,
and Tony Earls and Maya Carlson of the Harvard School of Public Health
are developing a new framework for assessment that goes beyond typical
school approaches to enable accurate sensing of the overall mission of
OLPC. In particular, the framework will enable a more scientific
evaluation of the whole child and the community. The framework will
also permit a more contextualized view as conditions and goals will
vary from site to site (e.g. from Haiti to Uruguay to rural Peru to
Afghanistan). Haiti will serve as the first instance for applying the
framework.

4. Ceibal: Plans are moving forward for an OLPC/Ceibal children's
festival in Uruguay in March. The festival will not only provide an
environment for children to explore construction and collaboration on
the laptop, but also a means for team development in Uruguay. We
expect many guests from other countries to visit for both the festival
and to visit the initial school in Vila Cardal.

5. Sugar: The Sugar team has posted some new designs for the Home
view, Journal, and Frame (See http://wiki.laptop.org/go/Design). The
gist of the proposed changes is to swap the roles of the Frame and
Home view in regard to activities: they'll be launched from the Home
view and active activities will be carried from view to view on the
Frame. The intention is to make it easier to issue invitation and
notifications and manage the growing number of activities in our
builds (Peru will have more than 30 activities loaded on the laptop by
default).

6. Wikireaders: A dozen different development projects related to
wikireaders are now signed up to our new [EMAIL PROTECTED] mailing
list, to work out how to coordinate Google Gears, pyxpcom, and
existing python and php codebases to generate and browse readers. An
old "static content" project on Wikipedia is being revived around the
same themes.

7. Phil Carrizzi, a professor at the Kendall College of Art in Grand
Rapids has created an XO viewfinder on his FDM machine (See
http://www.flickr.com/photos/curiouslee/2225021496/in/set-72157603547309133/).

8. Help wanted: There have been several requests for "typing tutor"
software on the XO coming from the various pilots. If anyone is
interested in breathing some life into the Typing Tutor Activity,
please contact the devel list.

9. Support: Adam Holt reports that discussions are under way regarding
setting up repair centers with Moraine Valley Community College (we
gave them 12 broken XO laptops towards prototyping a repair center)
and IMSA.edu.

Darah Tappitake discussed the long-term challenges of volunteerism at
last Sunday's support volunteers meeting.

Adam worked with Sandy Culver and Brightstar on shipping out
outstanding RMA machines and Fedex "undeliverables"; and he worked
with Alan Claver who's resolving dozens of escalated support tickets
daily.

10. Meshing: This week we held a tech meeting in Cambridge to work on
issues of scaling our collaboration technology. In attendance were
OLPC staff, Dave Woodhouse and Marco Presenti-Gritti of Red Hat,
Dafydd Harries and Guillaume Desmottes of Collabora, and Javier
Cardona of Cozybit. Several new bugs were identified and
characterized; some short-term fixes were adopted; testing of the
fixes was started. The longer-term strategy for achieving more scaling
was discussed extensively. The actual characterization of the result
awaits testing in a quieter network environment—there are over 100
access points that can be detected from the OLPC office, one ofthe
most severe network environments anyone has ssen.

11. Custom builds: Scott Anaian and Michael Stone worked with Daniel
Grajales Santana of Telmex and Hernán of the Ministry of Education in
Peru on developing a customization key (See
http://wiki.laptop.org/go/Customization_key ) to create builds for
Mexico and Peru.

12. FOSDEM: Simon Schampijer,

Re: WDS problems observed in today's testing

[John Watlington]

I was told that 17 laptops were associated on Friday, w. lots of  
bandwidth
left over.

Question 1:  What is "lots of bandwidth" ?   CSMC networks don't work  
well
past around 50 - 60% of available bandwidth...

Question 2:  Did this bandwidth measurement include the relayed WDS  
frames ?

wad

On Mar 1, 2008, at 2:17 PM, Kim Quirk wrote:

> Was anyone able to get a test with a different AP?  We were only able
> to associate something like 20 laptops on Fri. Do we believe it should
> be 30 or more?
>
> Kim
>
>
>
>
> On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
>> Kim, Michail,
>>
>> The conclusion to all of this is that we should not use WRT54G in
>> deployments, regardless of whether mesh is used or not (in fact,  
>> if we
>> *only* use mesh we don't have this problem as the AP ignores mesh
>> multicast traffic now).  The WRT54G will forward multicast traffic to
>> all other APs in the vicinity that it identifies as peers using  
>> flawed
>> criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
>> traffic, that creates a risk of triggering the multicast storms that
>> we saw at OLPC.
>>
>> Javier
>>
>> PS. If we have no choice but to use that AP, then we should re-image
>> the AP with a distribution that allows turning WDS off.  In Tomato
>> (http://www.polarcloud.com/tomato) this can be achieved via Basic ->
>> Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'
>>
>>
>> On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
>>> Ricardo,
>>>
>>>
 - The access point Javier mentions is the one I bought yesterday
>> (Linksys
 WRT54G)
>>>
>>>
>>> Agreed, yes:
>>>  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
>>>
>>>
 - Most of this traffic is retransmission (3606):
 (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
>> ce:6e) &&
 (wlan.fc.retry == 1)
>>>
>>>
>>> Agreed.
>>>
>>>
 - It is also interesting to detect other wds peers this AP  
 identified
>> (one
 is 00:0b:85:53:27:50 and got 1066 of these frames).
 ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
>> ce:6e))
 && (wlan.ra == 00:0b:85:53:27:50)
>>>
>>>
>>> Yes.  Note that none of the WDS peers are xo's, as was the case  
>>> in the
>> past.
>>>
>>>
 It seems that the linksys is expecting acks for this wds frames  
 (which
>> btw are mulcast frames). It is amazing.
>>>
>>>
>>> Well, even if the final destination is a multicast address, those  
>>> WDS
>>>  frames are unicast, and therefore acknowledged.  What's  
>>> troubling is
>>>  that the WDS links are not torn down when the link quality is so  
>>> poor.
>>>   But we all know that Lazy-WDS is a flawed protocol.
>>>
>>>
 I believe we should compare this with the previous capture from the
 Netgear AP, just to confirm that this is (again) specific to WDS  
 issues
 on the Linksys.
>>>
>>>
>>> I don't have access to that capture.  Maybe David?
>>>
>>>  Javier
>>>
>>>
>>>
 On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]>
>> wrote:

> Michail, Chris,
>
>
> This afternoon I captured some traffic while Chris was running  
> tests
> for Peru.  The test setup consisted on ~25 laptops associated to a
> WRT54 access point.  When the laptops were on, associated and (not
> sure about this) idle, we observed a high volume of wireless  
> traffic.
> The spectrum analyzer showed close to 50% duty cycle  
> utilization of
> the channel.
> We also observed that a few xo's could not associate, and some  
> seemed
>> to
> intermittently lose and recover association.
>
> Turning off the WRT54 (and therefore stopping all the infra  
> traffic)
> freed up most of the bandwidth on that channel.
>
> In my 50 second capture (taken before turning off the AP) we  
> observe:
>
> Total traffic:  15081 frames (100%)
> All WDS traffic (1): 6023 frames ( 40%)
> WDS, xo is source addr (2):  4343 frames ( 29%)
>  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single
>> AP(4))
>
> Compare that with
>
> xo originated infra frames (5):   401 frames ( 3%)
>  (77% of the above xmitted at rates higher than 2 Mbps (6))
>
> What does all this mean?
>
> 1. Multicast traffic gets replicated and retransmitted.
> 2. The ratio of original frames to AP generated multicast
> retransmissions is 1:11
> 3. Taking into account the data rates this means that for 1  
> airtime
> unit used to transmit useful traffic, over 200 units are wasted
> transmitting useless WDS traffic.
> 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
>
> Michail, is that one of OLPC APs?
> Chris, we should see a big improvement if we can disable that
> "feature" on the AP... or put it under water.
>
> I've posted my capture here:
>

>> http://dev

Re: Read Activity slowness

[karl]

Bert Freudenberg wrote:
> On Mar 1, 2008, at 21:16 , karl wrote:
>
>   
>> I found extreme slowness issues with the Read activity on this  
>> document:
>> http://vpri.org/pdf/steps_TR-2007-008.pdf
>> The document will render but it is 'prohibitively slow' as one  
>> commenter
>> put it.
>>
>> Another commenter mentioned this bug report about evince:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=183397
>> 
>
> I filed this as a bug:
>
> http://dev.laptop.org/ticket/6623
>
> - Bert -
A little more reading turned up this
https://bugzilla.redhat.com/show_bug.cgi?id=201542
And it seems to be resolved on Fedora 6 with updates to evince and 
poppler according to comments.

Karl


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

Re: WDS problems observed in today's testing

[John Watlington]

Yeah, but unfortunately, we (me and Ricardo) couldn't get DD-WRT to  
work on the WRT-54Gs
on Thursday.   It installed fine, but configuring it to just be a  
bridged access point (and not
a gateway) wasn't happening.It is going to be a problem in the  
field asking "lightly trained"
users to upgrade and configure their access points.

wad

On Mar 1, 2008, at 2:22 PM, Michail Bletsas wrote:

>
> I have associated and run successfully web and collaboration  
> sessions between groups of 5 machines with 40 XOs on a WRT54GS  
> running DD-WRT
>
>
> M.
>
>
>
>
> "Kim Quirk" <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 03/01/2008 02:20 PM
>
> To
> "Javier Cardona" <[EMAIL PROTECTED]>, "Kim Quirk"  
> <[EMAIL PROTECTED]>, "Michail Bletsas" <[EMAIL PROTECTED]>, "Chris  
> Ball" <[EMAIL PROTECTED]>, "OLPC Developer's List" <[EMAIL PROTECTED]>,  
> "Jim Gettys" <[EMAIL PROTECTED]>, "Ricardo Carrano"  
> <[EMAIL PROTECTED]>
> cc
> Subject
> Re: WDS problems observed in today's testing
>
>
>
>
>
> Was anyone able to get a test with a different AP?  We were only able
> to associate something like 20 laptops on Fri. Do we believe it should
> be 30 or more?
>
> Kim
>
>
>
>
> On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
> > Kim, Michail,
> >
> > The conclusion to all of this is that we should not use WRT54G in
> > deployments, regardless of whether mesh is used or not (in fact,  
> if we
> > *only* use mesh we don't have this problem as the AP ignores mesh
> > multicast traffic now).  The WRT54G will forward multicast  
> traffic to
> > all other APs in the vicinity that it identifies as peers using  
> flawed
> > criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
> > traffic, that creates a risk of triggering the multicast storms that
> > we saw at OLPC.
> >
> > Javier
> >
> > PS. If we have no choice but to use that AP, then we should re-image
> > the AP with a distribution that allows turning WDS off.  In Tomato
> > (http://www.polarcloud.com/tomato) this can be achieved via Basic ->
> > Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'
> >
> >
> > On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
> > > Ricardo,
> > >
> > >
> > >  > - The access point Javier mentions is the one I bought  
> yesterday
> > (Linksys
> > >  > WRT54G)
> > >
> > >
> > > Agreed, yes:
> > >  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
> > >
> > >
> > >  > - Most of this traffic is retransmission (3606):
> > >  > (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta 
> [4-5] ==
> > ce:6e) &&
> > >  > (wlan.fc.retry == 1)
> > >
> > >
> > > Agreed.
> > >
> > >
> > >  > - It is also interesting to detect other wds peers this AP  
> identified
> > (one
> > >  > is 00:0b:85:53:27:50 and got 1066 of these frames).
> > >  > ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta 
> [4-5] ==
> > ce:6e))
> > >  > && (wlan.ra == 00:0b:85:53:27:50)
> > >
> > >
> > > Yes.  Note that none of the WDS peers are xo's, as was the case  
> in the
> > past.
> > >
> > >
> > >  > It seems that the linksys is expecting acks for this wds  
> frames (which
> > btw are mulcast frames). It is amazing.
> > >
> > >
> > > Well, even if the final destination is a multicast address,  
> those WDS
> > >  frames are unicast, and therefore acknowledged.  What's  
> troubling is
> > >  that the WDS links are not torn down when the link quality is  
> so poor.
> > >   But we all know that Lazy-WDS is a flawed protocol.
> > >
> > >
> > >  > I believe we should compare this with the previous capture  
> from the
> > >  > Netgear AP, just to confirm that this is (again) specific to  
> WDS issues
> > >  > on the Linksys.
> > >
> > >
> > > I don't have access to that capture.  Maybe David?
> > >
> > >  Javier
> > >
> > >
> > >
> > >  > On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona  
> <[EMAIL PROTECTED]>
> > wrote:
> > >  >
> > >  > > Michail, Chris,
> > >  > >
> > >  > >
> > >  > > This afternoon I captured some traffic while Chris was  
> running tests
> > >  > > for Peru.  The test setup consisted on ~25 laptops  
> associated to a
> > >  > > WRT54 access point.  When the laptops were on, associated  
> and (not
> > >  > > sure about this) idle, we observed a high volume of  
> wireless traffic.
> > >  > > The spectrum analyzer showed close to 50% duty cycle  
> utilization of
> > >  > > the channel.
> > >  > > We also observed that a few xo's could not associate, and  
> some seemed
> > to
> > >  > > intermittently lose and recover association.
> > >  > >
> > >  > > Turning off the WRT54 (and therefore stopping all the  
> infra traffic)
> > >  > > freed up most of the bandwidth on that channel.
> > >  > >
> > >  > > In my 50 second capture (taken before turning off the AP)  
> we observe:
> > >  > >
> > >  > > Total traffic:  15081 frames (100%)
> > >  > > All WDS traffic (1): 6023 frames ( 40%)
> > >  > > WDS, xo is source addr (2):  4343 frames ( 29%)
> > >  > >  (96% of the

Re: Read Activity slowness

[Bert Freudenberg]

On Mar 1, 2008, at 21:16 , karl wrote:

> I found extreme slowness issues with the Read activity on this  
> document:
> http://vpri.org/pdf/steps_TR-2007-008.pdf
> The document will render but it is 'prohibitively slow' as one  
> commenter
> put it.
>
> Another commenter mentioned this bug report about evince:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=183397

I filed this as a bug:

http://dev.laptop.org/ticket/6623

- Bert -


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

storing Activity parameters

[Mikus Grinbergs]

There has been discussion of the use of the Journal, versus other 
places, to store information associated with an Activity.

What I've noticed is that some Activities are now storing their 
parameters in the Journal.  For instance, I prefer to change the 
shape of the eyes in 'Speak'.  If I launch 'Speak' from the menu 
frame, it shows the "default" eye shape.  If I launch 'Speak' from 
the Journal, it shows the eye shape I specified earlier.

Personally, I would prefer having Activities store user-specified 
overrides someplace other than in the Journal.  Then when a new 
'instance' of the Activity gets invoked, it can come up looking the 
way the user likes it, not just with its "built-in" appearance.

mikus

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

Read Activity slowness

[karl]

I found extreme slowness issues with the Read activity on this document:
http://vpri.org/pdf/steps_TR-2007-008.pdf
The document will render but it is 'prohibitively slow' as one commenter 
put it.

Another commenter mentioned this bug report about evince:

https://bugzilla.redhat.com/show_bug.cgi?id=183397


Karl


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

Re: WDS problems observed in today's testing

[Sameer Verma]

Javier Cardona wrote:
> Kim, Michail,
>
> The conclusion to all of this is that we should not use WRT54G in
> deployments, regardless of whether mesh is used or not (in fact, if we
> *only* use mesh we don't have this problem as the AP ignores mesh
> multicast traffic now).  The WRT54G will forward multicast traffic to
> all other APs in the vicinity that it identifies as peers using flawed
> criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
> traffic, that creates a risk of triggering the multicast storms that
> we saw at OLPC.
>
> Javier
>
> PS. If we have no choice but to use that AP, then we should re-image
> the AP with a distribution that allows turning WDS off.  In Tomato
> (http://www.polarcloud.com/tomato) this can be achieved via Basic ->
> Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'
>
>   
dd-wrt (http://www.dd-wrt.com/) has a tab for Wireless -> WDS which 
allows you to disable lazy WDS.

Sameer
> On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
>   
>> Ricardo,
>>
>>
>>  > - The access point Javier mentions is the one I bought yesterday (Linksys
>>  > WRT54G)
>>
>>
>> Agreed, yes:
>>  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
>>
>>
>>  > - Most of this traffic is retransmission (3606):
>>  > (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e) 
>> &&
>>  > (wlan.fc.retry == 1)
>>
>>
>> Agreed.
>>
>>
>>  > - It is also interesting to detect other wds peers this AP identified (one
>>  > is 00:0b:85:53:27:50 and got 1066 of these frames).
>>  > ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e))
>>  > && (wlan.ra == 00:0b:85:53:27:50)
>>
>>
>> Yes.  Note that none of the WDS peers are xo's, as was the case in the past.
>>
>>
>>  > It seems that the linksys is expecting acks for this wds frames (which 
>> btw are mulcast frames). It is amazing.
>>
>>
>> Well, even if the final destination is a multicast address, those WDS
>>  frames are unicast, and therefore acknowledged.  What's troubling is
>>  that the WDS links are not torn down when the link quality is so poor.
>>   But we all know that Lazy-WDS is a flawed protocol.
>>
>>
>>  > I believe we should compare this with the previous capture from the
>>  > Netgear AP, just to confirm that this is (again) specific to WDS issues
>>  > on the Linksys.
>>
>>
>> I don't have access to that capture.  Maybe David?
>>
>>  Javier
>>
>>
>>
>>  > On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]> wrote:
>>  >
>>  > > Michail, Chris,
>>  > >
>>  > >
>>  > > This afternoon I captured some traffic while Chris was running tests
>>  > > for Peru.  The test setup consisted on ~25 laptops associated to a
>>  > > WRT54 access point.  When the laptops were on, associated and (not
>>  > > sure about this) idle, we observed a high volume of wireless traffic.
>>  > > The spectrum analyzer showed close to 50% duty cycle utilization of
>>  > > the channel.
>>  > > We also observed that a few xo's could not associate, and some seemed to
>>  > > intermittently lose and recover association.
>>  > >
>>  > > Turning off the WRT54 (and therefore stopping all the infra traffic)
>>  > > freed up most of the bandwidth on that channel.
>>  > >
>>  > > In my 50 second capture (taken before turning off the AP) we observe:
>>  > >
>>  > > Total traffic:  15081 frames (100%)
>>  > > All WDS traffic (1): 6023 frames ( 40%)
>>  > > WDS, xo is source addr (2):  4343 frames ( 29%)
>>  > >  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single 
>> AP(4))
>>  > >
>>  > > Compare that with
>>  > >
>>  > > xo originated infra frames (5):   401 frames ( 3%)
>>  > >  (77% of the above xmitted at rates higher than 2 Mbps (6))
>>  > >
>>  > > What does all this mean?
>>  > >
>>  > > 1. Multicast traffic gets replicated and retransmitted.
>>  > > 2. The ratio of original frames to AP generated multicast
>>  > > retransmissions is 1:11
>>  > > 3. Taking into account the data rates this means that for 1 airtime
>>  > > unit used to transmit useful traffic, over 200 units are wasted
>>  > > transmitting useless WDS traffic.
>>  > > 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
>>  > >
>>  > > Michail, is that one of OLPC APs?
>>  > > Chris, we should see a big improvement if we can disable that
>>  > > "feature" on the AP... or put it under water.
>>  > >
>>  > > I've posted my capture here:
>>  > >
>>  > 
>> http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap
>>  > >  in case someone wants to double check my analysis (Ricardo?).
>>  > >
>>  > > Cheers,
>>  > >
>>  > > Javier
>>  > >
>>  > > (1) wlan.fc.ds == 3
>>  > > (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
>>  > > (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate 
>> ==
>>  > 0x2
>>  > > (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == 
>> ce:6e
>>  > > (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C

Re: WDS problems observed in today's testing

[Michail Bletsas]

I have associated and run successfully web and collaboration sessions 
between groups of 5 machines with 40 XOs on a WRT54GS running DD-WRT


M.





"Kim Quirk" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
03/01/2008 02:20 PM

To
"Javier Cardona" <[EMAIL PROTECTED]>, "Kim Quirk" <[EMAIL PROTECTED]>, 
"Michail Bletsas" <[EMAIL PROTECTED]>, "Chris Ball" <[EMAIL PROTECTED]>, 
"OLPC Developer's List" <[EMAIL PROTECTED]>, "Jim Gettys" <[EMAIL PROTECTED]>, 
"Ricardo Carrano" <[EMAIL PROTECTED]>
cc

Subject
Re: WDS problems observed in today's testing






Was anyone able to get a test with a different AP?  We were only able
to associate something like 20 laptops on Fri. Do we believe it should
be 30 or more?

Kim




On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
> Kim, Michail,
>
> The conclusion to all of this is that we should not use WRT54G in
> deployments, regardless of whether mesh is used or not (in fact, if we
> *only* use mesh we don't have this problem as the AP ignores mesh
> multicast traffic now).  The WRT54G will forward multicast traffic to
> all other APs in the vicinity that it identifies as peers using flawed
> criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
> traffic, that creates a risk of triggering the multicast storms that
> we saw at OLPC.
>
> Javier
>
> PS. If we have no choice but to use that AP, then we should re-image
> the AP with a distribution that allows turning WDS off.  In Tomato
> (http://www.polarcloud.com/tomato) this can be achieved via Basic ->
> Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'
>
>
> On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
> > Ricardo,
> >
> >
> >  > - The access point Javier mentions is the one I bought yesterday
> (Linksys
> >  > WRT54G)
> >
> >
> > Agreed, yes:
> >  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
> >
> >
> >  > - Most of this traffic is retransmission (3606):
> >  > (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
> ce:6e) &&
> >  > (wlan.fc.retry == 1)
> >
> >
> > Agreed.
> >
> >
> >  > - It is also interesting to detect other wds peers this AP 
identified
> (one
> >  > is 00:0b:85:53:27:50 and got 1066 of these frames).
> >  > ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
> ce:6e))
> >  > && (wlan.ra == 00:0b:85:53:27:50)
> >
> >
> > Yes.  Note that none of the WDS peers are xo's, as was the case in the
> past.
> >
> >
> >  > It seems that the linksys is expecting acks for this wds frames 
(which
> btw are mulcast frames). It is amazing.
> >
> >
> > Well, even if the final destination is a multicast address, those WDS
> >  frames are unicast, and therefore acknowledged.  What's troubling is
> >  that the WDS links are not torn down when the link quality is so 
poor.
> >   But we all know that Lazy-WDS is a flawed protocol.
> >
> >
> >  > I believe we should compare this with the previous capture from the
> >  > Netgear AP, just to confirm that this is (again) specific to WDS 
issues
> >  > on the Linksys.
> >
> >
> > I don't have access to that capture.  Maybe David?
> >
> >  Javier
> >
> >
> >
> >  > On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]>
> wrote:
> >  >
> >  > > Michail, Chris,
> >  > >
> >  > >
> >  > > This afternoon I captured some traffic while Chris was running 
tests
> >  > > for Peru.  The test setup consisted on ~25 laptops associated to 
a
> >  > > WRT54 access point.  When the laptops were on, associated and 
(not
> >  > > sure about this) idle, we observed a high volume of wireless 
traffic.
> >  > > The spectrum analyzer showed close to 50% duty cycle utilization 
of
> >  > > the channel.
> >  > > We also observed that a few xo's could not associate, and some 
seemed
> to
> >  > > intermittently lose and recover association.
> >  > >
> >  > > Turning off the WRT54 (and therefore stopping all the infra 
traffic)
> >  > > freed up most of the bandwidth on that channel.
> >  > >
> >  > > In my 50 second capture (taken before turning off the AP) we 
observe:
> >  > >
> >  > > Total traffic:  15081 frames (100%)
> >  > > All WDS traffic (1): 6023 frames ( 40%)
> >  > > WDS, xo is source addr (2):  4343 frames ( 29%)
> >  > >  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a 
single
> AP(4))
> >  > >
> >  > > Compare that with
> >  > >
> >  > > xo originated infra frames (5):   401 frames ( 3%)
> >  > >  (77% of the above xmitted at rates higher than 2 Mbps (6))
> >  > >
> >  > > What does all this mean?
> >  > >
> >  > > 1. Multicast traffic gets replicated and retransmitted.
> >  > > 2. The ratio of original frames to AP generated multicast
> >  > > retransmissions is 1:11
> >  > > 3. Taking into account the data rates this means that for 1 
airtime
> >  > > unit used to transmit useful traffic, over 200 units are wasted
> >  > > transmitting useless WDS traffic.
> >  > > 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
> >  > >
> >  > > M

Re: WDS problems observed in today's testing

[Kim Quirk]

Was anyone able to get a test with a different AP?  We were only able
to associate something like 20 laptops on Fri. Do we believe it should
be 30 or more?

Kim




On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
> Kim, Michail,
>
> The conclusion to all of this is that we should not use WRT54G in
> deployments, regardless of whether mesh is used or not (in fact, if we
> *only* use mesh we don't have this problem as the AP ignores mesh
> multicast traffic now).  The WRT54G will forward multicast traffic to
> all other APs in the vicinity that it identifies as peers using flawed
> criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
> traffic, that creates a risk of triggering the multicast storms that
> we saw at OLPC.
>
> Javier
>
> PS. If we have no choice but to use that AP, then we should re-image
> the AP with a distribution that allows turning WDS off.  In Tomato
> (http://www.polarcloud.com/tomato) this can be achieved via Basic ->
> Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'
>
>
> On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
> > Ricardo,
> >
> >
> >  > - The access point Javier mentions is the one I bought yesterday
> (Linksys
> >  > WRT54G)
> >
> >
> > Agreed, yes:
> >  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
> >
> >
> >  > - Most of this traffic is retransmission (3606):
> >  > (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
> ce:6e) &&
> >  > (wlan.fc.retry == 1)
> >
> >
> > Agreed.
> >
> >
> >  > - It is also interesting to detect other wds peers this AP identified
> (one
> >  > is 00:0b:85:53:27:50 and got 1066 of these frames).
> >  > ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
> ce:6e))
> >  > && (wlan.ra == 00:0b:85:53:27:50)
> >
> >
> > Yes.  Note that none of the WDS peers are xo's, as was the case in the
> past.
> >
> >
> >  > It seems that the linksys is expecting acks for this wds frames (which
> btw are mulcast frames). It is amazing.
> >
> >
> > Well, even if the final destination is a multicast address, those WDS
> >  frames are unicast, and therefore acknowledged.  What's troubling is
> >  that the WDS links are not torn down when the link quality is so poor.
> >   But we all know that Lazy-WDS is a flawed protocol.
> >
> >
> >  > I believe we should compare this with the previous capture from the
> >  > Netgear AP, just to confirm that this is (again) specific to WDS issues
> >  > on the Linksys.
> >
> >
> > I don't have access to that capture.  Maybe David?
> >
> >  Javier
> >
> >
> >
> >  > On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]>
> wrote:
> >  >
> >  > > Michail, Chris,
> >  > >
> >  > >
> >  > > This afternoon I captured some traffic while Chris was running tests
> >  > > for Peru.  The test setup consisted on ~25 laptops associated to a
> >  > > WRT54 access point.  When the laptops were on, associated and (not
> >  > > sure about this) idle, we observed a high volume of wireless traffic.
> >  > > The spectrum analyzer showed close to 50% duty cycle utilization of
> >  > > the channel.
> >  > > We also observed that a few xo's could not associate, and some seemed
> to
> >  > > intermittently lose and recover association.
> >  > >
> >  > > Turning off the WRT54 (and therefore stopping all the infra traffic)
> >  > > freed up most of the bandwidth on that channel.
> >  > >
> >  > > In my 50 second capture (taken before turning off the AP) we observe:
> >  > >
> >  > > Total traffic:  15081 frames (100%)
> >  > > All WDS traffic (1): 6023 frames ( 40%)
> >  > > WDS, xo is source addr (2):  4343 frames ( 29%)
> >  > >  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single
> AP(4))
> >  > >
> >  > > Compare that with
> >  > >
> >  > > xo originated infra frames (5):   401 frames ( 3%)
> >  > >  (77% of the above xmitted at rates higher than 2 Mbps (6))
> >  > >
> >  > > What does all this mean?
> >  > >
> >  > > 1. Multicast traffic gets replicated and retransmitted.
> >  > > 2. The ratio of original frames to AP generated multicast
> >  > > retransmissions is 1:11
> >  > > 3. Taking into account the data rates this means that for 1 airtime
> >  > > unit used to transmit useful traffic, over 200 units are wasted
> >  > > transmitting useless WDS traffic.
> >  > > 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
> >  > >
> >  > > Michail, is that one of OLPC APs?
> >  > > Chris, we should see a big improvement if we can disable that
> >  > > "feature" on the AP... or put it under water.
> >  > >
> >  > > I've posted my capture here:
> >  > >
> >  >
> http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap
> >  > >  in case someone wants to double check my analysis (Ricardo?).
> >  > >
> >  > > Cheers,
> >  > >
> >  > > Javier
> >  > >
> >  > > (1) wlan.fc.ds == 3
> >  > > (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
> >  > > (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:1

Re: WDS problems observed in today's testing

[Javier Cardona]

Kim, Michail,

The conclusion to all of this is that we should not use WRT54G in
deployments, regardless of whether mesh is used or not (in fact, if we
*only* use mesh we don't have this problem as the AP ignores mesh
multicast traffic now).  The WRT54G will forward multicast traffic to
all other APs in the vicinity that it identifies as peers using flawed
criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
traffic, that creates a risk of triggering the multicast storms that
we saw at OLPC.

Javier

PS. If we have no choice but to use that AP, then we should re-image
the AP with a distribution that allows turning WDS off.  In Tomato
(http://www.polarcloud.com/tomato) this can be achieved via Basic ->
Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'


On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> wrote:
> Ricardo,
>
>
>  > - The access point Javier mentions is the one I bought yesterday (Linksys
>  > WRT54G)
>
>
> Agreed, yes:
>  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
>
>
>  > - Most of this traffic is retransmission (3606):
>  > (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e) &&
>  > (wlan.fc.retry == 1)
>
>
> Agreed.
>
>
>  > - It is also interesting to detect other wds peers this AP identified (one
>  > is 00:0b:85:53:27:50 and got 1066 of these frames).
>  > ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e))
>  > && (wlan.ra == 00:0b:85:53:27:50)
>
>
> Yes.  Note that none of the WDS peers are xo's, as was the case in the past.
>
>
>  > It seems that the linksys is expecting acks for this wds frames (which btw 
> are mulcast frames). It is amazing.
>
>
> Well, even if the final destination is a multicast address, those WDS
>  frames are unicast, and therefore acknowledged.  What's troubling is
>  that the WDS links are not torn down when the link quality is so poor.
>   But we all know that Lazy-WDS is a flawed protocol.
>
>
>  > I believe we should compare this with the previous capture from the
>  > Netgear AP, just to confirm that this is (again) specific to WDS issues
>  > on the Linksys.
>
>
> I don't have access to that capture.  Maybe David?
>
>  Javier
>
>
>
>  > On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]> wrote:
>  >
>  > > Michail, Chris,
>  > >
>  > >
>  > > This afternoon I captured some traffic while Chris was running tests
>  > > for Peru.  The test setup consisted on ~25 laptops associated to a
>  > > WRT54 access point.  When the laptops were on, associated and (not
>  > > sure about this) idle, we observed a high volume of wireless traffic.
>  > > The spectrum analyzer showed close to 50% duty cycle utilization of
>  > > the channel.
>  > > We also observed that a few xo's could not associate, and some seemed to
>  > > intermittently lose and recover association.
>  > >
>  > > Turning off the WRT54 (and therefore stopping all the infra traffic)
>  > > freed up most of the bandwidth on that channel.
>  > >
>  > > In my 50 second capture (taken before turning off the AP) we observe:
>  > >
>  > > Total traffic:  15081 frames (100%)
>  > > All WDS traffic (1): 6023 frames ( 40%)
>  > > WDS, xo is source addr (2):  4343 frames ( 29%)
>  > >  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4))
>  > >
>  > > Compare that with
>  > >
>  > > xo originated infra frames (5):   401 frames ( 3%)
>  > >  (77% of the above xmitted at rates higher than 2 Mbps (6))
>  > >
>  > > What does all this mean?
>  > >
>  > > 1. Multicast traffic gets replicated and retransmitted.
>  > > 2. The ratio of original frames to AP generated multicast
>  > > retransmissions is 1:11
>  > > 3. Taking into account the data rates this means that for 1 airtime
>  > > unit used to transmit useful traffic, over 200 units are wasted
>  > > transmitting useless WDS traffic.
>  > > 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
>  > >
>  > > Michail, is that one of OLPC APs?
>  > > Chris, we should see a big improvement if we can disable that
>  > > "feature" on the AP... or put it under water.
>  > >
>  > > I've posted my capture here:
>  > >
>  > 
> http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap
>  > >  in case someone wants to double check my analysis (Ricardo?).
>  > >
>  > > Cheers,
>  > >
>  > > Javier
>  > >
>  > > (1) wlan.fc.ds == 3
>  > > (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
>  > > (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate ==
>  > 0x2
>  > > (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == 
> ce:6e
>  > > (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4
>  > > (6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate > 
> 4
>  > >
>  > > --
>  > > Javier Cardona
>  > > cozybit Inc.
>  > >
>  >
>  >
>
>
>
> --
>  Javier Cardona
>  cozybit Inc.
>


-- 
Javier Cardona
cozybit Inc.
___
Dev

Re: WDS problems observed in today's testing

[Javier Cardona]

Ricardo,

> - The access point Javier mentions is the one I bought yesterday (Linksys
> WRT54G)

Agreed, yes:
35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"

> - Most of this traffic is retransmission (3606):
> (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e) &&
> (wlan.fc.retry == 1)

Agreed.

> - It is also interesting to detect other wds peers this AP identified (one
> is 00:0b:85:53:27:50 and got 1066 of these frames).
> ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e))
> && (wlan.ra == 00:0b:85:53:27:50)

Yes.  Note that none of the WDS peers are xo's, as was the case in the past.

> It seems that the linksys is expecting acks for this wds frames (which btw 
> are mulcast frames). It is amazing.

Well, even if the final destination is a multicast address, those WDS
frames are unicast, and therefore acknowledged.  What's troubling is
that the WDS links are not torn down when the link quality is so poor.
 But we all know that Lazy-WDS is a flawed protocol.

> I believe we should compare this with the previous capture from the
> Netgear AP, just to confirm that this is (again) specific to WDS issues
> on the Linksys.

I don't have access to that capture.  Maybe David?

Javier


> On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]> wrote:
>
> > Michail, Chris,
> >
> >
> > This afternoon I captured some traffic while Chris was running tests
> > for Peru.  The test setup consisted on ~25 laptops associated to a
> > WRT54 access point.  When the laptops were on, associated and (not
> > sure about this) idle, we observed a high volume of wireless traffic.
> > The spectrum analyzer showed close to 50% duty cycle utilization of
> > the channel.
> > We also observed that a few xo's could not associate, and some seemed to
> > intermittently lose and recover association.
> >
> > Turning off the WRT54 (and therefore stopping all the infra traffic)
> > freed up most of the bandwidth on that channel.
> >
> > In my 50 second capture (taken before turning off the AP) we observe:
> >
> > Total traffic:  15081 frames (100%)
> > All WDS traffic (1): 6023 frames ( 40%)
> > WDS, xo is source addr (2):  4343 frames ( 29%)
> >  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4))
> >
> > Compare that with
> >
> > xo originated infra frames (5):   401 frames ( 3%)
> >  (77% of the above xmitted at rates higher than 2 Mbps (6))
> >
> > What does all this mean?
> >
> > 1. Multicast traffic gets replicated and retransmitted.
> > 2. The ratio of original frames to AP generated multicast
> > retransmissions is 1:11
> > 3. Taking into account the data rates this means that for 1 airtime
> > unit used to transmit useful traffic, over 200 units are wasted
> > transmitting useless WDS traffic.
> > 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
> >
> > Michail, is that one of OLPC APs?
> > Chris, we should see a big improvement if we can disable that
> > "feature" on the AP... or put it under water.
> >
> > I've posted my capture here:
> >
> http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap
> >  in case someone wants to double check my analysis (Ricardo?).
> >
> > Cheers,
> >
> > Javier
> >
> > (1) wlan.fc.ds == 3
> > (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
> > (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate ==
> 0x2
> > (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e
> > (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4
> > (6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate > 4
> >
> > --
> > Javier Cardona
> > cozybit Inc.
> >
>
>


-- 
Javier Cardona
cozybit Inc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Speech Synthesis Integration - User Interfaces and other Implementation Considerations

[Hemant Goyal]

Hi,

I was thinking while the packaging of speech dispatcher continues I could
finalize certain UI considerations for speech synthesis. I had a word with
Tomeu and he advised me to write all the points in a mail to the list.

Particularly we want to focus on :

   1. A Speech Configuration Management for Sugar
  1. Provision of a control panel for modifying speech synthesis
  parameters
  2. How these parameters will be stored and retrieved when
  changes are made
  3. What parameters to expose?
  1. Language - Perhaps this should be the sugar default?
 2. Voice Selection - Male/Female, Child/Adult, Age
 3. Rate
 4. Pitch
 5. Volume
  2. GUI considerations
  1. A Speech Synthesis Button
 1. Has many states - Play/Stop (Pause?)
 2. Reveals a control panel for modifying the speech
 synthesis parameters and provides a text box for getting some
text data for
 speech synthesis?
 2. What to text to send for speech synthesis?
 1. If some text is highlighted then that text should be
 sent
 2. If no text is highlighted and speech synthesis button
 is clicked
1. Send data of some active window and provide
karaoke style highlighting of text?
2. Continue synthesis until the end of the document
or stop button is pressed
 3. Possibly a Speech Synthesis keyboard shortcut too -
   Should effect the Speech Synthesis button
   4. Speak out a welcome message to the child when the XO boots up?
   (Hello xyz welcome to sugar or something like that?)

Please share any other ideas which you think can improve the User Experience
wrt speech synthesis.

I'd like to write the patches and wrap up the coding by the time speech
dispatcher RPMs are ready so that we can roll this feature in the XOs and
get some feedback :)

Thanks!
-- 
Hemant Goyal
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: show me the code

[Bert Freudenberg]

On Mar 1, 2008, at 18:38 , Chris Ball wrote:

> Hi,
>
>> AFAIK the only activities supporting the view-source key currently
>> are Chat (which opens its source code in Pippy), Browse (showing the
>> HTML source code) and Etoys (showing a menu giving access to code
>> browsers and other tools).
>
> Pippy supports view source too (and opens *itself* in Pippy, where you
> can make modifications to it and build a new Pippy bundle from them).

Ah right. My Pippy in jhbuild was outdated when I grepped for  
XF86Start. Isn't it time to include it properly, building it by default?

- Bert -


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

Re: show me the code

[Chris Ball]

Hi,

   > AFAIK the only activities supporting the view-source key currently  
   > are Chat (which opens its source code in Pippy), Browse (showing the  
   > HTML source code) and Etoys (showing a menu giving access to code  
   > browsers and other tools).

Pippy supports view source too (and opens *itself* in Pippy, where you
can make modifications to it and build a new Pippy bundle from them).

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

Re: WDS problems observed in today's testing

[Ricardo Carrano]

(last version was incomplete):

Just to add that:

- The access point Javier mentions is the one I bought yesterday (Linksys
WRT54G)

- Most of this traffic is retransmission (3606):
(wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e) &&
(wlan.fc.retry == 1)

- It is also interesting to detect other wds peers this AP identified (one
is 00:0b:85:53:27:50 and got 1066 of these frames).
((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e))
&& (wlan.ra == 00:0b:85:53:27:50)

It seems that the linksys is expecting acks for this wds frames (which btw
are mulcast frames). It is amazing.

I believe we should compare this with the previous capture from the Netgear
AP, just to confirm that this is (again) specific to WDS issues on the
Linksys.

-- RC

On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]> wrote:

> Michail, Chris,
>
>
> This afternoon I captured some traffic while Chris was running tests
> for Peru.  The test setup consisted on ~25 laptops associated to a
> WRT54 access point.  When the laptops were on, associated and (not
> sure about this) idle, we observed a high volume of wireless traffic.
> The spectrum analyzer showed close to 50% duty cycle utilization of
> the channel.
> We also observed that a few xo's could not associate, and some seemed to
> intermittently lose and recover association.
>
> Turning off the WRT54 (and therefore stopping all the infra traffic)
> freed up most of the bandwidth on that channel.
>
> In my 50 second capture (taken before turning off the AP) we observe:
>
> Total traffic:  15081 frames (100%)
> All WDS traffic (1): 6023 frames ( 40%)
> WDS, xo is source addr (2):  4343 frames ( 29%)
>  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4))
>
> Compare that with
>
> xo originated infra frames (5):   401 frames ( 3%)
>  (77% of the above xmitted at rates higher than 2 Mbps (6))
>
> What does all this mean?
>
> 1. Multicast traffic gets replicated and retransmitted.
> 2. The ratio of original frames to AP generated multicast
> retransmissions is 1:11
> 3. Taking into account the data rates this means that for 1 airtime
> unit used to transmit useful traffic, over 200 units are wasted
> transmitting useless WDS traffic.
> 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
>
> Michail, is that one of OLPC APs?
> Chris, we should see a big improvement if we can disable that
> "feature" on the AP... or put it under water.
>
> I've posted my capture here:
>
> http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap
>  in case someone wants to double check my analysis (Ricardo?).
>
> Cheers,
>
> Javier
>
> (1) wlan.fc.ds == 3
> (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
> (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate ==
> 0x2
> (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e
> (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4
> (6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate > 4
>
> --
> Javier Cardona
> cozybit Inc.
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: WDS problems observed in today's testing

[Ricardo Carrano]

Just to add that:

- The access point Javier mentions is the one I bought yesterday (Linksys
WRT54G)

- Most of this traffic is retransmission (3606):
(wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e) &&
(wlan.fc.retry == 1)

- It is also interesting to detect other wds peers this AP identified (one
is 00:0b:85:53:27:50 and got ).
((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e))
&& (wlan.ra == 00:0b:85:53:27:50)

I believe we should compare this with the previous capture from the Netgear
AP, just to confirm that this is (agian) specific to WDS issues on the
Linksys.

On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <[EMAIL PROTECTED]> wrote:

> Michail, Chris,
>
>
> This afternoon I captured some traffic while Chris was running tests
> for Peru.  The test setup consisted on ~25 laptops associated to a
> WRT54 access point.  When the laptops were on, associated and (not
> sure about this) idle, we observed a high volume of wireless traffic.
> The spectrum analyzer showed close to 50% duty cycle utilization of
> the channel.
> We also observed that a few xo's could not associate, and some seemed to
> intermittently lose and recover association.
>
> Turning off the WRT54 (and therefore stopping all the infra traffic)
> freed up most of the bandwidth on that channel.
>
> In my 50 second capture (taken before turning off the AP) we observe:
>
> Total traffic:  15081 frames (100%)
> All WDS traffic (1): 6023 frames ( 40%)
> WDS, xo is source addr (2):  4343 frames ( 29%)
>  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4))
>
> Compare that with
>
> xo originated infra frames (5):   401 frames ( 3%)
>  (77% of the above xmitted at rates higher than 2 Mbps (6))
>
> What does all this mean?
>
> 1. Multicast traffic gets replicated and retransmitted.
> 2. The ratio of original frames to AP generated multicast
> retransmissions is 1:11
> 3. Taking into account the data rates this means that for 1 airtime
> unit used to transmit useful traffic, over 200 units are wasted
> transmitting useless WDS traffic.
> 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
>
> Michail, is that one of OLPC APs?
> Chris, we should see a big improvement if we can disable that
> "feature" on the AP... or put it under water.
>
> I've posted my capture here:
>
> http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap
>  in case someone wants to double check my analysis (Ricardo?).
>
> Cheers,
>
> Javier
>
> (1) wlan.fc.ds == 3
> (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
> (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate ==
> 0x2
> (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e
> (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4
> (6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate > 4
>
> --
> Javier Cardona
> cozybit Inc.
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: show me the code

[Bert Freudenberg]

On Mar 1, 2008, at 9:12 , Christoph Derndorfer wrote:

> Hello,
>
> we're currently here at the Linux days in Chemnitz, Germany and as
> always the XOs are receiving a lot of attention. Interestingly we've
> also been asked about the „show me the code“ functionality a couple of
> times already. Now I'd like to know what the current status of that
> feature was, whether someone is actively working on it already, when
> it's expected to land, etc.

AFAIK the only activities supporting the view-source key currently  
are Chat (which opens its source code in Pippy), Browse (showing the  
HTML source code) and Etoys (showing a menu giving access to code  
browsers and other tools).

It works only on certain combinations of hardware and software. Like,  
on my B4 with Arabic keyboard at 693, fn-space does not generate the  
correct keyboard symbol (XF86Start). Browse has Ctrl-U as alternative  
shortcut, Etoys supports Ctrl-"," (comma) and Chat has no alternative  
shortcut. On my MP machine with English keyboard, fn-space works.

- Bert -


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

Re: [Server-devel] Google Summer of Code and OLPC

[Hilaire Fernandes]

I added to this page DrGeo enhancements needed to make it fully
operable within the XO machine.

Hilaire

2008/2/29, Shankar Pokharel <[EMAIL PROTECTED]>:
> > Is there a wiki page (specific to SoC 2008) which can be used to build
> > up a list of ideas ?
>
> http://wiki.laptop.org/go/Summer_of_Code/2008
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

show me the code

[Christoph Derndorfer]

Hello,

we're currently here at the Linux days in Chemnitz, Germany and as 
always the XOs are receiving a lot of attention. Interestingly we've 
also been asked about the „show me the code“ functionality a couple of 
times already. Now I'd like to know what the current status of that 
feature was, whether someone is actively working on it already, when 
it's expected to land, etc.

Thanks,
Christoph


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

New ship.2 build 659

[Build Announcer Script]

http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build659/

+Read-35.xo

--- Read-35 ---
 * #4454: Added a broad try..except Exception: to write_file() to  
allow
 read to close if write_file has an error. (pascals)

--
  This email was automatically generated
  Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New ship.2 build 658

[Build Announcer Script]

http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build658/

+Journal-72.xo

--- Journal-72 ---
 * #4909 Add Resume method to the DBus service. (marco)

--
  This email was automatically generated
  Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New ship.2 build 657

[Build Announcer Script]

http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build657/

-AcousticMeasure-6.xo
-Analyze-4.xo
-Calculate-13.xo
-Etoys-71.xo
-Journal-72.xo
-Log-5.xo
-Measure-14.xo
-Memorize-21.xo
-NewsReader-21.xo
-Pippy-10.xo
-Read-35.xo
-TamTamEdit-44.xo
-TamTamJam-44.xo
-TamTamMini-43.xo
-TamTamSynthLab-44.xo
-Terminal-2.xo
-TurtleArt-4.xo
-bootanim.i386 0:0.12-0
+bootanim.i386 0:0.15-0

--
  This email was automatically generated
  Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Server-devel] Google Summer of Code and OLPC

[Sayamindu Dasgupta]

On Sat, Mar 1, 2008 at 6:01 PM, Martin Langhoff
<[EMAIL PROTECTED]> wrote:
> On Sat, Mar 1, 2008 at 6:31 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
>  >  AFAIK - Summer of Code does not support non code related projects.
>
>  You are right - but the related GHOP does. We could get a lot of
>  mileage out of that.
>

Yes - OLPC should probably try to be a part of the next GHOP - there
are a lot of potential tasks that are suited for the GHOP.

In a related note - I have move the current SOC page in the wiki to an
archive (Summer of Code/2007) and the current toplevel page talks
2008.

Thanks,
Sayamindu



-- 
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Is read_file() always called after an activity __init__?

[Tomeu Vizoso]

On Sat, Mar 1, 2008 at 3:12 AM, John Gilmore <[EMAIL PROTECTED]> wrote:
> > Hmmm, so if my activity needs it's preferences before it can display
>  > anything to the user, potential future lazy loading of the data-store
>  > (to try and speed up general activity start-up time) is going to leave
>  > folks watching my activity with a blank screen for a lazy while? Ouch.
>
>  Ahem.  The Grand Unified Theory of OLPC was that the datastore/journal
>  were going to entirely replace the filesystem (as far as Activites
>  are concerned).  Activities aren't permitted to read/write the ordinary
>  Linux filesystem, according to this theory.

Not true. The datastore is for recording actions and storing the
documents associated to those. In other words: for saving the child's
work and allowing for efficient retrieval. Where have you found this
"theory"?

See the link below for an explanation of the suggested guidelines for
writing to the fs:

http://wiki.laptop.org/go/Low-level_Activity_API#Writable_Directories

>  If the datastore isn't just as ready, just as fast, and just as
>  available as the filesystem, e.g. for holding tiny little files that
>  rapidly keep the Activity's configuation options, then there's
>  something terribly wrong here.

Can you elaborate? I'm certainly not happy with the current state of
the DS, but would like to know more about which problems you see in
the current implementation.

Thanks,

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

Re: [Server-devel] Google Summer of Code and OLPC

[Martin Langhoff]

On Sat, Mar 1, 2008 at 6:31 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
>  AFAIK - Summer of Code does not support non code related projects.

You are right - but the related GHOP does. We could get a lot of
mileage out of that.

cheers,


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

WDS problems observed in today's testing

[Javier Cardona]

Michail, Chris,


This afternoon I captured some traffic while Chris was running tests
for Peru.  The test setup consisted on ~25 laptops associated to a
WRT54 access point.  When the laptops were on, associated and (not
sure about this) idle, we observed a high volume of wireless traffic.
The spectrum analyzer showed close to 50% duty cycle utilization of
the channel.
We also observed that a few xo's could not associate, and some seemed to
intermittently lose and recover association.

Turning off the WRT54 (and therefore stopping all the infra traffic)
freed up most of the bandwidth on that channel.

In my 50 second capture (taken before turning off the AP) we observe:

Total traffic:  15081 frames (100%)
All WDS traffic (1): 6023 frames ( 40%)
WDS, xo is source addr (2):  4343 frames ( 29%)
 (96% of the above xmitted at 1 Mbps (3) and 100% sent by a single AP(4))

Compare that with

xo originated infra frames (5):   401 frames ( 3%)
 (77% of the above xmitted at rates higher than 2 Mbps (6))

What does all this mean?

1. Multicast traffic gets replicated and retransmitted.
2. The ratio of original frames to AP generated multicast
retransmissions is 1:11
3. Taking into account the data rates this means that for 1 airtime
unit used to transmit useful traffic, over 200 units are wasted
transmitting useless WDS traffic.
4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e

Michail, is that one of OLPC APs?
Chris, we should see a big improvement if we can disable that
"feature" on the AP... or put it under water.

I've posted my capture here:
http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap
 in case someone wants to double check my analysis (Ricardo?).

Cheers,

Javier

(1) wlan.fc.ds == 3
(2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
(3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate == 0x2
(4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] == ce:6e
(5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4
(6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and radiotap.datarate > 4

-- 
Javier Cardona
cozybit Inc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel