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 C7E8D3B2A0 for ; Fri, 10 Jun 2016 11:33:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 2D30B40B3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1465572787; bh=uOQM4NjILYQimFmxHrklt29C2t6zgTX7kfp1xlz28iE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Mkx9yRSWmCNjLymy5WEzGWTg7E28R7SXKoYJpjMgKt5wnO06a1hb5+w8par426XJY 1PoH9wIxpbWYt1y5p2jp0jhjAfdxpPp1uwXC6sTBiHD3rKAb1lO08AJkT0yUX8dcUB wv1KJDGOqMwY76//Ddbk6bbd969i6xO/WVRZK2tQ= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 37A60C40197; Fri, 10 Jun 2016 17:33:06 +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> <87inxhl90y.fsf@toke.dk> <877fdxl8cu.fsf@toke.dk> <8737oll6fu.fsf@toke.dk> Date: Fri, 10 Jun 2016 17:33:06 +0200 In-Reply-To: <8737oll6fu.fsf@toke.dk> ("Toke =?utf-8?Q?H=C3=B8iland-J?= =?utf-8?Q?=C3=B8rgensen=22's?= message of "Fri, 10 Jun 2016 11:49:25 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wplxawjx.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 15:33:09 -0000 Toke H=C3=B8iland-J=C3=B8rgensen 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 =3D rs->rs_tstamp; } else if (rs->rs_isaggr && !rs->rs_moreaggr && an->airtime_rx_start) { airtime =3D rs->rs_tstamp - an->airtime_rx_start; } else if (!rs->rs_isaggr) { an->airtime_rx_start =3D 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