WDS problems observed in today's testing
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: [Server-devel] Google Summer of Code and OLPC
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
Re: Is read_file() always called after an activity __init__?
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
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
New ship.2 build 657
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
New ship.2 build 658
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 659
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
show me the code
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
Re: [Server-devel] Google Summer of Code and OLPC
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
Re: show me the code
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: WDS problems observed in today's testing
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.caphttp://dev.laptop.org/%7Ejavier/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
(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.caphttp://dev.laptop.org/%7Ejavier/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
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: show me the code
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: WDS problems observed in today's testing
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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WDS problems observed in today's testing
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 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
Re: WDS problems observed in today's testing
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: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
Read Activity slowness
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: Read Activity slowness
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
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.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
OLPC News (2008-03-01)
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: storing Activity parameters
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
Re: WDS problems observed in today's testing
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): 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
