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? 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
