WDS problems observed in today's testing
Javier Cardona
javier at cozybit.com
Sat Mar 1 23:33:38 EST 2008
John,
On 3/1/08, John Watlington <wad at laptop.org> 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 <javier at cozybit.com> 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 <javier at cozybit.com> 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 <javier at cozybit.com>
> >> 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 at lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
>
>
--
Javier Cardona
cozybit Inc.
More information about the Devel
mailing list