On Wednesday 29 April 2009 23:03:14 Bo Han wrote: > By default, minstrel will adjust the best throughput bit rate every > 100ms. If 48 Mbps should be used for the channel, but for some reason > minstrel selects 54 Mbps at the very beginning of the update interval, > 1 Mbps will be always used during that interval as fallback rate. > Even if the bit rate is reduced to 48 Mbps, after the first two > retries fail, 1 Mbps is again used as fallback rate. Of course, I > know it is caused by the fact that there are only 2 rates for b43 and > this may be the best we can do now.
Correct. So you'll get slow traffic for a duration of 100ms. That's even well below the event recognition borderline of humans, which is about 300ms. So you won't even notice it. You can only measure it with special benchmark tools, perhaps. > Yes, packet loss will make trouble for TCP. But for UDP, we have a > trade-off between the maximum throughput we can get and the overall > packet loss rate. For video streaming applications, I really don't > want a packet to be sent at 1 Mbps as fallback rate when the channel > quality is not that bad. Anyway, thank you for the explanations. Then wait for another 100ms, if you can spare that time, and you'll get the full throughput of your shiny quality connection. To say it once again. Fallback is really what the name says: A fallback. It's a fallback for error conditions. So if we already have an error condition (that is the first attempt failed), we should try our best to get the freaking frame out there. Our best guess with one-rate-retry is 1M. (For MRR we'd start with a higher rate before we try 1M, of course). It simply is a limitation of some devices. But I think it's not that bad. Throughput may just be worse for the first 1/2second or something like this after the environment conditions changed, because lots of retransmissions hit. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
