linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mattias Nissler <mattias.nissler@gmx.de>
To: Holger Schurig <hs4233@mail.mn-solutions.de>
Cc: linux-wireless@vger.kernel.org,
	Nick Kossifidis <mickflemm@gmail.com>,
	Stefano Brivio <stefano.brivio@polimi.it>,
	"John W. Linville" <linville@tuxdriver.com>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
Date: Wed, 05 Dec 2007 10:04:04 +0100	[thread overview]
Message-ID: <1196845444.7472.6.camel@localhost> (raw)
In-Reply-To: <200712050849.46760.hs4233@mail.mn-solutions.de>


On Wed, 2007-12-05 at 08:49 +0100, Holger Schurig wrote:
> On Tuesday 04 December 2007 23:05:28 Nick Kossifidis wrote:
> > [  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  3.242 ms
> > [  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  4.439 ms
> > [  3]  0.0-60.0 sec  32.7 MBytes  4.57 Mbits/sec
> ...
> 
> 
> Could it be the case that if we test the PID controller such way,
> then we optimize for throughtput in a scenario like "laptop sits 
> next the the AP".
> 
> Or, in other words: if we put the AP 80m away and then try the 
> test, would the same PID parameters that yielded high MB/s rates 
> now still keep us a sane (for that distance!) connection?

Good question. The important parameter here is the failed frames
precentage target value. If we're sitting next to the AP, the percentage
of failed frames will be very low, so the PID controller won't ever be
able to tune the TX rate to increase the failed frames percentage to the
target value. So this is not the right test case for tuning PID rate
control parameters. It'd be interesting to find out about the failed
frames percentage target value that gives us the best throughput. And
then do this experiment several times for different levels of distance
(or noise). Then see whether the optimal value is constant or not.

At the moment, I'm still cleaning up the rate control code. I also plan
to add some debugfs support, so we can retrieve the relevant data from
the kernel and make graphs from them. Only when this is done, I'm gonna
resume tuning parameters.

Mattias


  reply	other threads:[~2007-12-05  9:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-02 19:05 [RFC][PATCH] mac80211: Use PID controller for TX rate control Mattias Nissler
2007-12-03  3:16 ` Stefano Brivio
2007-12-03  3:26   ` Stefano Brivio
2007-12-03 11:03   ` Mattias Nissler
2007-12-03 11:21     ` Tomas Winkler
2007-12-03 11:31       ` Mattias Nissler
2007-12-04 13:40         ` Johannes Berg
2007-12-04 17:45           ` Mattias Nissler
2007-12-05 10:16             ` Johannes Berg
2007-12-04 17:48           ` Stefano Brivio
2007-12-03 11:58       ` Stefano Brivio
2007-12-03 11:54     ` Stefano Brivio
2007-12-03 11:59       ` Mattias Nissler
2007-12-03 12:06         ` Stefano Brivio
2007-12-03 22:42           ` Nick Kossifidis
2007-12-03 23:36             ` Mattias Nissler
2007-12-04  1:41             ` Stefano Brivio
2007-12-04  8:15               ` Mattias Nissler
2007-12-04 10:01                 ` Stefano Brivio
2007-12-04 17:40                   ` Mattias Nissler
2007-12-04 17:57                     ` Stefano Brivio
2007-12-04 18:33                       ` Mattias Nissler
2007-12-04 18:40                         ` Stefano Brivio
2007-12-04 20:50                     ` Holger Schurig
2007-12-04 20:57                       ` Mattias Nissler
2007-12-04 22:05               ` Nick Kossifidis
2007-12-05  7:49                 ` Holger Schurig
2007-12-05  9:04                   ` Mattias Nissler [this message]
2007-12-05  9:52                   ` Stefano Brivio
2007-12-05 12:13                     ` rc80211-pid: some tuning test results Stefano Brivio
2007-12-08  3:42                       ` Stefano Brivio
2007-12-08 10:39                         ` Mattias Nissler
2007-12-08 11:17                           ` Stefano Brivio
2007-12-08  9:45               ` [RFC][PATCH] mac80211: Use PID controller for TX rate control Stefano Brivio

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=1196845444.7472.6.camel@localhost \
    --to=mattias.nissler@gmx.de \
    --cc=hs4233@mail.mn-solutions.de \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mickflemm@gmail.com \
    --cc=stefano.brivio@polimi.it \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).