On Thu, 2013-04-11 at 11:56 +0200, Johannes Berg wrote: > On Tue, 2013-04-09 at 13:34 +0200, Antonio Quartulli wrote: > > > > Anyway my concern is that you're adding something that's rather minstrel > > > specific. It's not really usable by any other algorithm, you're > > > reporting minstrel's estimation of the throughput. If you report the > > > current "best" rate, that'll probably get you pretty much the same > > > behaviour overall, but be more portable to other algorithms I think. > > > > I understand your concern. My guess was that every algorithm was "somehow" able > > to provide such measurement. The point is that the throughput value is computed > > so that it also take probability of success into consideration. > > This means that two nodes using the same rate may have different throughputs > > (and this is important when building our distributed metric). > > > > However, nothing prevents any algorithm to implement the API the way it can do. > > I've not looked into other RC implementations yet, but I guess they would have a > > similar value to return too? > > Maybe, yeah. > > Anyway, I think having a separate externally visible API here is > overkill. It would seem a lot simpler to return it (to userspace) in the > station information, and (separately) allow other kernel modules to > request station information as well. > > Also I'm not sure it should be called "max_tp"? It's more like "expected > throughput" or something like that? Hm, no, that's not really it either ... It's maybe more like "current usable data rate" (as opposed to PHY rate?) 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
