Rate index for 11 Mbps

Viet-Ha Pham hapvbk at yahoo.co.uk
Sun Dec 11 19:35:51 UTC 2011


Hi Adrian,

Sorry for this late reply. The message goes to my junk box. I found it 
today.

I checked with the source code, do some test by printing our the rate index 
at different stages in the kernel and found the issue.

In the HAL, the rate order is: cck1 - cck2 - cck5.5 - cck11 - ofdm6 - 
ofdm9 - ofdm 12

In the 802.11, the rate order is: cck1 - cck2 - cck5.5 - ofdm6 - ofdm9 - 
cck11 - ofdm 12

So, the rate index for 6, 9 and 11 in the HAL and in 802.11 are actually 
different. When we select the rate, we need to pay attention to this and 
select the correct one.

Here is my test codes:

    snprintf(log_str, MAX_LOG_MSG_LEN, "rate index: %u %u %u \n", 
ni->ni_rates.rs_rates[5], GET_RATE_AND_CLEAR_BASIC_BIT(5), 
sc->sc_rixmap[GET_RATE_AND_CLEAR_BASIC_BIT(5)]);
    usr_write_log(log_str);

GET_RATE_AND_CLEAR_BASIC_BIT is a macro to clear the basic_rate bit, equally 
to remove 128 from the rate index. usr_write_log() is a user-defined 
function to write the input string to a separate user-defined log file.

The output is: "rate index: 150 22 3"

So the rate index number 5 in 802.11 is equally assigned to the rate index 
number 3 in the HAL.

This is not a big thing but hopefully it helps the newbies like me and also 
ppl who work closely with the transmission rates.


Viet-Ha


-----Original Message----- 
From: Adrian Chadd
Sent: Sunday, December 04, 2011 12:56 AM
To: Viet-Ha Pham
Cc: Freebsd Wireless
Subject: Re: Rate index for 11 Mbps

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 



More information about the freebsd-wireless mailing list