From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 7B62B3B2C9 for ; Fri, 10 Jun 2016 05:20:16 -0400 (EDT) Received: by mail-wm0-x22f.google.com with SMTP id v199so140337248wmv.0 for ; Fri, 10 Jun 2016 02:20:16 -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=jG/AZUy9ICTUfFHYyKSqtHP2lYievwMVW5JfGmZlx7w=; b=NhUr0iB1oUzZjzMuC4xY11tGg2p5k/c5KUQR4g9a0AOWLVF3a6g72BCWpNL2DmjaRN d/RYTwSUerqRXUSXjyrSxIR1+ijZzP9Alda3fRRObp8ZsEmGAR1ju95OKrgYQVnucwWU HV1f8/0JySR6MUXBC/zqmNmDTTbCX1O3Yq+7c= 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=jG/AZUy9ICTUfFHYyKSqtHP2lYievwMVW5JfGmZlx7w=; b=g7M1pCPO76Rnht9Me6qsQB3f4ADZ3mC2rcg82oRxXFY1L3yYFRmeoIKTBe3ohkhq20 X5EzjteoURpkhBJ4QegfE1F1Y8+mxedeRbRk5qjjsHrJR0u39rcNllHQZGcHx619n/2f GqbMs/5QPvXbi0h+ZYDz2j2ybu5qJN2eY5HpQYzK96kRtMffbVnWUEMwvRMn0xB0cjcf cBs9IJbPA0Lvd3suOUgjYQQEGxIK+5QNk9Xe7FLUblSGTOAbsbQX0k0j8QkTpCL3iOEn oxJkzFBrvnyuLpt4YCbaA1BnNqK6KzKZckSzd1g+xTrpjRGnhNhRn8SUpM6dgqBZS/7J /r/g== X-Gm-Message-State: ALyK8tJWxQVlaSrVV2HLUHBTnpNYRfBYx8JAoNnD7UAV7YIBpkhx99UWUArNYpsu6JehXJs9MzBehhHgfJWGV4xkMS2u/qd1ygtCXj0YRof2QJ1qL0m50fKhcF112I9fhIsMyIjKaj8AjvJJRaMel58fCwfLTG/VbbKODA== X-Received: by 10.194.134.164 with SMTP id pl4mr1269380wjb.113.1465550415596; Fri, 10 Jun 2016 02:20:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.36 with HTTP; Fri, 10 Jun 2016 02:20:14 -0700 (PDT) In-Reply-To: <877fdxl8cu.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> <877fdxl8cu.fsf@toke.dk> From: Michal Kazior Date: Fri, 10 Jun 2016 11:20:14 +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:20:16 -0000 On 10 June 2016 at 11:08, Toke H=C3=B8iland-J=C3=B8rgensen w= rote: > Michal Kazior writes: > >> 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). > > Right. So comparing the rs_stamp between first and last MPDU should give > the duration of the entire thing? Depends on how you define your "thing" :) I no, I don't know what you'll actually measure. It should be reasonable either way. > This would require keeping state > between subsequent calls to the RX handler. Also, what happens if the > last MPDU is lost? 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"). >>> 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". > > Hmm. If it is, comparing the stamp of the first MPDU to the current time > (when handling it) should give the needed duration? Will try doing that > and see what the result is. I'd say it's a little racy/inaccurate (and perhaps unreliable) to compare any kind of global timer and compare it against your rx-status descriptors. Micha=C5=82