From mboxrd@z Thu Jan  1 00:00:00 1970
From: Felix Fietkau <nbd@openwrt.org>
Date: Wed, 06 Apr 2011 16:52:17 +0200
Subject: [ath9k-devel] why is bitrate of 65.0 MBit/s MCS 7 appropriate
 for signal strength of -93 dBm?
In-Reply-To: <BANLkTi=ekCBmDiwG4EZMkE9+i-bZTiUYMQ@mail.gmail.com>
References: <BANLkTi=0uN1ar37_nEfSzqFx8dUM2DrA4g@mail.gmail.com>	<BANLkTimPgYss+sOD57srxPf-T0qaSjNjaA@mail.gmail.com>	<BANLkTikaGBzn-WrRqgRXoU0He47bdH9r8w@mail.gmail.com>	<4D9C7949.1050307@openwrt.org>
	<BANLkTi=ekCBmDiwG4EZMkE9+i-bZTiUYMQ@mail.gmail.com>
Message-ID: <4D9C7E21.8090805@openwrt.org>
List-Id: <ath9k-devel.lists.ath9k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: ath9k-devel@lists.ath9k.org

On 2011-04-06 4:49 PM, Larry Vaden wrote:
> On Wed, Apr 6, 2011 at 9:31 AM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>  So, why is 65.0 MBit/s MCS 7 even on the table if rate control is based on
>>>  PER?
>>
>>  Because the assumption that lower rates always work better than higher rates
>>  is a bad one to make in a rate control algorithm.
>
> I do not disagree.  I've seen plenty of cases where higher data rates
> are more successful than lower data rates.
>
> Is XR within the range of parameters tried by ath9k?
No. It's not even supported by the hardware.

>>  You can find better statistics with much more meaningful output in
>>  /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/*/rc_stats
>
> I'm not sure about the time domain covered by said stats as IIRC at
> least 3 hours of 'iperf' has been run since r26494 was installed.
>
> best regards/ldv
>
> root at OpenWrt:~# cat
> /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/*/rc_stats
> type      rate     throughput  ewma prob   this prob  this
> succ/attempt   success    attempts
> HT20/LGI TtPMCS0        1.7       28.2       33.3          0(  0)
>     34         193
> HT20/LGI    MCS1        0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS2        0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS3        0.0        0.0        0.0          0(  0)
>      0           1
> HT20/LGI    MCS4        0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS5        0.0        0.0        0.0          0(  0)
>      0           1
> HT20/LGI    MCS6        0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS7        0.0        0.0        0.0          0(  0)
>      0           1
> HT20/LGI    MCS8        0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS9        0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS10       0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS11       0.0        0.0        0.0          0(  0)
>      0           1
> HT20/LGI    MCS12       0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS13       0.0        0.0        0.0          0(  0)
>      0           0
> HT20/LGI    MCS14       0.0        0.0        0.0          0(  0)
>      0           1
> HT20/LGI    MCS15       0.0        0.0        0.0          0(  0)
>      0           1
>
> Total packet count::    ideal 34      lookaround 6
The total packet count indicates that there's no useful data in there 
(probably because a reconnect happened). The MCS7 rate that you saw was 
maybe just a probing attempt.

- Felix