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 Cardona >>>>> cozybit Inc. >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Javier Cardona >>> cozybit Inc. >>> >> >> >> -- >> Javier Cardona >> cozybit Inc. >> > > -- > Sent from Gmail for mobile | mobile.google.com > _______________________________________________ > 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