[ath9k-devel] ath9k rate control - rc.c

[ath9k-devel] ath9k rate control - rc.c

[Rakesh Kumar]

Is RSSI a parameter to rate control algorithm? It seems like it is
mantaining RSSI state and everything but when it comes to making the
decision of what rate to choose, it does that purely by maximizing expected
throughput which is a function of PER.
Just curious, why the part of codes relating to RSSI maintenance are there?
Do they represent change of directions during the development of rc.c code?

I apologize if this has been previously discussed on the list but who owns
the rc.c part of the ath9k code, in one of emails Louis had written that he
tries to stay away from it. :)

--
Rakesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091014/99548364/attachment.htm 

[ath9k-devel] ath9k rate control - rc.c

[Luis R. Rodriguez]

On Wed, Oct 14, 2009 at 03:10:10PM -0700, Rakesh Kumar wrote:
> Is RSSI a parameter to rate control algorithm?

I am not sure but it may be there for historical purposes.

> It seems like it is
> mantaining RSSI state and everything but when it comes to making the 
> decision of what rate to choose, it does that purely by maximizing 
> expected throughput which is a function of PER.

Yeah from what I recall this is how it worked too, but Vasanth may
know better.

> Just curious, why the part of codes relating to RSSI maintenance
> are there?

Maybe ANI, I forget.

> Do they represent change of directions during the development of rc.c code?

I don't think I understand your question.

> I apologize if this has been previously discussed on the list but who owns
> the rc.c part of the ath9k code, in one of emails Louis had written that
> he tries to stay away from it. :)

Well I stay away from it because IMHO its pretty convoluted. But I should note
that it was designed to be simple but more importantly to run really well
on low end MIPS APs. Another reason I stay away is I believe minstrel can
eventually be made MCS aware and it may work better. But someone has to
work on that first.

  Luis

[ath9k-devel] ath9k rate control - rc.c

[Rakesh Kumar]

>
> > Do they represent change of directions during the development of rc.c
> code?
>
> I don't think I understand your question.
>
>
I mean, you develop the basic stuff to implement an algorithm and then end
up not using those parameters.



> Well I stay away from it because IMHO its pretty convoluted. But I should
> note
> that it was designed to be simple but more importantly to run really well
> on low end MIPS APs.


It is convoluted primarily because it contains all these lines of code
corresponding to RSSI measurement that are not being used. Also, these parts
of code would be causing unnecessary slowing of the MIPS APs that you have
in mind. But all these arguments are futile if someone can point out that it
is crucial stuff and may be used for future development. I must mention that
I am using compat-wireless-2.31-rc4 code, maybe there has been more
development on this stuff after that?



> Another reason I stay away is I believe minstrel can
> eventually be made MCS aware and it may work better. But someone has to
> work on that first.
>
>
I can potentially hack minstrel and tailor it for ath9k but I really need to
be sure if that would be useful to the project that I am working on right
now, i.e. my Masters thesis. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091014/d86057ff/attachment.htm 

[ath9k-devel] ath9k rate control - rc.c

[Luis R. Rodriguez]

On Wed, Oct 14, 2009 at 6:11 PM, Rakesh Kumar <gopchandani@gmail.com> wrote:
>> > Do they represent change of directions during the development of rc.c
>> > code?
>> I don't think I understand your question.
>>
>
> I mean, you develop the basic stuff to implement an algorithm and then end
> up not using those parameters.

Ah, got it. Yeah this probably more like code was added eons ago, used
eons ago and never wiped clean after it stopped being used. At least
that is my speculation.

Care to point out exactly what variables you see are unused? If they
are definitely not used just send a patch and remove them, if one of
us does not complain then it'll get merged.

>> Well I stay away from it because IMHO its pretty convoluted. But I should
>> note
>> that it was designed to be simple but more importantly to run really well
>> on low end MIPS APs.
>
> It is convoluted primarily because it contains all these lines of code
> corresponding to RSSI measurement that are not being used. Also, these parts
> of code would be causing unnecessary slowing of the MIPS APs that you have
> in mind. But all these arguments are futile if someone can point out that it
> is crucial stuff and may be used for future development.

Sure -- since I am still not 100% clear it may be better for you to
just send a patch to remove this stuff, test it and see where it goes
from there.

