just some cents from me. i modified the algorithm a long time ago since
the dynack way ath9k was going was not correct.
i will look if it can make a patch out of my experiences, but dont
expect it within the next 2 days.
Am 22.06.2021 um 12:12 schrieb Petrosilius:
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
