On 13 September 2011 00:27, Bob Copeland <m...@bobcopeland.com> wrote:

> The hardware handles it - the tx descriptor specifies a list of rates
> and number of attempts to retry the frame and the hardware reports
> back how many tries at which rates were used (of course upper layers might
> retransmit packets unknown to ath5k but that is a different matter.)

And for the sake of completeness (and freebsd-specific; someone can
figure out how this is done in ath5k) there's configuration to
determine:

* the CW min, max values;
* the backoff algorithm used - it should be a binary exponential by default
* the frame RTS/CTS try limit - according to the documentation, the
try count in the descriptor is the number of air attempts (ie, the
frame is put in the air but not ACKed) - ie long retries, versus RTS
attempts (short).

The relevant bits from the FreeBSD ar5212 HAL:

cwmin, cwmax, aifs:

        /* set cwMin/Max and AIFS values */
        OS_REG_WRITE(ah, AR_DLCL_IFS(q),
                  SM(cwMin, AR_D_LCL_IFS_CWMIN)
                | SM(qi->tqi_cwmax, AR_D_LCL_IFS_CWMAX)
                | SM(qi->tqi_aifs, AR_D_LCL_IFS_AIFS));

Retry limit values:

        /* Set retry limit values */
        OS_REG_WRITE(ah, AR_DRETRY_LIMIT(q),
                   SM(INIT_SSH_RETRY, AR_D_RETRY_LIMIT_STA_SH)
                 | SM(INIT_SLG_RETRY, AR_D_RETRY_LIMIT_STA_LG)
                 | SM(qi->tqi_lgretry, AR_D_RETRY_LIMIT_FR_LG)
   // Frame short retries (RTS) before the current TX series is failed
                 | SM(qi->tqi_shretry, AR_D_RETRY_LIMIT_FR_SH)
 // Frame long retries (data TX with no ACK) before the current TX
series is failed
        );

The TX descriptor completion status indicates RTSFail and DataFail
counts - which are valid for the final TX series. FinalTsIdx tells you
what the final Tx series was.
I'm sure there's code in ath5k which will figure out how many actual
failures that is based on the TX queue config.

You can get a decent enough idea of the attempted TX time. Just please
keep in mind that this doesn't tell you how long the hardware waited
to try and transmit the frame. You can likely calculate the
per-attempt duration and cumulative backoff times, but not the time
after backoff whilst it waits for a quiet period to TX in.

I _think_ that's all correct. Good luck. :)



Adrian
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Reply via email to