> I must mention that
> I am using compat-wireless-2.31-rc4 code, maybe there has been more
> development on this stuff after that?

You mean 2.6.32-rc4? I think we did some major cleanups on rate
control code, but I do think those went in. Either way if you are
doing development you should *always* use wireless-testing. No ifs or
buts.

>> Another reason I stay away is I believe minstrel can
>> eventually be made MCS aware and it may work better. But someone has to
>> work on that first.
>>
>
> I can potentially hack minstrel and tailor it for ath9k but I really need to
> be sure if that would be useful to the project that I am working on right
> now, i.e. my Masters thesis. :)

That would be swell.

  Luis

[ath9k-devel] stlc45xx error

[bnc at netspeed.com.au]

All,
I have two issues
1) I am running kernel 2.6.31.3-1-desktop on a suse 11.2 system. I
checked the kernel config and it has all the 11n requirements set. I am
running the supplied ath9k and do not understand why I am connecting to
my dlink 11n capable router at 11g.

2) In view of the above I decided to download and compile
wireless-testing anyway. the make worked but the make modules gave me;

drivers/staging/stlc45xx/stlc45xx.c:2351: warning: initialization from
incompatible pointer type

So I did a search for the error and found that it was known and has
been suggested for removal;

In that case I guess probably the best option would be to remove
stlc45xx from staging as Kalle sugested. Users should migrate to p54spi
since it is already in /net/wireless/

Could this be done or could someone tell me how to remove it, or how I
can proceed.

Thanks,
Brian

[ath9k-devel] ath9k rate control - rc.c

[Vasanthakumar Thiagarajan]

On Thu, Oct 15, 2009 at 03:58:56AM +0530, Luis Rodriguez wrote:
> On Wed, Oct 14, 2009 at 03:10:10PM -0700, Rakesh Kumar wrote:
> > Is RSSI a parameter to rate control algorithm?
> 
> I am not sure but it may be there for historical purposes.

RSSI is never used to determine the tx rate. The code segment which
maintains rssi is removed in the latest rc kernel (2.6.32-rc). 

Vasanth

[ath9k-devel] ath9k rate control - rc.c

[Rakesh Kumar]

On Tue, Oct 20, 2009 at 12:51 AM, Vasanthakumar Thiagarajan <
vasanth@atheros.com> wrote:

>
> RSSI is never used to determine the tx rate. The code segment which
> maintains rssi is removed in the latest rc kernel (2.6.32-rc).
>
> Vasanth
>

Hey Vasanth,
Yes, you're right, my bad. I was using an old version of code from
2.6.30-rc4 which had those rssi calculations being done
which apparently were not contributing to the rate decision. Anyway,  I am
thinking about writing a new rate control algorithm which takes into account
the fact that ath9k is a MIMO card but I am having trouble identifying what
information is available to the driver programmer? Is there a comprehensive
document or something which explains it, if so is it available in public
domain?
I did stumble upon something here in mac.h:

struct ath_tx_status {
        u32 ts_tstamp;
        u16 ts_seqnum;
        u8 ts_status;
        u8 ts_ratecode;
        u8 ts_rateindex;
*        int8_t ts_rssi;*
        u8 ts_shortretry;
        u8 ts_longretry;
        u8 ts_virtcol;
        u8 ts_antenna;
        u8 ts_flags;
      *  int8_t ts_rssi_ctl0;*
*        int8_t ts_rssi_ctl1;*
*        int8_t ts_rssi_ctl2;*
*        int8_t ts_rssi_ext0;*
*        int8_t ts_rssi_ext1;*
*        int8_t ts_rssi_ext2;*
        u8 pad[3];
        u32 ba_low;
        u32 ba_high;
        u32 evm0;
        u32 evm1;
        u32 evm2;
};

I am just curious what these variables rssi_ctl0,ctl1,ctl2,ext0,ext1,ext2
contain?

Also the rssi measurement ts_rssi, what does it really represent on a 2 link
MIMO card? How is this number calculated and calibrated?


--
Rakesh Kumar,
Graduate Student,
Electrical and Computer Engineering Dept,
University of Illinois, Urbana-Champaign.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091020/9b5b5b39/attachment.htm 

