Rate index for 11 Mbps

[Adrian Chadd]

On 4 December 2011 13:36, Viet-Ha Pham <hapvbk at yahoo.co.uk> wrote:
> Hi there,
>
> I am working with the rate adaptation algorithm and at the very beginning
> point of testing/programing. I have a concern with the rate index used in
> the HAL.
>
> I wonder if the rate order in the rate table for 802.11g is 1 - 2 - 5.5 - 6
> - 9 - 11 - 12 .... or 1 - 2 - 5.5 - 11 - 6 -9 - 12 ... ?

The order of rate table entries is what you see:

[for 11g]:

/*                                                 short            ctrl  */
/*                valid                rateCode Preamble  dot11Rate Rate */
/*   1 Mb */ {  AH_TRUE, CCK,     1000,    0x1b,    0x00, (0x80| 2),   0 },
/*   2 Mb */ {  AH_TRUE, CCK,     2000,    0x1a,    0x04, (0x80| 4),   1 },
/* 5.5 Mb */ {  AH_TRUE, CCK,     5500,    0x19,    0x04, (0x80|11),   2 },
/*  11 Mb */ {  AH_TRUE, CCK,    11000,    0x18,    0x04, (0x80|22),   3 },
/* remove rates 6, 9 from rate ctrl */
/*   6 Mb */ { AH_FALSE, OFDM,    6000,    0x0b,    0x00,        12,   4 },
/*   9 Mb */ { AH_FALSE, OFDM,    9000,    0x0f,    0x00,        18,   4 },
/*  12 Mb */ {  AH_TRUE, OFDM,   12000,    0x0a,    0x00,        24,   6 },

..

so it's cck 1, cck 2, cck 5.5, cck 11, ofdm 6, ofdm 9, ofdm 12, ofdm
18 .. ofdm 54.

> I read the source code (ar5212_phy.c) but I am still confused. Also there is
> a comment with the rate table for 802.11g:
>
> /* Venice TODO: roundUpRate() is broken when the rate table does not
> represent rates
> * in increasing order  e.g.  5.5, 11, 6, 9.
> * An average rate of 6 Mbps will currently map to 11 Mbps.
> */

I don't know where roundUpRate() is - but yes, if your function tries
to map a throughput to a rate table index, it'll have problems if it
simply finds the first rate greater than your specified bit rate.

HTH,


Adrian