From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 9B88C3B25D for ; Sun, 5 Jun 2016 07:40:38 -0400 (EDT) Received: by mail-yw0-x230.google.com with SMTP id h19so118256931ywc.0 for ; Sun, 05 Jun 2016 04:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/BnYnRXhySCx5QXJnoO66+dCPmytB1krSWN3EZxFvHI=; b=jbXqTQ7HunIfuwI6KaZ6lEwyh6Aaxs++df/FrRuB+QyVTfzNZ8j5zM615GNtukZiA7 bQSGC6RuIXNSH3tdFLo/zWI03vfSvQxG3AZwrH947vwSRUS6XbSyFuiP1/vtR5IhcnTf 4XcwYjVM0m+ugEkg/I9TrnYR5euFbaGA0T5hvdLdwHjr1d4Jl9M9MlIioNYqGtPzdH8x bithtoFPcupgfPtl3o2a1MTsD0fUMdbMC5vHw59Bjb8CQSWcH1qE6oC9NnvDOo/wIsac vmpAePZZJzd57loezqDVvQxowrJXyeNCGsjaJpQ2fj4v1zxCKAJD9ZZ+3xhnrtbnbobJ lGEw== 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:date :message-id:subject:from:to:cc; bh=/BnYnRXhySCx5QXJnoO66+dCPmytB1krSWN3EZxFvHI=; b=XRu4ni2sVSTjCoFnU1sOyUuk4RAkZCF+CJAjd/DuSqsas4IraO2z/C5Z0Rpg/zlNFo mt3aSAoEGhEAJWn8MEJLgLYGbPaLuqVrBoJXj8waUVIbp3Rfb0K0En9ftIOIq24QVMsU nB6Hu3OW1IGM+O68L7C9/gkC2E5v/DQlzY7cRr77tG5/rlVKHRKdqLaA1vUs+lfrdwQk p3S68EorzIX6Ld90tM1f7bDypqX3AuLhj+Xdi3ITSAzUsTXTAFm9zK/MbhTZ/uGutfFl W1/azaBHXiCmfQ4l5KmXZYpd4oSN3HtwdN8/DS322xM54Ax16BEAneru1EAIq+TcQDug CdAA== X-Gm-Message-State: ALyK8tIeWaoBMVcpnNn6nzluBN68xWk/2zbtETwzm4Dh9xjyLEBakPwiR4yB+wLUUUMojeNGLHQOs1EUnW5zjg== MIME-Version: 1.0 X-Received: by 10.129.154.204 with SMTP id r195mr7816282ywg.119.1465126838026; Sun, 05 Jun 2016 04:40:38 -0700 (PDT) Received: by 10.37.74.134 with HTTP; Sun, 5 Jun 2016 04:40:37 -0700 (PDT) In-Reply-To: <877fe3ucvl.fsf@toke.dk> References: <20160603165144.17356-1-toke@toke.dk> <877fe3ucvl.fsf@toke.dk> Date: Sun, 5 Jun 2016 13:40:37 +0200 Message-ID: From: Luca Muscariello To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: "linux-wireless@vger.kernel.org" , "make-wifi-fast@lists.bufferbloat.net" , "ath9k-devel@lists.ath9k.org" Content-Type: multipart/alternative; boundary=94eb2c0b7964bb4ad70534866c2c Subject: Re: [Make-wifi-fast] [RFC/RFT 0/5] Adding an airtime fairness scheduler to ath9k 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: Sun, 05 Jun 2016 11:40:38 -0000 --94eb2c0b7964bb4ad70534866c2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, 5 June 2016, Toke H=C3=B8iland-J=C3=B8rgensen wro= te: > Luca Muscariello > writes: > > > I don't fully understand your plots but it would be useful to report > > the physical rate of the stations. > > Yes, well, there's not really one rate to report for each station, since > Minstrel jumps about a bit and tries different ones. > > I know. Try a simple case, one STA very close one far away. I am able to get quite stable average PHY rates with minstrel. 5GHz and a free channel can also help to get low variance in your numbers. A Faraday cage can also help :) . > > As a benchmark, if you know the physical rates assuming they are also > > optimally chosen (by minstrel for instance ) and stations don't move, > > the long term throughout can be computed ( e.g. for TCP ) assuming air > > time fairness. Than you can understand if your gain is what you should > > expect or if the implementation is not yet done. > > So far I've just been looking at the figures for airtime (the first > graph in the blog post). These are the same numbers that the scheduler > uses to make scheduling decisions. It seems like the scheduler does help > somewhat, but is not perfect yet. Am definitely lacking a good ground > truth to compare against, though. Computing the expected throughput > might be possible, since minstrel does report statistics for how many > packets were transmitted at each rate. Will look into it; thanks for the > suggestion :) > > -Toke > --94eb2c0b7964bb4ad70534866c2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, 5 June 2016, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Luca Muscariello <luca.muscariel= lo@gmail.com> writes:

> I don't fully understand your plots but it would be useful to repo= rt
> the=C2=A0 physical rate of the stations.

Yes, well, there's not really one rate to report for each station, sinc= e
Minstrel jumps about a bit and tries different ones.


I know. Try a simple case, one STA ver= y close one far away. I am able to get quite stable average PHY rates with = minstrel. 5GHz and a free channel=C2=A0can also help to get low variance in= your numbers. A Faraday cage can also help :) .=C2=A0

=C2=A0
> As a benchmark, if you know the physical rates assuming they are also<= br> > optimally chosen (by minstrel for instance ) and stations don't mo= ve,
> the long term throughout can be computed ( e.g. for TCP ) assuming air=
> time fairness. Than you can understand if your gain is what you should=
> expect or if the implementation is not yet done.

So far I've just been looking at the figures for airtime (the first
graph in the blog post). These are the same numbers that the scheduler
uses to make scheduling decisions. It seems like the scheduler does help somewhat, but is not perfect yet. Am definitely lacking a good ground
truth to compare against, though. Computing the expected throughput
might be possible, since minstrel does report statistics for how many
packets were transmitted at each rate. Will look into it; thanks for the suggestion :)

-Toke
--94eb2c0b7964bb4ad70534866c2c--