[ath9k-devel] ath9k rate control - rc.c

[Vasanthakumar Thiagarajan]

On Tue, Oct 20, 2009 at 11:28:41AM +0530, Rakesh Kumar wrote:

>I am having trouble identifying what information is available to the driver programmer? Is there a comprehensive document or something which explains it, if so is it available in public domain?

As far as rate control parameters are concerned, h/w expects the
rate code and maximum number of tries at that rate. ath9k supports
retries at four different rates, say r0..r3 where r0 is the
highest ideal rate, r1 is the next highest and so on. I don't think
there is any doc on ath9k rc.

> I am just curious what these variables rssi_ctl0,ctl1,ctl2,ext0,ext1,ext2 contain?

These are just rssi values on contol channel and ext channel of chain 0
and chain 1.

> Also the rssi measurement ts_rssi, what does it really represent on a 2 link MIMO card?

This is combined rssi value out of active MIMO.

> How is this number calculated and calibrated?

I'm not quite sure how it is done in h/w.


Vasanth
 

[ath9k-devel] ath9k rate control - rc.c

[Rakesh Kumar]

>
>
> >I am having trouble identifying what information is available to the
> driver programmer? Is there a comprehensive document or something which
> explains it, if so is it available in public domain?
>
> As far as rate control parameters are concerned, h/w expects the
> rate code and maximum number of tries at that rate. ath9k supports
> retries at four different rates, say r0..r3 where r0 is the
> highest ideal rate, r1 is the next highest and so on. I don't think
> there is any doc on ath9k rc.
>

So are the ratecodes present in the current ratetables in rc.c exhaustive?
Is that all the rates hardware offers? Because 802.11n standard specifies
more rate configurations which are not all present in the ratetable.


> > I am just curious what these variables rssi_ctl0,ctl1,ctl2,ext0,ext1,ext2
> contain?
>
> These are just rssi values on contol channel and ext channel of chain 0
> and chain 1.
>
>
... and chain 2? There are total 3 chains on the card I am using (AR5008)
and one of them is -128 for both ctl1 and ext1

Could you elaborate what control and ext channels are? I tried to dump these
values out and typically this is what they look like:

ts_rssi = 49
ts_rssi_ctl0 = 48
ts_rssi_ctl1 = -128
ts_rssi_ctl2 = 40
ts_rssi_ext0 = 47
ts_rssi_ext1 = -128
ts_rssi_ext2 = 41

 --
Rakesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091020/448a8dd9/attachment.htm 

[ath9k-devel] ath9k rate control - rc.c

[Rakesh Kumar]

Am not sure if you received this previously?

On Tue, Oct 20, 2009 at 12:20 PM, Rakesh Kumar <gopchandani@gmail.com>wrote:

>
>> >I am having trouble identifying what information is available to the
>> driver programmer? Is there a comprehensive document or something which
>> explains it, if so is it available in public domain?
>>
>> As far as rate control parameters are concerned, h/w expects the
>> rate code and maximum number of tries at that rate. ath9k supports
>> retries at four different rates, say r0..r3 where r0 is the
>> highest ideal rate, r1 is the next highest and so on. I don't think
>> there is any doc on ath9k rc.
>>
>
> So are the ratecodes present in the current ratetables in rc.c exhaustive?
> Is that all the rates hardware offers? Because 802.11n standard specifies
> more rate configurations which are not all present in the ratetable.
>
>
>> > I am just curious what these variables
>> rssi_ctl0,ctl1,ctl2,ext0,ext1,ext2 contain?
>>
>> These are just rssi values on contol channel and ext channel of chain 0
>> and chain 1.
>>
>>
> ... and chain 2? There are total 3 chains on the card I am using (AR5008)
> and one of them is -128 for both ctl1 and ext1
>
> Could you elaborate what control and ext channels are? I tried to dump
> these values out and typically this is what they look like:
>
> ts_rssi = 49
> ts_rssi_ctl0 = 48
> ts_rssi_ctl1 = -128
> ts_rssi_ctl2 = 40
> ts_rssi_ext0 = 47
> ts_rssi_ext1 = -128
> ts_rssi_ext2 = 41
>
>  --
> Rakesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091023/33c5c9ea/attachment-0001.htm