In this document I will analyze the timeline for single frame transmission and explain different behaviors of intercepting the frame transmission.
In the following experiments I set and clear FORCE_QUIET_COLLISION bit for certain amount of time after the ath9k driver pushes a frame into the hardware, and observe corresponding behavior to see if the transmission has truly been intercepted. The parameters I used for all of the following experiments are CW=0, AIFS=0. In this way I can reduce variables in experiments and obtain a more consistency result.
In this experiment the timing for starting and ending TX intercepting falls within the first ~148us after the ath9k driver pushes a frame into the hardware. See following figure for an illustration.
If FORCE_QUIET_COLLISION bit is set during this period (it is crucial that this bit is cleared before 148us), it ends up not intercepting the transmission at all, i.e. the adapter proceeds to transmit normally and emits a TX_OK interrupt after ~952us from the time the ath9k drvier pushed a frame into the hardware.
In this experiment the timing for ending TX intercepting falls within 148~926us after the ath9k driver pushes a frame into the hardware. See following figure for an illustration.
If FORCE_QUIET_COLLISION bit is set during this period, the interceping is successfully done and the adapter will emit a TX_OK interrupt after ~955us from the time when FORCE_QUIET_COLLISION bit is cleared.
In this experiment the timing for starting TX intercepting falls after 926us from the time when the ath9k driver pushes a frame into the hardware. See following figure for an illustration.
If FORCE_QUIET_COLLISION bit is set during this period (note that the timing for clearing this bit can exceed 952us), it won't intercept the actual transmission of current frame (becasue the actual transmission of current frame is already done). However, it will suppress the TX_OK interrupt from being emitted, therefore the ath9k driver won't know the adapter has successfully transmitted current frame. The ath9k driver has to wait until the FORCE_QUIET_COLLISION bit is cleared to learn about the successful transmission.
Note that in this situation, if combined with my modified ath9k TX path, there can be unfairness in the next competing period. This is because my modified TX path relies on TX_OK interrupt to push next frame into the hardware. If the actual frame has been transmitted (i.e. the hardware buffer now has no more frame to transmit) but the TX_OK interrupt is suppressed, the adapter won't get its next frame to transmit once the FORCE_QUIET_BIT is cleared, instead it needs to wait TX_OK interrupt being emitted and the ath9k driver pushes next frame into its buffer, which can be a delay of 30~40us. In the meanwhile, any other node whose transmission was successfully intercepted will hold the not-yet-transmitted frame in its hardware buffer, so it won't need to wait for its next frame to transmit once the FORCE_QUIET_BIT is cleared, giving it an advantage in competing the channel.
In another word, if the actual frame has been transmitted but TX_OK interrupt is suppressed, the adapter can get into a situation where it wins the channel access but has no frame to transmit at that time. It can't do anything but to wait the driver pushes next frame or yield channel access to another node, whichever comes first.
This problem won't happen with the original ath9k TX path because multiple frames are pushed into the hardware buffer at the same time, the adapter can directly proceed to next frame in buffer and try transmitting it in next competing period.