On 2020-02-27 12:07, Toke Høiland-Jørgensen wrote: > Felix Fietkau <nbd@xxxxxxxx> writes: > >>> Not sure I fully understand your concerns here. The AQL budget is per >>> STA, per TID, so frames queued in the driver's special queue for one >>> station won't impact another station's budget. Those frames are >>> counted towards the per interface pending airtime, which could trigger >>> AQL to switch to use the lower queue limit. In this case, that could >>> be the desirable behavior when there is heavy traffic. >> Yes, the per interface limit is what I'm concerned about. I'm not sure >> if it will be an issue in practice, it's just something that I noticed >> while reviewing the code. > > Ah, right. Note that it's not a hard limit, though; it's just a > threshold for when the per-station limit switches to a smaller value. > The idea is that when there are many stations with outstanding data, > each station's latency will be higher since they have to also wait for > their turn to transmit. And so we compensate for this by lowering each > station's queue limit, since the hardware is unlikely to become idle > when there are many stations to send to. > > The lower limit is still 5ms of data, though, so there should still be > enough for a full aggregate queued for each station. Arguably the limit > could actually be made *smaller*: On a very busy network with lots of > stations transmitting at once, IMO we *don't* want to send full-sized > aggregates as that will add up to way too much latency. Better to > sacrifice a bit of network efficiency to raise responsiveness :) Makes sense, thanks. - Felix
