On Mon, Feb 05, 2007 at 07:29:58PM +0100, Jiri Benc wrote: > No. It's the other way around, when they're reported immediately, they > will be out of order. ieee80211_tx_status is called from the interrupt > handler as the result of the frame being actually sent. Before that, a > frame can sit for an arbitrary long time in the hw queue or not sent at > all. Reporting only frames confirmed by ieee80211_tx_status as > successfully sent at the time the function is called reflects better > what is on the air (it's still not perfect as things like > retransmissions are not caught). What is your definition for "successfully sent" in this context? I would probably also include frames that did not receive ACK, but did have some transmit tries. If there is place for reporting TX status (ack/no ack, number of retries) that could be added here. In addition, some hardware designs may also return the timestamp of the transmission in TX status, so that could also be added. This would actually make it possible to figure out the exact sequence of frames (in userspace app), if needed. -- Jouni Malinen PGP id EFC895FA - 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
