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.
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. Thanks, -Bo On Wed, Apr 29, 2009 at 4:48 PM, Michael Buesch <[email protected]> wrote: > On Wednesday 29 April 2009 22:39:45 Bo Han wrote: >> What I said was when MRR is not enabled, b43 will always use 1 Mbps as >> fallback rate, which will significantly reduce the throughput for some >> cases. > > No it won't. Fallbacks will only be used if the main rate wasn't correctly > adjusted by the RC. That will only happen while it's scaling/probing the > rates. > If the RC correctly adjusted the rate to your network, only a very tiny number > of packets will be retried. (Real world numbers are an average of 1.01-1.02 > tries per packet). > >> For a channel with good quality, 54 Mbps may be the best >> throughput bit rate. After two retries fail with 54 Mbps, the bit >> rate will drop to 1 Mbps. But in fact, 48 or 36 Mbps may work well as >> fallback rate... > > No they won't. Starting with 54M as fallback is absolutely horrible > and it will cause horrible stalls. It will cause packets to be completely > lost that otherwise will get through on the second attempt with 1M. That will > trigger > retries and delays on the upper layers, such as TCP. The TCP frame loss > mechanism > will kick in, which will just reduce throughput even more. > The fact that high rates don't work at all on some b43 devices only helps > this fact. > > -- > Greetings, Michael. > _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
