The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
Using the same values in ath9k results in much better throughput for me.
Before this patch I had a huge amount of packet loss (sometimes up to
40%) and the max transfer speed was somewhere around 5Mbit/s. With this
patch applied I have zero packet loss and ten times the throughput.
My device uses a AR9227 which is the PCI variant of the AR9287.
[0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h
Signed-off-by: Martin Blumenstingl <[email protected]>
---
Patch has not changed, I am just CC'ing @linux-wireless (instead of
@ath9k-devel only).
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.h b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
index 6314ae2..9d17a53 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
@@ -610,8 +610,8 @@
#define AR_PHY_CCA_MIN_GOOD_VAL_9271_2GHZ -127
#define AR_PHY_CCA_MAX_GOOD_VAL_9271_2GHZ -116
-#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -120
+#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -112
#define AR_PHY_CCA_MIN_GOOD_VAL_9287_2GHZ -127
-#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ -110
+#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ -97
#endif
--
2.4.6
On Wed, Jul 29, 2015 at 9:49 AM, Adrian Chadd <[email protected]> wrote:
> ok, can you re-run this again before the NF patch, so I can compare?
Sure, here they are: [0]
And here are the NF values reported by ath9k right before that:
# cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
Channel Noise Floor : -91
Chain | privNF | # Readings | NF Readings
0 -110 2 -110 -110
1 -110 2 -110 -110
Regards,
Martin
[0] https://dl.dropboxusercontent.com/u/26940713/tmp/spectral_out_nopatch
On Tue, Jul 28, 2015 at 1:50 AM, Adrian Chadd <[email protected]> wrote:
> is it never getting any readings before your patch? NF Readings all
> look empty...
Yes, looks like it. Unfortunately I haven't saved a complete kernel
log (with ath9k debug level = 0x00004449) but only a few parts. Here
are the interesting bits:
<7>[ 449.746679] ath: phy1: NF calibrated [ctl] [chain 0] is -106
<7>[ 449.746697] ath: phy1: NF[0] (-106) > MAX (-110), correcting to MAX
<7>[ 449.746714] ath: phy1: NF calibrated [ctl] [chain 1] is -90
<7>[ 449.746731] ath: phy1: NF[1] (-90) > MAX (-110), correcting to MAX
<7>[ 449.746748] ath: phy1: NF calibrated [ext] [chain 0] is -103
<7>[ 449.746765] ath: phy1: NF[3] (-103) > MAX (-110), correcting to MAX
<7>[ 449.746781] ath: phy1: NF calibrated [ext] [chain 1] is -86
<7>[ 449.746798] ath: phy1: NF[4] (-86) > MAX (-110), correcting to MAX
<7>[ 449.746878] ath: phy1: Calibration @37407 finished: long ani, caldone: true
I'd assume (because I don't know the ath9k code) that ath9k simply
ignores NF readings that are "out of range" (as suggested by those
messages).
Regards,
Martin
On 28 July 2015 at 15:33, Martin Blumenstingl
<[email protected]> wrote:
> On Wed, Jul 29, 2015 at 12:22 AM, Adrian Chadd <[email protected]> wrote:
>> Hm, doesn't someone have a graphical frontend for this on linux?
> Yep, I just found FFT_eval (screenshot: [0] and ath_spectral
> (screenshot [1]) in the ath9k spectral scan wiki page.
>
>
> [0] http://abload.de/img/athscanfjsvv.png
> [1] http://abload.de/img/fft-evaldqsbq.png
Cool! Does it let you capture lots of samples over time and plot them?
Or is the second one that as well?
Is this before or after the NF patches?
-adrian
So the values aren't "bad" on the 1043nd - they're in 1/2 or 1/4dB,
but there's no scalar quantity (ie, it's not in dBm.) The 1043nd
calibrates down to around -95 or so, which "sounds" like it's in dBm
but it isn't, and any similarity is just coincidence.
It does sound like your AR9227 sees noise. can you fire up the
spectral analysis stuff to plot what the NIC is seeing? (yes, the
AR9287/AR9227 has spectral analysis mode, same as the AR9280, AR9285,
and >= AR9300.)
-adrian
Hm, doesn't someone have a graphical frontend for this on linux?
-a
On 28 July 2015 at 15:07, Martin Blumenstingl
<[email protected]> wrote:
> On Tue, Jul 28, 2015 at 7:25 PM, Adrian Chadd <[email protected]> wrote:
>> So the values aren't "bad" on the 1043nd - they're in 1/2 or 1/4dB,
>> but there's no scalar quantity (ie, it's not in dBm.) The 1043nd
>> calibrates down to around -95 or so, which "sounds" like it's in dBm
>> but it isn't, and any similarity is just coincidence.
> Ok, then we'll ignore the 1043nd from now on.
>
>> It does sound like your AR9227 sees noise. can you fire up the
>> spectral analysis stuff to plot what the NIC is seeing? (yes, the
>> AR9287/AR9227 has spectral analysis mode, same as the AR9280, AR9285,
>> and >= AR9300.)
> I am assuming that "background" mode is what you want, see [0].
> Thus I ran the following on my AR9227 device:
> # echo background > /sys/kernel/debug/ieee80211/phy1/ath9k/spectral_scan_ctl
> # echo trigger > /sys/kernel/debug/ieee80211/phy1/ath9k/spectral_scan_ctl
> # cat /sys/kernel/debug/ieee80211/phy1/ath9k/spectral_scan0 > /tmp/samples
>
> The result can be found here: [1].
> Note that at this point no client was connected to my AP. My patch
> (from the initial mail) was applied - but that shouldn't have any
> effect on the spectral scan output (at least that's what I'm
> assuming).
>
> Just for documentation purposes - those are the NF values that I have
> seen a few seconds before getting the spectral scan data:
> # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
> Channel Noise Floor : -93
> Chain | privNF | # Readings | NF Readings
> 0 -104 5 -109 -109 -109 -104 -104
> 1 -97 5 -97 -97 -97 -97 -97
>
>
> Regards,
> Martin
>
>
> [0] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/spectral_scan
> [1] https://dl.dropboxusercontent.com/u/26940713/tmp/spectral_out
On Wed, Jul 29, 2015 at 12:22 AM, Adrian Chadd <[email protected]> wrote:
> Hm, doesn't someone have a graphical frontend for this on linux?
Yep, I just found FFT_eval (screenshot: [0] and ath_spectral
(screenshot [1]) in the ath9k spectral scan wiki page.
[0] http://abload.de/img/athscanfjsvv.png
[1] http://abload.de/img/fft-evaldqsbq.png
On Tue, Jul 28, 2015 at 7:25 PM, Adrian Chadd <[email protected]> wrote:
> So the values aren't "bad" on the 1043nd - they're in 1/2 or 1/4dB,
> but there's no scalar quantity (ie, it's not in dBm.) The 1043nd
> calibrates down to around -95 or so, which "sounds" like it's in dBm
> but it isn't, and any similarity is just coincidence.
Ok, then we'll ignore the 1043nd from now on.
> It does sound like your AR9227 sees noise. can you fire up the
> spectral analysis stuff to plot what the NIC is seeing? (yes, the
> AR9287/AR9227 has spectral analysis mode, same as the AR9280, AR9285,
> and >= AR9300.)
I am assuming that "background" mode is what you want, see [0].
Thus I ran the following on my AR9227 device:
# echo background > /sys/kernel/debug/ieee80211/phy1/ath9k/spectral_scan_ctl
# echo trigger > /sys/kernel/debug/ieee80211/phy1/ath9k/spectral_scan_ctl
# cat /sys/kernel/debug/ieee80211/phy1/ath9k/spectral_scan0 > /tmp/samples
The result can be found here: [1].
Note that at this point no client was connected to my AP. My patch
(from the initial mail) was applied - but that shouldn't have any
effect on the spectral scan output (at least that's what I'm
assuming).
Just for documentation purposes - those are the NF values that I have
seen a few seconds before getting the spectral scan data:
# cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
Channel Noise Floor : -93
Chain | privNF | # Readings | NF Readings
0 -104 5 -109 -109 -109 -104 -104
1 -97 5 -97 -97 -97 -97 -97
Regards,
Martin
[0] https://wireless.wiki.kernel.org/en/users/drivers/ath9k/spectral_scan
[1] https://dl.dropboxusercontent.com/u/26940713/tmp/spectral_out
is it never getting any readings before your patch? NF Readings all
look empty...
-adrian
On 27 July 2015 at 15:30, Martin Blumenstingl
<[email protected]> wrote:
> Hi Adrian,
>
> On Mon, Jul 27, 2015 at 9:13 PM, Adrian Chadd <[email protected]> wrote:
>> I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.)
>>
>> can you log the noisefloor calibrated values before and after the
>> patch? I'd like to see how low it calibrrates to.
> Sure, I hope dump_nfcal provides all values you need.
>
> result with my patch applied (HT20):
> # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
> Channel Noise Floor : -95
> Chain | privNF | # Readings | NF Readings
> 0 -106 5 -110 -105 -109 -106 -106
> 1 -97 5 -97 -97 -97 -97 -97
>
> Result before my patch (HT20):
> # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
> Channel Noise Floor : -91
> Chain | privNF | # Readings | NF Readings
> 0 -120 0
> 1 -120 0
>
> Result before my patch (HT40):
> # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
> Channel Noise Floor : -91
> Chain | privNF | # Readings | NF Readings
> 0 -110 5 -110 -110 -110 -110 -110
> 1 -110 5 -110 -110 -110 -110 -110
> 3 -110 5 -110 -110 -110 -110 -110
> 4 -110 5 -110 -110 -110 -110 -110
>
>
> Let me know if this helps you or if you need more information.
>
>
> Regards,
> Martin
ok, can you re-run this again before the NF patch, so I can compare?
And yeah, I can compile up fft_eval for freebsd. I think I've done it
once or twice before..
-a
On 28 July 2015 at 16:43, Martin Blumenstingl
<[email protected]> wrote:
> On Wed, Jul 29, 2015 at 1:37 AM, Adrian Chadd <[email protected]> wrote:
>> Cool! Does it let you capture lots of samples over time and plot them?
> At least FFT_eval would allow capturing samples, but the device with
> the AR9227 is a small router -> no screen there, so I have to dump it
> on that device, copy it to my PC and look at the samples there.
> I have also just seen that in FFT_eval one can "Navigate through the
> currently selected datasets using the arrow keys (left and right)."
> This would require me to make many screenshots. Is there a chance you
> can compile FFT_eval on FreeBSD (it "only" seems to require SDL and
> SDL_ttf) and run it yourself?
>
>> Or is the second one that as well?
> What do you mean exactly?
>
>> Is this before or after the NF patches?
> This is after my NF patch.
>
>
> Regards,
> Martin
Those are some high values (eg from noise/spur somewhere) and the
driver is deciding to program in -110. So the radio thinks its deaf.
Hm, I think that explains a few other NICs behaving badly too....
-a
On 27 July 2015 at 16:55, Martin Blumenstingl
<[email protected]> wrote:
> On Tue, Jul 28, 2015 at 1:50 AM, Adrian Chadd <[email protected]> wrote:
>> is it never getting any readings before your patch? NF Readings all
>> look empty...
> Yes, looks like it. Unfortunately I haven't saved a complete kernel
> log (with ath9k debug level = 0x00004449) but only a few parts. Here
> are the interesting bits:
> <7>[ 449.746679] ath: phy1: NF calibrated [ctl] [chain 0] is -106
> <7>[ 449.746697] ath: phy1: NF[0] (-106) > MAX (-110), correcting to MAX
> <7>[ 449.746714] ath: phy1: NF calibrated [ctl] [chain 1] is -90
> <7>[ 449.746731] ath: phy1: NF[1] (-90) > MAX (-110), correcting to MAX
> <7>[ 449.746748] ath: phy1: NF calibrated [ext] [chain 0] is -103
> <7>[ 449.746765] ath: phy1: NF[3] (-103) > MAX (-110), correcting to MAX
> <7>[ 449.746781] ath: phy1: NF calibrated [ext] [chain 1] is -86
> <7>[ 449.746798] ath: phy1: NF[4] (-86) > MAX (-110), correcting to MAX
> <7>[ 449.746878] ath: phy1: Calibration @37407 finished: long ani, caldone: true
>
> I'd assume (because I don't know the ath9k code) that ath9k simply
> ignores NF readings that are "out of range" (as suggested by those
> messages).
>
>
> Regards,
> Martin
Hi Adrian,
On Mon, Jul 27, 2015 at 9:13 PM, Adrian Chadd <[email protected]> wrote:
> I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.)
>
> can you log the noisefloor calibrated values before and after the
> patch? I'd like to see how low it calibrrates to.
Sure, I hope dump_nfcal provides all values you need.
result with my patch applied (HT20):
# cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
Channel Noise Floor : -95
Chain | privNF | # Readings | NF Readings
0 -106 5 -110 -105 -109 -106 -106
1 -97 5 -97 -97 -97 -97 -97
Result before my patch (HT20):
# cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
Channel Noise Floor : -91
Chain | privNF | # Readings | NF Readings
0 -120 0
1 -120 0
Result before my patch (HT40):
# cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal
Channel Noise Floor : -91
Chain | privNF | # Readings | NF Readings
0 -110 5 -110 -110 -110 -110 -110
1 -110 5 -110 -110 -110 -110 -110
3 -110 5 -110 -110 -110 -110 -110
4 -110 5 -110 -110 -110 -110 -110
Let me know if this helps you or if you need more information.
Regards,
Martin
On Wed, Jul 29, 2015 at 1:37 AM, Adrian Chadd <[email protected]> wrote:
> Cool! Does it let you capture lots of samples over time and plot them?
At least FFT_eval would allow capturing samples, but the device with
the AR9227 is a small router -> no screen there, so I have to dump it
on that device, copy it to my PC and look at the samples there.
I have also just seen that in FFT_eval one can "Navigate through the
currently selected datasets using the arrow keys (left and right)."
This would require me to make many screenshots. Is there a chance you
can compile FFT_eval on FreeBSD (it "only" seems to require SDL and
SDL_ttf) and run it yourself?
> Or is the second one that as well?
What do you mean exactly?
> Is this before or after the NF patches?
This is after my NF patch.
Regards,
Martin
On Tue, Jul 28, 2015 at 5:47 AM, Adrian Chadd <[email protected]> wrote:
> Those are some high values (eg from noise/spur somewhere) and the
> driver is deciding to program in -110. So the radio thinks its deaf.
That made me think... I have a second ath9k device, this time with an
AR9300 (note, this is 3x3 instead of 2x2). I have set it up with
similar settings as the AR9227 (= AP mode) and this is the result:
# cat /sys/kernel/debug/ieee80211/phy0/ath9k/dump_nfcal
Channel Noise Floor : -95
Chain | privNF | # Readings | NF Readings
0 -122 5 -122 -122 -121 -122 -121
1 -119 5 -119 -119 -119 -119 -119
2 -121 5 -121 -121 -120 -120 -121
The values on that AR9300 device seem to be much better.
While I was at it, here is the output from a third device (TP-Link
TL-WR1043ND), which uses an Atheros AR9100 MAC/BB Rev:7 AR2133 RF
Rev:a2
Please note that this device is "STA" mode, whereas all other devices
are in "AP" mode.
# cat /sys/kernel/debug/ieee80211/phy0/ath9k/dump_nfcal
Channel Noise Floor : -95
Chain | privNF | # Readings | NF Readings
0 -89 5 -89 -89 -88 -89 -89
1 -88 5 -88 -88 -88 -88 -88
2 -81 5 -81 -81 -80 -82 -82
> Hm, I think that explains a few other NICs behaving badly too....
I have found an OpenWrt ticket where users are describing similar
problems, but on an TP-Link TL-WR1043ND (AR9100 + AR2133) ([0]
Now here comes the interesting part: Only my device with the AR9227
shows bad performance. All other devices (including the AR9100 +
AR2133 based one, which also ready "bad values") are performing fine -
at least for me.
Regards,
Martin
[0] https://dev.openwrt.org/ticket/17582
Hi,
I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.)
can you log the noisefloor calibrated values before and after the
patch? I'd like to see how low it calibrrates to.
-a
On 22 July 2015 at 01:42, Martin Blumenstingl
<[email protected]> wrote:
> The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
> Using the same values in ath9k results in much better throughput for me.
>
> Before this patch I had a huge amount of packet loss (sometimes up to
> 40%) and the max transfer speed was somewhere around 5Mbit/s. With this
> patch applied I have zero packet loss and ten times the throughput.
> My device uses a AR9227 which is the PCI variant of the AR9287.
>
> [0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h
>
> Signed-off-by: Martin Blumenstingl <[email protected]>
> ---
> Patch has not changed, I am just CC'ing @linux-wireless (instead of
> @ath9k-devel only).
>
> drivers/net/wireless/ath/ath9k/ar9002_phy.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.h b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
> index 6314ae2..9d17a53 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9002_phy.h
> +++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
> @@ -610,8 +610,8 @@
> #define AR_PHY_CCA_MIN_GOOD_VAL_9271_2GHZ -127
> #define AR_PHY_CCA_MAX_GOOD_VAL_9271_2GHZ -116
>
> -#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -120
> +#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -112
> #define AR_PHY_CCA_MIN_GOOD_VAL_9287_2GHZ -127
> -#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ -110
> +#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ -97
>
> #endif
> --
> 2.4.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Adrian,
On Wed, Jul 29, 2015 at 10:49 AM, Martin Blumenstingl
<[email protected]> wrote:
> Sure, here they are: [0]
Was this data useful for you?
Let me know if you need more information.
Regards,
Martin
hiya,
for what it's worth - this looks okay to me. His noise floor looks
about as low as I'd expect on his plots.
-adrian
On 22 July 2015 at 01:42, Martin Blumenstingl
<[email protected]> wrote:
> The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
> Using the same values in ath9k results in much better throughput for me.
>
> Before this patch I had a huge amount of packet loss (sometimes up to
> 40%) and the max transfer speed was somewhere around 5Mbit/s. With this
> patch applied I have zero packet loss and ten times the throughput.
> My device uses a AR9227 which is the PCI variant of the AR9287.
>
> [0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h
>
> Signed-off-by: Martin Blumenstingl <[email protected]>
> ---
> Patch has not changed, I am just CC'ing @linux-wireless (instead of
> @ath9k-devel only).
>
> drivers/net/wireless/ath/ath9k/ar9002_phy.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.h b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
> index 6314ae2..9d17a53 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9002_phy.h
> +++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
> @@ -610,8 +610,8 @@
> #define AR_PHY_CCA_MIN_GOOD_VAL_9271_2GHZ -127
> #define AR_PHY_CCA_MAX_GOOD_VAL_9271_2GHZ -116
>
> -#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -120
> +#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -112
> #define AR_PHY_CCA_MIN_GOOD_VAL_9287_2GHZ -127
> -#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ -110
> +#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ -97
>
> #endif
> --
> 2.4.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Martin Blumenstingl <[email protected]> writes:
> The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
> Using the same values in ath9k results in much better throughput for me.
>
> Before this patch I had a huge amount of packet loss (sometimes up to
> 40%) and the max transfer speed was somewhere around 5Mbit/s. With this
> patch applied I have zero packet loss and ten times the throughput.
> My device uses a AR9227 which is the PCI variant of the AR9287.
>
> [0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h
>
> Signed-off-by: Martin Blumenstingl <[email protected]>
So what should I do with this patch? Is this good to apply?
Discussion here:
https://patchwork.kernel.org/patch/6841051/
--
Kalle Valo
from qca-wifi-1.2:
ar5416phy.h:#define AR_PHY_CCA_NOM_VAL_KIWI_2GHZ -120
ar5416phy.h:#define AR_PHY_CCA_MIN_GOOD_VAL_KIWI_2GHZ -127
ar5416phy.h:#define AR_PHY_CCA_MAX_GOOD_VAL_KIWI_2GHZ -110
.. and:
ar5416phy.h:#define AR_PHY_CCA_NOM_VAL_MERLIN_2GHZ -112
ar5416phy.h:#define AR_PHY_CCA_MIN_GOOD_VAL_MERLIN_2GHZ -127
ar5416phy.h:#define AR_PHY_CCA_MAX_GOOD_VAL_MERLIN_2GHZ -97
.. so although the reference driver has the lower values for AR9287,
the AR9280 values work better for him.
So, hm. I think I recall finding the same when I did the initial
AR9287 support and found the AR9280 ANI/CCA values behaved better. It
doesn't look like he has any noise spurs in the spectral scan output
in his NIC; it just looks like everything needs to be slightly higher
to deal with ambient noise.
I'm okay with including it but I'd like other feedback/testing from
AR9287/AR9227 users. I used the AR9287 in a laptop for about a year w/
the AR9280 values (running FreeBSD-HEAD) and it performed great.
-adrian
On 6 October 2015 at 07:16, Kalle Valo <[email protected]> wrote:
> Martin Blumenstingl <[email protected]> writes:
>
>> The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
>> Using the same values in ath9k results in much better throughput for me.
>>
>> Before this patch I had a huge amount of packet loss (sometimes up to
>> 40%) and the max transfer speed was somewhere around 5Mbit/s. With this
>> patch applied I have zero packet loss and ten times the throughput.
>> My device uses a AR9227 which is the PCI variant of the AR9287.
>>
>> [0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h
>>
>> Signed-off-by: Martin Blumenstingl <[email protected]>
>
> So what should I do with this patch? Is this good to apply?
>
> Discussion here:
>
> https://patchwork.kernel.org/patch/6841051/
>
> --
> Kalle Valo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips.
> Using the same values in ath9k results in much better throughput for me.
>
> Before this patch I had a huge amount of packet loss (sometimes up to
> 40%) and the max transfer speed was somewhere around 5Mbit/s. With this
> patch applied I have zero packet loss and ten times the throughput.
> My device uses a AR9227 which is the PCI variant of the AR9287.
>
> [0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h
>
> Signed-off-by: Martin Blumenstingl <[email protected]>
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
