On 04/13/2018 06:48 AM, Kalle Valo wrote:
I agree with Sven on the usage or expectation of get_expected_throughput
Sven Eckelmann <sven.eckelm...@openmesh.com> writes:
But of course, I cannot say much about how the rate control from QCA works and
in which form these information are already available.
If you want to know the average PHY rate then wouldn't it be better to report
the rates to one of the upper layers and let them to the averaging? Similar to
what there already is for NL80211_STA_INFO_CHAIN_SIGNAL
(NL80211_STA_INFO_CHAIN_SIGNAL_AVG) just for NL80211_STA_INFO_TX_BITRATE/
NL80211_STA_INFO_RX_BITRATE. Not sure whether this makes sense or whether
someone has an use-case for it.
Sounds like a good idea, but I don't see it preventing to apply this
patch. We can always change the implementation later as this is just
communication between ath10k and mac80211, right?
It's not really ab expected throughput implementation.
However I'm with Kalle about approving this patch as Sven also mentioned
"here sounds a little bit like in "Our medical doctor would ideally not
decapitate each patient but we have at least an MD"".
I could improve it once merged since there are more members in
ath10k_per_peer_tx_stats useful such as succ_bytes, failed_bytes,
duration, and etc.