Michal Kazior <michal.kazior@xxxxxxxxx> writes: > On 10 June 2016 at 11:08, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: >> Michal Kazior <michal.kazior@xxxxxxxxx> writes: >> >>> For A-MPDU all MPDU rx status (except last one) should share the same >>> timestamp. Last one has a different one so all you need is to >>> distinguish first and last MPDU. Non A-MPDU obviously are special case >>> (status bits are pricky). >> >> Right. So comparing the rs_stamp between first and last MPDU should give >> the duration of the entire thing? > > Depends on how you define your "thing" :) I no, I don't know what > you'll actually measure. It should be reasonable either way. "Time spent receiving from this station" is the overall metric I want. In this case that then becomes "Time spend receiving this aggregate" which I can then account to that stations' total RX airtime. >> This would require keeping state between subsequent calls to the RX >> handler. Also, what happens if the last MPDU is lost? > > 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! >>> No idea. Maybe it is as there's distinction between "more" and >>> "moreaggr". >> >> Hmm. If it is, comparing the stamp of the first MPDU to the current time >> (when handling it) should give the needed duration? Will try doing that >> and see what the result is. > > I'd say it's a little racy/inaccurate (and perhaps unreliable) to > compare any kind of global timer and compare it against your rx-status > descriptors. Well, the timer would be the one coming from the card (tsf in the code snippet I posted comes from ath9k_hw_gettsf64()). But yeah, it is going to account some things that are not *strictly* air time (interrupt latency for one). However, the question is how much this really contributes (at least in cases where we are not running behind because of lack of CPU). And if there's a constant overhead it shouldn't matter so much as long as it is the same for all stations. Certainly just timestamping packets with the current time works well enough in the qdisc layer... -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
