Re: b43legacy woes

Re: b43legacy woes

[Larry Finger]

David Ellingsworth wrote:
> I've been using the b43legacy driver since it was first posted to this list.
 > The driver has been relatively stable, but my wireless connection has not.
 > In an environment with approximately 26 wireless access points, I experience
 > frequent disconnects and reconnects with the rate stuck at 1Mb/s. The ranges
 > for signal and noise reported under these conditions were (-53db, -59db) and
 > (-93db, -89db) respectively, with an average difference between the two around 20db.
 > The Windows driver under these conditions quickly scaled to 54Mb/s and maintained a
 > connection. In an environment with a single AP, the b43legacy driver performs very
 > similar to the results above where the rate is limited at 1Mb/s and the Windows driver
 > scales significantly higher.
> 

The poor performance of the BCM4306/2 (your chip/card) is known. There has been a report that this 
is a regression since 2.6.20, or so, has not been confirmed. With a 2.6.21 kernel, I got an iperf 
transmit rate of 4 Mbs, but that quickly dropped to 0.3 Mbs without me changing anything - I just 
repeated the iperf command. I will be doing a bisection on bcm43xx to see if I can indeed find a 
regression.

As for the loss of connection in an environment with lots of AP's, I cannot duplicate that 
environment. Has anyone else seen this with b43, or with some other mac80211 driver. Perhaps we can 
localize the problem component. Is there a possibility of buffer overflow in the scan results with 
that many AP's?

Larry

Re: b43legacy woes

[David Woodhouse]

On Fri, 2007-08-31 at 17:26 -0500, Larry Finger wrote:
> The poor performance of the BCM4306/2 (your chip/card) is known. Ther=
e has been a report that this=20
> is a regression since 2.6.20, or so, has not been confirmed. With a 2=
=2E6.21 kernel, I got an iperf=20
> transmit rate of 4 Mbs, but that quickly dropped to 0.3 Mbs without m=
e changing anything - I just=20
> repeated the iperf command.=20

That reminds me... I accidentally invented a new wireless test. It's
intended to stream the full OS images to OLPC laptops on the production
line, and does so by multicast -- so there are no link-layer ACKs and
retries compensating for your packet loss; it all gets reported.

It's in git://git.infradead.org/mtd-utils.git; the tools are recv_image
and serve_image.

usage: recv_image <host> <port> <mtddev>
usage: serve_image <host> <port> <image> <erasesize> [<tx_rate>]

A $ dd if=3D/dev/urandom of=3Dtestfile bs=3D131072 count=3D50
A $ ./serve_image ff0f::114 12345 testfile 131072 85
	Inter-packet delay (avg): 32858=C2=B5s
	Transmit rate: 85 KiB/s
	Checking CRC....85a0d369
	Checking block CRCS.... 50/50
	Image size 6400 KiB (0x00640000). 50 blocks at 47 pkts/block
	Estimated transmit time per cycle: 77s
	Sending data block 004e0000 packet  15/70    (85 KiB/s)   =20


B $ ./recv_image ff0f::114 12345 foo
	MEMGETINFO: Inappropriate ioctl for device
	Receive to file bar with (assumed) erasesize 131072
	Received 750/2350 (31%) in 25s @82KiB/s, 6 lost (0%), 0 dup/xs =20

You can use it unicast too, and/or with Legacy IP instead of IPv6.

If your AP sends all multicast at 1Mb/s, then 85 KiB/s is about all
you'll get. If you can configure the Basic Rate set not to include the
slower speeds, or if you can change the multicast rate (which could
actually be _any_ rate in the Basic Rate set), then you can go faster.
I find it works quite nicely at 24Mb/s.

--=20
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html