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
