Re: [ath5k-devel] Computing packet transmission time in ath5k
Dear Adrian,
Thanks for your answer. I was aware of some of the issues you mention, the
problem is that I do not know how to solve them. Anyway, for my purposes I do
not need a 100% accurate estimation of the utilization but a good enough one.
What is indeed surprising to me is that the different items you mention should
lead us to an underestimation of the actual utilization, e.g. we consider
higher ACK rates, and do not consider potential slow retransmissions, or
RTS/CTS. Therefore I think that there is something fundamentally wrong in what
we are doing.
In particular, as indicated in the previous email every time a packet is to be
transmitted we compute its expected transmission time and attach it to the
ath5k_buf structure. However, we only actually add up this transmission time to
the cumulated transmission time when the hardware sends back an signal saying
that the frame has been transmitted or dropped, in function
ath5k_tx_processq. Specifically within this loop:
static void
ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
{
list_for_each_entry_safe(bf, bf0, txq-q, list) {
// Add the estimated transmission time of the packet in bf to the cumulated
channel utilization
...
}
What I am not thinking is whether it is possible that the same packet stays in
list during several times that the function ath5k_tx_processq is called, and
therefore we are adding up the transmission time of the same packet several
times when it should only be counted once. Does this make any sense ?
Best Regards
Dani
De: Adrian Chadd adr...@freebsd.org
Para: Dani Camps danicamp...@yahoo.com
CC: ath5k-devel@lists.ath5k.org ath5k-devel@lists.ath5k.org
Enviado: sábado 10 de septiembre de 2011 6:06
Asunto: Re: [ath5k-devel] Computing packet transmission time in ath5k
Hi,
This isn't strictly involved in fixing your problem, but when you do
get it fixed, you're going to notice a bunch of discrepancies:
* the ack calculation is lifted from elsewhere in the code, but please
note that they use the basic rate for ACKs, not the current TX rate.
Please re-read the code in qcu.c that calculates the ack_tx_time :-)
* your airtime calculation isn't taking into account the hw rate being
used when doing multi-rate retry.
* your airtime calculation doesn't take into account how many
short/long retries were taken.
* what about the RTS frame (and the rate it's TXed at, which can be
different to the frame rate) ? And then the time spent on the return
CTS?
Just stuff to think about :)
adrian___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Computing packet transmission time in ath5k
You should only add to your channel usage estimate it if the buffer has been marked complete - ie: * the status bit in the descriptor indicates DMA is complete; * .. and the relevant flags say that it did go on the air or try to go on the air - ie, it can fail but still have been attempted. I don't have the code open in front of me but i bet it's pretty clear when the descriptor has been classified as complete, successful or otherwise. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Computing packet transmission time in ath5k
On Mon, Sep 12, 2011 at 4:47 AM, Dani Camps danicamp...@yahoo.com wrote: What I am not thinking is whether it is possible that the same packet stays in list during several times that the function ath5k_tx_processq is called, and therefore we are adding up the transmission time of the same packet several times when it should only be counted once. Does this make any sense ? This is absolutely the case. Packets are only considered transmitted when the tx status callback is invoked. And (for now) completed packets might remain in the list as well. -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] 5MHz channel width support in ath5k
Hi, I am new in using ath5k driver and heard that ath5k support 5MHz channel width. But no clue to how to configure it. If you known how to do it, would you please show me the steps to or changes needed in code. Thanks Brady___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Computing packet transmission time in ath5k
On Mon, Sep 12, 2011 at 02:43:48PM +0100, Dani Camps wrote: Where it is in ath5k_tx_processq() that you loop over all packets submitted for transmission by ath5k but not yet completely processed by the hardware. Therefore you might loop through this list for a certain packet more than once My doubt now would be related to retransmissions. Are retransmission handled by ath5k and therefore go through some of the functions previously mentioned? Or instead retransmissions are completely handled by the hardware and so ath5k does not see them ? 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.) -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Computing packet transmission time in ath5k
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
