ACK timing misconfiguration #146
Comments
|
Hm, we should check to see what the ACKCTS timeout is being programmed in?
It may be doing the math wrong for the clock rate on the AR9271.
…-adrian
On Tue, 24 Jul 2018 at 10:27, psyborg55 ***@***.***> wrote:
running AR9271 card with default ACK timing setting or enabling Coverage
class: 6 (up to 2700m) by issuing iw phy1 set distance 2500 will reduce
throughput. trying other coverage classes towards 0 improves the
throughput, which maxes out at Coverage class: 1 (up to 450m).
link distance 2500m
driver versions tested:
BACKPORTS_VERSION="v3.18.1-1-0-g5e9ec4c"
BACKPORTED_KERNEL_VERSION="v3.18.1-0-g39ca484"
BACKPORTS_VERSION="v4.4.2-1-0-gbec4037"
BACKPORTED_KERNEL_VERSION="v4.4.2-0-g1cb8570"
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#146>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ABGl7VDz21yihdrsOkdH1ti4I38hHnU-ks5uJ1kLgaJpZM4VdJoT>
.
|
|
does firmware sets that value? i'm running custom one with 6 and 9 Mbps rates enabled too. enabling dynack with auto distance seems to help in 4.4.2 but does not work on 3.18.1 |
|
It's done in the ath9k driver. That's why I think it's likely just
programmed wrong for the AR9271 MAC clock
…On Tue, 24 Jul 2018 at 16:21, psyborg55 ***@***.***> wrote:
does firmware sets that value? i'm running custom one with 6 and 9 Mbps
rates enabled too.
enabling dynack with auto distance seems to help in 4.4.2 but does not
work on 3.18.1
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7YRftjk3grPQmDeEW_G5Z4xz8EXfks5uJ6vggaJpZM4VdJoT>
.
|
|
is there an easy way to debug this? i have enabled debug output by passing 0xffffffff to htc_debug modparam but it outputs only a lot of calibration info. for ar9003 series there is ar9003_hw_selfgen_tpc_txpower routine that seems to set ALL_TARGET_LEGACY_1L_5L rates for these frames, so maybe it would help to allow all rates via similar routine for ar9002 (couldn't find one) (testcase AP runs pure-g 48M fixed). or try extending a workaround in hw.c: initval's 64us ack timeout value. Use 48us for the CTS timeout. + subtract of sifstime and slottime? |
|
debug output of SIFS EIFS SLOT ACK and CTS values: 4.4.2-0-g1cb8570: 3.18.1-0-g39ca484: patch used for enabling output: |
|
What's the value of ath9k_hw_mac_to_clks for those values?
…-adrian
|
|
how to properly print that value because i doubt dec or hex strings would be much of a help? from datasheet: default EIFS time 3480 -> run through this function should be 3480/40=87usec clockrate was not 40, but 44 (2c) so this will give EIFS=79.09 |
|
hi!
Well if you print both the mac and usec value in decimal I can go see what
it's choosing. :-)
The AR9271 doesn't run at 40/80/44/88MHz like the rest of the AR9280 family
does, it runs at like 112MHz or something. So maybe that isn't being taken
into account when overriding the ACK/RTS/CTS.
…-adrian
On Wed, 25 Jul 2018 at 08:13, psyborg55 ***@***.***> wrote:
how to properly print that value because i doubt dec or hex strings would
be much of a help?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7evzjKV6VbEt05zGkzM_x7cC_PvEks5uKIr8gaJpZM4VdJoT>
.
|
|
mac to clcks = 2688202816 it's max should be 117MHz, but from the cpu clock table it seems possible to set any of the combinations |
|
ok, we'll have to go verify that correct values are what are being
programmed in at the moment. It's an ath9k thing, so best to go poke on the
linux-wireless list.
…-adrian
On Wed, 25 Jul 2018 at 11:45, psyborg55 ***@***.***> wrote:
mac to clcks = 2688202816
it's max should be 117MHz, but from the cpu clock table it seems possible
to set any of the combinations
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7fBOky6IDwwnqpXX6J39_SlwjMPZks5uKLy1gaJpZM4VdJoT>
.
|
|
the value that is programmed in is ATH9K_CLOCK_RATE_2GHZ_OFDM, not 117 like it was for AR9287. update: dynack also works on 3.18 backport but there are other issues, possibly a well-known one: ack defaults to 64 S, setting distance to auto gives 61 S on both, but on 3.18 it works better at 67 S... +- kernel maths... or something with ath9k.. 2dB RX loss on 4.4.2 (-68dBm vs -66dBm on 3.18) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
running AR9271 card with default ACK timing setting or enabling Coverage class: 6 (up to 2700m) by issuing iw phy1 set distance 2500 will reduce throughput. trying other coverage classes towards 0 improves the throughput, which maxes out at Coverage class: 1 (up to 450m).
link distance 2500m
driver versions tested:
BACKPORTS_VERSION="v3.18.1-1-0-g5e9ec4c"
BACKPORTED_KERNEL_VERSION="v3.18.1-0-g39ca484"
BACKPORTS_VERSION="v4.4.2-1-0-gbec4037"
BACKPORTED_KERNEL_VERSION="v4.4.2-0-g1cb8570"
The text was updated successfully, but these errors were encountered: