<div dir="ltr">Hi,<div><br></div><div>after doing some tests with different ath10k Wi-Fi cards and clients, I found the following behaviour when combining AQL and the airtime scheduler: </div><div><br></div><div>- When using the default AQL limits (threshold 24000, limits per AC 5000/12000), the airtime scheduler is not working at all, regardless of the airtime weights of the STAs. Indeed, in some cases, slower stations were able to use a higher amount of airtime, leading to unfairness. I was thinking that maybe the default AQL limits are too high to these slow stations, allowing them to obtain too much pending airtime. I already used the last patches from <span class="gmail-il">Felix</span> Fietkau with the same results. </div><div><br></div><div>- Indeed, I was able to activate the airtime scheduler by fixing lower AQL limits (e.g. threshold of 5000, limits per AC 0/5000). This way, it seems that the STAs start competing again for the airtime, and their behaviour follows the airtime weights. However,  slower STAs lose a bit of performance due to these lower limits. </div><div><br></div><div>- The airtime weights have to be higher (e.g. 10000 vs 20000 to obtain a 33% vs 66% relation); I found the same behaviour using ath9k and 11n cards, so I guess this is due to the aggregation of packets.  </div><div><br></div><div>Looking into the code, it seems that the key airtime check is the one in ieee80211_tx_dequeue. To enable the airtime scheduling, the "ieee80211_txq_airtime_check" function has to return false more usually; maybe it is just a matter of adjusting the AQL limits according to the airtime weights or to modify a bit the "ieee80211_txq_airtime_check" function to consider the airtime weight or the deficit of the stations. </div><div><br></div><div>Cheers,</div><div>Miguel. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 30 jun. 2020 a las 17:41, Toke Høiland-Jørgensen (<<a href="mailto:toke@redhat.com" target="_blank">toke@redhat.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Miguel Catalan Cid <<a href="mailto:miguel.catalan@i2cat.net" target="_blank">miguel.catalan@i2cat.net</a>> writes:<br>
<br>
> Hi,<br>
><br>
> Do we need to use a specific firmware? It's ok to use the last one from<br>
> kvalo, or should we use the one from candelatech?<br>
<br>
Shouldn't matter, I think; the airtime scheduler tries to do its thing<br>
in software. It does have to work around the firmware, to a certain<br>
extent, though, which I suspect is why it doesn't work quite so well as<br>
on ath9k.<br>
<br>
Incidentally, this "impedance mismatch" between scheduler and firmware<br>
is what this patch was supposed to fix:<br>
<br>
<a href="https://lore.kernel.org/linux-wireless/20191222172423.131033-1-toke@redhat.com/" rel="noreferrer" target="_blank">https://lore.kernel.org/linux-wireless/20191222172423.131033-1-toke@redhat.com/</a><br>
<br>
Never did get around to respinning it, so not sure if it still applies.<br>
If it does, you could try taking it for a spin; otherwise I can try<br>
updating it so you can apply it and test :)<br>
<br>
-Toke<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><font color="#666666">Miguel Catalán Cid, PhD<br><br>Mobile Wireless Internet Group (MWI)<br>i2CAT Foundation, Barcelona, Spain<br><a href="http://www.i2cat.net/" target="_blank">http://www.i2cat.net/</a></font></div></div></div></div>