From: Jouni Malinen (jkmaline_at_cc.hut.fi)
Date: 2002-10-12 08:27:48 UTC
On Thu, Oct 10, 2002 at 10:57:42AM +0800, hao wrote:
> I dump the tx frame header when the interrupt HFA384X_EV_TX is called,but I found that the seq number do not continuous increase; when the interrupt HFA384X_EV_TXEXC is called ,I dump the tx header and do not found the frame with same seq number. why(this kind of frame need retransmition)? otherwise,I dump the time stamp when the prism2_transmit is called and the HFA384X_EV_TX is called,Can the duration between them be considered as delay of this frame.
I'm not exactly sure that I understood what you are doing, but maybe these clarifications could help you. Each TX frame from the host get only one TX event. This will be either TX or TXExc depending on whether the transmit was consider successful. If a unicast frame is retransmitted, it will still get only one TX or TXExc event. Firmware sets seq# and it should be unique for frames so you should not see the same seq# in other TX frame.
If you would like to match TX/TXExc event to a transmitted frame, you should use txfids. Transmit command records the txfid in local->intransmitfid table and TX/TXExc should have matching txfid in TXCOMPLFID register.
Time interval between prism2_transmit and matching TX is includes possible retransmission attempts. In addition, it includes frame queuing in the firmware code. In other words, this value would show how much time was spent from the moment the frame was queued to the firmware to the moment the frame was ACKed (or in case of broadcast/multicast frame the moment it was sent). It cannot, e.g., be used to resolve how long time it takes for a station to ACK one TX frame since this time interval includes queueing and possible retransmissions.
-- Jouni Malinen PGP id EFC895FA