From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 22FCF3B2A4 for ; Tue, 30 Jun 2020 11:33:14 -0400 (EDT) Received: by mail-il1-x131.google.com with SMTP id t4so4917592iln.1 for ; Tue, 30 Jun 2020 08:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i2cat.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BlxrHGVylPkc3hm1t2UaNMFUn8Xt6TTrfi88vuX2HIQ=; b=Ye9eaNO7uQaXWSLGdXa1eoNQYe40l2JVtK+ACWuf24nCjzd551e9kXfk4r+gvuTcSP f2gPqmVvgJ31i6hVU5SektugpSbvdzUGrHkuyp5NG1iyCaIOzLsIvZ8GUc6+88zW8e+k VlX1kg+/kpkJSh2qsjWnPu3E0oZlkYExGTts2ZLNRwOnlAsH3TZ+YdBhZywKpwrRj3dD Iu4XqYXE0sx80Hk7BhX4a88hBzLtrllWYV8yWNxaFFrkPEd0Vy1vti2YObUcFA8T0Lmx 0xPa5TJd8gfeIB6CZth71cEIc4vWVUOq80hZSCGRqiTzJeq47sfuPQCVqYQsPBM8RfDT SsFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BlxrHGVylPkc3hm1t2UaNMFUn8Xt6TTrfi88vuX2HIQ=; b=o+lWVgSigGhkSLSJ1pwAwVBf7t2jeniglQjBpB0ms/tfiHMw3dXGcDDPtTtSQ9q9ad x8+D7y21d7lZ9NgyYzErSwQLe0JaAlZzV9ZUuLmDOghxsEeCNGERxDHyP2tCj6KZ4dye p6AYVKDO8mZt7gljybfpcT5k4hWqhkiN4WLc1Jn1Y0Ym9C9rk/dZ5JfA2SVQkvLP0egY IWHdFXGWKNJ9x0o/UrM1ymqU+cv2nWZv3Zf8hy1q3uqTqsqcYFdsHC4+GtJPuSsgnN3Y CjnMYuEGtmlddOa4FtjjuWH1Y0jyVjNQF8oh/p408284LFE7bLuEknbKPloMYdd9p68I cwMg== X-Gm-Message-State: AOAM533peUf8AT4n95jrfmzQtR2CX+s/z8M9YQeFWTSTnnpLYEkY/iYl uyAuR9FWDH3dO/7l18Thcf/EBcOMDUtm3VSXCfbFkw== X-Google-Smtp-Source: ABdhPJxbIiR2qwCovgcnLW33+vo9elGlMa6jggP+CUVLOEpURATb+Qpq4zfAIMzntn3m1PDuQTNF3/mMB+0VHye8lPA= X-Received: by 2002:a05:6e02:e43:: with SMTP id l3mr3098179ilk.11.1593531193496; Tue, 30 Jun 2020 08:33:13 -0700 (PDT) MIME-Version: 1.0 References: <87zh8uruou.fsf@toke.dk> <87366ei2x7.fsf@toke.dk> In-Reply-To: <87366ei2x7.fsf@toke.dk> From: Miguel Catalan Cid Date: Tue, 30 Jun 2020 17:33:02 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org Content-Type: multipart/alternative; boundary="000000000000ba3b4405a94ee439" Subject: Re: [Make-wifi-fast] Support for airtime scheduling using ath10k 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: Tue, 30 Jun 2020 15:33:14 -0000 --000000000000ba3b4405a94ee439 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Do we need to use a specific firmware? It's ok to use the last one from kvalo, or should we use the one from candelatech? Best, Miguel. El lun., 29 jun. 2020 a las 12:26, Toke H=C3=B8iland-J=C3=B8rgensen () escribi=C3=B3: > Miguel Catalan Cid writes: > > > El mar., 23 jun. 2020 a las 11:35, Toke H=C3=B8iland-J=C3=B8rgensen > > () escribi=C3=B3: > >> > >> Miguel Catalan Cid writes: > >> > >> > Hi, > >> > > >> > we are trying to apply different airtime weights to different > stations in > >> > order to have some prioritization among connected stations. While > this is > >> > working pretty well with ath9k, with ath10k we always obtain a fair > >> > distribution of the airtime (i.e. 50%-50% in the case of two > stations), > >> > regardless of the airtime weight specified. > >> > > >> > E.g. STA1: > >> > RX: 0 us > >> > TX: 2295610622 us > >> > > >> > *Weight: 200*Deficit: VO: 256 us VI: 256 us BE: 34 us BK: 256 us > >> > > >> > E.g. STA2: > >> > RX: 0 us > >> > TX: 162597077 us > >> > >> 2295610622/162597077 ~=3D 14 > >> > >> which is not *too* far from the 20/1 ratio you've configured? Does the > >> ratio change at all when you change the weights (i.e., if they are > >> equal, do you get closer to a 50/50 split?). > >> > >> Do the two stations have roughly the same signal strength / rate? > > > > In this case I started the STA1 a bit earlier, so it had a higher > > airtime aggregate. Indeed, to compare the airtime share, I was > > continuously monitoring the "airtime rate" (i.e. the difference > > between Airtime(now) and Airtime (now-4s)) and the results of both > > STAs were the same (i.e. 50/50 split) independently of the weight > > being used. But when using ath9k the same test runs perfectly > > according to the weights. > > > >> > >> > *Weight: 10*Deficit: VO: 256 us VI: 256 us BE: 9 us BK: 256 us > >> > > >> > We are using Compex WLE650V5-18A cards. > >> > > >> > So, does ath10k support airtime scheduling? In such a case, do we ne= ed > >> > specific Wi-Fi cards? > >> > >> It should. My guess would be that maybe you're not getting enough > >> backpressure for the scheduler to actually enforce things correctly. Y= ou > >> could try to look at the TXQ output and see if you actually have any > >> drops ('iw dev wlan0 station dump -v' and look at the drops/marks > >> columns). > > > > ok, i will check! > > Another thing to check is the value of 'new_flows' in the TXQ output; if > that is high, it indicates that the queues run empty a lot, which can > prevent the airtime fairness scheduler from working properly. > > >> What kernel version are you running? If it's not new enough to have AQ= L, > >> that might help moving the backlog to where the scheduler can do more > >> with it. > > > > Kernel 5.5.5. > > Hmm, that should have AQL, actually. > > -Toke > > --=20 Miguel Catal=C3=A1n Cid, PhD Mobile Wireless Internet Group (MWI) i2CAT Foundation, Barcelona, Spain http://www.i2cat.net/ --000000000000ba3b4405a94ee439 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Do we need to use a specific firmwa= re? It's ok to use the last one from kvalo, or should we use the one fr= om candelatech?

