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 - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
