New mesh throughput record?
I just achieved a mesh throughput rate - XO to XO - of 2.8 MBytes/sec using multicast with TTL = 1. That's twice as fast as the best I was able to do through the Linux driver, using the same parameters. I did it using Open Firmware, paying careful attention to queuing USB bulk-out requests so the USB host controller doesn't have to wait for a USB frame boundary before sending the next one. The packet loss rate was quite low - on the order of 0.1% . The machines were less than a meter apart. The broadcast bit rate can be 36, 48, or 54 Mbits/s to achieve that throughput. At lower bit rates the throughput starts to drop off. I also measured the rate at which it's possible to push data to the wlan device over the USB bus without transmitting - that rate is 4.2 MBytes/s. I did that by tricking the chip into accepting the USB packets but not transmitting them. Using the Linux driver, the fastest transmit rate I was able to achieve was 1.4 Mbytes/s (multicast, TTL=1, high broadcast bit rates, i.e. the same parameters). That makes me suspect that the Linux driver is inadvertently throttling the rate. The throttled rate is almost exactly one ethernet frame per millisecond. I'm not sure what's causing it. Perhaps some characteristic of the EHCI driver is synchronizing the bulk-out transactions to the USB macro frames. It might also be a Linux scheduler artifact, perhaps related to the multithreaded nature of the Libertas driver. Mitch ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New mesh throughput record?
Hi Mitch! On Wed, Oct 22, 2008 at 7:01 AM, Mitch Bradley [EMAIL PROTECTED] wrote: I just achieved a mesh throughput rate - XO to XO - of 2.8 MBytes/sec using multicast with TTL = 1. That's twice as fast as the best I was able to do through the Linux driver, using the same parameters. I did it using Open Firmware, paying careful attention to queuing USB bulk-out requests so the USB host controller doesn't have to wait for a USB frame boundary before sending the next one. The packet loss rate was quite low - on the order of 0.1% . The machines were less than a meter apart. The broadcast bit rate can be 36, 48, or 54 Mbits/s to achieve that throughput. At lower bit rates the throughput starts to drop off. I also measured the rate at which it's possible to push data to the wlan device over the USB bus without transmitting - that rate is 4.2 MBytes/s. I did that by tricking the chip into accepting the USB packets but not transmitting them. Using the Linux driver, the fastest transmit rate I was able to achieve was 1.4 Mbytes/s (multicast, TTL=1, high broadcast bit rates, i.e. the same parameters). That makes me suspect that the Linux driver is inadvertently throttling the rate. The throttled rate is almost exactly one ethernet frame per millisecond. I'm not sure what's causing it. Perhaps some characteristic of the EHCI driver is synchronizing the bulk-out transactions to the USB macro frames. It might also be a Linux scheduler artifact, perhaps related to the multithreaded nature of the Libertas driver. This is a very useful input. Thank you! BTW, 2.8MB/s is very close to the maximum throughput you would get with 802.11 (because of headers and preambles). So it seems you cannot improve this significantly. Regarding the multicast rate, if you have the same throughput with 36, 48 and 54Mpbs, the tradeoff would be: the lower (36) rate will reach more distant laptops and with less frame loss, but it would consume more airtime (which may be relevant if the medium is contended). The higher rate (54) will save airtime, but increase error rates and decrease distances. If the update process is performed with laptops within a short range distance (20m), using 54 Mbps is probably a better idea. Mitch ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New mesh throughput record?
On Wed, 2008-10-22 at 00:01 -1000, Mitch Bradley wrote: It might also be a Linux scheduler artifact, perhaps related to the multithreaded nature of the Libertas driver. That's possible -- TX packets aren't sent directly from the driver's hard_start_xmit() function, but are just queued for the main thread to send them. It's like that because that was the 'sledgehammer' fix for the evil locking problems which the original driver had. There will be a certain amount of latency introduced by the current setup, obviously. If we believe we now have a handle on the concurrency issues, then we could sensibly look at moving the actual TX handling back into the TX routines. Carefully. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
