Sven Eckelmann <sven.eckelmann@xxxxxxxxxxxx> writes: > On Mittwoch, 28. März 2018 11:41:51 CEST akolli@xxxxxxxxxxxxxx wrote: > [...] >> The rate average and throughput are relative. no? > > In the sense that rate has a tendency to affect the expected throughput - yes. > But it is not like the expected throughput perfectly correlates with the rate > and you only have to multiply with a factor X (which seems to be missing in > your code) to get from rate to expected throughput. The average packet loss > for this selected rate, interframe spacing and the aggregation are important > factors here too. I doubt we can get that information from the firmware so should we just go with the "multiple with X" method? What would be good X? > 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? -- Kalle Valo
