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
