New mesh throughput record?

Ricardo Carrano carrano at laptop.org
Wed Oct 22 06:44:56 EDT 2008


Hi Mitch!

On Wed, Oct 22, 2008 at 7:01 AM, Mitch Bradley <wmb at laptop.org> 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
>
>



More information about the Devel mailing list