From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DC9BE3B2BD for ; Fri, 10 Jun 2016 05:02:36 -0400 (EDT) Received: by mail-wm0-x236.google.com with SMTP id v199so139717969wmv.0 for ; Fri, 10 Jun 2016 02:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gOargVKJggC5aLWNKsxGn2P5cg6mJRHBGVdAsV8hrpk=; b=glKpmdk83SuQzh0u4EamyeOkoZZqWaG72/cjNmb6MQ2cdg5dNTNVR4X8w01dqM9f3Z 3yPrOt67FPsmadN3p6XP5VeizerP/iv+mO809o+kj/pC77Q2OQaRyGOO30K2r1vlN93c lT+cmtfSzi0CGgCcQn8e+U/tkiN5b6Oazv9RI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gOargVKJggC5aLWNKsxGn2P5cg6mJRHBGVdAsV8hrpk=; b=ZopBljJDO6Gc7DrjSZzcsyWZ3mtbLt6t2b1mrHlju0GuseRCiFSzGl5+sQlM7Ic9v6 Z/XJx/x5N9ycz7GxRtsH84ln2WykkCFIapYHJQ9ZujQig2tWQ6IuKK7S2zRZiQGS2tiT NZb5+utK6izyTL9uDouMdFV7iUUyq5zvnMghUnSXKeplVnZ5JdJEc6keZbyseYC9V8d0 F4Mg30PYj1o7nX6OUg4e6zKObiBk5GcGlMSv7IZx3W7Ts8Fbm1wsNXavBy+a8zk+wjkR /ALSRUr4KtJZ5TmSsRzrXGt+8rapZAusDgHH88tVvYvjpIZl++Oy7McZ3gAGxuJ1zE38 ENlQ== X-Gm-Message-State: ALyK8tJ0YF4eyKTQdXHZKked1ISnOzJzcMURVt15qTwwzzlreSi49IVIizpAjPKIMmdG41PsEW4fJZIOnqEPPzNGcViLV3XWOXPi2ilqL/Kmd31His/jKrXKHnxEIpnFun53cVgUBnHknJ6yJAOWEtfpu8EoVKVasRiX/g== X-Received: by 10.194.134.164 with SMTP id pl4mr1173788wjb.113.1465549355942; Fri, 10 Jun 2016 02:02:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.36 with HTTP; Fri, 10 Jun 2016 02:02:35 -0700 (PDT) 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: 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 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com 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 09:02:37 -0000 On 10 June 2016 at 10:53, Toke H=C3=B8iland-J=C3=B8rgensen w= rote: > >>> 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: Shoul= d > * this be only the first frame? */ > if (!rs->rs_isaggr || !rs->rs_moreaggr) > airtime =3D (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=C5=82