Toke Høiland-Jørgensen <toke@xxxxxxx> writes: >> [snip] >> >> I also found one of my notes in my version of this - how can we >> estimate the duration of an A-MPDU, when we only get hardware >> de-encapsulated frames? > > Well in my case I'm sidestepping this by getting the TX duration from > a register in the hardware. There seems to be registers containing the > duration spent on each step in the retry chain; I simply sum these. Ah, but you're still talking RX? Hmm, I'm using ath_pkt_duration() to compute the RX time, which does take into account MIMO (I think) but expects the size to include padding. Which is probably not included in the rs_datalen field of struct ath_rx_status that I'm using. So yeah, how to account for that? I initially thought that using the timestamp put into the frame by the hardware could be a way to get timing. But there's only a timestamp of the first symbol in rs_tstamp, and getting a time to compare it with is difficult; by the time the frame is handled in the rx tasklet, way too much time has been spent on interrupt handling etc for the current time to be worth comparing with. -Toke -- 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
