rx rate issue

[Michal Kazior]

On 20 July 2016 at 13:10, Sebastian Gottschall <s.gottschall at dd-wrt.com> wrote:
> Am 20.07.2016 um 13:03 schrieb Michal Kazior:
>>
>> On 20 July 2016 at 12:50, Sebastian Gottschall <s.gottschall at dd-wrt.com>
>> wrote:
>>>
>>> Am 20.07.2016 um 12:23 schrieb Michal Kazior:
>>>>
>>>> On 20 July 2016 at 10:51, Sebastian Gottschall <s.gottschall at dd-wrt.com>
>>>> wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> while hunting a link stability (packet transmission stop) issue i
>>>>> discovered
>>>>> a maybe cosmetic, but maybe als serious issue.
>>>>> AP is a QCA9880 3x3 card configured as WDS AP
>>>>> Station is a QCA9880 2x2 card configured as WDS STA
>>>>>
>>>>> the TX rate of the station matches to the rx rate of the AP.
>>>>> but the RX rate of the station is wrong as it seems which may be a
>>>>> cause
>>>>> of
>>>>> the issue.
>>>>> could this be a firmware bug on QCA9880?
>>>>>
>>>>> output of fw_stats
>>>>>
>>>>> WDS AP:
>>>>>                Peer MAC address 40:a5:ef:85:4d:6f
>>>>>                        Peer RSSI 12
>>>>>                     Peer TX rate 175500
>>>>>                     Peer RX rate 175500
>>>>>                 Peer RX duration 0
>>>>>
>>>>>
>>>>> WDS STA:
>>>>>               Peer MAC address 40:a5:ef:51:49:db
>>>>>                        Peer RSSI 13
>>>>>                     Peer TX rate 175500
>>>>>                     Peer RX rate 351000
>>>>>                 Peer RX duration 0
>>
>> [...]
>>>>
>>>> Is this reproducible? Can you try setting a fixed tx bitrate (`iw
>>>> wlanX set bitrates legacy-5 ht-mcs vht-mcs 1:4` to force vht mcs=4,
>>>> nss=1) to see if it makes any difference? Perhaps rate-control and tx
>>>> try-list/status are not parsed properly (for statistical purposes) in
>>>> firmware which ends up with invalid peer-tx-rate on WDS AP.
>>>
>>> lets try. can you correct the syntax? the following is not correct
>>> iw dev ath1 set bitrates legacy-5 ht-mcs vht-mcs 1:4
>>>
>>> Usage:  iw [options] dev <devname> set bitrates [legacy-<2.4|5> <legacy
>>> rate
>>> in Mbps>*] [ht-mcs-<2.4|5> <MCS index>*] [v
>>> ht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*] [sgi-2.4|lgi-2.4]
>>> [sgi-5|lgi-5]
>>>
>>> Sets up the specified rate masks.
>>> Not passing any arguments would clear the existing mask (if any).
>>
>> Ah, sorry, my bad.
>>
>>    iw dev ath1 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:4
>>
>> (ht-mcs and vht-mcs were missing "-5" suffix)
>>
>> As a sidenote: The logic here is that you need to explicitly tell that
>> you want empty set of legacy rates and empty set of HT rates and only
>> a single VHT rate to be set (all explicitly for 5ghz band). This makes
>> sure that FW rate control is ignored and a fixed rate is used for all
>> data transmissions (and this should also build tx try-lists without
>> any fancy retries/fallbacks to different rates).
>
> after setting this setting on ap. i get the following results:
>
> sta:
> rx bitrate:     175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
>                  Peer TX rate 234000
>                   Peer RX rate 175500
>
>
> AP:
>         rx bitrate:     175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
>                   Peer TX rate 263300
>                   Peer RX rate 175500
>
> this looks even more curious

Thanks for checking.

Looks like firmware reports garbage for peer-tx-rate.. 234mbps and
263.3mbps were probably values that rate control tried before and
since firmware reuses memory hunks for tx descriptors it probably ends
up reading stale data and reports it as peer-tx-rate.

I did a quick look at firmware code that collects peer-tx-rate. It
does seem to have some logic flaws but I couldn't imagine how it can
report the values you're seeing.

On the plus side it's probably harmless.


Michał