On 22/01/14 19:32, Thomas Hühn wrote: > Hi all, > > I do also agree that the expected throughput [=max_throughput(mac_throughput_rate) * success_probability(max_throughput_rate)] is the value of interest. > For my current power control development I just use those minstrel statistics per client, that are provided via debugfs and parse those values that I am interested. > Maybe it is an alternative option for your development of batman is such a way to use those debugfs statistics, where you have all information, expected throughput included. And once your experimentation shows which subset of those stats is sufficient for a better routing performance, you go for a proper api. Or are you already confident about the expected throughput value is the one and only ? > The only stable point is that the our metric will be "throughput based"...the way how this "throughput" is computed could also change in the future.. Actually for experiment purposes I have already implemented my hacky cfg80211 API and I am using it (therefore I have no real need to use these debugfs stats). Now I would like to bring this API to the next level and merge it. The experiments performed shown that bitrate*probability is a reasonable value to use. But even if in the future we may decide to change how this "expected throughput" is computed I think there is no problem as soon as the semantic of the API is remains consistent (=return expected throughput). Cheers, > Greetings Thomas > > On 22.01.2014, at 15:43, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > >> On Wed, 2014-01-22 at 15:41 +0100, Antonio Quartulli wrote: >> >>> 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. >> >> I think that's a better choice, yes. >> >> johannes >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Antonio Quartulli
Attachment:
signature.asc
Description: OpenPGP digital signature
