All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <antonio@open-mesh.com>
To: "Thomas Hühn" <thomas@net.t-labs.tu-berlin.de>,
	"Johannes Berg" <johannes@sipsolutions.net>
Cc: Antonio Quartulli <antonio@meshcoding.com>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [RFC 1/5] cfg80211: export minstrel best rate information through get_station()
Date: Wed, 22 Jan 2014 19:44:02 +0100	[thread overview]
Message-ID: <52E01172.2080907@open-mesh.com> (raw)
In-Reply-To: <7C173B24-D062-49BE-836E-E0889633E955@net.t-labs.tu-berlin.de>

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

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@sipsolutions.net> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Antonio Quartulli


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

  reply	other threads:[~2014-01-22 18:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-21 11:09 [RFC 0/5] Export Minstrel best API information via get_station() Antonio Quartulli
2014-01-21 11:09 ` [RFC 1/5] cfg80211: export minstrel best rate information through get_station() Antonio Quartulli
2014-01-21 16:00   ` Johannes Berg
2014-01-21 16:09     ` Antonio Quartulli
2014-01-21 16:18       ` Johannes Berg
2014-01-21 16:32         ` Antonio Quartulli
2014-01-22 14:41           ` Antonio Quartulli
2014-01-22 14:43             ` Johannes Berg
2014-01-22 18:32               ` Thomas Hühn
2014-01-22 18:44                 ` Antonio Quartulli [this message]
2014-01-21 11:09 ` [RFC 2/5] mac80211: export minstrel best rate information in set_sta_info() Antonio Quartulli
2014-01-21 16:01   ` Johannes Berg
2014-01-21 11:09 ` [RFC 3/5] mac80211: minstrel - implement get_minstrel_best_rate() API Antonio Quartulli
2014-01-21 11:09 ` [RFC 4/5] mac80211: minstrel_ht " Antonio Quartulli
2014-01-21 11:09 ` [RFC 5/5] cfg80211: implement cfg80211_get_station Antonio Quartulli
2014-01-21 16:03   ` Johannes Berg
2014-01-21 16:07     ` Antonio Quartulli
2014-01-21 13:52 ` [RFC 0/5] Export Minstrel best API information via get_station() Thomas Hühn
2014-01-21 15:28   ` [B.A.T.M.A.N.] " Antonio Quartulli
2014-01-21 15:28     ` Antonio Quartulli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52E01172.2080907@open-mesh.com \
    --to=antonio@open-mesh.com \
    --cc=antonio@meshcoding.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=thomas@net.t-labs.tu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.