Thanks to the help from Bob on which area to focus in the code I was able to manipulate the number of retries per rate to the value I needed. It should be noted that any card that uses the ath5k_hw_setup_4word_tx_desc function (e.g 5212 and like devices) has an additional 4 retries, AR5K_TUNE_HWTXTRIES, added to the value in tx_tries0 the sum of which , appears to be, is written to the AR5K_4W_TX_DESC_CTL2_XMIT_TRIES0 register on the device. This is not obvious to the rate control algorithm as it calculate its own set of retries, and then has to deal with another 4 tries being added on in a different portion of the driver, unless it was originally assumed that this is going to calculated in? -Andrew On Fri, Feb 26, 2010 at 7:48 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: > On Thu, Feb 25, 2010 at 12:59:50PM -0500, Andrew Blaich wrote: > (top posting undone) >> The main file I focused on was net/mac80211/rc80211minstrel.c, but I >> have tried forcing retry values through the other portions of the >> code. >> >> I have tried setting the counts in the MRR array (ar[i].count) in the >> minstrel_get_rate function, but that hasn't appeared to work, >> additionally I tried limiting the max retry count. I have had luck in >> altering the rate used by changing the index value fed into ar[i].idx. >> Maybe my issue is with the MRR array. > > Well, this should work. The ath5k side of this is ath5k_txbuf_setup: > > ret = ah->ah_setup_tx_desc(ah, ds, pktlen, > ieee80211_get_hdrlen_from_skb(skb), > get_hw_packet_type(skb), > (sc->power_level * 2), > hw_rate, > info->control.rates[0].count, keyidx, ah->ah_tx_ant, flags, > cts_rate, duration); > > info->control.rates[0] is the TX rate (which may be different > for e.g. rts/cts frames than the one from the rate controller), > and the mrr rates are set up just after that: > > ah->ah_setup_mrr_tx_desc(ah, ds, > mrr_rate[0], mrr_tries[0], > mrr_rate[1], mrr_tries[1], > mrr_rate[2], mrr_tries[2]); > > > The .count field in the mac80211 rate struct is the number of > tries, not retries, to be precise. > >> next entry in the MRR array ar[1].idx=-1 so as to not try any rate, >> and then the count to 0 does this disable the rest of the MRR array, >> or is it possible the hardware is populating the array with other >> values? > > That should be the case due to memset and get_alt_retry_rate semantics, > but if you suspect a problem you can printk in the above spots. > > If the hardware doesn't respect those, there is some bug somewhere. > > (Also see hw->max_rate_tries in ath5k_pci_probe()). > > -- > Bob Copeland %% www.bobcopeland.com > > -- 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
