Re: [PATCH 1/3] cfg80211: add get_max_tp() API

[Antonio Quartulli <antonio@open-mesh.com>]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

On Thu, Apr 11, 2013 at 02:57:41AM -0700, Johannes Berg wrote:
> 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.

Ok, sounds good!

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

Mh..well, it is not a "real" value, so I would not use neither "expected" nor
"usable". It is supposed to be the result of a computation giving us an
estimation of the current/last throughput. "estimated throughput" sounds bad?

Well the name is not really important I guess :) I start sending some code using
the latter. We may change it at the end before merging (if you decide to do so).

Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]