On 2019-09-25 16:11, Toke Høiland-Jørgensen wrote:
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...
Do you mean we will use airtime reported by FW to calculate
local->airtime_queued in case we have FW reporting airtime?
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
--
Yibo
