Toke Høiland-Jørgensen <t...@toke.dk> writes:
>> No idea. If that's possible, then track last MPDU within PPDU, so you
>> can at least fallback to _something_ when you detect a new first
>> (A-)MPDU?
>>
>> Or maybe it's impossible (i.e. not worth worrying) and HW always
>> reports last MPDU as far as status bits are concerned (regardless of
>> it being _actual_ last MPDU, i.e. it just says "ok, I'm done with this
>> PPDU").
>
> I'll try a couple of different permutations of this and see what works.
> Thanks for the ideas!
OK, so having tried all the different approaches, this seems to be the
best one. Basically, this:
if (rs->rs_isaggr && rs->rs_firstaggr) {
an->airtime_rx_start = rs->rs_tstamp;
} else if (rs->rs_isaggr && !rs->rs_moreaggr && an->airtime_rx_start) {
airtime = rs->rs_tstamp - an->airtime_rx_start;
} else if (!rs->rs_isaggr) {
an->airtime_rx_start = 0;
/* keeping the previous length-based calculation here */
}
This seems to give me RX airtime figures that correspond fairly well to
the TX airtime for running the same test in the opposite direction (I'm
running a ten-second UDP flood test and looking at the total airtime
accounted after the end of the run).
-Toke
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
