On 21/01/14 17:32, Antonio Quartulli wrote: > On 21/01/14 17:18, Johannes Berg wrote: >> On Tue, 2014-01-21 at 17:09 +0100, Antonio Quartulli wrote: >> >>>> Actually this isn't expected throughput, but >>>> wouldn't something like expected throughput make even more sense? >>> >>> How should I obtain that if not with the previous operation (bitrate*prob)? >> >> Minstrel actually has some tables for that, no? This would still just >> only be the raw bitrate, not the actual throughput. > > I will check within Minstrel, but in this way we are limiting batman-adv > to use only what Minstrel thinks to be the "expected throughput"....And > if this turns to be something not adequate we will have to change > API. > > Johannes, do you think that an API exporting the "expected throughput" would be a acceptable? At that point any RC algorithm can implement it the way it prefers. Moreover, if users realise that the API is not returning a proper value we can still fix the implementation in the future (as soon as it still returns something called "expected throughput"). Can this be the way to go? At this point we forget about the concept of rate and we move to throughput, which is what we are really interested in. Cheers, -- Antonio Quartulli
Attachment:
signature.asc
Description: OpenPGP digital signature
