Ath5k and Retransmissions (Retries)

Ath5k and Retransmissions (Retries)

[Andrew Blaich]

Hi everyone,

   I have been attempting, unsuccessfully, to alter the number
retransmissions any particular transmission rate uses.  My card is
reported as an AR5414 (Atheros) and the ath5k driver is being loaded.
My understanding based on the source code in compat-wireless is that
the retry count for the rates are set, ideally in the rate control
algorithm, e.g. minstrel, and is then passed off to the hardware at
some point in the transmit chain.  Is there a lower limit that the
hardware accepts for retransmission values?  I've been trying to set
the value to 1 and then potenially to 0 to completely disable
retransmissions, for experimentation purposes.  However, despite
whatever value the data structures in the codereport back to me, I've
been through what I believe to be every file in the compat-wireless
that deals with  retries, when I sniff the wireless channel using a
separate node I am still seeing retransmissions being produced for the
particularly flow I have established.

Is this a hardware issue of which I will not be able to fix the
retransmissions, or is there something more obvious I am missing and
perhaps you can lend some wisdom as to the appropriate locations to
change the retry limit so that the hardware will obey the value.

Thank you.

-Andrew

Re: Ath5k and Retransmissions (Retries)

[Bob Copeland]

On Thu, Feb 25, 2010 at 9:40 AM, Andrew Blaich <ablaich@gmail.com> wrote:
> Hi everyone,
>
>   I have been attempting, unsuccessfully, to alter the number
> retransmissions any particular transmission rate uses.  My card is
> reported as an AR5414 (Atheros) and the ath5k driver is being loaded.

What exactly are you changing?  The MRR array determines how many
retries there are for a given packet (hint, each packet has a
set of 4 different rates and each rate has its own retry count).
The driver also tells mac80211 the max number of retries.

-- 
Bob Copeland %% www.bobcopeland.com

Re: Ath5k and Retransmissions (Retries)

[Andrew Blaich]

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.

 If I want the driver to try the packet once and only once , if it
fails (no ack) then give up, what would be the changes to make to the
MRR array.

 My understanding is I would set the ar[0].idx value the index for the
rate I want (this is not an issue), but then setting the ar[0].count,
do I set it to 1 to try and send it once, or is count simply the
number of retries to do after the initial send.  Also, if I set the
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?

-Andrew



On Thu, Feb 25, 2010 at 12:51 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Thu, Feb 25, 2010 at 9:40 AM, Andrew Blaich <ablaich@gmail.com> wrote:
>> Hi everyone,
>>
>>   I have been attempting, unsuccessfully, to alter the number
>> retransmissions any particular transmission rate uses.  My card is
>> reported as an AR5414 (Atheros) and the ath5k driver is being loaded.
>
> What exactly are you changing?  The MRR array determines how many
> retries there are for a given packet (hint, each packet has a
> set of 4 different rates and each rate has its own retry count).
> The driver also tells mac80211 the max number of retries.
>
> --
> Bob Copeland %% www.bobcopeland.com
>

Re: Ath5k and Retransmissions (Retries)

[Bob Copeland]

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

Re: Ath5k and Retransmissions (Retries)

[Andrew Blaich]

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@bobcopeland.com> 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
>
>

Re: Ath5k and Retransmissions (Retries)

[Bob Copeland]

On Sat, Feb 27, 2010 at 12:39:51PM -0500, Andrew Blaich wrote:
> 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.

Hrm, yeah that should probably go away.

-- 
Bob Copeland %% www.bobcopeland.com