On Fri, 2007-08-31 at 17:26 -0500, Larry Finger wrote:
> 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.
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=/dev/urandom of=testfile bs=131072 count=50
A $ ./serve_image ff0f::114 12345 testfile 131072 85
Inter-packet delay (avg): 32858µs
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)
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
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.
--
dwmw2
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
