Return-path: Received: from mail-wm0-f48.google.com ([74.125.82.48]:36834 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751988AbcFJJCh convert rfc822-to-8bit (ORCPT ); Fri, 10 Jun 2016 05:02:37 -0400 Received: by mail-wm0-f48.google.com with SMTP id n184so257696925wmn.1 for ; Fri, 10 Jun 2016 02:02:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87inxhl90y.fsf@toke.dk> References: <20160603165144.17356-1-toke@toke.dk> <20160603165144.17356-6-toke@toke.dk> <8737orucq4.fsf@toke.dk> <87k2i1ml43.fsf@toke.dk> <87wpm1b6bu.fsf@toke.dk> <87inxhl90y.fsf@toke.dk> From: Michal Kazior Date: Fri, 10 Jun 2016 11:02:35 +0200 Message-ID: (sfid-20160610_110244_396875_A7DD4D01) Subject: Re: [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Adrian Chadd , make-wifi-fast@lists.bufferbloat.net, ath9k-devel , "linux-wireless@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 10 June 2016 at 10:53, Toke Høiland-Jørgensen 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 > below. > >> 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". Michał