On Wednesday 02 February 2011 11:52:54 Bob Copeland wrote: > On Wed, Feb 02, 2011 at 09:06:40AM +0100, Sedat Dilek wrote: > > As I saw your patch in linux-next/wireless-next-2.6, I wanted to ask > > what's up with Bob's > > "mac80211-minstrel-honor-max-retry-counts-from-cfg80211.patch" (see > > [1])? > > I sort of dropped the ball on it. I guess I need to test it to > see if it actually works. It may not properly handle reconfiguring > the limits, e.g. Once I can boot a recent kernel (i915 issues) I'll > give it a spin and see. > > > Is this patch obsolete, now? > > Ath5k now uses the same values that my patch would have used in > minstrel, so my patch wouldn't have any effect now, for ath5k. > There still might be other drivers that would benefit from having > the change in the rate controller. My patch for ath5k is only one part of the story. It sets the retry limits in HW. Most of these values only affect after how many retries the contention window is reset to cw_min, not the actual number of retries (please check the register documentation in my patch). The total number of retries for a frame are the values we put into the TX descriptor - coming from the rate control module (minstrel). In my point of view there are two things missing: 1) minstrel should respect the short/long retry configuration as well. This is what Bob's patch attempts to do (I never tested it). 2) I think minstrel does currently not use the max number of retries (short/long retries or hw->max_rate_tries) in a correct way. It looks like it uses the max number of retries for every single rate, whereas it should stay below the max retries in SUM of all different rates. E.g now I can see something like rate1: 6 retries, rate2: 3 retries, rate3: 3 retries, rate4: 3 retries (or similar, i dont have the debugging output here, but it's easy to print the rates and tries before we setup the tx descriptor). This results in more total tries than have been setup in hw->max_rate_tries. One side effect is that this causes the contention window to be reset inbetween the retries (this is what Jonathan Guerin initially reported). Another effect is that we have WAY to many retries for a single frame. Also I think it does not make sense to have say 6 retries with the same rate, when we have other rates to try. I even wonder how the minstrel algorithm can work efficiently with this, but I didn't have the time to look closer into minstrel, and I won't be able to do that any time soon. bruno -- 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
