> > According to 802.11n-2009 the BA originator could send a BlockAckReq if > an AMPDU is not BlockAcked in time. However, I never see the hw sending a > BlockAckReq. > Not sending BAR (BlockAckReq) can be quite problematic. The originator needs to send BAR to tell the recipient that the frames that are pending in the reordering buffer can be released to the upper level even if there are holes in the packet sequence. Not sending BAR could in theory lead to deadlock. In practice, most implementations of reordering buffers release frames out of order after timeout. taken from rx.c of mac80211: /* * Timeout (in jiffies) for skb's that are waiting in the RX reorder buffer. If * the skb was added to the buffer longer than this time ago, the earlier * frames that have not yet been received are assumed to be lost and the skb * can be released for processing. This may also release other skb's from the * reorder buffer if there are no additional gaps between the frames. * * Callers must hold tid_agg_rx->reorder_lock. */ #define HT_RX_REORDER_BUF_TIMEOUT (HZ / 10) I am quite surprised that you see that frames are "stuck in the driver". This would mean that the windows drivers's implementation of the reordering buffer doesn't have timer... or I miss something... > At least, I hacked rt2x00 to set IEEE80211_TX_STAT_AMPDU_NO_BACK for failed > aggregated frames such that mac80211 sends a BlockAckReq for this failed MPDU > and this indeed seems to improve the situation but doesn't fix it completely. Can you please be more specific by "improve situation" ? better TPT ? lower packet loss ? What do you mean by not fixed completely ? Do you track packets out of the driver ? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
