Hello *, On Tue, 22 Jun 2021 12:40:31 +0200, Sebastian Gottschall <s.gottschall@xxxxxxxxxx> wrote: > 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 ackto.tar8720 [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 > > > > Did observe same/similar problem, in my case with IBSS mode and three nodes/ stations A, B, C. IP traffic only between A, B. Node C is 'passive' (sending only beacons and broadcasts), but the current algorithm keeps ackto at 600 (no update of the ackto value for node/station C - added an debugfs entry ack_to_detailed dumping the ackto values per station which are evaluated in ath_dynack_compute_ackto() where the highest value wins). Fixed it by setting the initial ackto value to zero for new nodes/stations: diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c index fbeb4a739..ebf7800bd 100644 --- a/drivers/net/wireless/ath/ath9k/dynack.c +++ b/drivers/net/wireless/ath/ath9k/dynack.c @@ -235,7 +235,7 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb, struct ath_node *an; an = (struct ath_node *)sta->drv_priv; - an->ackto = -1; + an->ackto = 0; /* do not vote for ackto until real value is known */ } da->lto = jiffies + LATEACK_DELAY; } @@ -323,7 +323,7 @@ void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an) { struct ath_dynack *da = &ah->dynack; - an->ackto = da->ackto; + an->ackto = 0; /* do not vote for ackto until real value is known */ spin_lock_bh(&da->qlock); list_add_tail(&an->list, &da->nodes); @@ -368,7 +368,7 @@ void ath_dynack_reset(struct ath_hw *ah) da->ackto = ath_dynack_get_max_to(ah); list_for_each_entry(an, &da->nodes, list) - an->ackto = da->ackto; + an->ackto = 0; /* do not vote for ackto until real value is known */ /* init acktimeout */ ath_dynack_set_timeout(ah, da->ackto); Another observation is that the initial/default ackto value is dependent on the order of the interface configure commands, e.g.: $ iw phy0 set distance auto $ iw wlan0 set type ibss $ ifconfig wlan0 10.11.0.3 up $ iw wlan0 ibss join test-ibss1 5180 1a:2b:3c:4d:5e:6f results in an initial ackto value of 300, $ iw wlan0 set type ibss $ ifconfig wlan0 10.11.0.3 up $ iw wlan0 ibss join test-ibss1 5180 1a:2b:3c:4d:5e:6f $ iw phy0 set distance auto results in an initial ackto value of 600... Regards, Peter