Best,
Miguel.=C2=A0

El lun., 29 jun. 2020 a las 12:26, Toke H=C3=B8iland-J=C3=B8rgensen (<<= a href=3D"mailto:toke@redhat.com">toke@redhat.com>) escribi=C3=B3:
Miguel Catalan Ci= d <miguel.= catalan@i2cat.net> writes:

> El mar., 23 jun. 2020 a las 11:35, Toke H=C3=B8iland-J=C3=B8rgensen > (<toke@redhat.= com>) escribi=C3=B3:
>>
>> Miguel Catalan Cid <miguel.catalan@i2cat.net> writes:
>>
>> > Hi,
>> >
>> > we are trying to apply different airtime weights to different= stations in
>> > order to have some prioritization among connected stations. W= hile this is
>> > working pretty well with ath9k, with ath10k we always obtain = a fair
>> > distribution of the airtime (i.e. 50%-50% in the case of two = stations),
>> > regardless of the airtime weight specified.
>> >
>> > E.g. STA1:
>> > RX: 0 us
>> > TX: 2295610622 us
>> >
>> > *Weight: 200*Deficit: VO: 256 us VI: 256 us BE: 34 us BK: 256= us
>> >
>> > E.g. STA2:
>> > RX: 0 us
>> > TX: 162597077 us
>>
>> 2295610622/162597077 ~=3D 14
>>
>> which is not *too* far from the 20/1 ratio you've configured? = Does the
>> ratio change at all when you change the weights (i.e., if they are=
>> equal, do you get closer to a 50/50 split?).
>>
>> Do the two stations have roughly the same signal strength / rate?<= br> >
> In this case I started the STA1 a bit earlier, so it had a higher
> airtime aggregate. Indeed, to compare the airtime share, I was
> continuously monitoring the "airtime rate" (i.e. the differe= nce
> between Airtime(now) and Airtime (now-4s)) and the results of both
> STAs were the same (i.e. 50/50 split) independently of the weight
> being used. But when using ath9k the same test runs perfectly
> according to the weights.
>
>>
>> > *Weight: 10*Deficit: VO: 256 us VI: 256 us BE: 9 us BK: 256 u= s
>> >
>> > We are using Compex WLE650V5-18A cards.
>> >
>> > So, does ath10k support airtime scheduling? In such a case, d= o we need
>> > specific Wi-Fi cards?
>>
>> It should. My guess would be that maybe you're not getting eno= ugh
>> backpressure for the scheduler to actually enforce things correctl= y. You
>> could try to look at the TXQ output and see if you actually have a= ny
>> drops ('iw dev wlan0 station dump -v' and look at the drop= s/marks
>> columns).
>
> ok, i will check!

Another thing to check is the value of 'new_flows' in the TXQ outpu= t; if
that is high, it indicates that the queues run empty a lot, which can
prevent the airtime fairness scheduler from working properly.

>> What kernel version are you running? If it's not new enough to= have AQL,
>> that might help moving the backlog to where the scheduler can do m= ore
>> with it.
>
> Kernel 5.5.5.

Hmm, that should have AQL, actually.

-Toke



--
Miguel Catal=C3=A1n Cid, PhD

Mobile Wireless Internet= Group (MWI)
i2CAT Foundation, Barcelona, Spain
http://www.i2cat.net/
=
--000000000000ba3b4405a94ee439--