On 2018-04-14 01:54, Peter Oh wrote:
On 04/13/2018 06:48 AM, Kalle Valo wrote:
Sven Eckelmann <sven.eckelmann@xxxxxxxxxxxx> 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?
I agree with Sven on the usage or expectation of
get_expected_throughput cabllback.
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.
On each packet sent successfully, driver has the success_bytes details.
Throughput calculation can be done using these bytes and tx rate
(tx_rate * bytes),
send this average value to mac80211. is this you are thinking of?
Thanks,
Anil.
