Re: [ath5k-devel] Computing packet transmission time in ath5k
Dear Adrian and Bob, Thanks again for your comments. We were able to figure out the exact number of retransmissions and the rate at which retransmission was attempted by looking at the fields ts_retry and ts_rates from the structure ath5k_tx_status included in the TX descriptor. However, the reason why we were overestimating transmission times was that the function ath5k_hw_get_frame_duration() computed transmission times as if we were in 11b mode with long preambles, when instead we were using 11g. We have now avoided this problem with a dirty hack, but I think that the main problem remains (I am working on kernel 2.6.38, maybe this is solved in 3.0?). In 2.6.38 the function ath5k_hw_get_frame_duration() is basically a wrapper for: ieee80211_generic_frame_duration(sc-hw,NULL, len, rate); The problem, I think, is that the function is called with the second parameter being NULL, and in that case ieee80211_generic_frame_duration() always assumes 11b and long preamble, which was not correct in our case. Here you can see the code of ieee80211_generic_frame_duration(): __le16 ieee80211_generic_frame_duration(struct ieee80211_hw *hw, struct ieee80211_vif *vif, size_t frame_len, struct ieee80211_rate *rate) { struct ieee80211_local *local = hw_to_local(hw); struct ieee80211_sub_if_data *sdata; u16 dur; int erp; bool short_preamble = false; erp = 0; if (vif) { sdata = vif_to_sdata(vif); short_preamble = sdata-vif.bss_conf.use_short_preamble; if (sdata-flags IEEE80211_SDATA_OPERATING_GMODE) erp = rate-flags IEEE80211_RATE_ERP_G; } dur = ieee80211_frame_duration(local, frame_len, rate-bitrate, erp, short_preamble); return cpu_to_le16(dur); } Best Regards Daniel De: Adrian Chadd adr...@freebsd.org Para: Bob Copeland m...@bobcopeland.com CC: Dani Camps danicamp...@yahoo.com; ath5k-devel@lists.ath5k.org ath5k-devel@lists.ath5k.org Enviado: martes 13 de septiembre de 2011 2:49 Asunto: 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
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
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
[ath5k-devel] Computing packet transmission time in ath5k
Dear all, I am trying to compute the duration of a transmitted packet in ath5k, my goal is to be able to measure network utilization as the sum of transmitted and received frames over the air. Regarding transmission time I have added the following code to ath5k_txbuf_setup: - static int ath5k_txbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf, struct ath5k_txq *txq, int padsize) { struct ath5k_hw *ah = sc-ah; struct ath5k_desc *ds = bf-desc; rc_flags = info-control.rates[0].flags; hw_rate = (rc_flags IEEE80211_TX_RC_USE_SHORT_PREAMBLE) ? rate-hw_value_short : rate-hw_value; pktlen = skb-len; //== My code: Start frame_len = (int) pktlen - padsize + FCS_LEN; ack_tx_time = compute_ack_duration(ah, rate); bf-frame_tx_duration = ath5k_hw_get_frame_duration(sc-ah, frame_len, rate) + (unsigned long long) ack_tx_time; //== My code: End - Where frame_tx_duration is a new int field that I have defined in ath5k_buf. The problem that I am having is that the previous code seems to overestimate the transmission time, but I do not know why. The only thing that occurs to me is whether the rate variable in ath5k_txbuf_setup is actually smaller than the rate that the HW actually uses. Could this be possible ? Or maybe my frame_len computation is not correct ? It would be really helpful if anyone can give me some advice, on why the previous code overestimates transmission time, and if possible on what would be a better way to compute the transmission time of the packet. I am currently testing this with kernel 2.6.38 and with an Atheros AR5413 chipset. Best Regards Daniel___ 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
Hi, I forgot to mention that the function compute_ack_duration(ah, rate); is simply equivalent to ath5k_hw_get_frame_duration(ah, 10, rate); Best Regards Daniel De: Dani Camps danicamp...@yahoo.com Para: ath5k-devel@lists.ath5k.org ath5k-devel@lists.ath5k.org Enviado: viernes 9 de septiembre de 2011 15:35 Asunto: Computing packet transmission time in ath5k Dear all, I am trying to compute the duration of a transmitted packet in ath5k, my goal is to be able to measure network utilization as the sum of transmitted and received frames over the air. Regarding transmission time I have added the following code to ath5k_txbuf_setup: - static int ath5k_txbuf_setup(struct ath5k_softc *sc, struct ath5k_buf *bf, struct ath5k_txq *txq, int padsize) { struct ath5k_hw *ah = sc-ah; struct ath5k_desc *ds = bf-desc; rc_flags = info-control.rates[0].flags; hw_rate = (rc_flags IEEE80211_TX_RC_USE_SHORT_PREAMBLE) ? rate-hw_value_short : rate-hw_value; pktlen = skb-len; //== My code: Start frame_len = (int) pktlen - padsize + FCS_LEN; ack_tx_time = compute_ack_duration(ah, rate); bf-frame_tx_duration = ath5k_hw_get_frame_duration(sc-ah, frame_len, rate) + (unsigned long long) ack_tx_time; //== My code: End - Where frame_tx_duration is a new int field that I have defined in ath5k_buf. The problem that I am having is that the previous code seems to overestimate the transmission time, but I do not know why. The only thing that occurs to me is whether the rate variable in ath5k_txbuf_setup is actually smaller than the rate that the HW actually uses. Could this be possible ? Or maybe my frame_len computation is not correct ? It would be really helpful if anyone can give me some advice, on why the previous code overestimates transmission time, and if possible on what would be a better way to compute the transmission time of the packet. I am currently testing this with kernel 2.6.38 and with an Atheros AR5413 chipset. Best Regards Daniel___ 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
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