From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8A3103B2B5 for ; Fri, 10 Jun 2016 04:53:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 5CA4340B38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1465548815; bh=Cnf6SIfvLjzaUommpICac93b65c8qhZJQkYnraPmniY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dX7TmqRYxidZ1bTo/Yn7dAqOt7pTxaXs9RtAPCwg0HIl7fcUm1y/4O21khK/8Hs3p XcFPeO1qpFFGROnCLyvDClR3WMDxrq277U5lsO45y1d84OOZo0r1ea01vd9E+1qXce IbRE30LLn80DyGJk//1/1QkEIReVYKpPOecAqllw= Sender: toke@toke.dk Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 2AC09767CEA; Fri, 10 Jun 2016 10:53:34 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Michal Kazior Cc: Adrian Chadd , make-wifi-fast@lists.bufferbloat.net, ath9k-devel , "linux-wireless\@vger.kernel.org" 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> Date: Fri, 10 Jun 2016 10:53:33 +0200 In-Reply-To: (Michal Kazior's message of "Fri, 10 Jun 2016 10:40:49 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87inxhl90y.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 08:53:37 -0000 >> 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? Is the entire A-MPDU received before the RX handler is called for the first frame? -Toke