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. 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...
Anyway, I just want to confirm it is what you are doing in the b43 driver and minstrel and I got the correct answers. Thank you! -Bo On Wed, Apr 29, 2009 at 1:19 PM, Michael Buesch <[email protected]> wrote: > On Wednesday 29 April 2009 22:13:54 Felix Fietkau wrote: >> Bo Han wrote: >> > Hi Felix, >> > >> > I just want to confirm that when b43 driver set max_rates of >> > ieee80211_hw to be 2, minstrel will think that MRR is not enabled and >> > thus will only provide the best throughput bit rate. There is NO >> > fallback bit rate calculate in this special case. >> > >> > Also, is it possible to modify the code to support just >> > one-fallback-rate-only case for drivers like b43? I think minstrel >> > should be flexible and provide the fallback rates based on the value >> > of max_rates. Currently, there will be either no fallback rates or 3 >> > fallback rates, right? >> > >> > Feel free to correct me if I am wrong. >> Minstrel will only start properly using fallback rates if it has >> 4 rates. Using 3 rates would be workable too, but there's not that >> much that can be done with 2 rates. The reason for that is that >> it makes sense to have one rate always use the lowest rate, to >> make sure that when the radio environment changes, it does not >> produce high packet loss during the time that minstrel takes to >> readjust the rate statistics. >> >> If the driver does not announce 4 rates, minstrel defaults to >> always specifying the lowest rate as fallback rate, regardless >> of whether a fallback rate was actually announced by the driver or >> not. > > Ok that makes sense. I understood Bo Han in a way that minstrel would not > define a fallback at all, so the variable was dangling. That wouldn't be > acceptable, of course. 1M is OK, of course. > > -- > Greetings, Michael. > _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
