On 2013-03-07 4:31 PM, Simon Wunderlich wrote: > Hello list, > > as you might be aware, it is possible to set short and long retry limits > to specify how often a frame should be retransmitted before getting dropped. > > However, it appears that minstrel completely ignores any retry limit, and it is > also not applied later in the code path. I've hacked minstrel_ht a little bit > to apply the retry limits in minstrel_get_rate() before returning the rates > (i.e. just cutting retries at the end from the struct ieee80211_tx_rate array). > > This worked for me, but is probably not clean either and might disturb minstrel > operation. Also minstrel uses much more retries than default retry limits > (short: 7, long: 4), so this patch might introduce behaviour changes. > > What is your opinion on this? Can we get it properly supported? Does it hurt > to just use the first $retry_limit retries, and cut the rest at other rates > at the end? I think simply cutting off from the end of the retry chain is a bad idea - if there are too many scheduled retries in the max throughput rate, it will not make it to the fallback to a reliable rate if that fails. A better approach is to make minstrel use fewer retries per rate. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
