[OpenWrt-Devel] ath9k: fix dynack in IBSS mode
Lorenzo Bianconi
lorenzo.bianconi at redhat.com
Sun Mar 31 09:45:16 EDT 2019
>
> bump.
Hi Joe,
sorry for the delay
>
> On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers <joe at ayerscasa.com> wrote:
>>
>> Lorenzo, I have tested dynack on a (real distance apart) ~60km link
>> with some success. This is the code change made:
>>
>> --- a/drivers/net/wireless/ath/ath9k/dynack.c
>> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
>> @@ -20,8 +20,9 @@
>>
>> #define COMPUTE_TO (5 * HZ)
>> #define LATEACK_DELAY (10 * HZ)
>> -#define LATEACK_TO 256
>> -#define MAX_DELAY 300
>> +#define LATEACK_TO 1054
>> +/* AREDN max distance set to 150km */
>> +#define MAX_DELAY 1054
>> #define EWMA_LEVEL 96
>> #define EWMA_DIV 128
>>
>> @@ -293,7 +294,8 @@
>> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
>> {
>> /* ackto = slottime + sifs + air delay */
>> - u32 ackto = 9 + 16 + 64;
>> + /* AREDN starting point is 20km */
>> + u32 ackto = 9 + 16 + 171;
>> struct ath_dynack *da = &ah->dynack;
>>
>> an->ackto = ackto;
>> @@ -328,7 +330,8 @@
>> void ath_dynack_reset(struct ath_hw *ah)
>> {
>> /* ackto = slottime + sifs + air delay */
>> - u32 ackto = 9 + 16 + 64;
>> + /* AREDN starting point is 20km */
>> + u32 ackto = 9 + 16 + 171;
>> struct ath_dynack *da = &ah->dynack;
>>
>> da->lto = jiffies;
>>
>> Notes:
>>
>> 1) The stations are showing ack_to between 525 up to 575 A. When
>> static set at 60k distance, the timeout is set to 460 S.
>> 2) significant performance improvement between these settings with
>> iperf3 and back to back runs with reboot in the middle:
>>
could you please try to attached patch? The max distance the hw can
support depends of channel width:
e.g @20MHz (HT20, 5GHz)
max distance is ~ 61Km
@Koen: do you have any chance to test the attached patch in your
environment? Thx
>> run 1 @ static 60km:
>> [ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec 0 sender
>> [ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec receiver
>>
>> run 2 @ static 60km:
>> [ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec 0 sender
>> [ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec receiver
>>
>> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
>> floats back to ~525 otherwise:
>> [ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec 0 sender
>> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec receiver
>>
>> [ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec 0 sender
>> [ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec receiver
>>
>> 3) running wpa_supplicant and psk2
>> 4) running ibss on ch 176 with AREDN channels on top of 18.06.2
>> 5) on one reboot, one of the stations stayed down at initial 196, then
>> bumped up to ~250 range and stayed there, link not functional. Not
>> sure how to explain this value...
>>
>> Question, can this condition be true periodically while the link is
>> live or only at initial 802.11 adhoc link setup?:
>>
>> if (ieee80211_is_assoc_req(hdr->frame_control) ||
>> ieee80211_is_assoc_resp(hdr->frame_control) ||
>> ieee80211_is_auth(hdr->frame_control)) {
>>
I do not think so since AFAIK auth frames are sent just during ibss join
>> 6) Auto distance stayed at initial 196 when turning off encryption.
>>
>> Any ideas of alternative options of packets to key off in late ack
>> situation? running wpad-mini is ~500k file size and RAM consumer.
>> It would be beneficial to take wpa_supplicant out of the equation if
>> at all possible.
>>
What is mandatory are unicast frames during joining phase, maybe you can
develop an userspace daemon for this purpose
>> Joe
Regards,
Lorenzo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ath-dynack-set-max-timeout-according-to-clockrate.patch
Type: text/x-patch
Size: 2989 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190331/b7426ae5/attachment.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list