From: Ben Greear <greearb@candelatech.com>
To: ath10k <ath10k@lists.infradead.org>
Subject: Latest ath10k performance stats
Date: Tue, 24 Jun 2014 11:04:58 -0700 [thread overview]
Message-ID: <53A9BDCA.8080000@candelatech.com> (raw)
Using CT firmware, E5 3.7Ghz hex-core station system, slightly slower AP system,
kernel is hacked 3.14.7+.
AP is NOT configured for software-crypt, but station machine is.
Systems are connected with 3 meter high quality COAX SMA cables + 30dB fixed attenuator,
but this is not a fully isolated environment. Running on channel 149, HT80.
UDP connections are configured with 2MB send + receive socket buffers, 1500 MTU sized packets.
AP is acting as router (and running ath10k, etc).
TCP is configured for 10 streams, default OS send/receive buffer management.
Station machine sends to/from eth1 and station, ie it is both ends
of the connection. UDP transmit is tuned to be just above what system
can handle. If you send at full 1Gbps, total received throughput is
around 20% slower.
The rates reported are 'goodput' for the protocol in question.
WPA2 (station RX uses software encryption, so CPU bound)
UDP Download: 530 Mbps
UDP Upload: 610 Mbps
TCP Download: 459 Mbps
TCP Upload: 570 Mbps
Open Authentication
UDP Download: 830 Mbps **
UDP Upload: 615 Mbps
TCP Download: 660 Mbps (400+ ms latency, one way, by the way)
TCP Upload: 570 Mbps
** We currently ignore checksum errors, part of what it takes to make
rx-software-crypt work. But, on high-speed UDP download (Open Auth) we see a fair
bit of what must be legit checksum errors, and our traffic generator sees
corrupted data streams and restarts itself. So throughput is not even.
Will work on fixing this in our kernel, should be able to pay attention to
csum errors IF packet is not encrypted.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
reply other threads:[~2014-06-24 18:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=53A9BDCA.8080000@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.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.