Yibo Zhao <yiboz@xxxxxxxxxxxxxx> writes: > So if it is going to work together with virtual time based mechanism in > the future, the Tx criteria will be met both of below conditions, > 1. Lower than g_vt > 2. Lower than IEEE80211_AIRTIME_QUEUE_LIMIT > Are we going to maintain two kinds of airtime that one is from > estimation and the other is basically from FW reporting? Yes, that was my plan. For devices that don't have FW reporting of airtime, we can fall back to the estimation; but if we do have FW reporting that is most likely going to be more accurate, so better to use that for fairness... > Meanwhile, airtime_queued will also limit the situation that we only > have a station for transmission. Not sure if the peak throughput will > be impacted. I believe it may work fine with 11ac in chromiumos, how > about 11n and 11a? Well, we will need to test that, of course. But ath9k shows that it's quite possible to run with quite shallow buffers, so with a bit of tuning I think we should be fine. If anything, slower networks need *fewer* packets queued in the firmware, and it's *easier* for the host to keep up with transmission. > Anyway, I think this approach will help to improve performance of the > virtual time based mechanism since it makes packets buffered in host > instead of FW's deep queue. We have observed 2-clients case with > different ratio in TCP fails to maintain the ratio because the packets > arriving at host get pushed to FW immediately and thus the airtime > weight sum is 0 in most of time meaning no TXQ in the rbtree. For UDP, > if we pump load more than the PHY rate, the ratio can be maintained > beacuse the FW queue is full and packtes begin to be buffered in host > making TXQs staying on the rbtree for most of time. However, TCP has its > own flow control that we can not push enough load like UDP. Yes, fixing that is exactly the point of this series :) -Toke
