Re: [Bugreport] ath9k dynack not working/low performance on 5 & 10MHz Bandwidth

[Koen Vandeputte <koen.vandeputte@citymesh.com>]

On 22.06.21 13:53, Petrosilius wrote:
> On 22.06.21 13:52, Koen Vandeputte wrote:
>> On 22.06.21 12:12, Petrosilius wrote:
>>> On 22.06.21 11:54, Koen Vandeputte wrote:
>>>> On 18.06.21 13:13, Petrosilius wrote:
>>>>> Hello Lorenzo Bianconi,
>>>>>
>>>>> we are running a set of R11e-2HPnD devices and having trouble getting
>>>>> dynack working properly.
>>>>> Setup:
>>>>> * linux-5.4.123
>>>>> * OpenWRT (current development branch) with wireless
>>>>> backports-5.10.34-1
>>>>> * distance 2m between ap and sta
>>>>> * Low ambient noise wifi environment
>>>>> We experienced some non working dynack or low performance in the
>>>>> connection due to too high calculated ackto's.
>>>>>
>>>>> Here is a ath9k debug output example for a non working dynack @ 10Mhz
>>>>> BW:
>>>>>
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.500427] ath: phy0:
>>>>> {48:8f:5a:3c:bb:03} tx sample 44905341 [dur 8720][h 29-t 30]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.500437] ath: phy0:
>>>>> ack_ts 44844835 st_ts 44905341 st_dur 8720 [17-29]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.500445] ath: phy0:
>>>>> ack_ts 44923425 st_ts 44905341 st_dur 8720 [18-29]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.554642] ath:
>>>>> phy0: rx
>>>>> sample 44977693 [h 18-t 20]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.554701] ath: phy0:
>>>>> {48:8f:5a:3c:bb:03} tx sample 44964984 [dur 6032][h 30-t 31]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.554710] ath: phy0:
>>>>> ack_ts 44923425 st_ts 44964984 st_dur 6032 [18-30]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.554718] ath: phy0:
>>>>> ack_ts 44977693 st_ts 44964984 st_dur 6032 [19-30]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.577890] ath:
>>>>> phy0: rx
>>>>> sample 45000939 [h 19-t 21]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.577946] ath: phy0:
>>>>> {48:8f:5a:3c:bb:03} tx sample 44998471 [dur 912][h 31-t 32]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.577956] ath: phy0:
>>>>> ack_ts 44977693 st_ts 44998471 st_dur 912 [19-31]
>>>>> Wed Jun  2 19:08:50 2021 kern.debug kernel: [  400.577964] ath: phy0:
>>>>> ack_ts 45000939 st_ts 44998471 st_dur 912 [20-31]
>>>>>
>>>>> THe above output is generated in dynack.c by
>>>>>
>>>>>            ath_dbg(ath9k_hw_common(ah), DYNACK,
>>>>>                "ack_ts %u st_ts %u st_dur %u [%u-%u]\n",
>>>>>                ack_ts, st_ts->tstamp, st_ts->dur,
>>>>>                da->ack_rbf.h_rb, da->st_rbf.h_rb);
>>>>>
>>>>> The ackto is afterwards calculated by
>>>>>
>>>>>            if (ack_ts > st_ts->tstamp + st_ts->dur) {
>>>>>                ackto = ack_ts - st_ts->tstamp - st_ts->dur;
>>>>>
>>>>> Filling in the values of the first sample:
>>>>>
>>>>> (ack_ts > st_ts->tstamp + st_ts->dur) ?
>>>>> (44844835 > 44905341+8720) ?
>>>>> (44844835 > 44914061) ? ... not given
>>>>>
>>>>> Therefore a new ackto is not calculated and i can also see that in the
>>>>> ack_to file:
>>>>>
>>>>> 600 A
>>>>> 600 A
>>>>> 600 A
>>>>> ...
>>>>>
>>>>> These look like the default values to me (and do not change), but
>>>>> ath_dynack_get_max_to() should return 750 A for our 10MHz BW case -
>>>>> this
>>>>> looks also suspecious to me.
>>>>>
>>>>> For 5 MHz bandwidth there is a ackto calculated (~382 A, looks a
>>>>> bit too
>>>>> high to me) but the performance is way below expectation (<1MBit)
>>>>> For 20 MHz bandwidth there is a ackto calculated (51 A) and the
>>>>> performance is fitting the expectation.
>>>>> If you want to take a look at the logs for each of these cases for ap
>>>>> and sta, you can download them here:
>>>>> https://cloud.hs-augsburg.de/s/eworxkJoL6JXYzZ
>>>>>
>>>>> Did anyone else experience such a behaviour on non 20MHz Channels or
>>>>> does anyone have an idea on where this behaviour might originate from?
>>>>> I am not experienced in the ath9k driver code, but a uneducated guess
>>>>> might be that the ring buffer where the dynack algorithm is taking its
>>>>> frame-samples from is not behaving as expected for the 5&10MHz case.
>>>>>
>>>>> regards,
>>>>> julian dorner
>>>> Are you stressing the link?
>>>> I'll try to simulate this later on
>>>>
>>>> Regards,
>>>>
>>>> Koen
>>>>
>>> Hi Koen,
>>>
>>> we didnt stress the link that much.
>>>
>>> There was only SSH from the ap to the sta running to get access to
>>> the sta.
>>>
>>> regards,
>>>
>>> Julian
>> Hi,
>>
>> Please retry while sending data over the link (iperf or so) and let me
>> know the results. :)
>>
>> Thanks,
>>
>> Koen
>>
> Hi Koen,
>
> we tried this
>
>> For 5 MHz bandwidth there is a ackto calculated (~382 A, looks a bit too
>> high to me) but the performance is way below expectation (<1MBit)
> running iperf didnt help on this.
>
> Regards,
>
> Julian
>
Thanks for confirming that.

What would really help is a small table showing this:

Real physical distance? (in m)
ack_to reported while stressing the link:

20MHz: xx
10 MHz: yy
5 MHz: zz

I'll try to simulate the issue somewhere in the next days.


Please do note that ongoing effort is currently going on to improve 
dynack on lower distances.

It was observed and reported by me to Lorenzo that ack_to was way higher 
than fixed settings when
real distance is <6km

Some testing patches were cooked and tested in the field last month 
covering long and short distances (1km up to 24km)
and these are matching fixed distance ack_to very close now. (speeds 
using dynack were also higher than fixed settings)
It's not finalized yet.

Also do note that dynack only shows (any) benefit when having links >3km
Below that, timing jitter and processing time seems to have more 
influence on ack_to than actual distance.

Regards,

Koen