[Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit
michal.kazior at tieto.com
Fri Jun 10 05:02:35 EDT 2016
On 10 June 2016 at 10:53, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>> 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.
> As an aside, I'm no longer sure this explanation for why I got wrong
> timings for this way of measuring RX time is correct. It may simply be
> that I was counting the same time interval more than once because I
> didn't realise that the handler would be called for each frame. See
>> I think rs_tstamp in rx-status is different for first MPDU and last
>> MPDU in an A-MPDU meaning you should be able to compute the entire
>> duration (if you track it, and this should be fairly straightforward
>> as you can't really rx interleaved MPDUs from different
>> A-MPDUs/stations). I'm not sure if the last MPDU defines the tstamp of
>> first symbol or last one.
> I actually went down this path again last night, but haven't had a
> chance to test it yet.
> So what I have now is this:
> /* Only count airtime for last frame in an aggregate. FIXME: Should
> * this be only the first frame? */
> if (!rs->rs_isaggr || !rs->rs_moreaggr)
> airtime = (tsf & 0xffffffff) - rs->rs_tstamp;
> Which was under the assumption that rs_tstamp will be the time of the
> first symbol *of the whole ampdu* for all the frames in that aggregate.
> However, if rs_tstamp differs between frames, tracking it at the first
> frame might be the right things to do?
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).
> Is the entire A-MPDU received before the RX handler is called for the
> first frame?
No idea. Maybe it is as there's distinction between "more" and "moreaggr".
More information about the Make-wifi-fast