Date: Sun, 11 Dec 2011 14:35:43 -0500 From: "Viet-Ha Pham" <hapvbk@yahoo.co.uk> To: "Adrian Chadd" <adrian@freebsd.org> Cc: Freebsd Wireless <freebsd-wireless@freebsd.org> Subject: Re: Rate index for 11 Mbps Message-ID: <AA341C19F3FF4D85BE6779EFADE3080B@PC> In-Reply-To: <CAJ-VmokLBw=JMaCLd=oVY189tMeUE4btHOJ9tMbRwykXve4qhQ@mail.gmail.com> References: <3d4d2d249836fafc6acd885693c02198@webmail.entel.upc.edu><CAJ-Vmo=1k=oKP-vDUH=BLdyeVzGnQvNmJ6TwGcdQjwpgJWt52w@mail.gmail.com><4ECFCDAB.1080407@entel.upc.edu><CAJ-VmokQTpgxMo=gmj0LsYhD6t9mmoHXG_sbhZdFNW5_OSGbmg@mail.gmail.com><a9d1d8f91deb80a89bed98c1ffdb23fd@webmail.entel.upc.edu><CAJ-Vmo=P%2BWAArZ1Kidh947yHuftZTBwF=Vx5Kn36-LKtD4grPg@mail.gmail.com><4ED3B4D1.3020701@entel.upc.edu><CAJ-Vmo=1KimWWEkV4gqEyFiNQRZTkK8okPBSfnc494iJbtLzsw@mail.gmail.com><4EDA4BBA.6010203@entel.upc.edu><CAJ-Vmon7-PdC51nWjW-M-ojuShwG-iNrBpztNovsZpzgjm9BqA@mail.gmail.com><4EDA609F.2080401@entel.upc.edu><CAJ-VmomqbBpJ9whQ2EStP7i5fuaKvR=%2BA9gxQJm3hZnCi%2BJnOg@mail.gmail.com><CAJ-Vmo=hEq9N=FhvdH8Ev7roG3TByJjri3q5rpLPDE__YZ=MZg@mail.gmail.com><C5FE57A2CF4942A2884B7B305E279CD5@PC> <CAJ-VmokLBw=JMaCLd=oVY189tMeUE4btHOJ9tMbRwykXve4qhQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA341C19F3FF4D85BE6779EFADE3080B>