Search Linux Wireless

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux