[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[UsuarioAnonimo]

My primary conntection to the internet has been the Alfa AWUS036NHA 
wireless adapter which uses the Atheros AR9271 802.11n chipset. The 
applicable linux driver/module and firmware is ath9k_htc. Ever since 
the upgrade from linux kernel 4.3.x to 4.4.x the throughput of the 
adapter chipset has been severely affected making the adapter basically 
unusable.

It will still readily connect to a distant access point. But instead of 
previously giving me steady and reliable download throughput in the 
range of 1/3 Mb/sec to almost a full Mb/sec with no packet loss, now 
after a minute or two it will very quickly slow and stall down to 1 or 
2 kbs/sec and 100% packet loss. If I reconnect, sometimes I will get 
good throughput for another minute or two before it stalls to nothing 
again.

I know this is a software issue, not hardware, because I have other 
distros installed on the same computer or another computer with linux 
kernel 4.3.x installed and the wifi adapter works beautifully as before.

I also now strongly suspect that this is not firmware related, but 
kernel driver related, that there was a regression or bug introduced 
into one of the .ko driver modules (whether ath9k, ath9k_htc, or other) 
in kernel 4.4.x and it is still present in linux kernel 4.7.x (Arch and 
Manaro linux).

I am surprised this basic functionality in managed mode has persisted 
for so long without other people noticing it or addressing it. I've 
been banging my head up against a wall for 6 months now with failed 
workarounds. And finally have settled on using other wifi adapters that 
have much lower throughput than the Atheros chipset, but which I can 
work with to some degree.

If anybody is willing or able to address this, I would be happy to run 
any tests and send any log output to try to help solve this. Thank you 
for your attention.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160825/500968c1/attachment.htm 

[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[bruce m beach]

Hello

   Just mention that I'm using kernel 4.2.2, a 35 ft usb cable going
up a 20 ft pole
  into a parabolic trough, through a forest, across a river and through another
  forest to my access point about a mile away and normally get about 1.2 mbits/s
  The only problem I have is the USB overheats during the hot summer days
  and the usb link goes down.

  I have been working on the ar9271 firmware for 8 months now and that may
  have something to do with it, although I doubt it.

  Bruce

On 8/25/16, UsuarioAnonimo <usuarioanonimo322@gmail.com> wrote:
> My primary conntection to the internet has been the Alfa AWUS036NHA
> wireless adapter which uses the Atheros AR9271 802.11n chipset. The
> applicable linux driver/module and firmware is ath9k_htc. Ever since
> the upgrade from linux kernel 4.3.x to 4.4.x the throughput of the
> adapter chipset has been severely affected making the adapter basically
> unusable.
>
> It will still readily connect to a distant access point. But instead of
> previously giving me steady and reliable download throughput in the
> range of 1/3 Mb/sec to almost a full Mb/sec with no packet loss, now
> after a minute or two it will very quickly slow and stall down to 1 or
> 2 kbs/sec and 100% packet loss. If I reconnect, sometimes I will get
> good throughput for another minute or two before it stalls to nothing
> again.
>
> I know this is a software issue, not hardware, because I have other
> distros installed on the same computer or another computer with linux
> kernel 4.3.x installed and the wifi adapter works beautifully as before.
>
> I also now strongly suspect that this is not firmware related, but
> kernel driver related, that there was a regression or bug introduced
> into one of the .ko driver modules (whether ath9k, ath9k_htc, or other)
> in kernel 4.4.x and it is still present in linux kernel 4.7.x (Arch and
> Manaro linux).
>
> I am surprised this basic functionality in managed mode has persisted
> for so long without other people noticing it or addressing it. I've
> been banging my head up against a wall for 6 months now with failed
> workarounds. And finally have settled on using other wifi adapters that
> have much lower throughput than the Atheros chipset, but which I can
> work with to some degree.
>
> If anybody is willing or able to address this, I would be happy to run
> any tests and send any log output to try to help solve this. Thank you
> for your attention.
>
>
>

[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[bruce m beach]

> I'm starting to get concerned that it will never get fixed, especially since
> I can't seem to convince anybody that it's real or that it's a problem. I've
> got wireshark installed and I can watch the signal gum up quickly with
> malformed packages, dup awks, spurious retransmissions, and terminations, but
> I don't know how to translate that into identifying the problem in the
> driver/module.

I tried to boot linux-4.7.2 to try to see if I have the same problem but the
video is broken on samsung exynos (again) so I can't do anything until
the video is fixed, unless there is someway to backport 4.7.x or 4.4.x
to 4.2.2 ( anybody? ) Meanwile have you tried getting a really good wireless
link within the immediate vicinity of your wireless device? Have you tried
a different link with a completely different ap.

>  I am surprised this basic functionality in managed mode has persisted for so
>  long without other people noticing it or addressing it

This is the thing: If it is true then why are there no other reports of
this behaviour. None the less I wouldn't give up, these impossible things
usually get resolved and become history as long as you stick  to it.


Bruce

[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

Am 31.08.2016 um 05:52 schrieb bruce m beach:
>> I'm starting to get concerned that it will never get fixed, especially since
>> I can't seem to convince anybody that it's real or that it's a problem. I've
>> got wireshark installed and I can watch the signal gum up quickly with
>> malformed packages, dup awks, spurious retransmissions, and terminations, but
>> I don't know how to translate that into identifying the problem in the
>> driver/module.
> 
> I tried to boot linux-4.7.2 to try to see if I have the same problem but the
> video is broken on samsung exynos (again) so I can't do anything until
> the video is fixed, unless there is someway to backport 4.7.x or 4.4.x
> to 4.2.2 ( anybody? ) Meanwile have you tried getting a really good wireless
> link within the immediate vicinity of your wireless device? Have you tried
> a different link with a completely different ap.
> 
>>  I am surprised this basic functionality in managed mode has persisted for so
>>  long without other people noticing it or addressing it
> 
> This is the thing: If it is true then why are there no other reports of
> this behaviour. None the less I wouldn't give up, these impossible things
> usually get resolved and become history as long as you stick  to it.
> 
> 
> Bruce
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 

here are test results which i get with recent kernel:

uname -a
Linux ultralex 4.8.0-rc3-00201-gaf56ff2 #200 SMP Sun Aug 28 14:14:36
CEST 2016 x86_64 x86_64 x86_64 GNU/Linux


./tests zwerg.local
tcp from client to server
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
zwerg.local () port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.04      24.80
tcp from server to client
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
zwerg.local () port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.00      48.61
udp from client to server
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
zwerg.local () port 0 AF_INET : demo
Socket  Message  Elapsed      Messages
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

212992   65507   10.02        1062      0      55.57
212992           10.02        1062             55.57

two tcp tasts at same time. both directions
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
zwerg.local () port 0 AF_INET : demo
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
zwerg.local () port 0 AF_INET : demo
Interim result:   49.69 10^6bits/s over 5.001 seconds ending at
1472655100.562
Interim result:   50.81 10^6bits/s over 5.001 seconds ending at
1472655105.562
Interim result:    1.25 10^6bits/s over 19.644 seconds ending at
1472655115.205
Interim result:   25.92 10^6bits/s over 9.793 seconds ending at
1472655115.355
Interim result:    1.71 10^6bits/s over 5.059 seconds ending at
1472655120.264
Interim result:   50.22 10^6bits/s over 5.015 seconds ending at
1472655120.370
Interim result:    1.67 10^6bits/s over 5.036 seconds ending at
1472655125.300
Interim result:   49.50 10^6bits/s over 5.072 seconds ending at
1472655125.442
Interim result:    1.69 10^6bits/s over 5.036 seconds ending at
1472655130.336
Interim result:   50.05 10^6bits/s over 5.001 seconds ending at
1472655130.444


Since it is not my reference setup i can't absolute maximum, but what i
get in this busy network with 20HT is not bad - 50Mbit/s!

I would suggest to start with git bisect to track down actual source of
regression.


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160831/8dbd2ca4/attachment.pgp 

[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[bruce m beach]

Oleksij

 I managed to boot 4.7.2 and got on an AP.  The signal strange was around -67 db
 which about par for this connection. Download speed was about 290kb/s
a little bit
 slow but it is raining, so It seems that 4828I'm getting a mostly
normal connection. The only
 anonaly is
  1 retry : not so bad
  4828 of misc which is very unusual

These numbers are coming from /proc/net/wireless

Bruce

On 8/31/16, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 31.08.2016 um 05:52 schrieb bruce m beach:
>>> I'm starting to get concerned that it will never get fixed, especially
>>> since
>>> I can't seem to convince anybody that it's real or that it's a problem.
>>> I've
>>> got wireshark installed and I can watch the signal gum up quickly with
>>> malformed packages, dup awks, spurious retransmissions, and terminations,
>>> but
>>> I don't know how to translate that into identifying the problem in the
>>> driver/module.
>>
>> I tried to boot linux-4.7.2 to try to see if I have the same problem but
>> the
>> video is broken on samsung exynos (again) so I can't do anything until
>> the video is fixed, unless there is someway to backport 4.7.x or 4.4.x
>> to 4.2.2 ( anybody? ) Meanwile have you tried getting a really good
>> wireless
>> link within the immediate vicinity of your wireless device? Have you
>> tried
>> a different link with a completely different ap.
>>
>>>  I am surprised this basic functionality in managed mode has persisted
>>> for so
>>>  long without other people noticing it or addressing it
>>
>> This is the thing: If it is true then why are there no other reports of
>> this behaviour. None the less I wouldn't give up, these impossible things
>> usually get resolved and become history as long as you stick  to it.
>>
>>
>> Bruce
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
> here are test results which i get with recent kernel:
>
> uname -a
> Linux ultralex 4.8.0-rc3-00201-gaf56ff2 #200 SMP Sun Aug 28 14:14:36
> CEST 2016 x86_64 x86_64 x86_64 GNU/Linux
>
>
> ./tests zwerg.local
> tcp from client to server
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> zwerg.local () port 0 AF_INET : demo
> Recv   Send    Send
> Socket Socket  Message  Elapsed
> Size   Size    Size     Time     Throughput
> bytes  bytes   bytes    secs.    10^6bits/sec
>
>  87380  16384  16384    10.04      24.80
> tcp from server to client
> MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> zwerg.local () port 0 AF_INET : demo
> Recv   Send    Send
> Socket Socket  Message  Elapsed
> Size   Size    Size     Time     Throughput
> bytes  bytes   bytes    secs.    10^6bits/sec
>
>  87380  16384  16384    10.00      48.61
> udp from client to server
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> zwerg.local () port 0 AF_INET : demo
> Socket  Message  Elapsed      Messages
> Size    Size     Time         Okay Errors   Throughput
> bytes   bytes    secs            #      #   10^6bits/sec
>
> 212992   65507   10.02        1062      0      55.57
> 212992           10.02        1062             55.57
>
> two tcp tasts at same time. both directions
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> zwerg.local () port 0 AF_INET : demo
> MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> zwerg.local () port 0 AF_INET : demo
> Interim result:   49.69 10^6bits/s over 5.001 seconds ending at
> 1472655100.562
> Interim result:   50.81 10^6bits/s over 5.001 seconds ending at
> 1472655105.562
> Interim result:    1.25 10^6bits/s over 19.644 seconds ending at
> 1472655115.205
> Interim result:   25.92 10^6bits/s over 9.793 seconds ending at
> 1472655115.355
> Interim result:    1.71 10^6bits/s over 5.059 seconds ending at
> 1472655120.264
> Interim result:   50.22 10^6bits/s over 5.015 seconds ending at
> 1472655120.370
> Interim result:    1.67 10^6bits/s over 5.036 seconds ending at
> 1472655125.300
> Interim result:   49.50 10^6bits/s over 5.072 seconds ending at
> 1472655125.442
> Interim result:    1.69 10^6bits/s over 5.036 seconds ending at
> 1472655130.336
> Interim result:   50.05 10^6bits/s over 5.001 seconds ending at
> 1472655130.444
>
>
> Since it is not my reference setup i can't absolute maximum, but what i
> get in this busy network with 20HT is not bad - 50Mbit/s!
>
> I would suggest to start with git bisect to track down actual source of
> regression.
>
>
> --
> Regards,
> Oleksij
>
>

[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[bruce m beach]

No. I've been online for ahtc_9271 hour or so and everything
seems to be fine.  I downloaded a 329Mbyte file and a
169Mbyte file, got on IRC talked for a While and so on.

As for firmware I am using a personal tree but all of
changes over the last 8 months always ended with a

     cmp htc_9271  htc_9271.reference

with no differences. I.e. I'm not actually changing how it works.

As far as I know the firmware has been static for a year or
so, so you shouldn't worry about it. It really sounds like
you have some strange anomally with your OS. As I say the
only thing that is strange is the very high miscellaneous
errors which is currently 14975.

For ifconfig I have:
 RX packets:373883 errors:0 dropped:15 overruns:0 frame:0
 TX packets:217048 errors:0 dropped:0 overruns:0 carrier:0
  RX bytes:562,229,747  TX bytes:19,932,871

[ath9k-devel] ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

To initial report.

Please test latest linux master branch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

no body will investigate old and probably fixed bugs. (except of
companies which get paid for this.)


Am 01.09.2016 um 06:42 schrieb bruce m beach:
> No. I've been online for ahtc_9271 hour or so and everything
> seems to be fine.  I downloaded a 329Mbyte file and a
> 169Mbyte file, got on IRC talked for a While and so on.
> 
> As for firmware I am using a personal tree but all of
> changes over the last 8 months always ended with a
> 
>      cmp htc_9271  htc_9271.reference
> 
> with no differences. I.e. I'm not actually changing how it works.
> 
> As far as I know the firmware has been static for a year or
> so, so you shouldn't worry about it. It really sounds like
> you have some strange anomally with your OS. As I say the
> only thing that is strange is the very high miscellaneous
> errors which is currently 14975.
> 
> For ifconfig I have:
>  RX packets:373883 errors:0 dropped:15 overruns:0 frame:0
>  TX packets:217048 errors:0 dropped:0 overruns:0 carrier:0
>   RX bytes:562,229,747  TX bytes:19,932,871
> _______________________________________________


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160901/5d0c44b1/attachment-0001.pgp