From: Oleksij Rempel <linux@rempel-privat.de>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] ath9k_htc kernel driver regression affecting throughput
Date: Wed, 31 Aug 2016 17:02:58 +0200 [thread overview]
Message-ID: <c647d1de-0852-3a7e-802b-723f454b4a53@rempel-privat.de> (raw)
In-Reply-To: <CAArymCmbBtr+q4vf9CDCT7M3nBmryRHr3LOKmiJ9PN-0V7-1Tw@mail.gmail.com>
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
next prev parent reply other threads:[~2016-08-31 15:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-25 19:27 [ath9k-devel] ath9k_htc kernel driver regression affecting throughput UsuarioAnonimo
2016-08-26 2:40 ` bruce m beach
[not found] ` <1472596968.4898.0@smtp.gmail.com>
2016-08-31 3:52 ` bruce m beach
2016-08-31 15:02 ` Oleksij Rempel [this message]
2016-09-01 4:01 ` bruce m beach
[not found] ` <1472703117.4656.0@smtp.gmail.com>
2016-09-01 4:42 ` bruce m beach
2016-09-01 7:21 ` Oleksij Rempel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c647d1de-0852-3a7e-802b-723f454b4a53@rempel-privat.de \
--to=linux@rempel-privat.de \
--cc=ath9k-devel@lists.ath9k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.